SPF, DKIM and DMARC for cold email: practical setup

For every domain you send cold email from, publish one SPF record that lists your sending sources, enable DKIM signing with a key under that same domain, and add a DMARC record that starts at p=none with a reporting address. Then send a test message and confirm that spf, dkim and dmarc all pass with the From domain aligned. Authentication does not guarantee inbox placement; it removes a reason to be rejected.

This is the working setup, not the theory. Each section gives the record, a provider note and a way to check it.

What each record does

Who requires them: Google asks all senders for SPF or DKIM and bulk senders for all three; Yahoo asks for SPF or DKIM from everyone and all three from bulk senders; Microsoft requires SPF, DKIM and DMARC (at least p=none) from domains sending more than 5,000 emails a day. Bulk thresholds differ by provider, as covered in cold email deliverability. Set up all three on every sending domain regardless of volume.

Step 1: SPF

SPF is a TXT record that lists the sources allowed to send for the domain. Examples below use example.com.

; Google Workspace only
example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

; Microsoft 365 only
example.com.  TXT  "v=spf1 include:spf.protection.outlook.com -all"

; Microsoft 365 plus one other service that documents its own include
example.com.  TXT  "v=spf1 include:spf.protection.outlook.com include:send.provider.example -all"

Rules that cause most failures:

• One record per domain. RFC 7208 forbids multiple records that would both be selected. Microsoft documents that multiple SPF TXT records cause permerror. If you add a second sending service, add its include: to the existing record instead of creating another.
• At most 10 DNS lookups. include, a, mx, exists and redirect each count, and nested includes count too. Individual ip4 and ip6 values do not. Over 10 returns permerror (RFC 7208, Microsoft’s SPF guide).
• -all or ~all. Google’s Workspace guide recommends ~all. Microsoft recommends -all when DKIM and DMARC are also configured, and notes that DMARC policy is effectively ignored for ~all failures if the message has no DKIM signature. Pick one and be consistent; either way, DKIM does the real work for DMARC.
• Each subdomain needs its own record. The record for example.com does not cover mail.example.com.
• Typos. Microsoft lists a trailing dot, include= instead of include: and a space after the colon as common syntax errors.

Step 2: DKIM

DKIM signs outgoing mail with a private key; receivers fetch the public key from DNS.

; Public key published as TXT under a selector you choose
s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

; Microsoft 365 uses two CNAME records instead
selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.<tenant>.<region>.dkim.mail.microsoft.
selector2._domainkey.example.com.  CNAME  selector2-example-com._domainkey.<tenant>.<region>.dkim.mail.microsoft.

(The Microsoft CNAME targets are shown in a generic form; use the exact values that the Defender portal gives you.)

Practical points:

• Key length. RFC 6376 says signers must use RSA keys of at least 1024 bits. Yahoo asks for a minimum of 1024 bits. Google’s admin guide recommends 2048 bits if your DNS host supports them. Use 2048 where you can.
• Selector. Google Workspace defaults to a selector named google. Microsoft uses selector1 and selector2. A platform that signs for you will tell you which selector to publish.
• Order of operations in Google Workspace. Add the TXT record first, then start authentication in the Admin console. Google says it can take up to 48 hours for DKIM authentication to start working.
• Sign with your own domain. The d= domain in the signature must align with your From domain, or DKIM passes without helping DMARC. See the alignment section.

Step 3: DMARC

; Start here
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

; Later, once every legitimate source passes
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com"

• Prerequisites. SPF and DKIM first. Google says to allow 48 hours after setting them up before setting up DMARC.
• Policy values. none takes no action and is for monitoring, quarantine asks receivers to treat failures as suspicious, reject asks them to refuse the message (RFC 7489; Microsoft’s DMARC guide).
• Reports. rua receives aggregate reports. Use a dedicated mailbox or a reporting service, not a personal inbox, because the volume can be high. An external reporting address needs an authorisation record on the receiving domain (Microsoft’s DMARC guide gives the format).
• Rollout. Both Google and Microsoft recommend starting at p=none and tightening gradually. Microsoft describes moving to quarantine, using pct to raise coverage step by step, then to reject.
• Cold sending domains. A domain that only sends your outreach has few legitimate sources, so moving to quarantine or reject can be quick. That is a choice, not a requirement; the minimum accepted by Google, Yahoo and Microsoft for bulk senders is p=none.
• Subdomains. A DMARC record applies to subdomains without their own record. Each subdomain still needs its own SPF and DKIM.

Alignment: why DMARC fails when SPF and DKIM pass

DMARC passes if either SPF or DKIM passes and aligns with the domain in the visible From address. Alignment is relaxed by default: the organisational domain must match, so a subdomain can align with its parent. Strict alignment requires an exact match.

The third row is the usual cold-email failure: a sending service signs and uses its own domain for the envelope, so SPF and DKIM both pass for the service’s domain and DMARC fails for yours. The fix is to have the service sign with d=example.com (custom DKIM), or to use your domain in the envelope address. Google states the same requirement for bulk senders: the From domain must align with the SPF domain or the DKIM domain.

Test before you send

1. Send a message from the new mailbox to an address you control at Gmail and at Outlook.
2. Open the original message and find Authentication-Results.
3. Confirm spf=pass, dkim=pass and dmarc=pass, and that header.from is your sending domain.
4. If DMARC fails, compare smtp.mailfrom and header.d with header.from; at least one of them should be your domain.
5. After the first week, read the aggregate reports for sources you did not expect.

Checklist

• One SPF record, fewer than 10 lookups, no typos.
• DKIM key published and a test message shows a pass with your domain in d=.
• DMARC at _dmarc with rua to a mailbox you actually read.
• Each sending subdomain has its own SPF and DKIM.
• A parked domain you do not send from can say so: v=spf1 -all and a DMARC record with p=reject (Microsoft’s guidance).
• Re-check the records after any provider or platform change.

How Dooxout handles this

Dooxout provisions sending domains and mailboxes. The preflight check before a campaign launch looks at the SPF, DKIM and DMARC records, the verified sending identity and the suppression list. You can also connect your own mailboxes and sending services; then the records are yours to publish, and the platform warns when something looks wrong and leaves the decision to you.

Authentication is one part of the picture. Dooxout also applies caps, a kill switch and a suppression list that cannot be disabled. See cold email infrastructure and email deliverability.