SPF, DKIM, and DMARC for Cold Email: The Setup That Actually Passes

To set up SPF, DKIM, and DMARC for cold email, publish exactly one SPF record on each sending domain, enable DKIM inside the tool that actually sends the mail, and add a DMARC record at _dmarc.yourdomain.com starting at p=none. The part that decides whether it works is alignment, not whether the three records exist. Almost every broken cold email setup we open has all three records present. A checker shows green. Mail still lands in spam or gets rejected outright. The reason is that SPF and DKIM authenticate domains the recipient never sees, and DMARC is the only mechanism that ties either of them back to the From line a human reads. If that link is missing, you have three valid records and zero authenticated mail. This post goes one layer below the basics. If you want the wider picture on domain architecture, warm-up, and spam recovery, read our guide to cold email deliverability in 2026 first. What follows is the DNS layer specifically, written for people sending outbound rather than running corporate IT.

What each record actually does

SPF is a TXT record on your domain listing which servers are allowed to use that domain in the envelope sender, the address technically called 5321.MailFrom and usually shown as Return-Path. A receiver takes the connecting IP, looks up your SPF record, walks the mechanisms left to right, and returns pass, fail, softfail, neutral, or permerror. Note what it checks: the envelope, which the recipient never sees.

DKIM works on the message itself. Your sending server hashes a set of headers plus the body, signs the hash with a private key, and attaches a DKIM-Signature header containing a selector and a d= domain. The receiver fetches the public key from selector._domainkey.yourdomain.com and recomputes. Because the signature travels with the message, DKIM survives forwarding. SPF usually does not, because forwarding changes the connecting IP.

DMARC is a TXT record at _dmarc.yourdomain.com that does two jobs. It tells receivers what to do when authentication fails, and it requests reports. Its real function is the one nobody puts on a checklist: it requires that a passing SPF or DKIM result belongs to the same domain as the visible From address. That requirement is called alignment, and it is where cold email setups break.

• SPF authenticates the envelope sender (Return-Path)
• DKIM authenticates the message via the d= domain in its signature
• DMARC binds one of those results to the header From address the recipient sees

Alignment: the rule that quietly fails everything

Every email has two From addresses. The header From (5322.From) is what the recipient reads. The envelope From (5321.MailFrom, or Return-Path) is where bounces go, and mail clients hide it. SPF alignment means the envelope domain matches the header From domain. DKIM alignment means the d= domain in the signature matches the header From domain. DMARC passes if at least one aligned mechanism passes.

Both alignment modes default to relaxed, per RFC 9989, the DMARC specification published in May 2026. Relaxed means the organizational domain has to match, so mail.outbound.com aligns with outbound.com. Strict (aspf=s, adkim=s) demands an exact hostname match. On a cold email domain, do not set strict. Many sending platforms use a subdomain for bounce handling, and strict alignment kills that while protecting you from nothing.

Here is the specific failure. Some sending platforms rewrite Return-Path to their own domain so they can process bounces centrally. SPF then evaluates and passes for their domain, not yours. If DKIM is either unconfigured or signing with the platform’s d= value, DMARC fails while a DNS checker cheerfully reports SPF pass and DKIM pass. A DNS checker cannot see alignment, because alignment only exists inside a delivered message.

The only reliable test is a live send. Mail a real campaign message to a Gmail account, open Show original, and read the three result lines. Next to SPF and DKIM, Gmail prints the domain each one authenticated. If those domains are not your sending domain, you are unaligned regardless of what your DNS looks like.

The 10-lookup SPF limit and why it breaks on its own

RFC 7208 states that SPF implementations MUST limit DNS-querying terms to 10 per evaluation. The terms that count are include, a, mx, ptr, exists, and the redirect modifier. The terms that cost nothing are all, ip4, ip6, and exp. The count is recursive, so every include nested inside another include counts against your total. Exceed 10 and evaluation returns permerror, which DMARC treats as an SPF failure, not a soft one.

The dangerous property of this limit is that you do not control it. Your record can sit at nine lookups for a year, then a provider adds one include inside their own nested record and you cross the line overnight. Nothing in your DNS changed. Mail simply starts failing. Treat anything above eight as already broken and fix it before it fails.

There is a second limit almost nobody checks. RFC 7208 says implementations SHOULD cap void lookups at two, where a void lookup is any query returning NXDOMAIN or no usable records. Exceeding it also produces permerror. The usual cause is stale includes for tools you stopped paying for. The same RFC also says of the ptr mechanism: “This mechanism SHOULD NOT be published.” If you have one, delete it.

To get under the limit, remove includes for platforms you no longer use and replace a or mx mechanisms with explicit ip4 entries where the IPs are static, since ip4 costs zero lookups. Flattening, meaning resolving every include down to raw IPs, works but moves the maintenance burden onto you. When your provider rotates IPs, your flattened record is wrong and every message fails SPF. Automate the refresh or do not flatten.

