SPF, DKIM and DMARC for Cold Email Setup

SPF, DKIM and DMARC for cold email are three DNS-based checks that decide whether a mailbox provider believes your message really comes from your domain. Get them wrong and your mail lands in spam or is rejected before anyone reads it. Get them right and you have the foundation every other deliverability step builds on.

What each record does in one sentence

SPF lists the servers allowed to send mail for your domain.
DKIM adds a cryptographic signature to each message so the receiver can detect tampering and confirm the signing domain.
DMARC tells receivers what to do when SPF and DKIM do not pass in alignment with your visible From address, and where to send reports.

The key word in the DMARC line is alignment. A message passes DMARC when SPF or DKIM passes and the domain it authenticated matches the domain in the From address. A pass on its own is not enough. This is the check that stops someone else spoofing your name, and it is the one cold senders most often miss.

Gmail and Yahoo now expect these records, as covered in our guide to the Gmail and Yahoo bulk sender requirements. This guide shows how to set them up.

SPF: one record per domain and the 10-lookup limit

SPF is a TXT record on your domain that names the servers allowed to send for it. RFC 7208 sets two rules that cause most failures.

One record only. If a domain publishes more than one SPF record, the check returns a permanent error. When you add a second provider, merge it into the existing record instead of creating another.

A limit of 10 lookups. The terms that trigger a DNS query are include, a, mx, ptr and exists, plus the redirect modifier. An SPF evaluation may use at most 10 of them, counting those nested inside included records. The all, ip4 and ip6 terms do not count. Exceed the limit and the result is a permanent error. The RFC also suggests limiting void lookups, queries that return nothing, to two.

A simple record for a domain that sends through Google Workspace looks like this:

v=spf1 include:_spf.google.com ~all

The ending sets how strictly to treat other servers: ~all is a soft fail and -all is a hard fail. Each include you add may bring its own nested lookups, so stacking a mailbox provider, a sending platform and a CRM can pass 10 quickly. Keep the record lean, and remove providers you no longer use.

DKIM: selector, key length and signing

DKIM works with a key pair. Your sending system signs outgoing messages with a private key, and you publish the matching public key in DNS. RFC 6376 describes how the signature carries two pointers: d= names the signing domain and s= names the selector. The receiver looks up the public key at the selector, then _domainkey, then the domain.

selector1._domainkey.example.com   TXT   v=DKIM1; k=rsa; p=(public key here)

The selector lets one domain publish several keys at once, which helps when you use more than one sending system or need to rotate keys.

Key length. The RFC says signers must use RSA keys of at least 1024 bits. Google requires 1024 bits or longer for bulk senders and recommends 2048 if your provider supports it. Choose 2048 where you can. Some DNS hosts need a long key split into several quoted strings, so paste the value exactly as your mail provider shows it.

Signing. The signature covers the body hash and the headers listed in the signature. If any covered part changes in transit, verification fails. For alignment, the d= domain should match your From domain. Many sending platforms sign with their own domain by default, which authenticates the message but fails DMARC alignment. Set up custom-domain signing so d= is your sending domain.

DMARC: p=none, quarantine, reject and alignment

DMARC is a TXT record published at _dmarc on the domain. RFC 7489 defines the policy tag p= with three values:

none: no specific action requested. Use this to monitor.
quarantine: treat failing mail as suspicious, for example by filing it as spam.
reject: refuse failing mail, preferably during the SMTP transaction.

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

The rua tag says where aggregate reports go. Without it you get no reports. The adkim and aspf tags set alignment to relaxed (the default, where the domains share the same organizational domain) or strict (an exact match). The pct tag applies the policy to a share of messages, which lets you roll out a stricter policy gradually. The sp tag sets a separate policy for subdomains; if omitted, p applies to them too.

For cold email, start at p=none with a reporting address. That meets the Gmail and Yahoo bulk-sender minimum. Once the reports show only your own systems passing, moving to quarantine or reject protects the domain from spoofing. That is a reasonable path, not a rule.

Setting this up on secondary sending domains

