How to Add an SPF Record on BigCommerce

First, find out where your DNS lives

This is the step people skip, and it is the reason most SPF fixes fail. BigCommerce does have a DNS editor with A, CNAME and TXT support, but only in specific circumstances.

You can use the BigCommerce DNS editor if you purchased your domain through BigCommerce, or if you have pointed a custom domain to BigCommerce via nameservers. If neither applies, your DNS is still at your registrar or wherever your nameservers point, and that is where the record goes.

If you run multiple storefronts, note that only the default storefront's DNS is manageable in the panel.

What SPF actually is

SPF is a single TXT record on your domain that lists which servers are allowed to send email as you. Receiving mail servers check it. If someone spoofs your domain from a server that is not listed, SPF is what flags it.

Two things worth knowing. There was once a dedicated SPF record type in DNS. It is deprecated, so use TXT. And subdomains are not covered by the parent domain's SPF record. If you send from a subdomain, it needs its own.

There is more background on our SPF glossary entry.

Write one record, not several

The single most common SPF fault is having more than one SPF record on a domain. That is a permerror, a hard failure. It does not average out or pick the better one. It just breaks.

This happens when a store owner adds a record for their email provider, then later adds another for a newsletter tool. The fix is to merge every sender into one record with multiple include: mechanisms and one terminal all.

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

One record. Multiple includes. One all at the end. The SendGrid include is only correct when Automated Security is switched off. With Automated Security on, which is the default, SendGrid uses CNAME-based authentication and no include is needed at all. Do not add it out of habit.

Confirmed values for common senders

Use the value your provider publishes. These are the ones we have verified.

→Google Workspace: v=spf1 include:_spf.google.com ~all
→Microsoft 365: v=spf1 include:spf.protection.outlook.com -all. GCC High and DoD tenants use include:spf.protection.office365.us, and 21Vianet uses include:spf.protection.partner.outlook.cn.
→SendGrid: include:sendgrid.net, but only with Automated Security off. On by default means no include.
→A domain that never sends email: v=spf1 -all. If you own a domain purely to redirect it, publish this. It is a free win.
→Everyone else: check your provider's current documentation. Vendors are moving away from include: values towards CNAME-delegated Return-Path subdomains, so an include you read in a 2023 blog post may now be wrong or unnecessary.

Adding the record

Whether you are in the BigCommerce DNS editor or at a registrar, the shape is the same. Record type TXT, host at the domain root, value as above.

1.Check for an existing SPF record first. Look for any TXT record starting with v=spf1. If one exists, edit it rather than adding a second.
2.Create or edit a TXT record at the root of your domain.
3.BigCommerce DNS editor gotcha: @ is not a valid value there. Enter your bare domain instead, for example example.com. Most other DNS hosts do accept @ for the root.
4.Paste your merged SPF value.
5.Save and wait. Propagation is usually minutes, sometimes longer. Then confirm it with a free check.

The 10-lookup limit

SPF has a budget. Your record is allowed ten DNS lookups, and include:, a, mx, exists and redirect each cost one. Worse, they nest. An include: that itself contains includes spends your budget on your behalf.

Go over ten and you get a permerror, which means your SPF stops working entirely. ip4:, ip6: and all cost nothing, so they are safe to use freely.

The practical advice: do not add an include for every tool that ever asks. Add it only if that tool actually sends mail from your domain.

Should you end with ~all or -all?

This one genuinely divides the industry, so we will not pretend otherwise. ~all is softfail, meaning "probably not authorised". -all is fail, meaning "not authorised". ?all is neutral and does almost nothing.

Google recommends ~all for Workspace. Microsoft recommends -all. Both are giving reasonable advice for their own platform.

Our guidance: start with ~all while you confirm every legitimate sender is listed. Once your DMARC reports show your real mail passing, move to -all. Going straight to -all before you know what sends on your behalf is how invoices end up in spam.

The mistake that catches nearly everyone

Most DNS editors take a relative name and quietly append your domain to it. So if you type example.com into a Host field that expects a relative name, you create a record for example.com.example.com, which resolves for nobody.

The exception is AWS Route 53, which takes a fully qualified name and does not append anything. Route 53 also wants values in double quotes.

BigCommerce is its own special case in the other direction: it rejects @, so the bare domain is what it wants. Read the field label, and check the record after you save it.

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

It depends on how your domain is connected. BigCommerce gives you a DNS editor only if you bought the domain through BigCommerce, or pointed a custom domain to BigCommerce using its nameservers. In any other setup, including a domain pointed by CNAME or A record, your DNS is elsewhere and the record goes there.

Why does BigCommerce reject @ in the DNS editor?

It simply is not a valid value in that editor. Where most DNS hosts use @ to mean the root of your domain, BigCommerce wants the bare domain typed out, for example example.com. It is a small quirk that costs people a lot of time.

Can I have a separate SPF record for BigCommerce and one for my email provider?

No, and this is the most common SPF mistake there is. A domain may have exactly one SPF record. Two records is a permerror and email authentication fails. Merge every sender into one record using multiple include: mechanisms and a single all at the end.

What is the 10-lookup limit and how do I know if I am over it?

SPF allows ten DNS lookups per record. Each include:, a, mx, exists and redirect costs one, and they nest, so a single include can consume several. Exceeding ten is a permerror that breaks SPF entirely. Trim includes for tools that do not actually send mail from your domain. ip4: and ip6: entries cost nothing.

Does SPF alone stop people faking emails from my store?

Not on its own. SPF tells receiving servers which senders are legitimate, but it does not tell them what to do about fakes. That is DMARC's job. SPF first, then DMARC on top. See our DMARC on BigCommerce guide for the next step.