SPF, DKIM and DMARC for cold email, in plain words

SPF, DKIM and DMARC are three DNS records that let a receiving mail server check that a message claiming to come from your domain really did. For cold email they are not optional: Gmail, Yahoo and Outlook.com require them of large senders, and a domain that fails them starts every message at a disadvantage.

The examples below use example.com and assume the domain sends only through Google Workspace, which is the usual setup for a cold-email sending domain.

The three records in plain words

SPF

SPF (Sender Policy Framework, RFC 7208) is a list of the servers allowed to send mail for your domain. The receiver takes the domain from the envelope sender (the Return-Path address, which readers rarely see) and checks whether the server that delivered the message is on that domain's list.

For a domain that sends only through Google Workspace, Google's SPF setup page gives this record:

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

include:_spf.google.com brings in Google's sending servers. ~all marks everything else as a soft fail, which is the option Google recommends.

DKIM

DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to each message. You publish a public key in DNS, the sending server signs with the matching private key, and the receiver checks the signature against your key. A valid signature shows the message was signed for your domain and the signed parts were not altered on the way.

In Google Workspace you generate the key in the Google Admin console. Google's default selector is google, so the record goes at google._domainkey (Google's DKIM setup page):

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

The p= value is the public key, shortened here. Google requires a key of 1024 bits or longer for mail to personal Gmail accounts, and recommends 2048 bits if your DNS host supports it (Google's sender guidelines).

DMARC

DMARC connects the other two to the address your recipient actually sees. It asks whether SPF or DKIM passed for the same domain as the From address. It also tells receivers what you want done with mail that fails, and where to send reports. The current specification is RFC 9989, which replaced RFC 7489 in May 2026; records still begin with v=DMARC1.

A sensible starting record:

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

• v=DMARC1 identifies the record and must come first.
• p=none asks receivers to take no special action on mail that fails, only to report it. It is the minimum policy Gmail, Yahoo and Outlook.com accept from bulk senders.
• rua= is where aggregate reports go. Use a mailbox someone reads, or a DMARC reporting service.

Once the reports show that only your own mail uses the domain, and it passes, you can tighten the policy to p=quarantine or p=reject.

Alignment in plain terms

SPF and DKIM can both pass for a domain your recipient never sees. Alignment is the check that the domain that passed is the domain in the From address.

• SPF aligns when the envelope sender's domain matches the From domain.
• DKIM aligns when the d= domain in the signature matches the From domain.

DMARC passes when at least one of them passes and is aligned. By default the match is relaxed: mail.example.com and example.com count as aligned because they share an organizational domain. Strict mode (aspf=s or adkim=s) requires the domains to be identical (RFC 9989).

With Google Workspace, both normally align once set up: the envelope sender is your own address, and DKIM signs as your domain once your key is published and turned on. Without your own key, messages go out unsigned or signed for a Google domain rather than yours. Either way DKIM does not align, and DMARC rests on SPF alone.

Common mistakes

Two SPF records

A domain should have exactly one SPF record. Two TXT records that both start with v=spf1, often one left by the registrar and one you added, make the SPF check return a permanent error instead of a pass (RFC 7208, sections 3.2 and 4.5). Merge them into a single record.

More than 10 DNS lookups

Each include, a, mx, ptr and exists mechanism, and the redirect modifier, costs a DNS lookup, and so does anything nested inside an include. RFC 7208, section 4.6.4 caps the total at 10; past that, SPF returns a permanent error. This usually happens when every tool you have ever tried gets its own include. A sequencer that sends through your connected Google inbox still sends from Google's servers, so it does not need an include of its own.

DKIM published but not turned on

In Google Workspace, adding the TXT record is only half the job. You also go back to the Google Admin console and start authentication for the domain. Google notes it can take up to 48 hours for DKIM to start working (Google's DKIM setup page). Until then, your messages are not signed with your domain's key. Also watch for DNS hosts that cut long keys short: if yours cannot hold a 2048-bit key, Google offers a 1024-bit one.

DMARC typos and misplaced records

DMARC is unforgiving about small errors:

• The record belongs at _dmarc.example.com, not at example.com.
• v=DMARC1 must be the first tag, spelled exactly that way. If it is not first, or the value is wrong, receivers ignore the whole record (RFC 9989, section 4.7).
• A misspelled value such as p=quarantin is a syntax error. Receivers discard it, so you end up with a weaker policy than you meant, or with no DMARC processing at all.
• rua= needs the mailto: prefix in front of the address.
• Publish one record only. If a receiver finds more than one DMARC record at the same name, it discards them all.

How to check them

From a terminal:

dig +short MX example.com
dig +short TXT example.com
dig +short TXT google._domainkey.example.com
dig +short TXT _dmarc.example.com

What to look for:

Google's Check MX tool, part of the Google Admin Toolbox, runs similar checks on a Google Workspace domain from a browser.

DNS tells you what is published. To see what a receiver actually concluded, send a message to a mailbox you control and open its full headers (in Gmail, "Show original"). In the Authentication-Results header, look for spf=pass, dkim=pass and dmarc=pass, and check that the DKIM result names your domain rather than someone else's.

For InboxesNow domains, the inbox placement record shows, before you buy, whether SPF, DKIM and DMARC passed on each day's test messages, as recorded at the seed inboxes.

What the big mailbox providers require of bulk senders

Each provider publishes rules for senders above a certain volume. Sources: Google's email sender guidelines and sender requirements FAQ, Yahoo's Sender Hub best practices and FAQ, and Microsoft's announcement for high-volume senders to Outlook.com.

Microsoft's requirements took effect in May 2025. Microsoft says mail that does not comply can be sent to Junk or rejected.

A single cold-email domain may never reach these volumes, but treat the bulk-sender list as your baseline anyway. Gmail asks every sender for SPF or DKIM. Google counts volume across a primary domain, and a sender that crosses the line once is treated as a bulk sender from then on.

What InboxesNow sets up

Before a domain goes on sale, InboxesNow configures its MX, SPF, DKIM and DMARC records, plus a custom tracking domain for Instantly, which is a CNAME record. The cold email infrastructure page shows what that looks like.

Once you have connected the inboxes to your sequencer, run the checks above once anyway.

Quick checklist

• One SPF record, such as v=spf1 include:_spf.google.com ~all, under 10 lookups.
• A DKIM key at google._domainkey, with authentication started in the Google Admin console.
• One DMARC record at _dmarc, starting v=DMARC1, with p=none or stricter and a rua address someone reads.
• A test message shows spf=pass, dkim=pass for your domain, and dmarc=pass.
• Then build reputation gradually: see how inbox warm-up works.