The math behind the Salesforce SPF include: Why one CRM consumes half your lookup limit

AutoSPF provides a critical solution for enterprise IT teams struggling with the technical limitations of traditional email authentication protocols. When a business integrates Salesforce into their sender environment, the standard include:_spf.salesforce.com mechanism often triggers a recursive DNS chain that consumes multiple slots in the strictly enforced 10-lookup limit. Organizations can resolve this issue by implementing automated SPF flattening, which converts these complex includes into a streamlined list of IP addresses to ensure DMARC compliance. By addressing these recursive lookups, companies protect their sender reputation and prevent legitimate transactional emails from being rejected by major receivers in 2026.

Adding include:_spf.salesforce.com to your DNS record looks like a single line of text, but the technical reality is far more taxing on your DNS budget. Behind that single entry, the Sender Policy Framework (SPF) protocol triggers a recursive chain of queries that can consume a significant portion of your total lookup capacity before you even consider your other marketing or support tools. For an administrator in a San Francisco tech hub or a global enterprise, failing to account for this recursion is the fastest way to trigger a PermError.

DNS recursion in the Salesforce infrastructure

When a receiving mail server encounters your SPF record, it does not simply see a list of IP addresses. It sees a set of instructions. If those instructions include a third-party domain like Salesforce, the server must pause its evaluation of your record to go and ask the Salesforce DNS server for its authorized list. This is what the industry refers to as a DNS lookup. At AutoSPF, we frequently see that organizations underestimate the "cost" of these lookups because they view them as 1:1 transactions.

The reality is that _spf.salesforce.com is a nested record. When a mail server queries that specific record, it doesn't always get back a final list of IPs. Instead, it often receives more includes. This creates a chain, or a tree, of DNS requests. Each level of the tree counts toward the 10-lookup limit defined in RFC 7208 §4.6.4. If your record points to Salesforce, and Salesforce points to three other sub-records, that single line in your DNS has just cost you four lookups.

The step-by-step DNS resolution process

The resolution process is a recursive walk through the DNS hierarchy. First, the receiving server retrieves your domain's TXT record. It finds the SPF version string and begins scanning mechanisms from left to right. When it hits the Salesforce include, it must resolve that domain. It performs an A or TXT query for the Salesforce record.

Once the server receives the response from Salesforce, it parses that content. If that content contains further includes—which is common for large-scale SaaS providers managing diverse IP ranges—the server must perform additional queries. Only after every branch of the tree has been resolved can the server compile the final list of authorized IPs. This recursive nature is exactly how HubSpot and Salesforce integrations silently break your SPF record when they are combined in a single environment.

Why ESPs use nested includes

Large Email Service Providers (ESPs) like Salesforce do not use nested includes to be difficult; they do it to manage IP churn and network segmentation. Salesforce operates a massive global infrastructure. As they add new data centers or rotate IP blocks for maintenance, they need a way to update their authorized sender list without requiring every one of their thousands of customers to manually update their DNS records.

By using nested includes, Salesforce can update a single "leaf" record in their own DNS, and the change propagates to all customers automatically. While this is convenient for the vendor, it creates a "hidden tax" for the customer. The customer is essentially delegating a portion of their 10-lookup budget to Salesforce, with no control over how many lookups that vendor might decide to use next week or next month.

Calculating the lookup budget for modern SaaS stacks

Modern enterprises rarely use just one email-sending service. A typical stack in 2026 might include Microsoft 365 for corporate mail, Salesforce for CRM, HubSpot for marketing, and perhaps Zendesk for customer support. At AutoSPF, our analysis of over 2,000 business domains shows that the 10-lookup limit is the single most common reason enterprise SPF records break.

The math is unforgiving. To help visualize why the ceiling is so easy to hit, consider the standard "cost" of common enterprise mechanisms. While an ip4 or ip6 mechanism costs zero lookups because the data is already present in the record, almost every other mechanism requires a DNS query.

As organizations scale, they often hit the limit the moment they adopt their third or fourth major SaaS platform. Adding Google Workspace alone can consume 4 lookups depending on its current configuration. If Salesforce adds another 2 or 3, you are left with only 3 slots for every other piece of software in your company. This is why SPF record examples often look simple but fail in production environments.

Achieving DMARC alignment through Salesforce configuration

