Defaults.Exposed › Setup walkthroughs › DMARC › Wix
Add a DMARC record in Wix DNS
The Wix panel allows more than one TXT (Text) record at the same host name. DMARC (Domain-based Message Authentication, Reporting and Conformance) needs exactly one record at _dmarc, so if a record already exists, edit it rather than adding a second. This console will not stop you creating the ambiguity, and two records at _dmarc is read as no valid policy at all.
The DMARC record for Wix
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
v=DMARC1 is the version and has to lead the record. p=none is the policy, the value that asks receivers to do nothing different. rua=mailto: is the address aggregate reports are sent to.
At p=none receivers block nothing and send reports instead. That makes it the right first step, and the policy has to be tightened later for the record to protect anything.
Check that Wix answers DNS for the domain
In the Wix account, open the domain and check its DNS (Domain Name System) settings, labelled DNS, Records or Advanced, and look at the nameservers section. If it shows another company’s nameservers, a web host, Cloudflare, the registrar or the email provider, the DMARC record has to go there instead. Adding it at Wix in that case does nothing, and the record never reaches receivers.
Wix is the DNS host here, the place the domain’s records get typed and saved. It only publishes what you enter, and it has no view on whether SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) already pass. It adds the surrounding quoting to the value automatically but generates no part of the DMARC string.
Add the record in the Wix console
- Sign in to Wix and open the account’s Domains area.
- Click the domain, then open its DNS settings, labelled DNS, Records or Advanced.
- Go to the TXT records section and read the existing rows for a
_dmarcentry before adding one. - Choose to add a new TXT record, or open the existing
_dmarcrow to edit it. - In the Host Name field, sometimes labelled Name, enter exactly
_dmarc, with the leading_character and nothing after it. - In the Value or Text field, paste the DMARC string plain, without adding quote marks.
- Leave TTL (Time to Live) at the Wix default value.
The Host Name field takes _dmarc alone, because Wix appends the domain automatically, so typing the full _dmarc.yourdomain.com publishes the broken host _dmarc.yourdomain.com.yourdomain.com. The Value or Text field takes the DMARC string pasted in full, with the reporting mailbox swapped in for the example address.
Traps in the Wix form
- Wix appends the domain to the Host Name field itself, so entering
_dmarc.yourdomain.comthere produces the doubled, unreachable host_dmarc.yourdomain.com.yourdomain.com. - Wix adds the surrounding quoting to the Value field on its own. Wrapping the pasted string in hand-typed quote marks corrupts the record.
- The address after
rua=mailto:has to be a mailbox someone opens, or the reports go nowhere useful.
What to expect if Wix business email is involved
Wix business email is a Google Workspace mailbox sold through Wix, which changes what your reports will show and where the fixes live.
Mail sent from those mailboxes leaves through Google’s servers, so it passes SPF when your record carries include:_spf.google.com, and it passes DKIM when the key is published at google._domainkey and signing has been started in the Google Admin console. Both of those are separate jobs from this one, and both live outside Wix: the SPF record goes in this same DNS panel at Host @, while the DKIM key is generated at admin.google.com and published here at its selector host.
So a DMARC report showing Google failing on your domain almost always means one of those two steps was skipped, and this record is not the cause. The commonest of the two is DKIM: the key gets published in DNS and the Start authentication button in the Google console never gets clicked, so nothing is signed.
Anything else that sends as you, a campaign tool, a booking system, an invoicing platform, shows up in the same reports and needs the same treatment at its own end.
Alignment, and the policy ladder
Two ideas explain nearly everything in a DMARC report, and both are worth having before the first one arrives.
The first is alignment. DMARC asks whether SPF or DKIM passed and whether the domain it passed for matches the domain in the From address a reader sees. A platform sending on your behalf often passes SPF on its own envelope domain while your domain sits in the From line, so DMARC fails despite the pass sitting in the report. Adding another include to your SPF record does not help, because your record was never the one evaluated. A DKIM key published on your domain does help, because the signature aligns by construction and survives forwarding as an SPF pass cannot.
The second is the policy ladder. p= takes none, quarantine or reject, and pct= lets you apply a policy to a share of failing mail rather than all of it. v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com quarantines one failure in ten, which means a sender you overlooked costs a tenth of the consequence and still shows up in the reports. Raise the figure over a few weeks, then drop the tag and move to reject.
Two tags you can ignore for now: sp= gives subdomains their own policy, and adkim=/aspf= switch alignment between relaxed and strict. Relaxed is the default and nearly always what you want.
Wait, then read the result
A saved record is picked up once the previous TTL for that host name expires, rather than on a fixed clock; re-query the record after saving instead of waiting a guessed duration. The saved record appears back in the domain’s TXT records list in the same DNS settings screen used to add it. Reopen that list and confirm the _dmarc entry shows the pasted string exactly, with no extra quote marks and no doubled domain in the host name.
How the scan grades this record: the DMARC policy check, with its pass and fail rules and how many domains pass it.
For scale: 249,025,625 domains (74.9%) in the October 2026 census publish no DMARC record at all, and among those at p=none, 35,049,364, or 80.17%, carry no rua= address either.
When the reports show every legitimate sender aligning, move to p=quarantine and then p=reject. Receivers act on the record only at p=quarantine or p=reject.
Figures from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.