How to Add a DMARC Record on BigCommerce

Start with SPF

DMARC builds on SPF and DKIM. It tells receiving inboxes what to do with mail that fails those checks, and it sends you reports about who is sending as you.

If you have not published an SPF record yet, do that first. Our SPF guide for BigCommerce walks through it. Turning on DMARC enforcement before SPF is right is how you accidentally send your own order confirmations to spam.

Where the record goes

DMARC is a TXT record at _dmarc.yourdomain.com. Where you create it depends on where your DNS is hosted.

BigCommerce has a DNS editor with A, CNAME and TXT support, but only if you bought your domain through BigCommerce or pointed a custom domain to BigCommerce via nameservers. Otherwise your DNS is at your registrar and that is where the record belongs. If you run multiple storefronts, only the default storefront's DNS is manageable in the panel.

One honest caveat: we have not been able to confirm from BigCommerce's documentation that its DNS editor accepts underscore hostnames like _dmarc. It very likely does, since that is a standard requirement, but it is not documented. If the editor refuses the host, create the record at your registrar instead. That always works.

Most DMARC guides online are now wrong

DMARCbis landed in May 2026. RFC 9989 is the new core specification, with RFC 9990 for aggregate reporting and RFC 9991 for failure reporting. Together they obsolete RFC 7489, which every DMARC article written before mid-2026 is based on.

The change that matters most: the pct tag has been removed. If a guide tells you to publish pct=100, it is working from the old spec. Do not include it.

The valid tags in RFC 9989 are v, p, sp, np, rua, ruf, adkim, aspf, fo, psd and t. Anything else you see in an old article deserves a second look. There is more detail on our DMARC glossary entry.

Start in monitoring mode

Do not begin at p=reject. The specification itself endorses monitoring first, and there is a good reason. You almost certainly send mail from more services than you remember, and you will not find out which until the reports arrive.

Publish this and leave it alone for a few weeks.

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

Note there is no pct tag. That was removed in RFC 9989 in May 2026, so any guide still showing pct=100 predates the current spec. v=DMARC1 must come first in the record. If p is missing from an otherwise valid record it is treated as p=none anyway, but publish it explicitly so your intent is clear.

Adding the record

The shape is the same in the BigCommerce editor and at any registrar.

1.Create a TXT record.
2.Set the host to _dmarc. Not _dmarc.example.com. See the warning below.
3.Paste the monitoring-mode value above, with your own reporting address.
4.In the BigCommerce editor specifically, remember that @ is not accepted for the root. That affects your SPF record rather than this one, but it trips people up in the same session.
5.Save, wait for it to propagate, then confirm with a free check.

The auto-append trap

This deserves its own section because it catches nearly everyone. Most DNS editors take a relative name and silently append your domain. Type _dmarc.example.com into the host field and you will create a record at _dmarc.example.com.example.com, which resolves for nobody and reports nothing.

Enter just _dmarc. The exception is AWS Route 53, which takes fully qualified names and does not append. Route 53 also requires values in double quotes.

After you save, look at what the record actually became. Every editor shows you. Ten seconds of checking saves a week of wondering why no reports arrived.

Then move up, slowly

The path is p=none, then p=quarantine, then p=reject. Move to the next stage only once your aggregate reports show your legitimate mail passing consistently.

Reports will surface senders you forgot about. An old newsletter tool. Your accounting software. A form on a site you retired years ago. That discovery is the entire point of monitoring mode, and it is why skipping straight to reject is a bad idea.

Why you might get no reports at all

The usual cause is an external rua address without the authorisation record. If your reports go to an address on the same domain as the DMARC record, nothing extra is needed and you can ignore this.

If they go to a different domain, such as a DMARC monitoring vendor, then that receiving domain must publish an authorisation record. Under RFC 9990 it takes the form <your-domain>._report._dmarc.<destination-host>, containing at minimum v=DMARC1, which must appear first. Vendors happy to receive reports for anyone may publish a wildcard *._report._dmarc.<their-domain> instead, in which case there is nothing for you to do.

"I set up DMARC but I get no reports" is nearly always this missing record.

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

Do I add DMARC in BigCommerce or at my registrar?

Wherever your DNS is hosted. BigCommerce offers a DNS editor only if you purchased the domain through BigCommerce or pointed a custom domain via BigCommerce nameservers. Any other setup means the record goes to your registrar. If the BigCommerce editor will not accept the _dmarc host, use your registrar instead.

Should my DMARC record include pct=100?

No. The pct tag was removed in RFC 9989, published in May 2026. Almost every DMARC guide online still shows it, because they were written against the older RFC 7489. Leave it out.

Can I go straight to p=reject?

You can, but do not. Monitoring first is officially endorsed for a reason. Start at p=none, read your aggregate reports for a few weeks, and only move to quarantine and then reject once you can see your legitimate mail passing. Almost every store sends from more services than its owner remembers.

I published DMARC but no reports are arriving. Why?

Two likely causes. First, check the record was created at _dmarc and not at _dmarc.example.com.example.com, which is what happens when a DNS editor auto-appends your domain to what you typed. Second, if your rua address is on a different domain, that domain must publish an authorisation record at yourdomain._report._dmarc.theirdomain. No such record is needed when reports go to an address on your own domain.

Does DMARC affect my BigCommerce store or just email?

Just email, but that matters more than most store owners expect. Without DMARC, anyone can send order confirmations, refund notices or password resets that appear to come from your domain. That is a far more common attack on a store than anything targeting the storefront itself.