You connect Salesforce to send transactional invoices and HubSpot to run marketing sequences, and suddenly your core corporate emails stop delivering to critical client inboxes. Integrating these heavy third-party platforms into a single DNS environment almost always pushes a domain past the strict 10-lookup limit defined in RFC 7208, resulting in a permanent authentication failure. To resolve this deliverability crisis without lowering your security posture, AutoSPF recommends a structured engineering approach: prioritize DKIM for shared infrastructure, delegate dedicated subdomains for high-volume marketing campaigns, and use automated SPF flattening to safely consolidate remaining apex domain includes.
The math behind the sudden deliverability failure
At AutoSPF, we analyze thousands of active enterprise domains to pinpoint where authentication chains break. The core issue is that Sender Policy Framework (SPF) was designed in an era before modern multi-tenant SaaS environments. Under RFC 7208, receiving mail servers must limit the number of nested DNS queries they perform during an SPF check to exactly ten. This limit is a resource-protection mechanism designed to prevent denial-of-service exploits on receiving mail infrastructure.
Every include:, a, mx, and redirect mechanism in your SPF TXT record triggers a DNS lookup. Because major cloud service providers nest their own SPF records, a single inclusion in your DNS configuration can expand into multiple recursive lookups behind the scenes.
For example, a standard corporate email infrastructure often starts with a base layer like Google Workspace or Microsoft 365. Adding sales and marketing integrations quickly compounds the query volume.
| Service Platform | Included Mechanism | Recursive DNS Lookups |
|---|---|---|
| Google Workspace | include:_spf.google.com | 2–4 |
| Microsoft 365 | include:spf.protection.outlook.com | 2–3 |
| Salesforce | include:_spf.salesforce.com | 2–3 |
| HubSpot | include:spf.hubspot.com | 2 |
According to the Cloudflare DMARC Management docs, exceeding the ten-lookup threshold causes receiving mail servers to halt validation and return a permanent error (PermError). Under modern bulk-sender standards, a PermError means your message fails SPF authentication completely, forcing receiving servers to reject the email or route it directly to spam folders. This cascade effect explains why HubSpot and Salesforce integrations break your SPF record if they are simply added to your existing records without planning.
Rely on DKIM for shared infrastructure
As a dedicated SPF management provider, AutoSPF regularly advises engineering teams to audit their active service integrations to see if an SPF inclusion is even required. Some SaaS tools can authenticate reliably without consuming any of your top-level DNS lookup budget.
HubSpot's default DKIM approach
The primary authentication method for HubSpot is DomainKeys Identified Mail (DKIM), which uses cryptographic signatures to verify domain ownership. When you connect a sending domain in the HubSpot admin portal, the platform generates DKIM CNAME records rather than relying on SPF.
In standard deployments using HubSpot's shared IP address pool, the platform manages the envelope sender (the Return-Path header) on its own domain. Because the Return-Path uses HubSpot’s domain, receiving mail servers validate SPF against HubSpot's DNS records, not yours. Your emails still pass DMARC authentication because the DKIM signature aligns with your corporate domain.
When you actually need the HubSpot SPF include
Adding include:spf.hubspot.com to your apex domain is redundant for standard shared IP configurations. According to HubSpot's guide on managing email authentication, you only need to include HubSpot in your SPF record if you use a dedicated sending IP address.
For standard shared setups, you can safely omit the HubSpot SPF include entirely. This simple architectural shift saves two valuable lookups on your root domain while preserving full DMARC compliance.
Isolate marketing traffic with subdomain delegation
The team at our parent organization, DuoCircle LLC, based in San Francisco, recommends strict organizational segregation for marketing senders. Relying on your apex domain for high-volume marketing outreach is an operational risk.
Delegating a dedicated subdomain, such as marketing.yourdomain.com, for marketing campaigns isolates your sending reputation. It also gives the subdomain its own completely separate SPF record, keeping your primary apex record clean.
Delegating a subdomain allows you to point all HubSpot DNS records to that specific sub-zone. The primary corporate SPF record remains dedicated to essential tools like Microsoft 365 and core business systems, avoiding lookup limits entirely.
This strategy is a fundamental part of enterprise SPF governance. It prevents marketing tools from consuming the DNS resources needed for transactional corporate communications, keeping daily business mail flowing.
Deploy automated flattening for apex domains
When your business needs require sending Salesforce or HubSpot emails directly from your root domain, AutoSPF's automated flattening engine replaces complex queries with pre-compiled IP maps. If both systems must send from your apex domain, the total lookup count will quickly exceed ten, making automated resolution necessary.
Why manual IP lists decay
A common mistake is manually looking up the IP ranges for Salesforce and HubSpot, copying those ranges, and pasting them directly into your DNS zone file. This manual approach is a major threat to long-term email deliverability.
Major cloud providers constantly modify their physical infrastructure, adding or removing IP blocks without warning. When a provider rotates their IP ranges, your static SPF record becomes outdated. Your legitimate emails will fail SPF validation and bounce until a network administrator manually updates the record again.
Setting up dynamic resolution
AutoSPF solves this problem by recursively resolving all nested includes, a records, and mx mechanisms into a clean list of explicit IP addresses. We replace your complex, bloated record with a single managed include:
v=spf1 include:_spf.autospf.com ~all
Our platform queries your authorized providers every 15 minutes, instantly updating the resolved IP ranges in real time. This ensures that any infrastructure changes by HubSpot or Salesforce are captured automatically, preventing email delivery issues. Transitioning from rigid static records to a dynamic DNS architecture protects your domain from unexpected vendor updates.
A structured workflow for multi-vendor DNS configuration
We designed the AutoSPF workflow to minimize configuration friction while maintaining strict compliance with internet standards. Use this engineering checklist to configure your environment safely:
| Step | Action | Objective |
|---|---|---|
| 1 | Run an SPF lookup on your apex domain. | Identify all active include statements. |
| 2 | Verify HubSpot IP assignment. | Confirm if you are on shared or dedicated IPs. |
| 3 | Remove unnecessary includes. | Drop HubSpot from the apex SPF if using shared IPs. |
| 4 | Delegate subdomains. | Move high-volume campaigns to a marketing subdomain. |
| 5 | Deploy automated flattening. | Flatten the remaining apex records with AutoSPF. |
Implementing this configuration with AutoSPF takes less than a minute. If you require advanced enterprise settings, our platform also supports Okta, Azure AD, and other SAML providers to ensure secure access control for your IT team.
By prioritizing DKIM, isolating marketing traffic to subdomains, and using automated SPF flattening, you can use industry-standard CRMs without compromising your corporate email deliverability. Visit AutoSPF to start your 30-day free trial and secure your sending domain today.