Why p=none is a starting position, not a finish line

p=none tells receivers to take no action on failures. Its value is the aggregate reports, which are the only view you will ever get of what is sending as your domain and whether it aligns. Publish it with a rua address you genuinely read, run it for two to four weeks while the domain warms, and use the reports to confirm that all of your legitimate volume is aligned via DKIM, not just SPF.

Be honest about what enforcement buys you on an outbound domain. Nobody is spoofing a three-month-old sending domain, so p=reject prevents an attack that is not happening. The reason to move anyway is diagnostic discipline: a domain parked on p=none for a year with a rua nobody opens is a domain where alignment has almost certainly drifted and no one noticed. Enforcement forces you to keep inventory accurate. Move p=none to p=quarantine to p=reject once reports show clean aligned DKIM.

RFC 9989 changed the mechanics of that ramp. The pct tag is removed, so the old p=reject with pct=10 staged rollout no longer applies. Use the new t=y tag to signal test mode instead. RFC 9989 also adds np, which sets a policy for non-existent subdomains, and that one is worth publishing because spoofing subdomains that were never provisioned is a standard technique.

One trap on reporting: if your rua address lives on a different domain than the one being reported on, the destination domain must publish an authorization record at yourdomain.com._report._dmarc.destination.com containing v=DMARC1. Without it, compliant reporters skip you entirely. Teams then read an empty inbox as proof that everything is healthy.

Per-domain versus per-inbox: what you can and cannot isolate

SPF and DMARC are strictly per-domain. There is one SPF record for the domain and one DMARC record at _dmarc, and neither can be scoped to an individual mailbox. DKIM is the only one of the three with room to move, because a domain can publish multiple selectors. That matters when Google Workspace and a cold email platform both send from the same domain: Workspace signs with its google._domainkey selector, the platform needs its own.

The consequence for infrastructure planning is direct. Ten inboxes on one domain is one reputation surface, one SPF record, one DMARC policy, and one spam-rate figure in Postmaster Tools. If one mailbox collects complaints, all ten carry the damage. Buying inboxes is not the same as buying isolation. Isolation comes from separate domains, which is why domain pool sizing matters more than mailbox count.

If you run outbound on a subdomain of a domain that also carries your brand mail, set the sp tag explicitly on the parent record. Subdomains inherit the parent policy by default, so a p=reject protecting your corporate domain will silently apply to an outbound subdomain whose DKIM is only half configured.

Finally, the sending domain needs MX records and a mailbox that actually receives. Bounces are delivered to the envelope domain. If it cannot accept mail, you lose your bounce signal, your replies vanish, and the domain reads as unmonitored. Microsoft’s sender guidance explicitly asks that From and Reply-To addresses be valid and able to receive replies.

What Google and Microsoft actually require in 2026

Per Google’s sender guidelines, every sender to Gmail, at any volume, must set up SPF or DKIM on the sending domain, have valid forward and reverse DNS (PTR) records for the sending IP, transmit over TLS, format messages to RFC 5322, and keep the spam rate reported in Postmaster Tools below 0.3%. Google’s stated recommendation is to stay under 0.10% and never reach 0.30%.

Bulk senders, defined by Google as 5,000 or more messages a day to Gmail addresses, carry additional requirements: both SPF and DKIM, a published DMARC record (p=none is acceptable), a From header aligned with either the SPF domain or the DKIM domain, and one-click unsubscribe support on marketing and subscribed messages using the List-Unsubscribe and List-Unsubscribe-Post headers.

Microsoft applied its own high-volume sender requirements from May 5, 2025, covering senders of 5,000 or more messages per day to outlook.com, hotmail.com, and live.com. Those senders need SPF, DKIM, and a valid DMARC record at minimum p=none, with DMARC passing via SPF and/or DKIM. Non-compliant mail was routed to Junk first, and Microsoft has since moved to rejection, returning 550 5.7.515 with the message that the sending domain does not meet the required authentication level.

Here is the nuance that trips outbound teams. Those 5,000-per-day thresholds are measured per sending domain, and a well-built cold email setup deliberately keeps per-domain volume far below that. It is tempting to conclude the bulk rules do not apply to you. Receivers do not run two separate filters. The threshold is the enforcement line, not the evaluation line, so build every domain to the bulk standard from day one.

The specific mistakes that break cold email setups

Most of what we find during an email deliverability audit is not exotic. It is the same eight or nine errors, and they are all cheap to fix once someone actually reads the records rather than trusting a green checkmark.

Work through this list against every sending domain you own, not just the one that is currently underperforming. Problems in this layer are usually copied across a whole domain pool at setup time, so a single bad template quietly breaks twenty domains at once.

