SPF, DKIM and DMARC for Cold Email: 7 Mistakes Ranked by Cost

Why I'm ranking this instead of writing another glossary entry

I'm Hlib Storchak. I build and run outbound systems for B2B founders and sales teams, and I've booked 2000+ meetings for B2B clients doing it. Every one of those campaigns starts with the same unglamorous step: checking the sending domain's SPF, DKIM and DMARC setup before a single email goes out. Explaining what the three acronyms stand for is the easy part, and a hundred other pages already do it. What actually decides whether a campaign lands in the inbox or gets bounced outright is which mistake you're making, and how much that specific mistake costs you. So instead of a definitions page, here are the 7 mistakes I see most often, ranked by how much deliverability damage each one actually does.

One number worth sitting with before the list: EasyDMARC's 2026 DMARC Adoption Report found 937,931 domains, 52.1% of the top 1.8 million domains it tracked, now publish a DMARC record, up from 47.7% in 2025 (EasyDMARC, "2026 DMARC Adoption Report"). Adoption is genuinely rising. What the same report found next is the part that actually matters for this list.

The 7 mistakes, ranked, at a glance

Here's the full ranking before the detail, roughly ordered by how much reply-worthy volume each mistake actually costs you.

1. No DMARC record published at all. Verdict: nothing stops anyone from spoofing your domain, and some receivers already treat that as a signal on its own.
2. DMARC published, but stuck at p=none since day one. Verdict: you're monitoring spoofing attempts, not stopping them.
3. SPF and DKIM both pass, but neither aligns with the From domain. Verdict: a setup that looks fully authenticated and still fails DMARC.
4. Cold volume sent from the root domain instead of a subdomain. Verdict: one bad campaign can drag down the domain your whole company depends on.
5. Missing the bulk-sender thresholds Google, Yahoo and Microsoft actually enforce. Verdict: outright rejection, not a spam folder.
6. A DKIM key under 1024-bit, or one that's never rotated. Verdict: technically valid today, quietly brittle against tomorrow's stricter checks.
7. No working one-click unsubscribe header. Verdict: perfect authentication, tanked by a spam-complaint rate nobody's watching.

#1: no DMARC record published at all

SPF tells a receiving server which mail servers are allowed to send on behalf of your domain. DKIM adds a cryptographic signature to each message so the receiver can confirm it wasn't altered in transit. Neither one, on its own, tells the receiver what to do when a message fails the check. That's DMARC's entire job: a DNS TXT record that says, in effect, "if a message claiming to be from this domain fails SPF and DKIM alignment, do X." Skip DMARC and you've built the locks without deciding what happens when someone doesn't have a key.

Roughly half of the top 1.8 million domains EasyDMARC tracked in 2026 still have no DMARC record at all, since 52.1% adoption means 47.9% don't (EasyDMARC, 2026). That gap isn't evenly spread. Fortune 500 companies were reported in the same wave of 2026 research to sit close to 95% adoption, which tells you the domains still missing DMARC skew smaller and less resourced, exactly the profile of a growing B2B company running cold outbound for the first time.

#2: a DMARC record that's been stuck at p=none since the day it went up

This is the one that costs the most, because it's invisible. A DMARC record has three policy settings: p=none (monitor only, take no action), p=quarantine (send failing mail to spam), and p=reject (block it outright). Almost every setup guide, including the tool that generates your record, tells you to start at p=none so you can watch DMARC aggregate reports for a few weeks before tightening it. The mistake is never tightening it.

EasyDMARC's 2026 report put a real number on how common this is: of the domains with a DMARC record, only around 44% (411,935 domains) had moved to an enforcement policy of p=quarantine or p=reject at all, and only about 9% combined enforcement with reporting, the configuration that actually blocks spoofed mail while still giving you visibility into what's happening (EasyDMARC, 2026). Put differently: having a DMARC record and having a DMARC record that does anything are two different claims, and most domains with one only have the first.

#3: SPF and DKIM both pass, but neither aligns for DMARC

This is the mistake that confuses people the most, because everything looks fine on a checker tool. SPF can pass because the sending server is authorized. DKIM can pass because the signature verifies. And DMARC can still fail, because DMARC doesn't just check whether SPF or DKIM passed, it checks whether the domain that passed matches the domain in your visible From header. If your ESP sends on behalf of yourdomain.com but the SPF check actually authorizes mail.espvendor.com with no alignment configured, you have two green checkmarks and a DMARC fail.

The fix is domain alignment, not a fourth acronym: make sure the domain that SPF or DKIM actually validates matches (or is a subdomain of) the domain in your visible From address. Most sending platforms walk you through this during domain setup, but it's worth confirming directly with a DMARC report rather than assuming the onboarding wizard got it right, especially if you added a sending tool after the domain was already live.

