Drip SPF, DKIM and DMARC setup, step by step

Authenticate Drip through Settings → Email Setup → Sending Domain, using the CNAME names and targets generated for your account. Publish the entire displayed set, complete Drip's verification, and check a real message for aligned DKIM and DMARC pass. Do not add a guessed SPF include at your root domain: the SPF identity that matters is the actual envelope sender used by Drip.

Scope and preparation

This guide covers email sent by Drip's marketing platform with a custom sending domain. It does not configure employee mailbox delivery, SMS, or a website's unrelated SMTP plugin. Drip's current account setup instructions require customers to validate a custom sending domain and associate it with a compliant DMARC policy. This is not merely an optional way to remove a service label from the From display. Drip account setup.

Have an authorized Drip user who can access Email Setup and an administrator who can edit the authoritative DNS zone participate. The reviewed setup article does not establish a separate paid-plan requirement or an exhaustive permission matrix for this screen. If the control is unavailable, have the account owner check permissions with Drip rather than treating a missing button as a DNS failure.

Record the account, proposed domain, visible From addresses, campaign/workflow names and DNS host. Export existing records before changing anything. Identify which team owns SPF and DMARC, and arrange a small controlled send to a mailbox you can inspect. Include existing scheduled workflows in the plan: switching a sending identity is not just a one-off broadcast edit.

If Microsoft 365 also sends ordinary business email for the organization, preserve that separate configuration. Authenticating Drip does not authenticate employee mailboxes, or vice versa.

Get the account-generated DNS records

Open Settings → Email Setup → Sending Domain. The detailed setup instructions call the control Change Sending Domain; the account-setup screenshot instead shows Add New Sending Domain beneath existing verified domains. Use the action appropriate to adding or changing the approved domain in your account, not an unrelated account-setting change. Enter the intended custom domain and continue with Next. Copy every CNAME owner and destination Drip displays. After publication, return and select I've added these records so Drip performs its check. Cloudflare users must keep these records DNS-only, not proxied. Drip custom sending domains.

Drip documents a standard three-CNAME set with drip, s1._domainkey and s2._domainkey owner labels. Treat those as the standard pattern, not authority to reuse a target or override a support-generated custom set. Allow the documented 24–48 hours for DNS visibility. Save that set with the domain and account identifier in your change ticket, without passwords or API tokens.

In Email Setup → Basic Email Settings, also check the default From address. Drip requires From addresses to be verified before campaigns use them. A mailbox confirmation and DNS authentication are separate checks: complete both. The campaign From domain must match the verified domain. Review individual message overrides rather than assuming every workflow inherits the new default. Drip basic email settings.

Publish CNAMEs without damaging other senders

For each generated row, use these field mappings:

For example, if the account supplies selector._domainkey.example.com and your editor automatically appends example.com, enter selector._domainkey as the relative host. This is a formatting illustration, not a Drip selector to publish. A fully qualified target must not accidentally become target.vendor.example.example.com because the editor appended your zone.

For a child signing domain, SELECTOR._domainkey.mail.example.com maps to relative SELECTOR._domainkey.mail in the parent example.com zone, or SELECTOR._domainkey in a separately delegated mail.example.com zone. If _domainkey.mail.example.com is delegated, its authoritative editor uses SELECTOR; if _domainkey.example.com is delegated for apex signing, that editor likewise uses SELECTOR. Preserve the valid NS delegation and publish with its authoritative administrator, not a shadow copy in the parent. This mapping is illustrative: keep Drip’s issued owners.

Compare the resulting public name, not just the text inside the editor. Follow your DNS host's rules for trailing dots; randomly adding punctuation can turn a relative name into a different absolute name.

A CNAME cannot coexist with ordinary TXT, A, AAAA, MX or another conflicting record at the same owner. Do not erase an existing selector used by another service. Record the collision, stop that row and ask Drip support for a supported alternative. Records at different selector names can coexist. DNS alias rules, RFC 1034.

If s1 or s2 conflicts, ask Drip support to generate Custom CNAME records. If the DNS host cannot support the required CNAME configuration, support can instead generate an MX/TXT set: its first record is MX and the next two are TXT. Publish that alternative only after support confirms generation, using its exact owners, values and MX priority guidance. Drip recommends MX priority 0 or 1 for this support-issued branch, but a generated packet is not routing approval. Before publication, have the routing owner approve the exact MX owner, destination and priority against the authorized mail-routing plan; preserve corporate inbound MX. Stop if the packet would change an unapproved route. Copy complete tagged TXT values without truncation, never private keys. A long DKIM value can use multiple character-strings inside one logical TXT record: concatenate them without inserting spaces; do not create separate independent TXT records for the fragments. DKIM TXT record syntax, RFC 6376 §3.6.2.2. The alternative screenshot shows an MX and a TXT at the same non-selector owner plus a separate DKIM TXT; this does not authorize a CNAME at either occupied owner. Do not convert the CNAME targets yourself. Multiple Drip accounts using the same domain require support linking; do not add competing record sets. Drip supported alternatives.

Keep Drip’s required literal CNAME answers visible. On Cloudflare use DNS only, turn per-record Flatten off when available, and ensure relevant whole-zone CNAME flattening for all CNAME records is off: it overrides per-record behavior. Coordinate affected services before changing that shared setting. Apex aliases flatten by default and same-zone targets flatten regardless of the setting. Do not move Drip’s owners to the apex, remove valid delegations or invent a switch. If mandatory behavior cannot preserve the issued literal CNAMEs, stop and agree a supported configuration with Drip and the DNS administrator. Cloudflare verification controls and flattening scope.

Understand SPF and DKIM