• Two SPF records on one domain. RFC 7208 is explicit that selecting more than one record produces permerror. Merge every include into a single v=spf1 string.
• Using -all before you have a full sender inventory. Any legitimate system missing from the record gets hard-failed. Start at ~all with DMARC at p=none, then tighten once reports confirm what is sending.
• Truncated DKIM keys. DNS TXT character strings cap at 255 characters, so a 2048-bit key must be split into multiple quoted strings that concatenate. Some registrar interfaces cut instead of splitting. The record looks present and DKIM fails permanently.
• DKIM enabled in Google Workspace but not in the sending platform. The google._domainkey selector only signs mail routed through Google. Anything sent over SMTP by Smartlead or Instantly needs its own selector, or DKIM fails for every campaign message.
• DMARC published at the domain apex instead of _dmarc. The host must be _dmarc.yourdomain.com. A v=DMARC1 string on the root record does nothing at all.
• Copying an SPF record wholesale from another domain. Includes for platforms you never used resolve to nothing, which burns your two-void-lookup allowance before you send anything.
• Setting p=reject before confirming DKIM alignment. Forwarding through autoresponders and distribution lists breaks SPF alignment routinely. DKIM survives it. Enforce without aligned DKIM and you drop legitimate mail.
• A custom tracking domain on a bare CNAME with no HTTPS. It does not touch SPF, DKIM, or DMARC, but it is a strong filtering signal, and a tracking link resolving through a shared redirect host is worse than sending no tracking at all.

A 15-minute verification pass you can run today

Run dig TXT yourdomain.com and confirm exactly one v=spf1 string. Count every include, a, mx, exists, and redirect term, following nested includes to their full depth. Anything above eight needs work now. Then run dig TXT selector._domainkey.yourdomain.com for each selector your stack uses and confirm the p= value is complete rather than cut off mid-string. Then dig TXT _dmarc.yourdomain.com and check for a policy plus a rua address someone reads. Finish with dig MX yourdomain.com to confirm the domain can receive.

That covers DNS. Alignment needs a live message. Send a real campaign email to a Gmail address, open Show original, and read which domain sits next to each of the SPF, DKIM, and DMARC results. Repeat against a Microsoft 365 tenant and read the Authentication-Results header, paying attention to the compauth value. Two test sends will tell you more than any DNS checker.

Across 118+ GTM systems built, authentication has been the single most common root cause we find behind a sudden drop in reply rate, and it is nearly always something in the list above rather than the copy. If you want a second pair of eyes on your records, sender pool, and actual inbox placement, our free 30-minute outbound audit produces a written fix list, ranked, with a recommendation on whether each domain should be repaired, parked, or retired.

Related reading

• Cold email spam test: how to check inbox placement before you send
• How many cold emails per inbox per day in 2026
• Cold email deliverability in 2026: why your emails land in spam

Frequently asked questions

Do I need SPF, DKIM, and DMARC for cold email if I send under 5,000 emails a day?

Yes. Google requires SPF or DKIM, valid forward and reverse DNS, TLS, and a spam rate under 0.3% from every sender at any volume. The 5,000-per-day threshold only adds requirements like mandatory DMARC and one-click unsubscribe. Receivers do not run a separate, softer filter for low-volume senders, so configure all three on every sending domain regardless of volume.

What is DMARC alignment and why does it fail for cold email?

Alignment means the domain that passed SPF or DKIM matches the domain in the visible From address. It fails most often because a sending platform rewrites the Return-Path to its own domain for bounce handling, so SPF passes for the platform rather than for you. DNS checkers cannot detect this. Send a live message to Gmail, open Show original, and read which domain each result names.

How many DNS lookups can an SPF record have?

Ten. RFC 7208 requires implementations to cap DNS-querying terms at 10 per evaluation, counting include, a, mx, ptr, exists, and redirect, including everything inside nested includes. The all, ip4, and ip6 mechanisms cost nothing. Exceeding 10 returns permerror, which DMARC treats as an outright SPF failure. A separate limit caps void lookups at two.

Should my cold email domain use p=none, p=quarantine, or p=reject?

Start at p=none with a reporting address you actually read, run it for two to four weeks while the domain warms, and confirm from the reports that all legitimate volume passes aligned DKIM. Then move to p=quarantine, then p=reject. On a dedicated sending domain, enforcement mainly buys you the discipline of keeping sender inventory accurate rather than anti-spoofing protection.

Can I set up SPF and DKIM separately for each inbox on a domain?

No. SPF and DMARC are per-domain records with no mailbox-level scope. Only DKIM supports multiple selectors on one domain, which lets different sending systems sign with their own keys. This means ten inboxes on one domain share one reputation surface and one spam-rate figure. Real isolation comes from separate domains, not from adding mailboxes.

Does one-click unsubscribe apply to cold email?

Google requires one-click unsubscribe headers on marketing and subscribed messages from senders above 5,000 per day to Gmail, so most cold email falls outside the strict requirement. The spam-rate threshold applies to everyone, though, and an easy opt-out is the cheapest way to keep complaints below 0.3%. A plain-text opt-out line at the end of the message is sufficient.