Cold senders usually send from secondary domains so that the main brand domain stays clear of any reputation damage. Each of those domains needs its own full setup: an SPF record, a DKIM key for each sending system, and a DMARC record. Do not assume the main domain's records cover them.

A workable order of operations:

Register the domain, and decide which mailbox provider and which sending platform will use it.
Publish one SPF record that includes only those systems.
Enable DKIM in the mailbox provider and in the sending platform, using custom-domain signing so the signing domain matches the From domain.
Publish DMARC at p=none with a reporting address.
Test the whole chain (next section) before sending anything.
Begin warm-up only once all three pass. Our domain warm-up guide covers the ramp.

Use domains clearly tied to your own brand rather than names that resemble someone else's. The M3AAWG cold email position defines lookalike domains as ones that resemble legitimate domains but are actually unrelated, and treats using them to avoid spam filters as deceptive.

How to test it before you send

Send a test message from each mailbox to a Gmail address you control.
Open the message, choose Show original, and read the SPF, DKIM and DMARC lines. All three should say PASS.
If DMARC fails while SPF or DKIM passes, the problem is alignment. Compare the domain that passed with the domain in the From address.
Look up the DNS records directly. Confirm exactly one SPF record, a DKIM key at the expected selector and a DMARC record at _dmarc.
Repeat for every new mailbox, not just the first one on a domain.

DNS changes can take a while to spread, so if a record looks right but the test fails, wait and test again before changing it. Keep a simple sheet with one row per sending domain: mailbox provider, sending platform, SPF includes, DKIM selectors and DMARC policy. Once you run several domains, that record saves hours of guessing which one drifted.

Passing authentication does not guarantee inbox placement. It removes one major reason for failure. Our inbox placement guide covers the rest of the stack.

Common mistakes

Two SPF records. A second record, added when a new tool is connected, turns the whole check into a permanent error. Merge them.
Too many lookups. Every include adds lookups. Past 10, SPF fails for every message. Remove unused providers.
Passing but not aligned. SPF and DKIM pass for the platform's domain while the From address uses yours, so DMARC fails.
DKIM forgotten on new mailboxes. A domain can be set up correctly while a newly added mailbox or sending tool is not signing.
No DMARC reporting address. Without a rua address you never see failures.
Jumping to reject too early. If a legitimate sending system is not yet aligned, a strict policy blocks your own mail.

How Realtrix handles setup

Realtrix registers, configures and authenticates sending domains, including SPF, DKIM, DMARC and custom tracking, as part of its done-for-you infrastructure. If you want that built for you, see the cold email infrastructure and automation setup service.

Frequently asked questions

Do I need DMARC for cold email?

Yes, in practice. Google requires DMARC from senders of more than 5,000 messages a day to Gmail, and Yahoo requires it from bulk senders, with a policy of none accepted. Below those volumes it is not mandatory, but Yahoo strongly urges every sender to publish a policy. It also gives you reports showing who is sending as your domain.

What does p=none do?

It tells receivers to take no specific action on mail that fails DMARC, so nothing is blocked or filed as spam because of the policy. You still get aggregate reports if you add a rua address. It meets the Gmail and Yahoo bulk-sender minimum and is the normal starting point before moving to quarantine or reject.

How many includes can an SPF record have?

The limit is not on includes alone but on lookups. An SPF check may trigger at most 10 DNS-querying terms: include, a, mx, ptr, exists and redirect all count, and includes nested inside other includes count too. The ip4, ip6 and all terms do not. Go over 10 and the result is a permanent error.

Do secondary domains need their own records?

Yes. Each domain you send from needs its own SPF, DKIM and DMARC setup, because receivers evaluate the domains in the message, not your main brand domain. A subdomain can inherit the DMARC policy of its parent domain, but SPF and DKIM must still be set up for the domain that actually sends.

How do I check my email authentication?

Send a test message to a Gmail account you control, open Show original, and look for SPF, DKIM and DMARC results. All three should say PASS. Then look up your DNS records directly to confirm there is exactly one SPF record, a DKIM key at the selector, and a DMARC record at _dmarc on the domain.

SPF, DKIM and DMARC for Cold Email: A Setup Guide