The idea
Email was designed to be trusting. Anyone can write anything in the "From" line, which is why you get messages that look like they came from your bank.
Three records fix this between them. SPF lists who is allowed to send email for your domain. DKIM signs your messages so they cannot be tampered with. DMARC is the one that ties them together and answers the missing question: what should an inbox actually do when a message fails?
Without DMARC, the answer is usually "deliver it anyway and hope for the best".
What it looks like
DMARC is a TXT record published at _dmarc followed by your domain. A sensible starting record looks like this:
Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:[email protected]Enter the name as just _dmarc. Most DNS hosts add your domain automatically, so typing the full _dmarc.example.com usually creates _dmarc.example.com.example.com, which does nothing.
The three policies
The p tag is the whole point of the record. It has three settings, and you are meant to move through them in order.
- →p=none is monitoring mode. Nothing changes for your mail, but you start receiving reports. Always start here.
- →p=quarantine tells inboxes to treat failures with suspicion, usually meaning the spam folder.
- →p=reject tells inboxes to refuse failures outright. This is the goal, and it is the only setting that truly stops impersonation.
Why you should not jump straight to reject
Because you will almost certainly break something. Most businesses send email from more places than they remember: the website, a newsletter tool, an invoicing system, a helpdesk, a booking platform.
Turning on p=reject before all of those are properly authorised means real messages get refused, silently, and you find out when a customer says they never got their receipt. Sit on p=none until the reports show everything legitimate is passing. Then tighten.
A detail almost every guide gets wrong
DMARC was rewritten. RFC 9989 was published in May 2026 and it obsoletes RFC 7489, which is what nearly every DMARC article online still describes.
The headline change is that the pct tag has been removed. If a guide or generator hands you a record containing pct=100, it has not been updated since May 2026. Leave it out. The valid tags are now v, p, sp, np, rua, ruf, adkim, aspf, fo, psd and t.
It is a small thing, but it is a useful test of whether the advice you are reading is current.
Why "I set up DMARC but get no reports"
This is the most common complaint, and there is usually one reason for it.
If your rua address is on a different domain to the one the record protects, that other domain has to agree to receive the reports. It does that by publishing its own record, in the form yourdomain.com._report._dmarc.theirdomain.com, containing v=DMARC1. Most reporting vendors publish a wildcard so it just works, but if you pointed reports at your own second domain, nothing will arrive until that record exists.
If the reports go to an address on the same domain, you do not need any of this.
We have step by step instructions for every major platform, including the ones that will not let you.
See how to add DMARC on your platform