SPF Records Explained: The #1 Reason Shopify Emails Get Rejected

If order confirmations, abandoned-cart flows, or shipping updates from your Shopify store are landing in spam — or not arriving at all — the cause is very often a single misconfigured DNS record: your SPF record. Specifically, it’s exceeded a hard limit that most store owners have never heard of, and once it’s exceeded, mail servers are told to distrust every email your domain sends, including the legitimate ones.

This is a deep dive on SPF only. If you want the full picture of how SPF, DKIM, and DMARC work together, see the pillar guide linked at the end.

What Is an SPF Record?

SPF (Sender Policy Framework) is a DNS TXT record that lists every server and service allowed to send email on behalf of your domain. When a receiving mail server (Gmail, Outlook, Yahoo) gets an email claiming to be from yourstore.com, it checks the SPF record published on yourstore.com’s DNS to see whether the sending server’s IP address is on the approved list.

• If the sending IP is listed → SPF passes.
• If it isn’t listed → SPF fails, and the receiving server applies whatever policy your record specifies (reject, flag, or ignore).
• If your record itself is broken — too many nested lookups, syntax errors, duplicate v=spf1 tags — the check returns permerror, and most receivers treat that the same as a fail, even for mail you actually sent.

  [VERIFIED]

Anatomy of an SPF Record

A typical Shopify store’s SPF record looks something like this:

v=spf1 include:spf.shopify.com include:_spf.google.com include:_spf.klaviyomail.com include:servers.mcsv.net ~all

Each piece has a job. Here’s how to read every part of it:

Piece	Example	What it means
Version tag	v=spf1	Every SPF record must start with this. It tells receiving mail servers “this TXT record is an SPF policy, version 1.”
Mechanism	include:spf.shopify.com	Points to another domain’s SPF record and pulls in its authorized senders. Each include costs one DNS lookup.
Mechanism	ip4: / ip6:	Authorizes a specific IP address or range directly. Does not cost a DNS lookup.
Mechanism	a / mx	Authorizes the IPs found in the domain’s A record or MX record. Each costs a lookup.
Qualifier	+ (default)	Pass — sender is authorized. This is implied if no symbol is present.
Qualifier	~all	Softfail — unauthorized senders are flagged/marked but usually still delivered. Common middle-ground setting.
Qualifier	-all	Hardfail — unauthorized senders should be rejected outright. Strictest setting, used once you’re confident every legitimate source is listed.
Qualifier	?all	Neutral — no explicit policy either way. Rarely useful in production.

  [VERIFIED]

The #1 Misconfiguration: Too Many DNS Lookups

SPF has a hard ceiling written into the spec: a maximum of 10 DNS lookups per SPF check (RFC 7208, Section 4.6.4). Mechanisms that each cost one lookup are include, a, mx, ptr, exists, and redirect. Plain IP mechanisms — ip4 and ip6 — don’t cost a lookup, which is the basis for how this gets fixed.

  [VERIFIED]

Why this hits Shopify stores specifically A Shopify store rarely sends email from one place. Shopify itself sends order and shipping notifications. Klaviyo or Omnisend sends marketing flows. Google Workspace sends staff email. A helpdesk app, a review-request app, an SMS platform, and an invoicing tool may each ask you to add their own “include:” line to your SPF record. Every one of those includes counts toward the 10-lookup ceiling — and each of those included domains may itself nest further includes, which also count. It’s common to see stores blow past the limit without anyone realizing it, because each individual app install felt like a small, safe change.

Here’s roughly what each common addition costs:

Typical sender	Adds this	Lookups it costs
Shopify (store platform)	include:spf.shopify.com	1, plus whatever its own record nests
Google Workspace	include:_spf.google.com	1, plus nested includes inside Google’s record
Klaviyo	include:_spf.klaviyomail.com	1
Mailchimp / other ESP	include:servers.mcsv.net	1
Helpdesk / support tool	include:…	1 each
Review app, SMS app, invoicing app	include:…	1 each

  [VERIFIED]

What happens when you go over