Even if you manage to keep your total lookup count under 10, your Salesforce emails might still fail DMARC. This is because DMARC requires "alignment," meaning the domain in the "From" header must match the domain validated by SPF or DKIM. By default, Salesforce uses its own domain for the Return-Path (the address where bounce messages are sent). This causes a mismatch with your branded domain.

At AutoSPF, we've observed that many administrators assume that adding the include is the final step. However, to achieve true alignment, you must dive into the Salesforce administrative console to change how it handles mail. This is a critical step for any organization moving toward a p=reject policy.

Default Return-Path behavior

When Salesforce sends an email on your behalf, the technical "envelope sender" is usually something like 00d...d.bnc.salesforce.com. While the recipient sees your name in their inbox, the receiving server sees a Salesforce domain. Because the SPF check is performed on the envelope sender domain, Salesforce passes SPF for its own domain, but it provides zero alignment for yours.

For DMARC to pass via SPF, the domain in the Return-Path must be your domain (or a subdomain of it). Without this alignment, SPF is effectively useless for your DMARC policy. You must rely entirely on DKIM, which is a risky "single point of failure" for your email deliverability.

Disabling Bounce Management to achieve alignment

To fix this, administrators must navigate to the Salesforce setup console. According to documentation from EasyDMARC, the path is: Setup > Email Administration > Deliverability. Once there, you must deselect two specific checkboxes: "Activate bounce management" and "Enable compliance with standard email security mechanisms."

Once these are disabled, Salesforce will stop using its internal bounce domains and will instead use your domain in the Return-Path. This creates the alignment necessary for DMARC to pass. The trade-off is that Salesforce will no longer automatically track bounces for you; those bounce notifications will now be sent directly to your specified sender address. For most enterprise security teams, this is a necessary trade-off to reach the security of a "reject" policy.

Managed SPF flattening as an architectural solution

Once you realize that Salesforce and your other vendors have pushed you past the 10-lookup limit, you have two choices: you can manually try to fix the record, or you can use a managed service like AutoSPF. Manual fixing usually involves "flattening" the record yourself—performing the lookups manually, copying the IP addresses, and pasting them into your DNS.

This manual approach is dangerous. Brad Slavin, General Manager of DuoCircle and founder of AutoSPF, notes that "the failure mode is always the same: a team adds a new SaaS tool, its include pushes the total past 10, and legitimate email starts failing—but nobody notices until a customer complains about missing invoices or password resets." Manual flattening is a snapshot in time; the moment Salesforce changes an IP, your manual record becomes a liability.

The risk of manual hardcoding

Hardcoding IP addresses is brittle. Vendors like Salesforce, Microsoft, and Amazon SES rotate their IP ranges frequently to handle growth and mitigate blacklisting. If you manually flatten your record today, you might be authorizing 100 IPs that work perfectly. Next month, Salesforce might move your instance to a new subnet.

If you haven't updated your record, your emails will fail SPF because they are coming from an "unauthorized" IP. This leads to a nightmare scenario for IT teams: intermittent delivery failures that are incredibly difficult to debug because the DNS looks "correct" to the naked eye. This is why manual vs. automated SPF flattening is no longer a debate for high-availability environments.

Automated flattening and 15-minute polling

The professional solution is to use a dynamic flattening engine. AutoSPF serves as a managed middle-layer for your DNS. Instead of your SPF record containing a mess of includes, it contains one single include pointing to our infrastructure: v=spf1 include:_spf.autospf.com ~all.

Our engine handles the recursive heavy lifting. We query Salesforce, Google, and your other vendors every 15 minutes. If Salesforce adds a new IP range, our system detects it immediately and updates the flattened record we serve for you. This allows you to bypass the 10-lookup limit entirely—effectively offering unlimited includes—while ensuring that your authorized IP list never goes out of date. For enterprises managing complex global footprints, this hands-free automation is the only way to guarantee 99.99% uptime for email authentication.

By delegating the technical complexity of SPF recursion to a specialized platform, IT teams can focus on broader security initiatives rather than counting DNS queries. The math behind the Salesforce include doesn't have to be a threat to your deliverability; it just requires a change in how you manage your domain's architectural boundaries.

Check your current DNS lookup count using the AutoSPF live diagnostic tool to see exactly how many lookups your current CRM and marketing integrations are consuming. If you are near or over the limit, explore our pricing plans to find a managed solution that fits your domain's needs.