How to Add a DMARC Record on Shopify

The short answer

There is no DMARC setting in your Shopify admin. DMARC is a TXT record in DNS, and it lives wherever your DNS is hosted.

If you bought your domain through Shopify, Shopify gives you a DNS editor that supports TXT records, and that is where it goes. If your domain sits with a third-party registrar and just points at Shopify, your DNS stays at the registrar. Add it there.

DMARC builds on SPF. Do SPF first if you have not.

Read this before you copy a record off Google

DMARC was rewritten. RFC 9989 was published in May 2026 and it obsoletes RFC 7489, the version nearly every guide online still describes.

The change that will bite you: the pct tag has been removed. If a guide tells you to publish pct=100, that guide is written against the old spec. Do not include it. The valid tags now are v, p, sp, np, rua, ruf, adkim, aspf, fo, psd and t.

This is not pedantry. It is a decent test of whether the page you are reading has been touched since May 2026.

Step 1: start in monitoring mode

Do not start strict. Starting strict is how a store discovers, in production, that its invoicing system was never authenticated.

Start with p=none, which the spec itself calls Monitoring Mode. It changes nothing about how your mail is treated. It just asks receiving servers to send you reports about who is sending as you.

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

v=DMARC1 must come first. Note there is no pct tag. That tag was removed in RFC 9989 (May 2026), so ignore any guide that still shows pct=100.

The mistake almost everyone makes

The record goes at _dmarc.yourstore.com. But in the Name or Host field of your DNS editor, you type just _dmarc.

Most registrar interfaces automatically append your domain to whatever you type. So if you enter _dmarc.yourstore.com, you actually create _dmarc.yourstore.com.yourstore.com, which resolves for nobody and does nothing forever. Your check keeps failing and the record looks perfectly fine in the panel.

Namecheap says it plainly: the domain name itself should not be included in the Host field. Cloudflare behaves the same way. AWS Route 53 is the exception, because it takes a fully qualified name and does not auto-append.

If your DMARC "is set up" but nothing works, check this first.

Step 2: read the reports, then tighten

Leave it at p=none until aggregate reports show that all your legitimate mail is passing. Every sender. Your Shopify notifications, your newsletter, your helpdesk, your accountant's invoicing tool.

Then walk it up. The order is deliberate and the spec endorses it:

1.p=none. Monitoring only. Collect reports. Nothing is affected.
2.p=quarantine. Failing mail goes to spam rather than the inbox. Recoverable if you got something wrong.
3.p=reject. Failing mail is refused outright. This is the goal, and it is the point at which nobody can send convincing fake email in your store's name.

Why you are getting no reports

This is the second classic failure, and it has a specific cause.

If your rua address is on the same domain as the DMARC record, it just works. Nothing else needed.

If you send reports to a different domain, for example a DMARC reporting service, that receiving domain has to authorise it. Under RFC 9990, the destination must publish a record at yourstore.com._report._dmarc.their-domain containing at minimum v=DMARC1, with v=DMARC1 first. Vendors that accept reports for anyone typically publish a wildcard at *._report._dmarc.their-domain.

Without it, reports are silently not sent. This is nearly always the answer to "I set up DMARC but I never get reports".

A record to grow into

Once monitoring is clean and you are ready to enforce:

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

sp sets the policy for subdomains. Only publish p=reject once your reports show every legitimate sender passing. Again: no pct tag.

Worth knowing

→If p is missing from an otherwise valid record, it is treated as p=none. So a half-written record protects nothing.
→v=DMARC1 must be the first tag. Order matters here in a way it does not for SPF.
→Do not skip SPF. DMARC leans on SPF and DKIM. A DMARC record over a broken SPF record just enforces failure.
→It needs revisiting. DMARC is not fire and forget. Senders change. Review reports periodically, especially before tightening the policy.

Check it worked

DNS is not instant, so give it time before you panic. Then run a free check to see whether your DMARC record is actually resolving at _dmarc, which is the thing the auto-append mistake quietly breaks.

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

Where do I add a DMARC record on Shopify?

In DNS, not in Shopify. If your domain is managed by Shopify, use the DNS editor it provides, which supports TXT records. If your domain is with a third-party registrar, add the TXT record there. Shopify itself has no DMARC setting.

Should I include pct=100 in my DMARC record?

No. The pct tag was removed in RFC 9989, published in May 2026, which obsoletes the older RFC 7489. Most DMARC guides online still show pct=100 because they have not been updated. The valid tags now are v, p, sp, np, rua, ruf, adkim, aspf, fo, psd and t.

Why is my DMARC record not being found?

Usually because the hostname is wrong. Most DNS editors auto-append your domain, so entering _dmarc.yourstore.com creates _dmarc.yourstore.com.yourstore.com, which never resolves. Enter just _dmarc. AWS Route 53 is the exception and expects the full name.

Why am I not receiving DMARC reports?

If your rua address is on a different domain to the DMARC record, that receiving domain must authorise it by publishing yourstore.com._report._dmarc.their-domain containing at least v=DMARC1. Without that record, reports are silently never sent. No authorisation is needed if rua points at an address on your own domain.

Can I go straight to p=reject?

You can, but do not. Start at p=none and read the aggregate reports until every legitimate sender is passing, then move to p=quarantine, then p=reject. Jumping straight to reject is how stores discover a forgotten sender by having its mail refused.