DMARC Explained: What It Is and How to Roll It Out Safely
DMARC (Domain-based Message Authentication, Reporting & Conformance) is a DNS TXT record that tells receiving mail servers two things: what to do with a message that fails to align with your SPF or DKIM setup, and where to send reports about it. SPF and DKIM check technical details most recipients never see; DMARC is what ties those checks to the address actually shown in the inbox, and it's the only one of the three that gives you visibility into who is sending mail as your domain in the first place.
Last updated: September 10, 2026
How DMARC actually works
DMARC lives in a TXT record at _dmarc.yourdomain.com, starting with v=DMARC1. When a message arrives claiming to be from your domain, the receiver checks whether it passes SPF or DKIM, and whether the domain that passed actually aligns with the visible "From" address the recipient sees. A message can pass SPF on a completely different technical sender domain and still fail DMARC alignment if that domain doesn't match. Once alignment is checked, DMARC's p= tag tells the receiver what to do with anything that fails: nothing (none), send it to spam (quarantine), or refuse it outright (reject). Its rua= tag tells the receiver where to email a daily summary of everything it saw claiming to be from your domain, pass or fail.
Why SPF and DKIM alone aren't enough
SPF checks the invisible envelope sender, a header field most mail clients never display. DKIM checks a cryptographic signature, which proves a message wasn't altered but doesn't by itself say anything about which "From" address it's allowed to appear under. Neither one, alone, stops someone from sending mail that fails their checks entirely and just showing up in the inbox anyway, because without DMARC there's no policy telling the receiver what "failed" should actually mean for delivery. DMARC is the piece that closes that gap, and until it's enforced, a domain with perfect SPF and DKIM can still be freely spoofed.
The rollout path: none → quarantine → reject
- Get SPF and/or DKIM working first. DMARC has nothing to align against without at least one of them passing.
- Publish at
p=nonewithrua=set. This blocks nothing — it just starts the reports flowing so you can see who's actually sending mail as your domain. - Read the reports for a few weeks. Confirm every legitimate source (your mail server, marketing platform, helpdesk tool, CRM) shows up passing.
- Move to
p=quarantine. Failing mail now lands in spam instead of the inbox — a softer landing than outright rejection if something was missed. - Move to
p=reject. Once quarantine has run cleanly, this is full enforcement: failing mail is refused.
Skipping straight to p=reject without reading reports first is the single most common way a DMARC rollout breaks something — an old integration or a marketing platform nobody remembered gets silently blocked the moment enforcement turns on.
What each tag actually means
p= | Required. The policy for this exact domain: none, quarantine, or reject. |
|---|---|
sp= | Optional. A different policy for subdomains. Left unset, subdomains inherit p= — worth setting explicitly to reject for subdomains you never send mail from; see the parked domain & wildcard spoofing guide. |
pct= | Optional, defaults to 100. What percentage of failing mail the policy applies to — a gradual-rollout dial, not a destination to leave it at. |
rua= | Where aggregate reports go, as one or more mailto: addresses. Set this from day one. |
ruf= | Where forensic (per-message failure) reports go. Optional, higher-volume, and not universally sent by receivers. |
adkim= / aspf= | r (relaxed, default) accepts any matching subdomain; s (strict) requires an exact domain match. Most domains leave both relaxed. |
fo= | Controls when forensic reports (if ruf= is set) get generated: 0 only if everything fails, 1 if anything fails, d/s for DKIM- or SPF-specific failures only. |
Common mistakes
- Jumping straight to
p=rejectwithout ever reading an aggregate report. - Never setting
rua=at all — publishing DMARC with no reports is enforcing blind. - Assuming DMARC replaces SPF and DKIM instead of depending on them — it has nothing to align against without at least one passing.
- Forgetting that BIMI (the logo-in-inbox feature) silently does nothing below
p=quarantineatpct=100, even if the BIMI record itself is published correctly.
See exactly what's published now, or build a new policy field-by-field with the safe none → quarantine → reject rollout built in.
Frequently asked questions
Do I need SPF and DKIM before I set up DMARC?
You can publish a DMARC record without them, but it won't do anything useful — DMARC's alignment check needs at least one of SPF or DKIM to actually pass for a message to align. Set up SPF and/or DKIM first, then layer DMARC on top.
What's the difference between rua= and ruf=?
rua= gets you daily aggregate reports: a summary of volume and pass/fail rates by sending source. ruf= gets you forensic reports: a copy of individual failing messages, sent per-failure. Most domains only need rua= — ruf= is higher volume, not every receiver sends it, and it can include message content, which is a bigger data-handling consideration.
Is it safe to jump straight to p=reject?
Not without reviewing reports first. Any legitimate sender you forgot about, a marketing platform, an old CRM integration, a ticketing system, will have its mail rejected outright the moment you enforce. Start at p=none with rua= set, confirm every real source passes, then move to quarantine before reject.
Why is my DMARC policy enforced but BIMI still doesn't show my logo?
BIMI needs DMARC enforced at p=quarantine or p=reject with pct=100 — a partial rollout (pct less than 100) or a policy that's technically present but missing its p= tag won't activate it. Check the BIMI guide for the rest of the checklist.
If your mail runs through Microsoft 365 or Google Workspace
Both support DMARC as a standard DNS TXT record, published the same way regardless of provider — there's no provider-side toggle to enable it. Their own reference docs on reading what it does with your mail flow: