How to Add an SPF Record on Wix

First, work out where your DNS actually lives

This is the step everyone skips, and it is why so many people add a record and see nothing change. Wix is clear about it: "If your domain is connected to Wix via pointing, you must add or update TXT records with your domain host (not Wix)."

So there are two cases:

→Connected by nameservers. Your domain uses Wix's nameservers, so Wix hosts your DNS. Add the TXT record in the Wix editor.
→Connected by pointing. You added A or CNAME records at your registrar to point at Wix. Your registrar still hosts your DNS. Add the TXT record there, not in Wix. Anything you add in Wix will be ignored.
→Bought your domain through Wix. Wix hosts the DNS. Note that the NS records for a Wix-registered domain cannot be changed, so you stay on Wix DNS.

What an SPF record is

SPF is a single TXT record on your domain that lists who is allowed to send email as you. Inboxes look it up and use it to judge whether a message is genuine. Without it, anyone can put your domain in the From line of a phishing email and it looks plausible.

It is a TXT record, not the old SPF record type. That type is deprecated and you should not use it. There is more background on our SPF glossary entry.

The rule that breaks most setups

You get exactly one SPF record per domain. Two SPF records is a permerror, a hard failure, and it is one of the most common faults we see. It usually happens when someone adds a second record for a new email tool instead of merging it into the existing one.

If you use more than one sender, they all go in one record with multiple include: mechanisms and one terminal all:

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

One record, not two. That SendGrid include is only correct when Automated Security is turned OFF. With Automated Security ON, which is the default, SendGrid uses CNAME-based authentication and no include is needed at all. Check before you add it.

Records for the common providers

If you only send through one provider, use its record as-is.

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

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

A domain that sends no email at all:
  v=spf1 -all

Vendor include values change over time. Treat these as verify-at-the-time facts, not something to paste blindly in three years.

How to add it

1.Work out whether your domain is connected by nameservers or by pointing. If it is pointing, everything below happens at your domain host instead of in Wix.
2.Check whether you already have an SPF record. Look for an existing TXT record on your root domain that starts with v=spf1. If one exists, edit it. Do not add a second.
3.Add or edit the TXT record on the domain itself, not on a subdomain. Most DNS editors use @ for the root.
4.Paste your single, merged SPF value.
5.Save and wait for DNS to update. Then re-check it.

Two limits worth knowing

The 10-lookup limit. Each include:, a, mx, exists and redirect costs a DNS lookup, and they nest, so an include can quietly cost several. Go past ten and the whole record is a permerror. ip4:, ip6: and all cost nothing. If you have collected includes from five different tools over the years, check this.

Subdomains are not covered. Your root domain's SPF record does nothing for mail.yourdomain.com. Subdomains that send email need their own record.

Should you end with ~all or -all?

The vendors genuinely disagree, so anyone who tells you there is one right answer is guessing. Google recommends ~all for Workspace. Microsoft recommends -all.

~all is a softfail: probably not authorised. -all is a fail: not authorised. ?all is neutral and does almost nothing.

Our advice: start with ~all while you confirm every legitimate sender is in the record. Once you are sure nothing legitimate is missing, move to -all. Going straight to -all with a sender you forgot about means real email quietly disappearing.

A domain that never sends email is the easy case: v=spf1 -all and you are done.

One thing that is changing

The old model was "add our include: to your SPF record". Vendors are moving away from it towards CNAME-delegated Return-Path subdomains instead. SendGrid's Automated Security, Mailchimp and Amazon SES all work this way now. It preserves your 10-lookup budget, which is the point.

Practically, this means an include you find in an old blog post may be unnecessary or wrong today. Check the vendor's current instructions rather than trusting a guide.

Then do DMARC

SPF on its own is only half the job. It says who may send as you. It does not tell inboxes what to do about messages that fail. That is DMARC, and it is the piece that actually stops the fakes. Do SPF first, then DMARC on p=none, then tighten.

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

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

Can I have two SPF records?

No. One SPF record per domain. Two records is a permerror, a hard failure, and it is one of the most common email authentication faults there is. Merge every sender into one record with multiple include: mechanisms and a single terminal all.

Should I use ~all or -all?

The vendors disagree. Google recommends ~all for Workspace and Microsoft recommends -all. Start with ~all while you confirm every legitimate sender is listed, then move to -all once you are certain nothing is missing.

I added an SPF record and nothing changed. Why?

The most likely cause is that your domain is pointed to Wix rather than connected by nameservers, so your registrar is still answering DNS queries and the record you added in Wix is not being served. The next most likely cause is a second SPF record already on the domain.

Does my SPF record cover my subdomains?

No. SPF is not inherited. A subdomain that sends email needs its own SPF record on that subdomain.