How to Add a DMARC Record to Your Domain

Start here: almost every DMARC guide online is now wrong

DMARCbis was published in May 2026. It is Standards Track, and it obsoletes RFC 7489, which is what every DMARC article written before then describes. The relevant documents are RFC 9989 for the core spec, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting.

The headline change: the pct tag has been removed. If a guide tells you to publish pct=100, or to roll out a policy gradually by stepping pct from 10 to 50 to 100, that guide predates RFC 9989. Do not put pct in your record.

This matters because DMARC guidance is the most copy-pasted content on the internet. The record you find at the top of a search result is very likely a 7489 era record. Ours is not.

The valid tags

RFC 9989 defines these: v, p, sp, np, rua, ruf, adkim, aspf, fo, psd, and t. That is the list. Anything else you see in an old example is either removed or was never real.

Two rules on structure. v=DMARC1 must come first in the record. And if p is absent from an otherwise valid record, it is treated as p=none, which means you get reports and no enforcement. That is a fine place to start, but be deliberate about it rather than accidental.

The record is a TXT record at _dmarc.example.com, not at your domain root. Our DMARC glossary entry covers the concepts.

The record to start with

This is the right first record for almost everyone. It enforces nothing and tells you everything.

Name:   _dmarc
Type:   TXT
Value:  v=DMARC1; p=none; rua=mailto:[email protected]

Note the name is just _dmarc, not _dmarc.example.com. Most DNS UIs append your zone automatically, and typing the full name gets you _dmarc.example.com.example.com, which resolves for nobody. Route 53 is the exception and wants the fully qualified name.

The ladder, and why you do not skip rungs

Monitoring first is not caution, it is the officially endorsed path.

p=none. Monitoring mode. Nothing changes for your mail. Reports start arriving. Leave it here until you can look at a week of aggregate reports and recognise every sender in them. You will find things you forgot about: an old CRM, a support desk, a billing system, someone's scanner.

p=quarantine. Failing mail goes to spam rather than the inbox. This is where a forgotten legitimate sender becomes visible without becoming a disaster.

p=reject. Failing mail is refused outright. This is the goal, and it is the only setting that actually stops someone sending invoices in your name. Get here, but get here on evidence.

The failure mode of rushing is not subtle. Publish p=reject before you know what sends your mail and legitimate messages stop being delivered, silently, to people who then assume you never replied.

Why you set up DMARC and got no reports

This is the most common DMARC support question there is, and it has one usual answer.

If your rua points at an address on a different domain, the receiving domain must authorise it. That includes pointing reports at your DMARC vendor, or at your agency, or at a Gmail address when your domain is not Gmail. Without the authorisation record, reporters will not send to it, and everything on your side looks fine.

Per RFC 9990, the destination domain publishes a TXT record at <policy-domain>._report._dmarc.<destination-host> containing at minimum v=DMARC1, which must appear first.

Your DMARC record on example.com:

  _dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

The record that must exist on vendor.net for that to work:

  example.com._report._dmarc.vendor.net.  TXT  "v=DMARC1"

You cannot publish this second record yourself unless you control vendor.net. That is the point of the mechanism: the receiver is consenting to accept your reports.

The two exceptions to that

Neither is obscure, and knowing them saves an afternoon.

→A vendor may publish a wildcard. A reporting service willing to receive for any domain can publish *._report._dmarc.<their-domain>, which authorises everyone at once. Most established DMARC vendors do exactly this, which is why their setup instructions never mention the record. If yours does not, you have to ask them to add one for your domain.
→Same domain needs nothing. If your rua points at an address on the same domain as the DMARC record, no authorisation record is required. rua=mailto:[email protected] on _dmarc.example.com just works. This is why the starter record above is the safest first move.

A fuller record, once you know what you are doing

When you have your reports and you are ready to enforce, this is roughly where you land.

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]

sp sets the policy for subdomains. adkim and aspf set strict alignment, which is tighter than the default and worth testing under p=none before you enforce. There is deliberately no pct here, because pct no longer exists.

DMARC does not work alone

DMARC checks that a message passes SPF or DKIM and that the passing domain aligns with the domain in the From address. So it depends entirely on those two being set up correctly underneath it.

If you have not done SPF yet, do that first. A DMARC record over a broken SPF record just tells you in more detail that your SPF record is broken. Then run a free check to confirm both resolve.

Check your work in seconds

Run your site through our free safety check to confirm the fix is live, and see what else a shopper would notice.

Run a free check

Frequently asked questions

Should my DMARC record include pct=100?

No. The pct tag was removed in RFC 9989, published May 2026, which obsoletes RFC 7489. Any guide showing pct=100 or a gradual pct rollout predates the current spec. Leave it out entirely.

I set up DMARC but I get no reports. Why?

Usually because your rua points at a different domain and that domain has not authorised your reports. Under RFC 9990, the destination must publish a TXT record at yourdomain._report._dmarc.destination-host containing at least v=DMARC1. Many DMARC vendors publish a wildcard that covers everyone, but not all do. If your rua points at an address on your own domain, no such record is needed and reports should just arrive.

What happens if I leave out the p tag?

If p is absent from an otherwise valid record, it is treated as p=none. So you get reporting and no enforcement. That is a reasonable starting state, but set it explicitly so the next person reading your DNS knows it was a decision.

Can I go straight to p=reject?

You can, and we would not. Monitoring first is the officially endorsed path for good reason. Start at p=none, read a week or two of aggregate reports, and you will almost certainly find a legitimate sender you had forgotten. Move to quarantine, then reject, once the reports show your real mail passing.

Where does the DMARC record go?

A TXT record at _dmarc.yourdomain.com, in whatever DNS your domain uses. Enter the name as just _dmarc, because most DNS interfaces append your zone automatically and the full name would create _dmarc.example.com.example.com. Route 53 is the exception and expects a fully qualified name.

Do I need DMARC if I already have SPF?

Yes, they do different jobs. SPF says who may send. DMARC says what a receiver should do when a message fails, requires the passing domain to align with your visible From address, and reports back to you on who is sending as your domain. Without DMARC, an SPF failure is just an opinion nobody has to act on.