How to add DMARC, SPF and DKIM records on Wix

7 June 2026 · 14 min read

Wix is a website builder first and a DNS host second, and that order of priorities shows up the moment you need to add email authentication. The DNS editor exists, it works, and it will accept every record DMARC, SPF and DKIM require, but it phrases things its own way, hides a few options, and has a couple of behaviours that will silently break a record if you do not know about them in advance. This guide is specifically about adding TXT and CNAME records for DMARC, SPF and DKIM inside Wix, where the buttons are, what to type into each field, and the Wix-specific traps: how the root domain is written, how Wix handles long TXT values, why some CNAME-based DKIM setups misbehave, and how TTL affects your testing.

It assumes you are using Wix as your DNS host, meaning your domain's nameservers point at Wix (you either bought the domain through Wix or you connected an external domain and chose the nameserver method). If instead you connected your domain by pointing records at Wix while keeping it registered and DNS-hosted elsewhere, your DNS editor lives at that other provider, not in Wix, and this guide will not match what you see. There is a quick check for that near the end.

First, confirm Wix is actually hosting your DNS

This sounds pedantic, but it is the single biggest source of wasted time. Wix offers two ways to connect a domain:

• Connect via nameservers (also called pointing your nameservers to Wix). Wix becomes your DNS host. You manage all records, including the ones in this guide, inside Wix.
• Connect via pointing (an A record and a CNAME at your existing registrar). Your DNS stays at the registrar. Wix only handles the website.

To find out which you have, sign in to Wix and go to your Domains page (under your account, or Settings then Domains). Open the domain. If you see an Advanced or Manage DNS Records section with editable TXT, CNAME and MX records, Wix is your DNS host and you are in the right place. If you only see options to point an existing domain and there is no record editor, your records belong at your registrar instead.

You can also confirm from the outside. Run your domain through the DMARC checker or look up your nameservers; if they read something like ns0.wixdns.net and ns1.wixdns.net, Wix holds your DNS. If they read GoDaddy, Cloudflare, Namecheap or anyone else, go there.

How DMARC, SPF and DKIM fit together (the short version)

These three records do different jobs and you need all three to reach a policy that actually stops impersonation.

• SPF is a single TXT record listing which servers may send mail using your domain in the hidden envelope sender. Receivers check the sending server's IP against it.
• DKIM is a cryptographic signature your mail provider adds to every message, verifiable against a public key you publish in DNS (as a TXT record, or via a CNAME that points at a key your provider hosts).
• DMARC is a TXT record at a fixed location, _dmarc.yourdomain.com, that tells receivers what to do when a message fails both SPF and DKIM, and where to send reports.

DMARC passes when at least one of SPF or DKIM both authenticates and aligns with the domain shown in the visible From address. Alignment is the concept people skip and then cannot work out why DMARC fails despite SPF passing; if it is new to you, /blog/dmarc-alignment-explained covers it and the glossary defines each term. For Wix specifically, the records you publish are standard; the friction is purely in the editor.

Opening the Wix DNS editor

From the Domains page, click the domain you want to edit, then look for Advanced and Edit DNS (the exact wording shifts between Wix interface versions, but it is consistently under an Advanced or DNS Records area). You will land on a page grouped by record type: A (Host), CNAME (Aliases), MX (Mail Servers), TXT and a few others. Each group has an Add Record button.

Two pieces of Wix vocabulary to learn now, because they appear on every record:

• Host Name. This is the subdomain part. Wix expects the host relative to your domain. For a record on the root of your domain, Wix uses @. For _dmarc.yourdomain.com, the Host Name is just _dmarc. You never type your full domain into the Host Name field, and doing so creates _dmarc.yourdomain.com.yourdomain.com, which is a classic Wix mistake.
• Value (sometimes Points to for CNAME). This is the content of the record.

Wix shows a TTL column too, covered in its own section below.

Step 1: Add the SPF record (TXT on the root)

