How to Add a DMARC Record for a WordPress Site

Q: What does the record actually look like?

To start with: v=DMARC1; p=none; rua=mailto:you@yourdomain.com, published as a TXT record named _dmarc. v=DMARC1 must come first. No pct tag.

The short answer

Add a TXT record named _dmarc at your DNS host, and start with a policy of none. That is monitoring mode. It changes nothing about how your mail is treated, and it starts sending you reports about who is using your domain.

Like SPF, this has nothing to do with WordPress. Go to wherever your DNS lives: your registrar, your web host, or Cloudflare.

Read this before you follow any other guide

DMARC was rewritten. The new specification, RFC 9989, was published in May 2026 and it obsoletes the old RFC 7489 that everything online was written against. Aggregate reporting moved to RFC 9990.

The change that will bite you: the pct tag has been removed. Almost every guide, generator and vendor blog still shows pct=100 in its example record. Do not copy it. The valid tags now are v, p, sp, np, rua, ruf, adkim, aspf, fo, psd and t.

If a guide is telling you to use pct, it has not been updated since May 2026, which is a reasonable reason to be careful with the rest of its advice too.

What DMARC does that SPF does not

SPF says who is allowed to send. DMARC does two extra things.

It tells receiving inboxes what to do when a message fails your checks: nothing, send it to spam, or reject it outright. And it asks them to send you reports about mail claiming to be from you. Those reports are the entire point of starting out. They are how you find the sender you forgot about before you accidentally block it.

The record to start with

Add this as a TXT record. The name is _dmarc, and the value is:

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

Use your own address in place of [email protected]. v=DMARC1 must come first. Note there is no pct tag, because it no longer exists. If p is missing from an otherwise valid record it is treated as p=none anyway, but write it out so your intent is obvious to the next person.

The mistake that catches nearly everyone

Most DNS interfaces take a relative name and append your domain automatically. So if you type _dmarc.example.com into the name field, you create a record at _dmarc.example.com.example.com, which resolves to nothing.

Type just _dmarc. Nothing else. AWS Route 53 is the exception, it expects a fully qualified name and does not append anything.

If you set DMARC up and a checker says you have no record, this is the first thing to look at.

If your reports go to another domain

This is the reason for almost every "I set up DMARC and never got a report" complaint, and it is rarely explained.

If your rua address is on the same domain as the record, you are done. Nothing more to do.

If it points somewhere else, a monitoring vendor or a different domain you own, the receiving domain has to authorise it. That means a record at <your-domain>._report._dmarc.<destination-host> containing at minimum v=DMARC1, with v=DMARC1 first. Without it, compliant receivers just will not send the reports.

Name:  example.com._report._dmarc.reports-vendor.net
Value: v=DMARC1

This record lives on the destination domain, not yours. A vendor happy to receive reports for anyone may publish a wildcard at *._report._dmarc. instead, which covers you automatically. If your reports never arrive and your rua is external, ask the vendor about this specifically.

Moving from none to reject

Do not skip ahead. Monitoring first is the officially endorsed path, not a cautious opinion.

1.Start at p=none. Nothing changes for your mail. Reports start arriving, usually daily, as XML files. A parser or a monitoring service makes them readable.
2.Read the reports for a few weeks. You are looking for legitimate senders that are failing. This is where you find the invoicing tool nobody remembered, or the WooCommerce notifications going out through a service you never authorised.
3.Fix what you find. Add the sender to your SPF record, or set up its authentication properly, until real mail passes consistently.
4.Move to p=quarantine. Failing mail now goes to spam rather than the inbox. Recoverable if you got something wrong.
5.Move to p=reject, but only once the reports are clean. This is the goal, and it is the setting that actually stops people sending fake invoices in your name.

One thing to watch on a WooCommerce store

Stores send a lot of automated mail: order confirmations, shipping updates, password resets, review requests. Often through more services than the owner realises, because a plugin quietly introduced one.

That is exactly why monitoring mode matters. Jumping to p=reject on a store means finding out the hard way that your order confirmations were failing all along. Let the reports tell you first.

Once your record is live, give DNS a little time to propagate and run a check to confirm it is being read correctly.

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 I include pct=100 in my DMARC record?

No. The pct tag was removed in RFC 9989, published in May 2026. Nearly every guide and generator online still shows it, because they were written against the old RFC 7489. Leave it out. The valid tags now are v, p, sp, np, rua, ruf, adkim, aspf, fo, psd and t.

Is there a WordPress plugin for DMARC?

No. DMARC is a DNS record at _dmarc.yourdomain.com, published by whoever hosts your DNS. WordPress has no involvement. That is true for WooCommerce stores as well.

I added DMARC but I am not getting any reports.

Two likely causes. First, check the record name. Most DNS interfaces append your domain automatically, so entering _dmarc.example.com creates _dmarc.example.com.example.com, which never resolves. Enter just _dmarc. Second, if your rua address is on a different domain, that domain must publish an authorisation record at yourdomain._report._dmarc.destination-host containing v=DMARC1. Without it, receivers will not send reports.

Can I go straight to p=reject?

You can, but we would not. Monitoring first is the endorsed approach for a reason: p=none costs you nothing and shows you which legitimate senders are currently failing. Almost every domain has at least one nobody remembered. Go to reject before you find it, and that mail stops being delivered.

Do I need SPF before DMARC?

Yes, in practice. DMARC builds on the results of SPF and DKIM, so a DMARC record on a domain with no working sender authentication has nothing to evaluate. Sort your SPF record first, then add DMARC in monitoring mode.

What does the record actually look like?

To start with: v=DMARC1; p=none; rua=mailto:[email protected], published as a TXT record named _dmarc. v=DMARC1 must come first. No pct tag.