What DMARC does that SPF and DKIM don't
SPF validates the sending server. DKIM validates the message signature. Neither one, on its own, protects the address your recipients actually see in the From: line. DMARC closes that gap: it requires SPF or DKIM to pass and to align with the visible From: domain, and it tells receivers what to do when both fail. The record is a TXT entry at a fixed name, which makes it the easiest of the three to check:
_dmarc.example.com → v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc@example.comThat example enforces quarantine on all failing mail, refuses mail from subdomains that do not exist in DNS, and sends daily aggregate reports to a mailbox. Every tag in it is doing a job, and the checker reads each one against RFC 9989, the DMARC standard since May 2026.
How the checker grades a policy
p=reject gets the strongest grade. Failing mail is refused during delivery; spoofed messages never reach a human. This is the end state Gmail, Yahoo, and the BIMI standard all point toward.
p=quarantine is solid. Failing mail lands in spam rather than being refused. Most domains sit here for months during rollout, often rehearsing first with t=y, the RFC 9989 testing flag that has receivers apply one policy level down — the checker flags testing mode so you can see whether the policy is actually live.
p=none draws a warning. It is monitoring-only: reports flow, enforcement does not, and a spoofer's mail is delivered exactly as before. Legitimate as a first step; a finding when it has been sitting there for two years. The tag that separates those two cases is rua — a p=none record without a report address collects nothing and protects nothing, so the checker flags that combination separately.
No record is graded critical. Beyond the spoofing exposure, a missing DMARC record now violates Gmail's and Yahoo's bulk-sender requirements, which made DMARC mandatory for senders above 5,000 messages a day in 2024. If the name you checked has no record of its own but a parent domain does, the checker runs the RFC 9989 DNS tree walk and shows the parent record receivers apply instead.
The tags people get wrong
- t=y left on: testing mode is a rehearsal switch.
p=reject; t=yrejects nothing at receivers following RFC 9989 — they quarantine instead. Correct mid-rollout, forgotten surprisingly often. - Legacy pct: RFC 9989 removed the tag. A record reading
p=quarantine; pct=25is sampled by receivers still on RFC 7489 but enforced in full by updated ones, so the checker flags it and points tot=y. - sp weaker than p:
sp=nonenext top=rejectprotectsexample.comwhile leaving existing subdomains likeanything.example.comopen. Spoofers read DNS too. - No np under enforcement: RFC 9989's
np=covers subdomains that do not exist in DNS. Without it they fall back tosp, thenp; made-up names send no legitimate mail, so the checker suggestsnp=reject. - Missing rua: without aggregate reports you cannot see which sources fail, which means you cannot safely tighten the policy. Reports arrive as XML from each receiver; even reading them manually once a week beats flying blind.
- Multiple DMARC records: like SPF, more than one record means receivers act as if there were none.
- Strict alignment set prematurely:
adkim=soraspf=sfails mail from subdomains and many ESP setups. Relaxed alignment is the default for a reason; go strict only when your reports show it is safe.
Reading the result honestly
A pass here means your DMARC record is present, parseable, and enforcing. It does not mean your mail passes DMARC — that depends on SPF and DKIM alignment on each message you send, which only your aggregate reports can confirm. And none of this measures inbox placement: authentication is the entry ticket, not the seat. Our deliverability rankings measure the seat — what percentage of real, authenticated campaigns reached the inbox at each provider, tested on the schedule described in our methodology.
If the checker found no record, or you want to tighten the one you have, build a correct record with the DMARC generator — it includes the staged none → quarantine → reject rollout. Then verify the two mechanisms DMARC depends on with the SPF checker and DKIM checker.
Frequently asked questions
What does a DMARC check look for?
The checker fetches the TXT record at _dmarc.{domain}, confirms it starts with v=DMARC1, and parses every tag RFC 9989 defines: p (policy), sp (existing subdomains), np (non-existent subdomains), t (testing mode), psd (public suffix flag), rua/ruf (report addresses), adkim/aspf (alignment mode) and fo (failure options). Tags RFC 9989 removed (pct, rf and ri) are still read and flagged as legacy. It then grades the policy and flags gaps like a missing rua, testing mode left on, or enforcement without np.
Is p=none bad?
p=none is the correct starting point and a bad place to stay. It turns on reporting without enforcing anything, so spoofed mail is still delivered. Collect reports for a few weeks, fix the legitimate senders that fail, then move to p=quarantine and eventually p=reject.
What is the difference between quarantine and reject?
p=quarantine asks receivers to put failing mail in spam; p=reject asks them to refuse it during the SMTP conversation. Reject is the stronger end state — quarantined spoof mail still sits in someone's spam folder waiting to be clicked. RFC 9989 adds a caution: a reject domain must sign its mail with aligned DKIM rather than rely on SPF alone, and domains whose users post to mailing lists should weigh reject carefully.
What happened to the pct tag?
RFC 9989, the DMARC standard that replaced RFC 7489 in May 2026, removed pct because receivers applied values other than 0 and 100 unevenly. Its replacement for staged rollouts is t=y, testing mode: receivers apply one policy level down, so p=reject; t=y is handled as quarantine. The checker still reads pct on older records and flags it — at receivers on the new standard, pct=25 without t=y means the policy applies to all failing mail.
Why does DMARC need SPF or DKIM to be aligned?
DMARC passes only when SPF or DKIM passes AND the domain that passed matches the From: address the recipient sees. An ESP signing with its own domain passes DKIM but fails DMARC alignment for your domain. That is why platforms ask you to publish their DKIM key under your domain.
Do I need DMARC if I'm a small sender?
Since February 2024, Gmail and Yahoo require a DMARC record (at minimum p=none) for anyone sending 5,000+ messages a day to their users. Below that volume it is still worth publishing: it costs one TXT record and stops your domain being an easy spoofing target.