Why Your SPF Record Breaks When You Add Another Service

Your SPF record stops working when you add another service because RFC 7208 caps SPF evaluation at 10 DNS-querying mechanisms per check (dev.to), and when your record exceeds 10 lookups, the receiving mail server stops processing and returns a permerror, doesn't try to figure out which senders are valid, doesn't partially pass, and the entire SPF check fails (valimail.com).

What counts toward the limit?

The mechanisms that count are include, a, mx, ptr, and exists, plus the redirect modifier. The ones that do not count are ip4, ip6, and all, because they are answered from the record itself without another query.

The real problem is nested lookups. include:sendgrid.net triggers SendGrid's SPF record that contains 2 additional include: mechanisms for 3 lookups total, and include:_spf.google.com triggers Google's SPF record that contains 3 additional mechanisms for 4 lookups (powerdmarc.com). A record approaches the limit with only three services, and adding one more third-party service likely pushes beyond 10 lookups (namesilo.com).

What happens when you exceed 10 lookups?

If your SPF record triggers more than 10 DNS lookups, receiving mail servers return an "SPF PermError: too many DNS lookups," and DMARC treats that as a hard fail, resulting in legitimate emails getting rejected or sent to spam without warning.

There's no built-in alert system for this, your DNS provider won't flag it, your email-sending platforms won't warn you, and most teams only find the problem reactively, after complaints start rolling in or deliverability metrics drop. The ten-lookup limit is a slow-motion failure: nothing breaks the day you cross it, and by the time you notice, some of your mail has been quietly failing for a while.

Why adding one more include breaks everything

The 11th lookup is never evaluated, and any email service listed after that point silently loses authorization, causing emails from those services to start failing authentication (autospf.com). SPF too many DNS lookups is a hard failure, and your emails can get rejected, routed to spam, or silently dropped, even when they're completely legitimate.

The RFC 7208 specification enforces this to protect receiving mail servers from a Denial-of-Service (DoS) attack meant to shut down a network or machine (inboxally.com). The SPF 10-lookup limit exists to protect DNS infrastructure from abuse, because when a receiving mail server checks an SPF record, it must resolve each mechanism that references an external domain by making additional DNS queries, and without a cap, a maliciously crafted or poorly maintained SPF record could force receiving servers to make dozens or hundreds of DNS queries (emailindustries.com).

What flattening is and how it works

SPF flattening is the process of optimizing a Sender Policy Framework record by replacing domain-based include: mechanisms with their respective IP addresses, so the resulting SPF record has fewer DNS lookups. For each include in the record, everything it references (sub-includes, a, mx) is resolved recursively until the full list of authorized address ranges emerges, then the include is replaced by the corresponding ip4: and ip6: addresses.

SPF flattening replaces DNS-querying SPF mechanisms such as a, mx, and include with the ip4 and ip6 addresses they point to, condensing everything into a single SPF record, which cuts the DNS lookups needed to validate the record to one, avoiding the 10-lookup limit.

What flattening costs in maintenance

The IP ranges behind a provider's include are not frozen, and Microsoft, Google, SendGrid and the rest add, remove or reorganize their servers regularly. Most email and cloud service providers regularly add, remove, or update their sending IP addresses, and a flattened SPF record quickly becomes outdated unless you manually track every change.

Manual SPF flattening creates more problems than it solves: what works today breaks next month when a service updates their infrastructure, and Microsoft, Google, and Salesforce regularly modify their IP ranges without notice, making your flattened record a maintenance nightmare.

The downside is maintenance: you must monitor every provider for IP changes and update your record promptly, miss a change and your emails from that provider fail authentication, and for organizations using multiple dynamic email services, this is an ongoing, high-stakes maintenance task that demands constant vigilance. You forget the record exists, a flattened record needs revisiting on a schedule forever, six months later the person who flattened it has moved on, the new owner sees a long list of IP4 ranges with no comments explaining where they came from, nobody dares touch it, the record quietly decays, and documentation in DNS is non-existent.

Automated flattening services exist and offer low-maintenance with SPF records constantly updated as your legitimate email senders update their sending configurations, but the main disadvantages of automated SPF flattening are cost and control: some providers charge by lookup served, others by domain, while others charge for each time the records are flattened or updated, and there is also a degree of control lost when outsourcing to a 3rd party, with dependence on your host for accurate SPF records, timely updates and uptime.

Check your current lookup count with the free AI-visibility check (/check) to see where your record stands. If you are already at seven or more lookups and evaluating another email service, test whether adding it would push you over before going live. You can validate your SPF configuration through the guide (/guide) before making changes that might break existing authentication. If you need to flatten your record, budget time every quarter to audit whether the IP addresses in your flattened record still match what your providers are actually using, and consider whether ActiScore's pricing (/pricing) makes sense for ongoing monitoring of DNS and TLS configuration alongside your broader security posture.