How to Add an SPF Record on Shopify

The short answer

There is no SPF field anywhere in your Shopify admin, and you are not missing it. SPF is a DNS record. It lists the servers allowed to send email using your domain name, and it lives with whoever runs your DNS.

So the first question is not "where in Shopify", it is "who manages my domain".

Step 1: find out where your DNS lives

Shopify domains fall into two camps, and they lead to two different places.

Domain managed by Shopify

If you bought your domain through Shopify, or transferred it in, Shopify gives you a DNS editor that supports TXT records. That is where your SPF record goes.

Third-party domain

If your domain is with GoDaddy, Namecheap, Cloudflare or any other registrar and simply points at Shopify, your DNS stays there. Add the record at the registrar, not in Shopify.

Step 2: check whether you already have one

This step matters more than people realise. You are only allowed one SPF record per domain. Two SPF records is not twice the protection. It is a permanent error, called a permerror, and it makes receiving mail servers throw the whole thing out. It is one of the most common email authentication faults there is.

So look before you add. If a TXT record starting with v=spf1 already exists on your domain, you edit that one. You do not add a second.

Step 3: write the record

An SPF record is a single TXT record on the domain itself. It names your senders, then ends with one all mechanism. If you use Google Workspace for your store email:

Type:  TXT
Name:  @
Value: v=spf1 include:_spf.google.com ~all

Use @ for the root domain in most DNS editors. Some ask for the bare domain instead. Route 53 wants the value in double quotes.

Common sender values

These are the ones worth publishing, because they are stable and confirmed. Anything else, check the vendor's own docs on the day you set it up.

→Google Workspace: v=spf1 include:_spf.google.com ~all
→Microsoft 365: v=spf1 include:spf.protection.outlook.com -all. Microsoft recommends the strict -all ending.
→SendGrid: only add include:sendgrid.net if Automated Security is turned off. It is on by default, and when it is on SendGrid uses CNAME-based authentication and you need no include at all. Adding one anyway just burns a lookup.
→Multiple senders: merge them into one record with several include: mechanisms and a single all at the end. For example v=spf1 include:_spf.google.com include:sendgrid.net ~all.

The 10-lookup limit

SPF has a hard ceiling. Your record is allowed to trigger at most 10 DNS lookups when it is evaluated. Every include:, a, mx, exists and redirect costs one, and they nest, so an include can quietly cost you several. Go over 10 and you get a permerror, which means your SPF fails completely.

ip4: and ip6: and all cost nothing. If you are close to the limit, swapping an include for the actual IP addresses buys you room.

This is also why the industry is shifting. Vendors like SendGrid and Amazon SES now prefer CNAME-delegated sending subdomains over "add our include". It preserves your lookup budget. Treat any include value you read online as something to verify at the time, not a permanent fact.

~all or -all?

The ending of your record tells receivers what to do with mail that fails.

~all is softfail. It means "probably not authorised". -all is fail. It means "not authorised, full stop". ?all is neutral and does almost nothing.

The vendors genuinely disagree here, and it is worth knowing that. Google recommends ~all for Workspace. Microsoft recommends -all. Both are defensible.

Our advice: start with ~all. Live with it while you confirm every legitimate sender is passing, including your invoicing tool, your newsletter, your helpdesk and anything else that sends in your name. Then move to -all. Going straight to -all before you know your full sender list is how you make real customer email disappear.

One exception: if a domain sends no mail at all, park it properly with v=spf1 -all. That is the correct, strict answer.

Things that catch people out

→Subdomains are not covered. An SPF record on yourstore.com does nothing for mail.yourstore.com. Subdomains that send mail need their own record.
→Do not use the old SPF record type. DNS once had a dedicated SPF record type (99). It is deprecated. Use TXT.
→Cloudflare users: TXT records are always DNS-only and cannot be proxied, so there is no orange cloud to worry about here.
→Give it time. DNS changes are not instant. Namecheap, for example, quotes around 30 minutes.

Then do DMARC

SPF on its own is half the job. It tells receivers who may send as you, but it does not tell them what to do when something fails, and it gives you no visibility. That is what DMARC adds, and it is the same kind of DNS record in the same place. Do that next.

When you are done, run a free check to confirm the record is live and readable.

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

Where do I add an SPF record in Shopify?

Nowhere, strictly speaking. SPF is a DNS record, not a Shopify setting. If your domain is managed by Shopify, use the DNS editor Shopify provides, which supports TXT records. If your domain is with a third-party registrar, add the TXT record there instead.

Can I have two SPF records?

No. One SPF record per domain, always. Two records cause a permerror, which is a hard failure, and receiving servers will discard your SPF entirely. If you have more than one sender, merge them into a single record with multiple include: mechanisms and one all at the end.

Should my SPF record end in ~all or -all?

Start with ~all, then move to -all once you are certain every legitimate sender passes. The vendors disagree: Google recommends ~all for Workspace, Microsoft recommends -all. Both are reasonable. Going to -all too early is how legitimate customer email gets rejected. A domain that sends no mail at all should use v=spf1 -all.

What is the 10-lookup limit?

SPF may trigger at most 10 DNS lookups when evaluated. Each include:, a, mx, exists and redirect costs one, and they nest, so includes can cost several each. Exceeding 10 causes a permerror and your SPF fails completely. ip4:, ip6: and all cost nothing.

Does SPF cover my subdomains?

No. SPF is not inherited. A record on yourstore.com does not protect mail.yourstore.com. Any subdomain that sends email needs its own SPF record.