DMARC
DMARC record / p=reject / email authentication / domain spoofing protection
DMARC is a DNS record that tells receiving mail systems what you think about messages using your domain that fail authentication. The current standard, RFC 9989, is explicit that receivers can honor your request but are not required to. It was revised in 2026, and the percentage rollout tag was removed.
Start with what the current standard says it does. RFC 9989 describes DMARC as permitting the owner of an email's Author Domain to enable validation of the domain's use, to indicate the message handling preference for failed validation, and to request reports about use of the domain name. Preference and request. Those two words carry the whole design.
The policy has three settings, and the 2026 wording states them as the domain owner's opinion rather than an instruction. With none, the domain owner offers no expression of preference. With quarantine, the domain owner considers such mail to be suspicious, and the standard adds that it is possible the mail is valid although the failure creates a significant concern. With reject, the domain owner considers all such failures to be a clear indication that use of the domain name is not valid.
Then the sentence most people selling DMARC leave out. A mail-receiving organization that performs DMARC validation can choose to honor the requested handling, the standard says, but is not required to do so, and DMARC is commonly used as one input to more complex filtering decisions. You are publishing an opinion into somebody else's filter.
One more caution from the same document, and it is the reason rollouts go wrong. Some messages making authorized use of your domain can still fail DMARC validation. A strict policy published before you know which of your own senders fail is a decision to have your own mail rejected.
In practice
There is a live disagreement worth knowing about here. Microsoft's instructions describe a staged rollout, moving the pct value through 10, 25, 50, 75 and 100 to affect more mail gradually. RFC 9989 removed that tag. Its explanation is blunt: operational experience showed the pct tag was usually not applied accurately unless the value was 0 or 100, and inaccuracies at other values varied widely between implementations. So the staged percentage many guides still describe was taken out of the standard for not working reliably.
Not the same as
- SPF and DKIM
- Those authenticate a message. This states what you want done when they fail, and asks whether the authenticated domain matches the visible From address.
- A spam filter
- The receiving system decides. Your record is one input to their decision, by the standard's own description.
Why it matters to you
The real benefit is that a stranger cannot easily invoice your customers from your own domain. Microsoft names the pattern it defends against: spoofed senders used in business email compromise, ransomware and other phishing attacks. That is worth having. It is a different claim from better inbox placement, which is what this usually gets sold as, and the one you should expect a supplier to make.
What to ask or check
- 01What policy are we publishing today, none, quarantine or reject?
- 02Which of our own senders currently fail, and how do we know?
- 03Is our rollout plan built on the pct tag, which the current standard removed?
What people get wrong
That a published policy is binding on receivers. RFC 9989 says a receiver can choose to honor the requested handling but is not required to, and that DMARC is commonly one input among several.
Red flags
- A jump straight to p=reject before anyone knows which of your own senders fail validation.
- A staged rollout built on the pct tag, which the current standard removed as unreliable.
- A policy presented as a deliverability improvement rather than a spoofing control.
Who owns it
Whoever controls the domain's DNS. That is often not the same people who send the mail, which is why rollouts stall.
Where you will see it
As a TXT record at the _dmarc hostname on your domain, and in any email deliverability audit.