SPF is a TXT record at the root of your domain. The value depends on who sends your mail. If you use Google Workspace, it is:

v=spf1 include:_spf.google.com ~all

If you use Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

In the Wix DNS editor, under TXT, click Add Record and set:

• Host Name: @
• Value: the SPF string, exactly, for example v=spf1 include:_spf.google.com ~all
• TTL: leave the default for now (more on this later)

A few rules that catch Wix users specifically:

• Only one SPF record per domain. SPF is the v=spf1 TXT record; a domain may have exactly one. If Wix has already auto-created an SPF record (it sometimes adds one when you set up Wix-hosted email through its partners), do not add a second. Edit the existing one and merge your includes into it. Two separate v=spf1 TXT records is a permanent error and SPF fails for everyone, every time.
• Wix may already hold a partial record. Wix-branded mailboxes are usually Google Workspace or another provider under the bonnet, and Wix can pre-populate DNS during setup. Open the TXT group and read what is there before adding anything.
• Mind the lookup limit. Every include: in SPF costs DNS lookups, and SPF permanently fails (a PermError) above ten. If you send through several services (your mailbox provider, a newsletter tool, a CRM, your help desk), they all share this one record and the lookups add up fast. Check yours with the SPF checker; if you are near the limit, /blog/spf-permerror-10-lookups explains the fix and flattening is described in /blog/how-spf-flattening-works.
• ~all versus -all. ~all is a soft fail and a safe place to start while you confirm every sender is listed. -all is a hard fail and the stricter, correct end state. Tighten to -all once your reports show nothing legitimate is being missed.

Do not put your DKIM or DMARC content into this SPF record. They are separate records at separate hosts.

Step 2: Add DKIM (the part where Wix gets fiddly)

DKIM is where Wix's quirks bite hardest, because DKIM can be published two ways and Wix handles each differently.

Option A: DKIM as a CNAME (Google Workspace, many ESPs)

Some providers ask you to add CNAME records that point at keys they host. Google Workspace publishes its DKIM as a single TXT (covered below), but plenty of email services (transactional senders, marketing platforms) give you CNAMEs that look like this:

Host: s1._domainkey
Points to: s1.domainkey.u123456.wlXXX.sendprovider.net

In Wix, under CNAME (Aliases), click Add Record and set:

• Host Name: the selector part only, for example s1._domainkey (not the full hostname)
• Value / Points to: the target your provider gave you, for example s1.domainkey.u123456.wlXXX.sendprovider.net

The Wix-specific gotchas here:

• No trailing dot needed. Some DNS hosts want the target written with a trailing dot (...sendprovider.net.). Wix does not; paste the target exactly as the provider shows it without adding a dot, and let Wix store it.
• CNAME flattening on the root only. Wix (and CNAME rules generally) forbid a CNAME at the root @, because the root must hold other record types like MX and SOA. DKIM selectors are always on a subdomain (something._domainkey), so this rarely affects DKIM directly, but it is why you cannot CNAME your root domain to Wix and keep separate MX. Keep DKIM selectors as the host and you are fine.
• Do not also add a TXT for the same selector. If your provider uses a CNAME for a selector, that selector's key is published at the provider's end; adding a conflicting TXT at the same host confuses resolvers. Pick the method your provider specifies, not both.

Option B: DKIM as a TXT record (Google Workspace, Microsoft, Zoho and others)

Google Workspace, for instance, generates a DKIM key in the Admin console and asks you to publish it as a TXT record at a host like google._domainkey. The value is long, beginning v=DKIM1; k=rsa; p= followed by a public key that can run to several hundred characters.

In Wix, under TXT, click Add Record:

• Host Name: the selector, for example google._domainkey
• Value: the entire v=DKIM1; k=rsa; p=MIIBIjANBgkqh... string

Here is the most important Wix DKIM trap, TXT length and chunking:

