DMARC record check
Finds the policy receivers actually apply to your domain, including one inherited from a parent, and one silently disabled by test mode.
Judged against RFC 9989, with reporting rules from RFC 9990 and RFC 9991
Symptoms
DMARC problems rarely announce themselves. The record exists, the syntax looks right, and somebody at some point declared the project finished. Then a supplier is invoiced by someone impersonating you, or you discover that the policy you set two years ago has never once been enforced.
What we find most often:
- A policy of
p=nonethat was always meant to be temporary. t=yleft in place after a rollout, quietly overridingp=reject.- No
rua, so nobody has ever seen a report and nobody dares tighten the policy. - A subdomain policy weaker than the domain's, which is where the spoofing then happens.
- Reports sent to an agency's address that never authorised the domain, so none arrive.
Diagnosis
DMARC ties SPF and DKIM to the address your recipient actually sees, and tells receivers what to do when neither matches. Three things decide whether it works.
Which record applies
Receivers look for _dmarc at your domain, and if there is nothing there they walk up the DNS tree, stripping a label at a time, up to eight queries, until they find one. A record found on a parent still applies to you, through its sp value rather than itsp. This test performs that walk and reports which record governs your mail.
What enforcement really is
p=reject refuses forged mail. p=quarantine sends it to spam, where a determined recipient still finds it. p=none does nothing but report. Andt=y replaces whatever you set with none, which is why we report the effective policy rather than the published one.
Reporting you can act on
Aggregate reports are the only way to see who sends mail as you before you start blocking. If the address belongs to another domain, that domain must publish an authorisation record. Otherwise receivers drop the reports and you are enforcing blind.
Cure
- Start honestly. Publish
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comand read the reports for two to four weeks. - Fix what the reports show. Every legitimate sender should pass SPF or DKIM with alignment. This is the work; the rest is configuration.
- Move to quarantine, then reject. Change
p, watch the reports for a week at each step, and setspto match so subdomains are not the soft target. - Close the gaps. Add
np=rejectfor subdomains that do not exist, and removet=yand anypctleft over from the rollout.
Questions people actually ask
Does p=none protect my domain?
No. p=none tells receivers to report what fails and deliver it anyway. It is the correct place to start, because it shows you who sends your mail before you block anything, but a domain left at p=none is exactly as spoofable as a domain with no DMARC at all.
What does t=y do to my DMARC policy?
It overrides it. With t=y, receivers apply p=none no matter what your policy says. A record reading p=reject; t=y protects nothing, and it is the single most common reason a domain owner is certain they are protected when they are not.
Why do my DMARC reports never arrive?
Usually because the reporting address is at a different domain and that domain has not authorised you. The destination must publish a record at yourdomain._report._dmarc.theirdomain, without it, receivers silently drop every report.
Do I still need the pct tag?
No. pct, rf and ri were removed in the current DMARC standard. Receivers ignore them, so a staged rollout built on pct is not happening. Use the t tag instead.
What is the difference between p and sp?
p applies to the domain itself, sp to its subdomains. If sp is weaker than p, attackers simply spoof a subdomain instead, invoices.yourdomain.com looks just as convincing in an inbox.
Related tests
Every fix on this site is yours to implement. If you would rather someone did it, I take this work directly.