SPF checks SMTP MAIL FROM, usually reflected in the delivered Return-Path, or HELO in applicable cases such as a null reverse-path, not automatically visible From. The Drip workflow supplies CNAMEs; it does not document a universal customer-root SPF TXT include to paste into every domain. Install the displayed records, then observe which envelope identity the production route uses.

A provider-owned envelope can pass SPF without aligning to your visible From domain. Adding an authorization at example.com does not change an envelope using a different domain. If the account offers additional instructions for your particular route, assess those separately; do not infer support for strict SPF alignment from a successful domain verification.

Where you do manage an SPF TXT record, retain one v=spf1 policy per owner, preserve active senders and account for the ten DNS-lookup-causing-term limit, including nested includes. Preserve existing qualifiers and any intentional redirect= flow: an all mechanism anywhere in the policy causes redirect to be ignored, and mechanisms after all are not evaluated. Do not append a new all to a redirect-based policy without its owner’s review. Qualifiers express authentication results, not guaranteed delivery or rejection. SPF precedence. A second SPF record is not a safe way to add another sender. Unrelated verification TXT records are not duplicate SPF policies. SPF specification.

DKIM proves that the receiver can validate the signature against the public key associated with the signing domain and selector. A Drip CNAME can direct that lookup to provider-managed DNS. Do not replace it with a copied key unless the actual account explicitly changes its instructions. Public DNS alone does not prove that Drip signed a particular message. DKIM specification.

Keep your DMARC policy intact

Inspect _dmarc at the actual From domain and check any inherited parent policy before adding a record. Preserve existing enforcement, alignment settings and reporting destinations. A new local p=none record on a subdomain can weaken inherited protection; it is not a harmless setup default.

For a domain with no applicable established policy, a policy owner may approve a monitored starting record:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example domain and reporting address with approved real values. Establish the approved receiving mailbox or reporting service first. The apex example uses relative _dmarc in example.com. For _dmarc.mail.example.com, use _dmarc.mail in the parent example.com zone or _dmarc in a separately delegated mail.example.com zone, not under a delegated _domainkey. rua requests aggregate reporting; it is not a request for individual-message forensic reports. Do not assume every receiver sends reports.

If a report destination belongs to a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted: for policy domain example.com, a destination under reports.example.com is within that boundary, but example.net is not. DNS authorization does not replace the owner’s privacy/data-sharing approval. RFC 9990 section 4.

DMARC passes when either SPF or DKIM passes and aligns with the visible From domain. Relaxed alignment permits the same organizational domain; strict alignment requires exact domains. RFC 9989 replaced RFC 7489 and removed pct, so percentage-based enforcement is not a reliable staged rollout. Inventory and test legitimate senders before changing to quarantine or reject. Current DMARC standard.

Verify DNS and a delivered message

Use the real generated owners in place of these illustrative names:

dig CNAME GENERATED_OWNER.example.com +short
dig TXT SELECTOR._domainkey.SIGNING_DOMAIN +short
dig TXT ACTUAL_MAIL_FROM_DOMAIN +short
dig TXT _dmarc.ACTUAL_FROM_DOMAIN +short

The first result must match the corresponding account target. For DKIM, follow any CNAME chain until the key is available. Inspect the full DNS response if short output is empty: timeout, SERVFAIL and NXDOMAIN require different fixes. Query the authoritative service and an independent recursive resolver before blaming propagation. A provider green check is one checkpoint, not the final delivery test.

Next, send a representative message through the real Drip workflow to a controlled, valid, directly receiving mailbox using harmless test content. Open the complete source, not only the client summary. Use Authentication-Results created within the actual receiving service’s known processing boundary. Confirm its documented handling of externally supplied fields with the receiver’s administrator. A familiar authserv-id or header position alone cannot prove provenance; ignore untrusted or attacker-inserted results. Record:

• the visible From domain and intended address;
• spf result and smtp.mailfrom domain;
• dkim result, signing header.d and selector s=;
• dmarc=pass for the intended From domain;
• which passing identifier supplies alignment.

For this custom-domain rollout, require the intended Drip signature to pass and align with the intended branded visible From, plus trusted dmarc=pass. A pass via SPF alone does not prove DKIM activation. Do not accept a rewritten provider-owned From as brand-authentication success. As a fictional illustration, From sender@example.com with passing d=mail.example.com aligns only in relaxed mode when both share Organizational Domain example.com; passing d=example.com aligns in both relaxed and strict modes. Actual identities come from the account and message. Investigate SPF independently: fail calls for evaluating whether that connecting source is authorized at the observed envelope owner; permerror calls for policy syntax, duplicate SPF and evaluated lookup-budget checks; temperror calls for transient DNS/lookup investigation. These remain defects to diagnose even if DKIM supplies DMARC pass. A passing but unaligned SPF result is not itself a DNS defect. Keep the message timestamp, workflow and receiver with the results. Authentication-Results trust boundary.

For the distinction between a passing signature and the aligned result, see EmailAuth’s raw versus aligned DKIM results.

Troubleshooting

Drip cannot find the CNAMEs: Check the authoritative host, doubled suffixes, target spelling and proxy status. Confirm all rows belong to this account's current domain, not an abandoned setup attempt.

The DNS record exists but DKIM fails: Compare the message's actual s= and d= with the queried owner. An old selector can resolve perfectly while the new message uses a different one. Also check whether a relay modified signed content.

DMARC fails despite SPF pass: Compare the envelope domain with the visible From. Repair the custom-domain signing path instead of adding random includes to the root SPF record.

Some workflows pass and others fail: Inspect From overrides, address verification and the actual service used by each message. A website notification may not use Drip at all.

You need to remove the old domain: Stop its use in scheduled messages first and consult Drip's deliverability team before revoking the configuration. Preserve records needed by delayed messages until your migration owner approves removal.