A single DNS TXT string is capped at 255 characters by the protocol. DKIM public keys, especially 2048-bit ones, exceed that. The DNS standard handles this by splitting the value into multiple quoted strings within one record, which resolvers concatenate back together. Most providers, including Google, hand you a key that already contains the split (you will see quotation marks breaking it into pieces). The question is how Wix wants you to enter it.

• Paste the value exactly as your provider supplies it. If Google's console shows the key as one continuous block, paste it as one block; Wix will store and serve it correctly, chunking under the hood. If the console shows it already broken into quoted segments, paste that whole thing, quotes and all, into the single Value field. Do not create several separate TXT records to hold the pieces.
• Do not manually insert spaces or line breaks into the key to make it fit. Whitespace inside the base64 key is not always ignored and can invalidate the signature.
• Strip surrounding quotes only if Wix double-quotes them. Some Wix versions add their own quoting; if your published DKIM ends up with literal quote characters inside the key, remove the ones you added and let Wix do it. After saving, verify with the DKIM checker, which tells you whether the key parses, rather than guessing.

If the checker says the key is malformed, the cause is almost always a stray space, a missing character at a chunk boundary, or a duplicated p=. Re-copy from the provider and re-paste in one go. Selectors and how providers name them are explained in /blog/dkim-selectors-explained.

Turn signing on at the provider

Publishing the DKIM record in Wix is only half the job. In Google Workspace you must then click Start authentication in the Admin console; in other providers there is an equivalent enable or verify step. Until you do, your mail is not actually signed, the DNS record sits there unused, and DMARC has no DKIM to align. Publish the record, wait for it to propagate, then flip signing on at the provider.

Step 3: Add the DMARC record (TXT at _dmarc)

DMARC lives at a fixed host, and on Wix that means a TXT record with the Host Name _dmarc. Start in monitoring mode so you collect data without affecting delivery:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; fo=1

In the Wix DNS editor, under TXT, Add Record:

• Host Name: _dmarc
• Value: v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; fo=1
• TTL: default for now

What each part does:

• p=none tells receivers to take no action on failures yet, only report. It is the safe starting point, and it is not a finished configuration; sitting on p=none forever gives you reporting but no protection, as explained in /blog/p-none-false-security.
• rua=mailto:... is the address that receives daily aggregate XML reports. Use an address you can actually read, or better, a tool that parses the XML for you. These reports are how you discover which services send as your domain before you tighten the policy.
• fo=1 asks for failure reporting detail. Optional, but useful early on.

Wix-specific notes for DMARC:

• The host is _dmarc, never the full domain. As with every Wix record, type only _dmarc. Wix appends your domain automatically.
• Wix does not validate DMARC syntax. It will happily save a typo like v=DMARC1 p=none (missing semicolon) and you will not find out until reports never arrive. Generate a known-good record with the DMARC generator and paste it, or check what you published with the DMARC checker.
• Reporting to an external address may need authorisation. If reports@ is on a different domain from the one you are protecting, that other domain has to publish a record permitting it. Keeping the rua address on the same domain avoids the issue entirely.

If you also run a subdomain that sends mail, it can need its own DMARC handling; see /blog/subdomain-dmarc-record.

TTL: why your changes seem slow, and how to test faster

Wix exposes a TTL (time to live) field on each record, in seconds, and it matters more during setup than people expect. TTL is how long resolvers cache the record. A long TTL means that after you fix a mistake, the broken version can linger in caches for hours.

• During active testing, set TTL low, 300 seconds (five minutes) is sensible, so corrections propagate quickly and you are not chasing a stale record.
• Once everything is verified and stable, you can raise it (Wix often defaults around 3600 seconds, one hour) to reduce lookups, though leaving it modest is harmless.
• Remember that lowering the TTL only takes effect after the old TTL has expired. If a record was cached at one hour and you drop it to five minutes, the first cache cycle still runs on the old hour.