#4: sending cold volume from the root domain instead of a subdomain

This is the mistake that isn't about SPF, DKIM or DMARC syntax at all, it's about domain hygiene. Cold email at any real volume takes on reputation risk: a bad list, an aggressive sequence, or a spike in spam complaints will all ding sender reputation, and reputation is tracked per sending domain. Run that risk on yourcompany.com and a bad week of cold outreach can drag down deliverability for every transactional and internal email your whole company sends from the same domain.

The practice I run for clients, and what most experienced senders converge on independently, is a dedicated subdomain for cold outreach, something like outreach.yourcompany.com or a purpose-built alias domain, each with its own SPF, DKIM and DMARC records inheriting from the parent domain's policy. If that subdomain's reputation takes a hit, it's isolated. Your root domain, and the email your finance and support teams depend on, stays clean.

#5: missing the bulk-sender rules Google, Yahoo and Microsoft actually enforce

Google's own current sender guidelines are unambiguous on this: senders who send 5,000 or more messages a day to Gmail addresses must have SPF and DKIM set up, must add a DMARC record for the sending domain, and non-compliant messages can be rejected outright with a 5.7.26 error, not simply routed to spam (Google, "Email sender guidelines"). Google and Yahoo announced this jointly in October 2023 and began enforcing it on February 1, 2024, starting with temporary deferrals before moving to permanent rejections later that year; Microsoft brought Outlook.com into the same enforcement model in May 2025.

Two details in the guidelines catch people who think "under 5,000 a day" means none of this applies. First, Google still recommends SPF or DKIM for every sender regardless of volume, it's only the DMARC requirement and unsubscribe rules that are volume-gated. Second, the guidelines also cap spam complaint rates, ideally under 0.1% and never above 0.3%, tracked through Google Postmaster Tools, and a domain that clears that threshold gets treated as non-compliant even with perfect SPF, DKIM and DMARC. Authentication is necessary here, not sufficient.

#6: a DKIM key that's too weak, or never rotated

DKIM keys have a minimum viable length and a recommended one, and the two are drifting further apart every year as compute gets cheaper. Current guidance puts the floor at 1024-bit, with 2048-bit recommended for anyone sending at real volume (Google, "Email sender guidelines"). A domain still running a 1024-bit key set up years ago isn't broken today, but it's the kind of setting that quietly becomes the reason a future authentication check starts failing, and almost nobody audits DKIM key length unless something else forces them to look.

Rotation is the other half of this and gets skipped even more often. A DKIM key that's never rotated is a bigger blast radius if it's ever compromised, since every message signed with that key going back to whenever it was created is affected. Most DNS and email providers make rotating a DKIM selector straightforward. The mistake isn't technical difficulty, it's that nobody put it on a calendar.

#7: no working one-click unsubscribe header

This one isn't SPF, DKIM or DMARC at all, but it belongs on this list because it undoes all three. Bulk senders are required to include a functioning List-Unsubscribe header with one-click behavior per RFC 8058, and to honor unsubscribe requests within two days (Google, "Email sender guidelines"). Skip it, or implement a version that forces the recipient to log in or fill out a form, and the predictable result is more people marking your mail as spam instead of unsubscribing, since that's the one-click option they can actually see.

Spam complaints don't care that your SPF, DKIM and DMARC are all perfectly aligned. A rising complaint rate degrades sender reputation on its own, independent of authentication status, and it's the fastest way to turn a technically clean setup into a domain that lands in spam anyway.

SPF vs DKIM vs DMARC, side by side

The three mechanisms answer three different questions, and none of them fully works without the others.

What a clean setup actually looks like, in order

This is the checklist I actually run when I take over a client's sending domain, in the order I run it. First, confirm SPF is published and lists every service that legitimately sends on the domain's behalf, no more. Second, confirm DKIM is active with at least a 1024-bit key, 2048-bit if the platform supports it, and note the rotation date somewhere you'll actually see it again. Third, publish DMARC at p=none with reporting turned on to an inbox someone actually reads. Fourth, use a dedicated subdomain for cold volume, never the root domain. Fifth, after roughly 30 days of clean reports, move DMARC to p=quarantine, then p=reject once you're confident nothing legitimate is failing. Sixth, if you're anywhere near 5,000 sends a day, add a working one-click unsubscribe header before you get there, not after Google's rejection rate tells you.

The infrastructure stack I default to for clients, Infraforge and Mailforge, ships dedicated sending subdomains with SPF and DKIM already configured out of the box, which removes step one and most of step two. It doesn't remove step three: publishing and actually tightening a DMARC policy is still a decision only you can make, and it's the step I see skipped most often regardless of which infrastructure provider is behind the domain.

FAQ