How to Read a Company's DMARC Policy in Ten Seconds (And What It Does Not Tell You)

One DNS lookup tells you what a company has asked the world's mail servers to do with forged mail sent in its name. The record is public, and the command is one line: dig +short TXT _dmarc.example.com. What comes back is a short string of settings, and inside it is one instruction — p=none, p=quarantine or p=reject — that states the domain owner's preference when a message using that domain fails authentication.

The current specification, RFC 9989, published in May 2026 as an IETF Standards Track document, replaced the older RFC 7489. It defines the three values almost tersely:

• p=none — "The Domain Owner offers no expression of preference."
• p=quarantine — "The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern."
• p=reject — "The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid."

Read those words again, because they are weaker than most explanations of DMARC admit. A policy is a preference, published by the sender for receivers to consider. It is not an instruction a receiver is obliged to carry out. RFC 9989 says so in one sentence: "The final handling of any message is always a matter of local policy and is left to the discretion of the Mail Receiver." The same section adds both halves of the consequence — receivers "MAY choose to reject or quarantine a message even if it passes the DMARC validation check," and they "SHOULD NOT reject messages solely because of a published policy of 'reject'," precisely so that legitimate mail sent in ways DMARC cannot describe, and mailing lists, do not get destroyed in the process.

So what does p=none actually confess? Less than it is usually accused of. In the spec's own terms it is Monitoring Mode: the domain owner is collecting aggregate reports and "expresses no handling preference for messages that fail DMARC validation," while a receiver that deploys DMARC "can still" validate the domain's use. What it does not do is switch anything off at the receiving end. Your provider's spam filtering, reputation scoring, URL checks and attachment analysis are separate machinery that runs regardless of what the sender published. A forged message arriving at a p=none domain is not promoted to your inbox by the record; it is simply handed to the receiver without a stated preference, and the receiver decides.

The other half of the misunderstanding runs the other way. DMARC does not read the dangerous part of a phishing email. Its own specification lists what is deliberately out of scope, and "content analysis" is on that list, in those words. It also states that DMARC "does not address the use of visually similar domain names or abuse of the RFC5322.From human-readable display name" — the two tricks that carry most brand-impersonation mail. And on the value of a pass: "a DMARC pass by itself does not guarantee that delivery to the recipient's inbox would be safe or desirable." A properly authenticated message from a throwaway domain passes DMARC cleanly. DMARC answers who was authorised to use the domain in the From: header. Nothing more.

This is where the 2024 bulk-sender rules are routinely misreported, including in the first version of this article. Google's sender guidelines require senders of 5,000 or more messages a day to Gmail accounts to "Set up DMARC email authentication for your sending domain," and then say, in the same breath: "Your DMARC enforcement policy can be set to none." Yahoo's own Sender Hub, which has to be read separately rather than assumed to copy Google, states the requirement as "Publish a valid DMARC policy with at least p=none - DMARC must pass," and publishes no numeric volume threshold at all. Both sets of requirements took effect from February 2024. Neither forces anyone off p=none. What both actually force is authentication that lines up: Google requires that "the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain," and Yahoo says relaxed alignment is acceptable. Alignment, not severity, is the gate.

Which leaves the real reason domains sit at monitoring, and it is operational rather than cowardly. Moving to quarantine or reject means first finding every service that sends mail in your name — payroll, ticketing, marketing, a support desk nobody documented — and authenticating each one so it aligns. The standard itself acknowledges the hazards that make this slow: third-party senders are neither introduced nor excluded by DMARC, forwarding and mailing lists can break alignment through no fault of the sender, and the spec points receivers at RFC 7960 for exactly those failure modes. An organisation that publishes p=none and reads its reports is doing the work in the order the spec describes. One that publishes p=none and ignores the reports is not. From outside, the record alone cannot tell you which of the two you are looking at.

You do not need a terminal to look. Free lookup tools — dmarcian's domain checker, MXToolbox's DMARC check — fetch the record and print the policy for you. Do it for your bank, your payroll provider, the airline you fly. Just read the answer for what it is: a statement of intent by the domain's owner, one input among many into a decision your mail provider makes on its own, about one specific kind of forgery. That is a genuinely useful thing to be able to read in ten seconds. It is not a verdict on whether the next message claiming to be from that brand is safe.

Correction, 20 October 2026. An earlier version of this article described p=none as delivering forgeries to the inbox and p=reject as the only setting that blocks a spoofed message, said that the 2024 Google and Yahoo bulk-sender rules forced senders away from p=none, and cited a figure of roughly one in three domains at enforcement. The policy descriptions have been corrected against RFC 9989; both Google and Yahoo in fact accept p=none, quoted above from their own documentation; and the enforcement figure has been removed because the underlying report does not publish its sample or denominator. The article now also states what DMARC does not examine.