After any change, give it time and then verify from outside rather than trusting that "saved" means "live". Wix can take from a few minutes to a couple of hours to publish, occasionally longer on first setup. The free checkers (DMARC, SPF, DKIM) query live DNS and tell you what the world currently sees.

Putting it in the right order

Sequence matters, because turning on enforcement before your senders are aligned is how legitimate mail gets binned.

1. Publish SPF (one TXT at @) and confirm it passes and is under ten lookups.
2. Publish DKIM (TXT or CNAME at the selector host) and enable signing at your provider. Confirm with the DKIM checker.
3. Publish DMARC at p=none and start collecting reports.
4. Read the reports for a couple of weeks. Identify every legitimate sender (your mailbox provider, newsletters, your contact-form notifications from Wix, invoicing tools) and make sure each one passes SPF or DKIM and aligns. Reading reports is covered in /blog/reading-your-first-dmarc-report.
5. Move to p=quarantine, watch again, then to p=reject. The full staged path, with the safety checks at each gate, is in /blog/reach-p-reject-without-breaking-email and /docs/the-enforcement-journey.

A common Wix-site oversight at step 4: your contact and form notification emails. If your Wix site emails you (or customers) when a form is submitted, that mail may originate from Wix's own infrastructure or a partner, using your domain in the From address. If that source is not in your SPF and not DKIM-signed for your domain, it will fail DMARC and could be quarantined once you enforce. Watch your reports for an unexpected sending source and authorise or align it before tightening the policy. The big mailbox providers' baseline expectations are summarised at /requirements.

Quick reference: what each record looks like in Wix

For a Google Workspace domain hosted on Wix, a complete set reads like this (Host Name on the left as Wix wants it, value on the right):

Type   Host             Value
TXT    @                v=spf1 include:_spf.google.com ~all
TXT    google._domainkey   v=DKIM1; k=rsa; p=MIIBIjANBgkqhki...   (full key)
TXT    _dmarc           v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; fo=1

For Microsoft 365, swap the SPF include for spf.protection.outlook.com -all, and Microsoft's DKIM is published as two CNAME records at selector1._domainkey and selector2._domainkey pointing at Microsoft-hosted targets, enabled afterwards in the Microsoft admin centre.

When the records are not in Wix at all

If you opened your Wix Domains page and found no editable record list, your DNS is hosted elsewhere. Wix only proxies the website. In that case you make these exact same records, with the same Host Name and Value logic, at whichever provider runs your nameservers (GoDaddy, Cloudflare, Namecheap, and so on). The DMARC, SPF and DKIM content does not change; only the editor does. The nameserver lookup mentioned earlier tells you where to go.

It is also worth knowing that Wix's DNS editor, while perfectly capable, is not built for the ongoing maintenance email authentication needs. There is no SPF flattening, no alerting when a record changes, and no help reading the XML reports. Those gaps are exactly where authentication quietly drifts back to broken months after you set it up.

The practical takeaway

Adding DMARC, SPF and DKIM on Wix is not hard once you know its language: every Host Name is relative (@ for the root, _dmarc for DMARC, the selector for DKIM, never the full domain), TXT values go in one field even when long, DKIM keys are pasted whole and chunked by Wix rather than split into separate records, CNAME-based DKIM points at the provider's target with no trailing dot, and a low TTL during testing saves you hours. Publish in order, start DMARC at p=none, and let the aggregate reports prove every sender aligns before you enforce.

Before and after each change, verify what is actually live with the free DMARC checker, SPF checker and DKIM checker, and split any over-length record cleanly with the DNS record splitter. If you would rather not babysit a Wix DNS editor through the journey from p=none to p=reject, and not be the person who finds out months later that a record broke, DMARC Engine hosts and maintains your DMARC, SPF and DKIM records through a one-time delegation, keeps SPF under the lookup limit automatically, translates your reports into plain language, and emails you the moment anything changes. Start at /docs/getting-started when you are ready to hand off the moving parts.