SPF and DKIM each answer a narrow question. DMARC is what ties them to the thing your recipients actually see — the From: address — and tells the world’s mailbox providers what to do when the answer is “this isn’t really you.” It’s also the single most effective control against exact-domain spoofing, and, since 2024, a hard requirement for anyone sending volume to Gmail and Yahoo. If you run a domain that sends email, DMARC is not optional homework; it’s the lock on the front door.

What DMARC does that SPF and DKIM can’t

Domain-based Message Authentication, Reporting and Conformance builds on SPF and DKIM by adding two things they lack: alignment and a published policy. Alignment is the crucial idea. SPF authenticates the envelope sender and DKIM authenticates whatever domain signed the message — neither is required to match the visible From:. DMARC insists that at least one of them does match your From: domain. A spoofer can happily pass SPF for their own server, but they can’t make that pass align with your domain, so DMARC catches them.

The policy half tells receivers what to do with mail that fails: p=none (watch and report only), p=quarantine (send to spam), or p=reject (refuse outright). The record lives at _dmarc.yourdomain as a TXT record and, at minimum, looks like v=DMARC1; p=none; rua=mailto:you@yourdomain.

The standards moved in 2026 — this checker is current

DMARC was published for years as the informational RFC 7489. It has since been placed on the standards track: RFC 9989 is now the primary DMARC protocol specification and obsoletes both RFC 7489 and the experimental RFC 9091, while reporting has been split into its own documents — RFC 9990 for aggregate (rua) reports and RFC 9991 for failure/forensic (ruf) reports. This checker validates against those. The wider ecosystem context lives at dmarc.org.

Roll out in stages — never jump straight to reject

The mistake that generates panicked support tickets is publishing p=reject on a domain you’ve never monitored. You will, guaranteed, discover a legitimate sender you forgot about — a billing system, a helpdesk, a five-year-old cron job — and its mail will vanish. Do it in the order the protocol was designed for:

Monitor (p=none). Publish with a rua address and change nothing else. Reports start flowing within a day. This is where our DMARC report monitoring earns its keep — it turns the raw XML into a readable list of every source sending as you.
Quarantine, gradually. Once you recognise every legitimate source and have them passing, move to p=quarantine. Use pct= to ramp — pct=25 applies the policy to a quarter of failing mail while you watch for collateral damage.
Reject. When the reports are clean, move to p=reject and remove pct. Now nobody can spoof your exact domain into an inbox.

Reading the tags

p — the policy for the domain itself.
sp — a separate policy for subdomains. Without it, subdomains inherit p. Set sp=reject to stop spoofers abusing random.yourdomain.
rua — where aggregate reports go. This is the useful one.
ruf — where failure reports go. Handle with care (see the privacy note below).
adkim / aspf — alignment mode, relaxed (default) or strict. Relaxed allows a subdomain to align with the parent; strict demands an exact match.
pct — the percentage of failing mail the policy applies to during rollout.

A privacy warning about failure reports

It’s tempting to add a ruf address to see the failing messages, but forensic reports can contain message headers and even body content — which means personal data. Under regimes like the GDPR you need a lawful basis to collect that. For day-to-day monitoring, aggregate rua reports are enough and carry no message content. Reach for ruf only deliberately.

Worked examples

Monitoring — always start here:

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

Quarantine, half of failing mail, strict alignment:

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com; adkim=s; aspf=s

Full enforcement, subdomains included:

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

Where DMARC leads next

Enforced DMARC is also the entry ticket to BIMI — the standard that puts your logo next to authenticated mail — which won’t display until your policy is at quarantine or reject. Build the record with the DMARC Generator, see how it fits with SPF and DKIM in the Email Health Check, and confirm real messages actually align by sending one through the Outbound Deliverability Test. Google and Yahoo’s bulk-sender requirements (which mandate DMARC) are summarised in Google’s sender guidelines; check your domain against them with the Bulk Sender Compliance tool.

Frequently asked questions

Does p=none protect my domain?: No — p=none is monitoring only. It gathers reports but doesn’t stop spoofing. Use it first, then move to quarantine and reject once your reports confirm your senders pass.
Why does SPF pass but DMARC fail?: DMARC requires alignment — SPF can pass for the ESP’s bounce domain while that doesn’t match your From:. Align SPF (custom Return-Path) or DKIM (sign with your domain).
What does pct do?: pct applies the policy to only a share of failing mail during rollout (e.g. pct=25). Ramp it up, then remove it at full rollout.
What is the subdomain policy (sp)?: sp sets a separate policy for subdomains (they inherit p otherwise). Use sp=reject to protect unused subdomains.
Should I collect ruf (failure) reports?: Only if you can process them lawfully — ruf can contain headers/content (personal data). For monitoring, aggregate rua reports are enough.
How long until DMARC stops spoofing?: Only once your policy reaches quarantine or reject — p=none observes but doesn’t act. A careful rollout usually takes a few weeks, paced by getting every legitimate sender aligned.

DMARC Checker