TL;DR — DMARC is the policy layer that makes SPF and DKIM mean something: it ties them to the From address people actually see, tells receivers what to do when both fail, and — the underrated half — sends you reports showing everyone claiming to send as your domain. One TXT record, three policy levels, and a rollout path that shouldn't be skipped. Since 2024, Gmail and Yahoo require it from bulk senders; for everyone else it's simply how you stop your domain being forged.
The gap DMARC closes
SPF authenticates the invisible envelope sender. DKIM authenticates a signing domain named in a header nobody reads. Neither, by itself, says anything about the From line — the only address a human sees. DMARC's core idea is alignment: a message passes DMARC only if SPF or DKIM passes and the domain that passed matches the From-header domain.
That single rule is why a spammer can no longer pass authentication on their own domain while displaying yours. It's also why either leg alone is enough — which matters, because forwarding breaks SPF by design while DKIM survives it.
The record
_dmarc.yourdomain.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com"
| Tag | What it does |
|---|---|
p= |
Your policy for failing mail: none (deliver, just report), quarantine (spam-folder it), reject (refuse it outright). |
rua= |
Where aggregate reports go — the feedback channel. Set it always. |
sp= |
Separate policy for subdomains; defaults to p. Worth setting sp=reject explicitly once mature — forged billing.yourdomain.com is as damaging as the apex. |
pct= |
Apply the policy to only N% of failing mail — a canary dial for cautious rollouts. |
adkim= / aspf= |
Alignment strictness, relaxed (subdomains align with the apex — the default, right for nearly everyone) or strict. |
Skip ruf= (per-message forensic reports): most large receivers don't send them, and they can leak message content to whatever mailbox you name.
The reports are the product
Aggregate reports arrive daily from each large receiver as XML attachments: which IPs sent as your domain, how many messages, what passed and failed, how the policy was applied. Raw XML is unreadable by design-accident; run it through any report-visualizing tool — several providers (ours included) ingest and graph them for you.
What the reports reveal, in practice:
- The senders you forgot — the CRM, the invoice tool, the website's contact form, all sending as your domain without alignment, all about to break the day you set
p=reject. - Forgery attempts — unfamiliar IPs failing everything, which is DMARC quietly working.
- Forwarding patterns — SPF-fail/DKIM-pass clusters that explain themselves once you know the forwarding rule above.
One operational footnote from running this at scale: if your reports are sent to an address on a different domain than the one being reported on (rua=mailto:reports@otherdomain.com), the receiving domain must publish a tiny verification record (yourdomain.com._report._dmarc.otherdomain.com) authorizing itself to receive them — or reporters silently decline. Report tooling handles this; hand-rolled setups routinely miss it and wonder where the reports went.
The rollout path: none → quarantine → reject
Going straight to p=reject on day one is how you discover your invoicing tool the hard way. The boring, correct sequence:
p=none+rua=— changes nothing about delivery; starts the reports flowing. Watch for two to four weeks.- Fix what the reports surface — every legitimate sender gets aligned: your provider's records for your own mail, each third-party tool's CNAME/DKIM flow so they sign as your domain.
p=quarantine, optionally starting withpct=25— failures now land in spam. Watch the reports for anything legitimate caught in the net.p=reject— the destination. Forged mail is refused before anyone sees it. For a personal domain with one mail provider and no third-party senders, the whole path can be a week; the point is the sequence, not the duration.
A domain that sends no mail at all deserves the short version: v=spf1 -all, empty-p= DKIM revocation optional, and v=DMARC1; p=reject; — three records that make a parked domain worthless to phishers.
What DMARC doesn't do
Worth stating plainly, because "we have DMARC" gets sold as more than it is: DMARC stops exact-domain forgery. It does nothing about look-alike domains (yourdomain-billing.com), display-name tricks ("Your CEO random@gmail.com"), or compromised legitimate accounts. It also doesn't improve deliverability by itself — receivers treat it as table stakes now (Gmail and Yahoo mandate at least p=none for bulk senders since 2024), so its absence hurts more than its presence helps.
Checking your work
Gmail "Show original" on a message from your domain shows all three verdicts — DMARC: PASS requires that alignment, not just raw SPF/DKIM passes. For the record itself, any DMARC inspector parses the tags; for ongoing health, the reports are the check — a report stream you actually look at (or have graphed for you) is the difference between a policy and a hope.
The series: SPF explained · DKIM explained · MX records explained · the full picture in Email on Your Own Domain: The Complete 2026 Guide. MailHow generates the record, ingests your aggregate reports, and graphs the pass rate per domain.