DMARC explained: your policy for mail that fails the checks

DMARC is a TXT record at _dmarc.yourdomain.com that does two jobs: it tells every receiver in the world what to do with mail that claims to be from your domain but can't prove it, and it asks them to send you reports about what they're seeing. SPF and DKIM produce evidence; DMARC is the policy that says what the evidence must add up to and what happens when it doesn't. Since 2024 it has also been mandatory in practice: Gmail and Yahoo refuse to play nicely with bulk senders who don't publish one.

Why a third standard was needed

You now know the gap. SPF authenticates the envelope sender, the Return-Path domain. DKIM authenticates whatever domain appears in the signature's d= tag. Notice what neither of them mentions: the From address, the one thing your reader actually sees. A message can pass SPF for one domain, carry a valid DKIM signature for a second domain, and display a third domain in the From header. Before DMARC, nothing in the standards connected the evidence to the display.

DMARC (RFC 7489) closes the loop. It is anchored to the visible From domain, and it defines a single verdict: pass or fail, computed from the SPF and DKIM results plus one extra condition called alignment.

How the verdict is computed

A message passes DMARC if at least one of these is true:

1. SPF passed, and the domain SPF passed for aligns with the visible From domain.
2. DKIM passed, and the signature's d= domain aligns with the visible From domain.

Either one is enough. Both can be true, which is the healthy state, and it gives you slack: when forwarding breaks SPF, the surviving DKIM pass still carries the message through DMARC.

"Aligns" means, loosely, "is the same domain or a subdomain of it." The precise rules, relaxed versus strict mode and the traps hiding in them, are the subject of the next lesson; alignment is where nearly every confusing DMARC failure lives. For this lesson, hold the shape of the verdict: a pass requires evidence that is both valid and yours.

Fail the verdict, and your published policy kicks in.

The record, tag by tag

v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc@example.com

v=DMARC1 is the version marker, always first, exactly this.

p= is the policy, your instruction for messages that fail. Three values. p=none means take no action, deliver as you otherwise would, just report back to me. p=quarantine means treat failures with suspicion, which in practice means the spam folder. p=reject means refuse them outright at the door; the mail bounces instead of ever reaching a person.

sp= sets a separate policy for subdomains. Without it, subdomains inherit p=. This tag cuts both ways: it lets you protect mail.example.com while observing on the apex (the bare registered domain, example.com itself), and it also lets a forgotten sp=none quietly exempt every subdomain from a policy you thought was strict.

pct= applies the policy to a percentage of failing mail, meant as a ramp: pct=25 while you build confidence, then upward. Know what happens to the mail outside the sample, because it isn't what most people assume. The standard downgrades it one step rather than releasing it: unsampled failures under p=reject are treated as quarantine, and unsampled failures under p=quarantine are treated as none, delivered as if no policy existed. That second case is the trap. A record saying p=quarantine; pct=10 delivers ninety percent of forgeries untouched while reading as strict to anyone skimming. And some receivers skip the sampling arithmetic entirely and just apply your p= to everything, so the tag is at best approximate. Our domain check grades policy strength for exactly this reason: a percentage tag hollowing out a proud-looking policy is a pattern we keep finding on real domains.

rua= is the address where receivers send aggregate reports: XML summaries, typically daily per receiver, of every message they saw claiming your domain, with the SPF, DKIM, and alignment outcomes. They are unreadable raw (a later lesson, reading DMARC reports, deals with that), but they are the only view you get of your mail through the receivers' eyes, including forgeries you'd otherwise never know about.

ruf= requests forensic reports, per-message failure samples. Privacy concerns mean most large receivers simply don't send them. Publish rua and treat ruf as a bonus if anything arrives.

The path from none to reject

p=none is the designed starting point, and skipping it is how people hurt themselves.

The mechanic behind that warning: your DMARC policy applies to every message carrying your From domain, and that includes legitimate mail from tools you forgot: the survey platform marketing added in 2023, the CRM that sends "on behalf of" you, the billing system IT set up. Any of them sending unaligned mail is, in DMARC's eyes, indistinguishable from a forger. Publish p=reject before finding them and the first mail you block is your own. From our side, watching sending domains, tightening a policy while a legitimate tool still sends unauthenticated is the classic way people spam-folder their own newsletter. The damage report arrives as "our open rate died," weeks later, with nobody connecting it to the DNS change.

So the path is deliberate:

1. Publish p=none with rua= pointing somewhere you'll actually process. Nothing changes for your mail; the reports start flowing. (One wrinkle: if the reports go to an address on a different domain, a report processor typically, that domain has to publish a one-line record consenting to receive them. The reports lesson covers it.)
2. Read the reports for a few weeks. Every legitimate source shows up, including the ones nobody remembered. Fix each one: aligned DKIM, or an aligned Return-Path, per that tool's setup docs.
3. When the reports show your real mail aligning, move to p=quarantine, with pct= as a ramp if the volume scares you.
4. When quarantine has been quiet for a while, p=reject. That is the destination: at reject, a forged message using your exact domain is refused before any human sees it.

Expect weeks between steps, sometimes months for an organization with years of accumulated tools. The reports decide the pace, not the calendar.

The 2024 line in the sand

For DMARC's first decade, publishing a record was optional and mostly the habit of banks and big brands. That ended in February 2024, when Google and Yahoo began enforcing requirements on bulk senders (in Gmail's case, senders of roughly 5,000+ messages a day to Gmail addresses): SPF and DKIM must both pass, the mail must align with the From domain, and the domain must publish a DMARC record of at least p=none. Microsoft followed with equivalent requirements for its consumer domains, phased in from May 2025. The full ruleset, complaint-rate thresholds and unsubscribe requirements included, gets its own lesson; the point here is narrower.

A minimal record satisfies the requirement:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Note what p=none earns you under these rules: compliance, plus the reporting stream. It does nothing yet to stop forgery, and it wasn't meant to. It's step one of the path above, now with a deadline attached.

One thing no tool vendor can do for you: this record lives at _dmarc on your domain, and only you (or whoever holds your DNS) can publish it. Whether yours exists, and whether a pct= or a stray sp= is undermining it, is public information; the free health check reads and grades it in seconds.

The verdict above kept leaning on one word, "aligns", and the next lesson unpacks it: relaxed against strict mode, and the ESP trap that passes every individual check while failing DMARC.

Terms from this lesson

• DMARC - the standard (RFC 7489) tying SPF and DKIM results to the visible From domain and declaring a policy for failures, via a TXT record at _dmarc.yourdomain.com.
• policy (p=) - your published instruction for failing mail: none (deliver, just report), quarantine (to spam), or reject (refuse outright).
• subdomain policy (sp=) - an optional separate policy for subdomains; absent, subdomains inherit p=.
• pct= - applies the policy to a percentage of failing mail; intended as a temporary ramp, dangerous when forgotten at a low value.
• aggregate report (rua=) - the XML summaries receivers send, showing every message that claimed your domain and how it fared.
• forensic report (ruf=) - per-message failure samples; most large receivers decline to send them.
• alignment - the requirement that the domain passing SPF or DKIM match the visible From domain; covered in depth in the next lesson.

Check yourself

1. A message passes SPF for the ESP's bounce domain and carries a valid DKIM signature with d= set to the ESP's domain. The From shows your domain, which publishes DMARC. What is the DMARC result?

Pass, because both SPF and DKIM passedPass, because at least one authentication succeededFail, because neither passing domain aligns with the visible FromNeutral, because the ESP is a known sender

2. What does p=none actually do?

Disables DMARC checking for the domainQuarantines failures but doesn't reject themRejects forgeries but skips reportingDelivers failing mail normally while sending you reports

3. Why is jumping straight to p=reject risky?

Forgotten legitimate tools sending unaligned mail get blocked along with forgersReceivers ignore reject policies from new domainsIt disables aggregate reportingReject policies require a paid certificate

4. A domain publishes v=DMARC1; p=reject; pct=10. How is failing mail treated?

All of it is rejectedRoughly one in ten failing messages is rejected; the rest are delivered normallyRoughly one in ten is rejected; the rest are handled as if the policy said quarantineThe record is invalid because pct requires p=quarantine