The conversation that started this post happened in early August. A customer’s marketing team had grown their stack: they had picked up a new CRM, switched marketing automation tools, added a service desk platform, signed up for a webinar tool, integrated a payment processor that sends receipts on their behalf. Each one came with the same setup instruction: “add this include to your SPF record.”
By August they had a 14-include SPF record and emails were starting to land in spam for some recipients. The marketing team blamed content. The IT team blamed the deliverability vendor. The CMO escalated to the CEO. Nobody had checked SPF.
We checked SPF. PermError. The record was making 17 DNS lookups when resolved against the major receivers. Per RFC 7208, that fails authentication at lookup 11. Every mailbox provider had been treating their outbound mail as authentication-failed for an indeterminate period. The fix took an afternoon. The damage had been months.
This kind of failure pattern is operationally common and almost never the first thing teams check when deliverability degrades. The 10-lookup limit is a real constraint, it does break things, and the way it breaks things is not always obvious from the symptoms.
What the limit actually says
RFC 7208 section 4.6.4 defines the rule. When a receiving SMTP server evaluates a sender’s SPF record, it follows includes, redirects, A records, MX records, PTR mechanisms, and existsmechanisms. Each one of these involves additional DNS lookups beyond the initial fetch of the SPF record itself.
The rule: no more than 10 DNS-querying mechanisms in the entire evaluation tree. If the evaluation exceeds 10 queries before completing, the receiver returns PermError. The behavior on PermError is up to the receiver but the practical result is the same as a soft fail or no SPF at all: the message loses authentication credit.
The 10 is cumulative across the whole tree. If your top-level SPF has 4 includes, and each of those includes has 3 sub-includes, you are at 4 + (4 * 3) = 16 lookups. Failed before evaluation completes.
The PTR mechanism counts but should never be used in modern SPF (it has been deprecated for years and causes other problems). The MX mechanism counts as one lookup plus one per MX server. The A mechanism counts as one. The exists mechanism counts as one.
How teams accumulate excess lookups
The pattern is consistent across customers. Each individual SaaS adoption seems harmless. The cumulative effect of many adoptions over time is what breaks things.
The starting state: a simple SPF record. v=spf1 include:_spf.google.com -all for a Google Workspace customer. Counts as 1 lookup for the include, plus internal lookups within _spf.google.com (which itself includes other Google records). The total cost of Google Workspace in 2023 was 4 lookups counting Google’s internal expansions.
A customer then signs up for HubSpot. HubSpot setup instructions say to add include:_spf.hubspotemail.net. The customer adds it. HubSpot’s record internally includes additional sub-records: about 3 lookups internally. The customer is now at 7 lookups.
The customer then signs up for Salesforce. Salesforce SPF setup costs another 4 lookups in their include chain. The customer is now at 11. PermError.
The customer does not know they are at PermError. Their emails seem to send. Some bounce. Some go to spam. Some reach the inbox. The deliverability is degraded but not catastrophically broken. The IT team does not investigate because nothing is “obviously” broken.
Months pass. The customer adds Mailchimp, Intercom, Zendesk, ActiveCampaign, a payment processor that sends receipts. Each one adds includes. The SPF record evaluates to 17, 19, 23 lookups. The PermError gets worse. Some receivers still let mail through; others reject outright.
The receiver behaviors that confuse the diagnosis
Different mailbox providers handle PermError differently. The variation is what makes the problem hard to spot.
Gmail historically applied PermError as something close to “treat as if there was no SPF record” — soft penalty, not hard fail. Mail still reached inbox sometimes, especially if the sender had good engagement history. This is changing in 2023 as Gmail prepares for the 2024 bulk sender requirements, where authentication will matter more.
Microsoft Outlook/Hotmail tends to be stricter on PermError. The message often gets junked or rejected outright. Customers with significant Outlook recipient base notice the problem faster than Gmail-heavy senders.
Apple iCloud Mail is somewhere between Gmail and Microsoft on PermError handling, and behavior changed in recent years.
Yahoo handling is closer to Gmail historically but is also tightening per their 2024 requirements alignment with Google.
Smaller mailbox providers and corporate mail servers vary widely. Some treat PermError as outright fail (no delivery). Some ignore it. Some log it but deliver anyway.
The result: a customer with PermError sees inconsistent deliverability across receivers. Gmail looks fine. Outlook is worse. Yahoo is mixed. The pattern points to “deliverability problem” but does not point to “SPF problem” because the same SPF record produces different outcomes at different receivers.
How to detect the actual lookup count
The diagnosis is mechanical: count the lookups. Several approaches work.
Command line with dig
The manual approach. Walk the SPF record by hand, following each include, A, MX mechanism. Count each DNS query that would be required during evaluation. Tedious but produces a definitive number.
dig TXT example.com +short
# Returns: "v=spf1 include:_spf.google.com include:_spf.hubspot.net include:salesforce.com -all"
dig TXT _spf.google.com +short
# Returns: "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com -all"
# Continue recursively...Each include triggers another lookup. Each lookup may contain more includes. Recursion stops at terminal records (those without further includes or with only IP4/IP6 mechanisms).
Online checkers
mxtoolbox.com/spf.aspx and similar tools count automatically. Paste the domain, get the lookup count. Easy and reliable for one-off diagnosis.
The catch with online checkers: they reflect what they see in DNS at the moment of the query. If the customer’s SPF or any of its includes change frequently (which happens with SaaS providers that occasionally update their SPF), the lookup count can change without the customer being aware.
Automated monitoring
For operators managing many customer domains, automated monitoring catches changes before they cause problems. Several services run periodic SPF evaluations and alert on lookup count increases or PermError conditions: dmarcian, EasyDMARC, Valimail, MailHardener. Cost is typically $50-$500/month depending on domain count.
For technical operators, scripting the check is straightforward: pull SPF records via DNS, walk the include tree, count lookups, alert if above threshold (we recommend alerting at 8 lookups, not 10, to give buffer for SaaS provider changes).
TXT record size limit reminder
Independent of the lookup limit, TXT records have practical size limits. DNS UDP packets are constrained, and TXT records longer than 255 characters must be split into multiple strings. SPF records that grow large hit this practical constraint before they hit the 10-lookup limit sometimes. Both problems require flattening as the solution.
The fixes that actually work
Once a customer is over the lookup limit, several remediation patterns apply. Each has trade-offs.
Pattern 1: SPF flattening (recommended for most cases)
The standard approach. Replace include mechanisms with their resolved IP ranges. The SPF record then includes the IPs directly instead of referencing other records that contain them.
Before flattening:
v=spf1 include:_spf.google.com include:_spf.hubspot.net include:mailchimp.com -allAfter flattening (hypothetical resolved IPs):
v=spf1 ip4:209.85.220.0/24 ip4:74.125.0.0/16 ip4:108.177.0.0/16 ip4:191.96.0.0/16 ip4:198.61.254.0/24 ip4:205.201.128.0/20 -allThe flattened version uses IP4 mechanisms which do not count toward the 10-lookup limit (IP4 and IP6 are resolved during SPF record parsing, not via additional DNS queries during evaluation).
The trade-off: when SaaS providers add or change their sending IPs, the flattened record becomes stale. The customer needs to refresh the flattening periodically. Without automation, this becomes operationally fragile.
Pattern 2: SPF flattening with automation
The improved approach. Use a service that automatically flattens and updates SPF records when underlying SaaS provider SPF records change. Services like dmarcian, EasyDMARC, Valimail, Sendmarc, and others provide this.
The customer’s SPF record contains a single include pointing to the service’s domain. The service maintains the resolved IP list and updates it as SaaS providers change theirs. The customer benefits from flattening without manual maintenance overhead.
The trade-off: dependency on the third-party service. If the service has DNS issues, the customer’s SPF authentication breaks. The service is also a fee, typically $50-$300/month depending on domain count and feature set.
Pattern 3: Subdomain separation
Split sending across subdomains, each with its own focused SPF record. Marketing campaigns go from marketing.example.com. Transactional email goes from mail.example.com. CRM-triggered messages go from crm.example.com.
Each subdomain has a simpler SPF record that includes only the senders relevant to that subdomain. The 10-lookup limit applies per record, so distributing the includes across subdomains effectively distributes the lookup count.
Before:
example.com TXT "v=spf1 include:google include:hubspot include:salesforce include:mailchimp ... -all"
# 14 includes, PermErrorAfter:
example.com TXT "v=spf1 -all"
mail.example.com TXT "v=spf1 include:google -all"
crm.example.com TXT "v=spf1 include:hubspot include:salesforce -all"
marketing.example.com TXT "v=spf1 include:mailchimp -all"Each subdomain stays well under the 10-lookup limit. Senders configure their tools to send from the appropriate subdomain. Custom from-addresses and reply-to addresses can still use the root domain for brand consistency, though there are DMARC alignment implications to consider.
The trade-off: operational complexity. Different sending tools need to be configured to use different subdomains. Brand consistency suffers slightly (especially in the visible from address if you keep alignment strict). Some customer-facing tools do not support subdomain customization easily.
Pattern 4: Drop unused includes
The most-overlooked fix. Many customers have SPF includes for SaaS tools they no longer use, evaluated, or actively send from. The IT person who added the include left the company. The tool subscription lapsed. The marketing team switched to a different platform. The include remains.
We see this pattern constantly during audits. A customer with 14 SPF includes often has 4-6 that are no longer needed. Removing them brings the lookup count back into compliance without flattening or subdomain reorganization.
The audit process: list each include in the current SPF record. For each, identify what tool it supports. Check whether that tool is still in active use and still sending mail. Remove includes for tools that are not sending.
The DMARC alignment consideration that complicates things
SPF flattening and subdomain separation interact with DMARC alignment in ways that matter.
DMARC enforcement requires either SPF alignment or DKIM alignment. SPF alignment means the domain in the Return-Path (envelope sender) matches the domain in the From header (or aligns by relaxed/strict rules per the DMARC policy).
When you flatten SPF, the IPs in the flattened record can authenticate mail from any sender, but the alignment is still based on the Return-Path domain. Mail sent through HubSpot, even with HubSpot’s IPs included in your flattened SPF, may use a HubSpot-controlled Return-Path domain that does not align with your From header. The SPF check passes, but DMARC fails alignment.
DKIM alignment then becomes the only path to DMARC pass. If HubSpot signs with DKIM using your domain (which they do when properly configured), DKIM alignment works. The mail passes DMARC via DKIM even when SPF alignment fails.
The practical implication: when migrating to flattened SPF or subdomain-separated SPF, verify DKIM is properly configured for all SaaS senders. SPF alignment may break for some sender paths, and DKIM becomes the only authentication mechanism providing DMARC compliance.
The operational pattern we use with customers
When a customer comes to us with deliverability problems and we suspect SPF issues, our diagnostic sequence runs about 15 minutes.
Pull the current SPF record. Count lookups via automated tool. If at or above 10, document the problem clearly.
Identify each include and what it supports. The customer often does not know what some includes support. We help identify with WHOIS lookups, DNS history, and asking marketing/IT for context.
Identify includes for unused tools. Most customers have 2-5 unused includes. Drop those first. Often this alone brings the record back to compliance.
If still over the limit, evaluate flattening options. For customers with stable SaaS stack, manual flattening is acceptable. For customers with frequently-changing tools, recommend an automated SPF flattening service.
If both above fail, recommend subdomain separation. The operational complexity is real but necessary at this point.
Throughout, verify DKIM is properly configured. SPF changes can break DMARC alignment in ways that DKIM can compensate for, but only if DKIM is set up correctly for every sender.
Document all changes. Customer gets a written record of what was in SPF before, what is in SPF now, why each include is present, and what to do when adding new SaaS tools in the future. The documentation matters because the SPF accumulation cycle repeats unless the customer has a process for evaluating each new tool’s lookup cost.
The longer game: avoiding the problem in the future
For customers we work with long-term, the SPF lookup management becomes part of operational hygiene. Several practices help.
Before adding any new SaaS tool that requires SPF inclusion, count the current SPF lookups. If at or above 8, do not add more. Either drop existing includes (audit for unused tools) or restructure to subdomain separation before adding the new tool.
Document every SPF include with its purpose. The single document listing “what each include is for” is more valuable than the SPF record itself. When the question “do we still need this include?” comes up in 18 months, the documentation answers it.
Quarterly SPF audits. Walk the SPF record. Verify each include is for a tool still in use. Verify the lookup count. Refresh any flattening if used. Update documentation.
Monitor for SaaS provider SPF changes. When HubSpot or Salesforce changes their SPF record, the customer’s flattened record becomes stale. Automated services handle this transparently. Manual flattening requires manual refresh.
Train marketing and IT teams. New SaaS adoptions often happen at the marketing layer without IT awareness. Teaching marketing teams to ping IT before signing up for any new tool that sends email helps prevent the silent accumulation.
What we are seeing in late 2023
The August conversation that started this post was not unusual. We are seeing more SPF issues in customer audits this year than in previous years, for two reasons.
The Gmail and Yahoo bulk sender announcements in October are pushing more customers to audit their SPF, DKIM, and DMARC setups. The audits surface PermError conditions that have been silently degrading deliverability for months or years.
SaaS adoption continues to accelerate. The average marketing stack in 2023 includes more tools than in 2020. The SPF accumulation that takes years to build up is now reaching the 10-lookup threshold for many medium-sized senders.
The PermError issues are not new. The pressure to fix them is new. We expect SPF audits to become a standard part of email deliverability work over the next 12 months as the 2024 enforcement deadlines approach.
For customers reading this with a “we haven’t checked our SPF lately” thought: check it now. The tools are free. The diagnosis takes minutes. The fix takes hours or days depending on complexity. The cost of not fixing it before February 2024 will be significant.