Once a lookup chain exceeds 10, the SPF check doesn’t fail gracefully — it returns permerror. Under RFC 7208, receivers are told to treat permerror as if no usable SPF record exists at all. In practice, most major mailbox providers respond by discounting or rejecting mail from that domain, even the messages sent through your legitimate, correctly configured provider. This is the mechanism behind the most common symptom store owners report: “our order confirmation emails are landing in spam and we didn’t change anything.” Often, the trigger was an unrelated app install that quietly pushed the lookup count over ten.

  [VERIFIED]

How to Read Your Current SPF Record

Before touching anything, pull the live record so you’re working from what’s actually published, not what you think is published:

• Terminal / command line: dig TXT yourstore.com +short
• Windows: nslookup -type=TXT yourstore.com
• Or use any SPF-specific checker tool that shows the resolved lookup count, not just the raw text — the raw record alone won’t show you nested lookups inside each include.

Read the record left to right. Every include, a, mx, ptr, exists, and redirect mechanism is one tick against your budget of 10 — and you have to follow the chain into each included domain’s own record to get the true total, not just count the mechanisms sitting in your own TXT record.

How to Fix an Over-Budget SPF Record

• Audit and remove dead includes. Apps get uninstalled but their SPF include often stays behind indefinitely. Cross-check every include against tools you actually still use.
• Consolidate where possible. Some providers publish a single include that already nests everything needed — don’t add a redundant secondary entry for the same service.
• Flatten the record. SPF flattening resolves includes down to their underlying IP addresses (ip4/ip6 mechanisms, which don’t cost lookups) and republishes a static record. This reclaims budget but trades it for a maintenance burden: if a vendor changes its sending IPs and you haven’t re-flattened, mail from that vendor can start failing silently.
• Use a managed flattening service for high-app-count stores. Several third-party services monitor included domains and auto-update your flattened record when a vendor’s IPs change, removing the manual re-flattening risk.

  [VENDOR CLAIM]

Whichever approach you use, re-check the resolved lookup count afterward — don’t assume the fix worked without verifying it against the live DNS record.

A Shopify-Specific Checklist

• Pull your live TXT record and count total resolved lookups (not just top-level mechanisms).
• List every app and platform actually sending email on your domain’s behalf today.
• Cross-reference that list against every include in your SPF record — remove anything for a tool you no longer use.
• Confirm your all mechanism matches your confidence level: ~all while you’re still verifying sources, -all once you’re certain the list is complete.
• Re-test after every app install or removal going forward — this isn’t a one-time fix, it’s an ongoing budget to manage.

SPF Isn’t the Whole Story

A passing SPF record authorizes a sending IP — it does not verify message content and it doesn’t survive most forwarding. That’s what DKIM (a cryptographic signature) and DMARC (the policy layer that ties SPF and DKIM together and tells receivers what to do on failure) are for. A domain with SPF but no DMARC policy is still exposed to spoofing. We cover how the three work together, including the alignment checks DMARC actually performs, in the pillar guide below.

  [VERIFIED]

Source Grading for This Article

In line with our editorial standard, every claim above is graded by confidence:

• VERIFIED — Directly from the SPF specification, RFC 7208 (the 10-lookup limit, mechanism types, permerror behavior, qualifier meanings).
• VENDOR CLAIM — Based on published claims from SPF-flattening service providers about auto-updating flattened records; verify current behavior with the specific vendor you choose before relying on it.
• DISPUTED — None in this article. Where a future edit introduces disputed material (e.g., conflicting guidance between mailbox providers), it will be flagged here.

Key Takeaways

• SPF authorizes senders by IP address, checked at the domain level via a DNS TXT record.
• The hard limit is 10 DNS lookups per check — includes, a, mx, ptr, exists, and redirect each count; ip4/ip6 don’t.
• Exceeding the limit returns permerror, which most receivers treat as a full SPF failure — for all your mail, not just the excess sender.
• Shopify stores are especially exposed because each connected app or ESP can add its own include line.
• Fix it by auditing dead includes first, then flattening or consolidating what’s left — and re-check after every app change.

For the complete picture of how SPF, DKIM, and DMARC work together, read our pillar guide: Email Deliverability for E-Commerce: The Complete Guide.

If you’re still troubleshooting deliverability beyond SPF, our guide on why your store’s emails are landing in spam covers the broader causes and fixes.