Drip SMTP Settings and Configuration (2026)

People searching “Drip SMTP settings” want one of three things: to stop the via drip.com byline in Gmail, to fix a failing DKIM or DMARC check, or to send receipts and password resets from their own app. The first two are the Custom Sending Domain setup below. The third needs a second provider beside Drip-Postmark, Amazon SES, Resend, MailerSend and SMTP2GO all publish real relays. Switching marketing platforms rarely fixes it: Klaviyo, ActiveCampaign, Omnisend and Customer.io take comparable positions on transport.

Quick reference

Why Drip has no SMTP relay

Drip is an ecommerce CRM, not email infrastructure. Its product is the decisioning layer, segments, workflows, abandoned-cart and post-purchase automations built on Shopify, WooCommerce and BigCommerce data, and the transport underneath is an implementation detail it keeps to itself. Every send originates from a Drip-owned object, which is what lets Drip enforce opt-in status, unsubscribe handling and revenue attribution on every message. An open relay would let arbitrary mail bypass all of that and put unvetted traffic onto shared IP pools. It is also why Drip can say it does not cap volume: uncapped is only safe when the platform controls what leaves.

The absence is structural, and worth naming because Drip has no page saying “we do not offer SMTP”. The API reference enumerates roughly 18 resource families. Subscribers, Tags, Events, Broadcasts, Campaigns, Workflows, Metrics, Webhooks and the Shopper Activity trio among them, with no SMTP credential resource and no raw-message endpoint. The Email Setup article covers only From-address verification, Custom Sending Domains and DMARC, and Drip’s guidance for custom order systems points at the Batch API, never at a mail transport.

What you actually need instead

Sending transactional email

Receipts, shipping notices and password resets go out regardless of marketing opt-in, and Drip draws that line itself: its help centre defines transactional mail as messages facilitating an agreed-upon transaction, distinct from the marketing email it governs. Drip neither sends that category nor resells a service that does. Postmark is the usual pick when transactional latency and deliverability are the only criteria, Amazon SES when volume economics dominate, Resend or MailerSend for a modern API with templating, SendGrid or Mailgun when one vendor should cover both at scale.

Connecting a CMS or app

Getting customers, orders and behaviour into Drip so automations fire is an API job. Prebuilt connectors exist for Shopify, WooCommerce, BigCommerce and Magento. For a custom or headless storefront, push people to POST /v2/:account_id/subscribers, behaviour to /v2/:account_id/events, commerce data to /v3/:account_id/shopper_activity/. Auth is HTTP Basic with your API token as username and an empty password, plus the descriptive User-Agent header Drip requires on every request.

Routing notifications

Internal alerts, a high-value order, a form needing a human, a churn-risk flag, are the third reason people look for a relay. Drip’s answer is outbound: register a webhook at POST /v2/:account_id/webhooks, receive the event in near real time, and let your own system or a relay deliver it. Drip’s Zapier connector exposes 16 triggers and 7 actions if you would rather not host the receiver.

Sending domain authentication

This is the real answer to “Drip SMTP settings”, in two layers people conflate. Layer one is verifying the From address, mandatory on every account. Layer two is the Custom Sending Domain: free, optional on paper, required in practice, it removes the via drip.com byline, authenticates with DKIM, and moves you onto a separate IP pool for authenticated sending.

SPF and DKIM setup

Start at Settings › Email Setup › Basic Email Settings and add your custom email address. Drip sends a confirmation that must be actioned within 30 minutes, clicked while signed in as owner, admin or contributor, and only domain-matched business addresses qualify. Then generate the Custom Sending Domain records at your DNS provider. Drip publishes the host names and types but not the targets: those are per-account and shown only inside Drip.

; Drip Custom Sending Domain, three records, generated per account.
; Targets are shown in Drip at Settings › Email Setup. Drip publishes
; no static target, do not copy one from a third party.

Host            Type   Value
drip            CNAME  <shown in your Drip account>
s1._domainkey   CNAME  <shown in your Drip account>
s2._domainkey   CNAME  <shown in your Drip account>

; Registrar fallbacks documented by Drip, if a type is refused:
;   drip           → add as an MX record (not a second CNAME)
;   s1._domainkey  → TXT
;   s2._domainkey  → TXT

; DMARC, Drip's published starter value
_dmarc          TXT    v=DMARC1; p=none;

; Propagation: allow 24 to 48 hours before assuming failure.

One thing is deliberately missing: there is no SPF include: mechanism, because Drip publishes none. DKIM is delegated by CNAME and the return path rides the drip. subdomain, so the bounce domain resolves through Drip’s delegated records rather than an edit to your root SPF TXT. Third-party Drip SPF strings are unofficial: pasting one in burns a lookup and can break authentication that already works.

DMARC alignment

Drip requires DMARC and, unusually, publishes an exact starter value: host _dmarc, type TXT, value v=DMARC1; p=none;. Its guidance is to start lenient and tighten as the domain establishes reputation, so move to p=quarantine then p=reject only once aggregate reports are clean. The requirement became real on February 1, 2024, when the Gmail and Yahoo bulk-sender rules took effect.

Alignment is relaxed by default on both mechanisms: the DKIM d= field only has to match the organisational domain of the From address, so signing as drip.example.com aligns with a From address at example.com. A correctly installed Custom Sending Domain therefore passes DMARC untuned, failures almost always trace to a missing or half-propagated record, or a second platform sending as the same domain without its own authentication.

Sending limits

Drip publishes no sending ceiling. Its deliverability guide states it does not cap sends, and the pricing page advertises unlimited email on paid plans from $39/month for 1-2,500 contacts. Billing scales on active people plus monthly volume, so unlimited means no hard throttle, not no cost. The limits that bite are on the API side, in two pools counted independently.

Recipients per message, maximum message size and an API request timeout are not published anywhere official. Treat third-party figures for those as unverified.

Common mistakes

Pairing Drip with an SMTP provider

Recommended setup

Split by message class, not by system of record. Drip owns marketing and lifecycle mail: anything triggered by a segment, workflow, broadcast or ecommerce event, governed by opt-in status. The relay owns application mail: receipts, shipping notices, password resets, invoices. Wire your storefront to push orders into Drip through the Shopper Activity API for automation and attribution, and independently to call the relay for the confirmation. The two paths never touch, which is the point, a Drip outage should not stop receipts.

On DNS, run the transactional provider on its own subdomain rather than the root: notify.example.com for the relay, Drip on its drip.example.com return path. That keeps the two reputations separate while both still align to the same organisational domain, so one _dmarc policy at the root covers both.

Keeping the two systems from colliding

Three conflicts are worth designing out. First, DKIM selectors: Drip hard-claims s1._domainkey and s2._domainkey, so pick a relay whose selectors are configurable or distinct, and confirm before cutover. Second, SPF lookup budget: SPF permits 10 DNS lookups per evaluation, and stacking includes from several vendors is the classic way to fail authentication everywhere at once. Drip adds no include of its own, but a relay plus a helpdesk plus a billing tool gets you there quickly.

Third, double sending. Storefront, Drip and relay can all emit a confirmation for the same order, and customers notice. Pick one owner per message type and disable the others explicitly: usually the storefront or relay sends the receipt, Drip sends only the post-purchase sequence. Before tightening DMARC to p=quarantine or p=reject, verify both senders in aggregate reports, changing policy while one is unauthenticated silently drops half your mail.

Frequently asked questions