How to Add a DMARC Record on Wix

Where the record goes

Same rule as SPF, and it trips up the same people. Wix says: "If your domain is connected to Wix via pointing, you must add or update TXT records with your domain host (not Wix)."

So: connected by nameservers, or bought through Wix? Add it in the Wix editor. Wix accepts _dmarc hostnames, so there is nothing special to work around. Note that NS records for a Wix-registered domain cannot be changed, so you stay on Wix DNS.

Pointed at Wix with A or CNAME records? Your registrar still hosts your DNS. Add it there. A record added in Wix will never be served.

The mistake that eats the most time

Almost every DNS editor takes a relative name and appends your domain automatically. So if you type _dmarc.yoursite.com into the host field, you actually create _dmarc.yoursite.com.yoursite.com, which never resolves and never will.

Enter just _dmarc. Nothing else.

The one exception is AWS Route 53, which expects a fully qualified name and does not auto-append. If you are on Route 53, type the whole thing.

Start here

DMARC is a TXT record at _dmarc on your domain. Start in monitoring mode. This is not us being cautious, it is what the spec itself endorses.

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

v=DMARC1 must come first. p=none means monitor only, so nothing is quarantined or rejected while you watch. Swap in your own address. If p is missing from an otherwise valid record it is treated as p=none anyway.

Do not paste pct=100

This is the single most useful thing on this page. The pct tag was removed in RFC 9989, published May 2026. It is gone.

You will see pct=100 in nearly every DMARC guide, generator and vendor doc online, because they all still reflect RFC 7489, which RFC 9989 obsoletes. Do not copy it.

The tags that are valid in RFC 9989 are: v, p, sp, np, rua, ruf, adkim, aspf, fo, psd and t. If a generator hands you something outside that list, it is out of date, and that tells you something about the rest of its advice too.

More background on our DMARC glossary entry.

Why you set up DMARC and get no reports

Very common, and the cause is nearly always the same.

If your rua address is on the same domain as the DMARC record, everything just works. No extra setup.

If your rua points at a different domain, which is what happens the moment you use a DMARC reporting vendor, that other domain has to authorise it. Otherwise reports are simply not sent, silently. The receiving domain must publish a record at:

<policy-domain>._report._dmarc.<destination-host>

containing at minimum:  v=DMARC1

v=DMARC1 must appear first. A vendor happy to receive reports for any domain may publish a wildcard at *._report._dmarc., in which case you need to do nothing. This is defined in RFC 9990. If your vendor already handles it, fine. If reports never arrive, this is the first thing to check.

Then tighten, slowly

DMARC gets its teeth from the p tag, but going there early is how you make legitimate email disappear. The order is not optional:

1.p=none. Monitoring mode. Nothing changes for your mail. Reports start arriving. Leave it here until you can account for every sender in them.
2.p=quarantine. Failing mail goes to spam. Watch for anything legitimate landing there. Your own newsletter tool and invoicing system are the usual surprises.
3.p=reject. Failing mail is refused outright. This is the goal, and it is what actually stops people phishing your customers in your name. Only get here once the reports are clean.

DMARC needs SPF first

DMARC does not check anything by itself. It sits on top of SPF and DKIM and decides what to do when they fail. If your SPF record is missing, duplicated, or over the 10-lookup limit, a strict DMARC policy will start rejecting your own email.

Fix SPF first. Then add DMARC at p=none. Then read the reports. Then tighten. In that order, this is safe.

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 the DMARC record in Wix or at my registrar?

It depends on how the domain is connected. Nameservers connected, or bought through Wix, means Wix hosts your DNS and you add it in the Wix editor, which accepts _dmarc hostnames. If your domain is connected by pointing, Wix says you must add or update TXT records with your domain host, not Wix.

Why does every guide show pct=100 but you say not to use it?

Because the pct tag was removed in RFC 9989, published in May 2026, which obsoletes RFC 7489. Most guides, generators and vendor docs online still reflect the old spec. The valid tags now are v, p, sp, np, rua, ruf, adkim, aspf, fo, psd and t.

What host name do I enter for DMARC?

Just _dmarc. Do not enter _dmarc.yoursite.com, because most DNS editors append your domain automatically and you end up with _dmarc.yoursite.com.yoursite.com, which never resolves. AWS Route 53 is the exception and wants the full name.

I set up DMARC but I get no reports. What is wrong?

Usually the external reporting authorisation record is missing. If your rua address is on a different domain than the DMARC record, that domain must publish ._report._dmarc. containing at minimum v=DMARC1. If rua points at an address on your own domain, no authorisation record is needed.

Can I go straight to p=reject?

You can, but do not. Start at p=none, read the aggregate reports until every legitimate sender is passing, then move to p=quarantine, then p=reject. Monitoring first is what the spec itself endorses, and it is the difference between blocking phishers and blocking your own invoices.