Table of Contents
- What Do SPF, DKIM and DMARC Each Actually Check?
- SPF vs DKIM vs DMARC Compared
- Which One Actually Stops Someone From Spoofing Your Domain?
- DMARC Policy Compared: None vs Quarantine vs Reject
- How Does This Actually Affect Cold Email Deliverability?
- What Is the Most Common Setup Mistake Outbound Teams Make?
- Four Checks Before You Send Your First Cold Email Campaign
- Where This Leaves a Team Setting Up Outbound Infrastructure
- Key Takeaways
- Key Terms Glossary
- See How a Fully Authenticated System Compares for Your Domain
- Related reading
A founder setting up a new sending domain almost always asks the same question once a developer or an agency mentions DNS records: what is the actual difference between these three, and do you need all of them? SPF vs DKIM vs DMARC is not a choice between three competing standards. It is three separate checks that mailbox providers run against every message, and a domain missing any one of them is exactly the kind of gap Gmail and Outlook now treat as a reason to reject mail outright rather than just mark it as suspicious.
This matters more in 2026 than it did a few years ago. Gmail and Yahoo both tightened bulk-sender requirements, and a domain sending real volume without a working DMARC record now bounces or lands in spam far more often than the same domain would have in 2022. This guide compares what each of the three records actually checks, what happens when one is missing, and which DMARC policy setting is right for a domain running cold email at volume.
What Do SPF, DKIM and DMARC Each Actually Check?
Each record answers a different question a receiving mailbox asks before it decides whether to trust a message, and none of the three alone answers all of them.
- SPF (Sender Policy Framework). Answers "is this server allowed to send mail for this domain?" by publishing a list of approved sending IP addresses in DNS. It fails silently the moment mail routes through a server not on that list, which is common when a team adds a new sending tool without updating the record (Wikipedia).
- DKIM (DomainKeys Identified Mail). Answers "has this message been altered in transit, and did it genuinely come from this domain?" by attaching a cryptographic signature to every outgoing message that the receiving server verifies against a public key in DNS (Wikipedia).
- DMARC (Domain-based Message Authentication, Reporting and Conformance). Answers "what should happen if a message fails SPF or DKIM, and who should be told?" by publishing a policy that tells receiving servers whether to deliver, quarantine, or reject unauthenticated mail claiming to be from the domain (Wikipedia).
SPF vs DKIM vs DMARC Compared
None of the three records does the other two's job, which is why cold email infrastructure needs all three configured correctly, not just one.
| Record | What it checks | What it protects against | What happens if missing |
|---|---|---|---|
| SPF | Which servers are authorised to send for the domain | Spoofed mail sent from unauthorised infrastructure | Legitimate mail from new tools can fail if not added to the record |
| DKIM | Whether the message content was altered and genuinely signed by the domain | Message tampering and impersonation mid-transit | Receiving servers cannot verify the message is unaltered |
| DMARC | What to do when SPF or DKIM fails, and where to report it | Domain spoofing and phishing using your exact domain | No enforcement policy exists, so spoofed mail using your domain is not blocked |
A domain with SPF and DKIM but no DMARC record has verification with no enforcement: mailbox providers can check whether a message is genuine, but nothing tells them what to do when it fails. That gap is precisely what DMARC closes.
Which One Actually Stops Someone From Spoofing Your Domain?
DMARC is the only one of the three that enforces a consequence, so it is the record that actually stops a spoofed message from reaching an inbox under your domain's name. SPF and DKIM only provide the receiving server with information; DMARC is the instruction that turns that information into a decision.
Without DMARC, a bad actor can send mail that appears to come from your domain, and even if it fails SPF and DKIM checks, most mailbox providers will still deliver it to the inbox by default, because "fail" without an enforcement policy is treated as a warning, not a block.
DMARC Policy Compared: None vs Quarantine vs Reject
The `p=` tag in a DMARC record sets the enforcement level, and the three options represent a genuine escalation, not interchangeable settings.
- p=none. Monitor only. Failing messages are still delivered, but the domain owner receives aggregate reports showing who is sending mail claiming to be from the domain, authenticated or not. This is the correct starting point for any new domain, never the end state.
- p=quarantine. Failing messages are routed to spam rather than blocked outright. This is the middle step most domains should sit at for several weeks while confirming that every legitimate sending source (marketing tools, CRM notifications, cold email infrastructure) is properly authenticated.
- p=reject. Failing messages are refused outright at the mail server, never reaching the inbox or the spam folder. This is the end state a domain running real volume should reach, but only after `p=quarantine` has run long enough to confirm no legitimate mail is being caught by the policy.
Jumping straight to `p=reject` on a domain that has never been monitored is the most common outbound infrastructure mistake we see: a single missed sending source (an invoicing tool, a support platform) gets silently blocked with no warning, and nobody notices until a client says they never received an email.
How Does This Actually Affect Cold Email Deliverability?
Missing or misconfigured authentication is one of the fastest ways to collapse a domain's sender reputation, because mailbox providers increasingly treat weak authentication itself as a spam signal, independent of message content. Across 1,634,250 emails sent over the past 90 days on Danish Lead Co.'s own outbound platform, bounce rates varied sharply by sending setup, from 0.03% on a properly warmed, fully authenticated provider up to 21.45% on a manually configured Outlook setup, a gap almost entirely explained by authentication and warm-up discipline rather than message quality (see the full case study library for how this plays out across client campaigns). A SaaS company that got this layer right before scaling volume added $72,000 in new ARR in under two months, and infrastructure discipline, not a cleverer message, was the difference between that result and a domain that quietly stops landing.
That is the practical stakes of SPF vs DKIM vs DMARC for outbound specifically: a domain sending real cold email volume without all three configured correctly is not a minor technical gap, it is the difference between an outbound system that reaches the inbox and one that quietly bounces without anyone noticing until reply rates collapse.
What Is the Most Common Setup Mistake Outbound Teams Make?
The most common mistake is authenticating the root domain while sending from unauthenticated subdomains, which leaves every message from the subdomain unprotected even though the main domain looks fully configured. Cold email infrastructure typically uses dedicated sending subdomains to protect the primary domain's reputation, and each one needs its own SPF, DKIM and DMARC alignment checked individually, not assumed from the parent record.
The second most common mistake is treating DMARC as optional because SPF and DKIM already pass. A domain can have perfect SPF and DKIM records and still have no DMARC policy at all, which means nothing stops a spoofed message from using that same trust to reach someone else's inbox under your name.
Four Checks Before You Send Your First Cold Email Campaign
Run these against any new sending domain before the first message goes out, not after deliverability drops.
- Confirm SPF includes every sending source. Check every tool that sends on the domain's behalf, not just the primary platform, and re-check after adding any new tool.
- Verify DKIM signs correctly on a live test message. A DKIM record can exist in DNS and still fail if the signing key does not match what is published.
- Set DMARC to p=none first and read the reports for two weeks. Confirm every legitimate sending source shows as authenticated before tightening the policy.
- Move to p=quarantine, then p=reject, only once the reports are clean. Each step should run long enough to catch anything the previous step missed.
Where This Leaves a Team Setting Up Outbound Infrastructure
SPF, DKIM and DMARC are not three optional boxes to tick once and forget; they are the layer that decides whether every message after that point has a fair chance of reaching an inbox at all. Getting all three configured and escalated correctly is a one-time setup with a permanent payoff, and it is worth confirming before a single cold email campaign sends, not after reply rates already look wrong.
Key Terms Glossary
See How a Fully Authenticated System Compares for Your Domain
If you are setting up outbound infrastructure and are not certain your SPF, DKIM and DMARC records are configured and aligned correctly, a demo with Danish Lead Co. includes a review of your current domain setup against exactly the checks above. You leave the call knowing precisely which of the three records is misconfigured, if any, and what a fully managed outbound system looks like once infrastructure stops being the reason messages do not land, backed by a client track record built on getting this layer right before anything else.
