SPF for Wix, and the records Wix does not publish for you

You built the site on Wix, connected your domain and switched on business email, and the reasonable assumption is that email security arrived with the build. It didn’t. Wix holds your domain’s DNS and serves your pages, and that is the whole of its part. The three records that stop someone forging your address (SPF, DKIM and DMARC) come from whoever runs your mailboxes, and you put them into Wix DNS yourself. This page splits the job into the column Wix handles and the column that’s yours, with the exact record to paste for each row, the field it goes in, and the failure it prevents.

What Wix does when you connect a domain

The left column is short. Being precise about it stops you crediting Wix with work it isn’t doing.

• It holds the DNS zone, provided your nameservers point at Wix. Wix answers queries for your domain and stores whatever records you add.
• It appends your domain to host names. Type @ and Wix reads it as the bare domain; type _dmarc and Wix publishes _dmarc.yourdomain.com. You never type the full domain in the Host Name field.
• It serves the website, on its own web servers with its own certificate.
• If you bought Wix business email, it sold you a Google Workspace mailbox and may have added an SPF TXT record at the same time. That record carries Google’s value, and it may be the only one of the three that exists on your domain today.

Wix’s website servers don’t send your business email. The SPF value, the DKIM key and the DMARC policy all come from the mail side, and the Wix DNS page is where you file them.

What nobody publishes for you

Each right-hand row below has the same three parts: the record, the field, and the specific thing that goes wrong without it. Before any of them, there’s one precondition that breaks most attempts.

Check where your nameservers point first

A DNS record only takes effect where the domain’s nameservers point. If you bought the domain through Wix, or connected an outside domain by pointing its nameservers at Wix, Wix is your DNS host and the steps below apply. If the nameservers still point at your registrar, a web host or another DNS provider, the records have to be added there, and adding them in Wix does nothing at all. The Wix DNS page will still let you save them, which is the frustrating part, because nothing on the internet will ask Wix for those records.

To find the DNS page in Wix, open Domains, click the domain, then open its DNS settings. The section is labelled DNS, Records or Advanced, and sometimes Manage DNS Records. The TXT section is where all three records go.

Row one: the SPF record at @

SPF is one TXT record at the root of your domain listing the servers allowed to send mail as you. The value depends on who runs your mailboxes. For a domain that sends only through Google Workspace, which includes Wix-sold business email, the record is:

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

For Microsoft 365 it’s:

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

Use the value your mail provider gives you. In Wix, add a TXT record, put @ in Host Name, paste the value into the Value field (sometimes labelled Text) and save. Typing your full domain name in Host Name puts the record in the wrong place. Don’t add quotes around the value either; Wix quotes it for you, and adding your own can produce a broken, double-quoted record.

Before you add anything, look for an existing TXT record starting v=spf1. If switching on business email created one, edit that record. A domain gets exactly one SPF record. Two v=spf1 records break SPF entirely, because a receiver that finds two returns a permanent error rather than picking one. When you add a second sender later, a newsletter tool for instance, it goes into the same record as another include: and never as a second TXT.

The failure this row prevents runs in both directions. Without SPF, anyone can put your address on a forged invoice and the receiving server has no list to check it against; with SPF, your own mail stops looking like the forgery. Missing SPF is common. Of the 316,600,902 graded and dead domains in the September 2026 census, 166,497,698 (52.6%) publish no SPF record at all. The SPF piece explains what the ~all and -all endings do and when to use each.

Row two: the DKIM key at the selector

DKIM is the one people get tangled on, because two companies are involved and neither of them does the other’s job. Your mail provider generates the key and Wix publishes it. You can’t make the value up, and Wix can’t make it for you.

Sign in to your mail provider’s admin console. For Wix business email that’s the Google admin console, since the mailbox is Google Workspace; for Microsoft 365 or another host, it’s their console instead. Find the DKIM or email authentication section and generate a key for your domain. The provider gives you two things: a selector host ending ._domainkey, such as google._domainkey or selector1._domainkey, and a long TXT value that begins:

v=DKIM1; k=rsa; p=

and continues for hundreds of characters of public key. Keep that page open while you copy.

Back in Wix, add a TXT record. Host Name takes only the selector part, so google._domainkey and nothing more. Wix appends your domain, and entering google._domainkey.yourdomain.com creates the broken host google._domainkey.yourdomain.com.yourdomain.com, where no receiver will look for a key. Paste the full value, check nothing was cut off and no stray spaces or line breaks crept in on the way, and save without adding quotes.

Some providers then need a final click, usually labelled something like “start authentication”, after the record is live. Skip it and the key sits in DNS while nothing gets signed. The selector in Wix has to match the provider’s character for character, because the receiver builds its DNS lookup from the selector named in the message header.

This row prevents tampering and impersonation that SPF alone can’t catch. SPF checks the sending server; DKIM checks the message itself, so a forwarded email that has lost its SPF alignment still carries a valid signature, which is what keeps your quote out of spam when a customer forwards it to a colleague. Across the 75,823,110 domains where the September 2026 census could run the DKIM check, it observed no selector on 37,823,648 (49.9%). If you can’t work out which selector your provider uses, find your DKIM selector walks through it.

Row three: the DMARC policy at _dmarc

DMARC tells receivers what to do with mail that fails SPF and DKIM, and it’s the record that turns the other two into an instruction a receiver will act on. It’s one TXT record at Host Name _dmarc, with the leading _ character included and without your domain on the end. A safe starting value is:

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

p=none monitors and blocks nothing. The rua= address is where the aggregate reports go, and it has to be a mailbox someone reads, since those reports are how you learn whether your genuine mail is passing before you tighten anything. Replace the example address with one of your own. Leave TTL at the default, save without quotes, and check there isn’t already a TXT record at _dmarc before you add one; if there is, edit it.

DMARC depends on the two rows above. Publish p=reject before SPF and DKIM are working and your own quotes and invoices get refused along with the forgeries. The order is p=none first, then p=quarantine once the reports show your real mail passing, then p=reject.

This row prevents the forgery itself. With SPF and DKIM published and no DMARC, a receiver can watch a message fail both checks and still have no instruction from you about what to do with it, so most will deliver it anyway. Of the 316,600,902 graded and dead domains in the September 2026 census, 238,156,049 (75.2%) have no DMARC record. The DMARC piece covers reading the reports and what each policy tag means.

Wait, then check

DNS changes take from a few minutes up to a couple of hours to apply everywhere. Once the records have had time to spread, run the free scan below. It confirms in plain language whether each record is published and correct, and tells you which of the three rows still needs work. Scan data is processed in the EU.

If a record shows as missing when you’re sure you saved it, revisit the nameserver check at the top of this page. A record saved on the Wix DNS page while the nameservers point somewhere else is the most common reason a scan comes back unchanged, and the fix is to add the same record at the company the nameservers name.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.