What Is DMARC? SPF, DKIM & DMARC, Explained Simply
DMARC tells mailbox providers what to do when email fails SPF or DKIM. Learn how the authentication trio works and the safe rollout path from p=none to p=reject.
On this page
- What do SPF, DKIM, and DMARC each do?
- Why did mailbox providers make DMARC mandatory?
- What does a DMARC record actually look like?
- What is DMARC alignment, and why do messages fail it?
- How do you roll out DMARC without losing legitimate mail?
- How do you read DMARC reports?
- Where does DMARC fit in your deliverability program?
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record that tells receiving mail servers what to do with a message that fails authentication: deliver it anyway, quarantine it to spam, or reject it outright. It sits on top of two older standards — SPF, which lists the servers allowed to send mail for your domain, and DKIM, which cryptographically signs message content — and adds the two things they always lacked: an enforcement policy and a reporting loop back to the domain owner.
Since 2024 this has stopped being optional plumbing. Gmail and Yahoo require bulk senders to authenticate with SPF, DKIM, and DMARC, and Microsoft applies equivalent rules from May 2025. If email carries revenue for your business, DMARC now sits directly between your campaigns and the inbox.
What do SPF, DKIM, and DMARC each do?
The three protocols answer three different questions, and mixing them up causes most authentication mistakes.
SPF (Sender Policy Framework) is a DNS TXT record listing the servers authorized to send mail for your domain. When a message arrives, the receiving server checks whether the connecting IP appears on that list. SPF is simple and brittle: forwarding breaks it, and the domain it actually checks — the invisible return-path — can be entirely different from the From address a human reads.
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each message. The receiver fetches your public key from DNS and verifies the signature, which proves the message was authorized by the signing domain and arrived unmodified. DKIM survives forwarding, but the signing domain can still differ from the visible From.
DMARC closes that gap with a requirement called alignment: SPF or DKIM must pass, and the domain that passed must match the From domain your reader sees. On top of alignment, DMARC publishes your policy for failures and requests reports on every message received in your name.
| Protocol | What it proves | Where it falls short alone |
|---|---|---|
| SPF | The sending server is on the domain's approved list in DNS | Forwarding breaks it; the checked domain can differ from the visible From |
| DKIM | The message was authorized by the signing domain and unchanged in transit | The signing domain can differ from the visible From; rogue tools send unsigned |
| DMARC | The From domain the reader sees aligns with what SPF or DKIM verified | Only as strong as its policy — a record left at p=none observes without enforcing |
A useful mental model: SPF is the guest list, DKIM is the tamper-proof seal, and DMARC is the security policy that says what happens when someone shows up with neither.
Why did mailbox providers make DMARC mandatory?
Because without it, the From field is trivially forgeable. For decades anyone could send mail claiming to be your brand, and phishing operations industrialized exactly that. The authentication standards existed, but adoption lagged because nothing forced the issue.
In 2024, Gmail and Yahoo forced it. Their bulk-sender requirements turned long-standing best practice into a hard gate, and Microsoft followed with equivalent rules from May 2025:
| Requirement | The bar |
|---|---|
| SPF and DKIM | Mandatory for all senders |
| DMARC | Required for bulk senders, at minimum p=none |
| One-click unsubscribe | Must be offered and honored within two days |
| Spam complaint rate | Under 0.3% as the hard ceiling, under 0.1% as the working target |
Two details matter for marketers. First, the rules pair authentication with behavior: passing SPF, DKIM, and DMARC gets your mail judged on its merits, while engagement and complaint rate — the heart of sender reputation — deliver the verdict. Second, the numbers reward doing this properly. Validity puts global inbox placement near 83%, while authenticated senders holding complaints under 0.1% reach roughly 96%. That thirteen-point spread is the business case in two numbers, and the wider mechanics live in our email deliverability glossary entry.
What does a DMARC record actually look like?
A single DNS TXT record published at _dmarc.yourdomain.com:
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@yourdomain.com
Four tags carry most of the weight. v declares the version and is always DMARC1. p is your policy for failing mail — none, quarantine, or reject. pct applies the policy to only a percentage of failing messages, which makes gradual enforcement possible. rua is the address where receivers send aggregate reports about everything they saw from your domain. Optional tags like sp set a separate policy for subdomains, and adkim and aspf toggle between relaxed and strict alignment matching.
The record takes five minutes to publish. The judgment lives in choosing the policy, which is why the rollout below is the part worth studying.
What is DMARC alignment, and why do messages fail it?
Alignment is the detail that trips up otherwise well-run programs. A message can pass SPF and pass DKIM and still fail DMARC, because both checks validated a domain other than the one in the From header.
This happens constantly with third-party services that send on your behalf: your ESP, your CRM, your marketing automation platform, billing and receipts, the support desk, the survey tool someone in product connected last quarter. Out of the box, many of these sign with their own domain and use their own return-path — technically authenticated, completely unaligned with you.
The fix is configuration rather than heroics. Every legitimate sending service needs either a custom return-path on your domain, which aligns SPF, or a DKIM key published under your domain, which aligns DKIM. Most reputable platforms support both and document the exact DNS records to add. The rollout process exists precisely to find every one of these services before you start enforcing.
How do you roll out DMARC without losing legitimate mail?
In stages, and with more patience than the DNS change itself suggests. The three policy settings form a ladder:
| Stage | What receivers do with failing mail | Your job at this stage |
|---|---|---|
| p=none | Deliver normally and send you reports | Inventory every legitimate sending service; bring each into SPF or DKIM alignment |
| p=quarantine | Route failures to the spam folder | Ramp with the pct tag; watch reports for real mail getting caught |
| p=reject | Refuse delivery outright | Hold here permanently; monitor reports for new tools connected without your knowledge |
Start at p=none and let reports accumulate for a few weeks. The goal is a complete inventory: every service that legitimately sends as your domain, each brought into alignment one by one. Then move to p=quarantine, optionally ramping with pct so only a share of failing mail is affected while you confirm nothing real is being caught. Finish at p=reject, the only setting that actually stops spoofing, and stay there.
The common failure mode is impatience: jumping straight to p=reject, discovering the billing system was never DKIM-signed, and spending a week explaining to finance why invoices bounced. The second most common is the opposite — publishing p=none to satisfy the Gmail checklist and never enforcing at all, which leaves the spoofing door wide open while producing reports nobody reads.
How do you read DMARC reports?
The rua tag tells receivers where to send aggregate reports: daily XML files listing every IP that sent mail claiming your domain, with pass and fail counts per authentication check. Raw XML is genuinely unpleasant, so run the reports through a parser or monitoring service that turns them into a dashboard of sending sources.
During rollout, the reports are your inventory tool. After rollout, they become your smoke detector. A new source appearing in the reports is either a tool someone connected without telling you or an active spoofing attempt, and both deserve attention within days. Some ops teams now point an AI agent at parsed report data to flag new sources and alignment regressions automatically — a mundane, high-value example of agentic automation earning its keep on a chore humans reliably abandon.
Where does DMARC fit in your deliverability program?
Think of authentication as the entry ticket. It proves identity, and it says nothing about whether anybody wants your mail. Once the trio is enforced, placement is decided by engagement, complaints, list hygiene, and volume consistency — the full checklist lives in our guide to improving email deliverability.
Two free tools shortcut the diagnostic work. Our Email Deliverability Checker grades your SPF, DKIM, and DMARC records and flags alignment gaps in about a minute. If you are standing up a new domain or subdomain for sending, the Email Warmup Planner builds the volume ramp that lets reputation form before full-scale campaigns hit. For the market-level numbers behind all of this, our Email Deliverability report compiles placement and authentication benchmarks in one place.
Authentication is also where a lifecycle and demand generation practice usually starts an engagement — infrastructure first, because the cleverest campaign in the world converts nobody from a spam folder. And if any term in this piece is new, the growth marketing glossary collects every definition in this series.
