Defaults.Exposed

Defaults.Exposed › Setup walkthroughs › SPF › Wix

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

Connecting a domain to Wix and switching on business email does not set up email security. Wix’s part is holding your domain’s DNS (Domain Name System) and serving your pages. 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.

What Wix does when you connect a domain

The list is short, and knowing it stops you crediting Wix with work it isn’t doing.

Wix’s website servers don’t send your business email. The SPF value, the DKIM (DomainKeys Identified Mail) key and the DMARC (Domain-based Message Authentication, Reporting and Conformance) policy all come from the mail side, and the Wix DNS page is where you file them.

What nobody publishes for you

Done for you by WixYours to do
Holding the DNS zoneSPF TXT at @, with the value your mail provider gives you
Appending your domain to host namesDKIM TXT at the selector, with a key generated in your mail provider’s console
Serving the siteDMARC TXT at _dmarc, starting at p=none

Before any of the rows below, 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. The Wix DNS page will still let you save them, but 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 332,492,319 graded and dead domains in the October 2026 census, 175,426,748 (52.8%) 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.

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. Across the 76,563,365 domains where the census could run the DKIM check, it observed no selector on 37,896,567 (49.5%). 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:dmarc@yourdomain.com

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 (Time to Live) 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 332,492,319 graded and dead domains in the census, 249,025,625 (74.9%) 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.

How the scan grades this record: the SPF record check, with its pass and fail rules and how many domains pass it.

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 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.