How to authorise SaaS email senders without breaking domain authentication

At 2:00 AM, Gmail bounces a critical batch of password reset emails because someone on the marketing team added a new CRM to your DNS and quietly pushed your domain past the 10-lookup limit. To securely integrate external SaaS senders without triggering deliverability failures, you must separate DKIM configuration from SPF management. When adding providers like Salesforce, Zendesk, or marketing automation platforms, AutoSPF recommends isolating DKIM keys for each provider on their own selectors, publishing a monitoring DMARC policy, and replacing your nested SPF includes with a flattened record. This strategy keeps your domain under the strict 10-lookup limit while ensuring every authorized tool can deliver mail to the inbox.

Audit the shadow IT sending mail on your behalf

Managing DNS for a growing enterprise often feels like trying to hold back a flood with a screen door. Marketing teams integrate a new CRM, support sets up a helpdesk, and product engineering connects a transactional email provider. These additions frequently happen without consulting the IT infrastructure team.

Before making any DNS edits, map out your entire email sender environment. This is where most organizations fail: they treat email DNS as a passive billboard rather than an active routing table. To avoid deliverability disasters, list every active tool, including:

• Core productivity suites like Google Workspace or Microsoft 365
• Transactional email delivery systems like Amazon SES or Resend
• Marketing automation and customer relationship managers like HubSpot and Salesforce
• Customer support ticketing systems like Zendesk

When working with enterprise clients who use the AutoSPF for Enterprises tier, we find that the most common point of failure is when departments authorize a tool like HubSpot without notifying IT. This results in conflicting DNS entries. You must decide whether these tools actually require the authority of your root domain or if they should be delegated to subdomains.

As documented in the Email Sending Guide, while sharing DNS configuration with third-party tools allows SaaS systems to send authentic-looking messages, it introduces significant DNS complexity. Delegating to a subdomain isolates the reputational risk. It prevents a single rogue marketing campaign from blocking corporate communication.

Publish separate DKIM keys for every provider

Once you have mapped out your senders, the next tactical step is isolating their cryptographic signatures. Many IT teams make the mistake of relying solely on SPF for authentication. However, modern spam filters demand DKIM (DomainKeys Identified Mail) to verify that the message content has not been altered in transit.

Because SPF is highly vulnerable to email forwarding, relying on it alone means forwarded emails will almost certainly fail authentication. As a specialized SPF management platform, AutoSPF advises implementing unique DKIM keys for every single SaaS provider. Never share a DKIM selector across multiple services.

Instead, set up DKIM first, before you touch your SPF record. Each third-party tool should generate its own distinct DKIM public-private key pair. You will publish the public key in your DNS using a unique selector, such as resend._domainkey.yourdomain.com.

According to the Cadence blog, isolating your keys ensures that if one vendor rotates their keys or suffers a security compromise, your other critical mail flows remain entirely unaffected. This separation is also critical for establishing DMARC alignment.

As explained by SmartxTechnologies, when a third-party service like Mailchimp or SendGrid sends mail on your behalf, they often sign with their own default domain key, which fails DMARC alignment because it does not match your visible From: header domain. Delegating a CNAME to the provider forces them to sign using your domain name, passing DMARC alignment checks.

Flatten the SPF record to handle multiple includes

The core challenge with authorizing multiple SaaS providers is the strict RFC 7208 limit of 10 DNS lookups. Every time an email receiver processes a message, they query your SPF record. If your record contains multiple nested include: statements, the receiver must perform a new DNS lookup for each one.

Microsoft 365, Salesforce, and Zendesk each require multiple nested lookups. It takes only three or four such integrations to hit the 10-lookup ceiling. This triggers an immediate SPF PermError and causes emails to bounce.

Rather than stacking endless include: statements, you must consolidate your SPF record. Let's look at how the SPF footprint of common enterprise tools adds up:

Why manual flattening fails

When faced with this problem, many administrators attempt to manually resolve these domain names into their underlying IPv4 and IPv6 addresses. They copy the IP blocks, paste them into a single long TXT record, and delete the include statements.

This manual hack is dangerous and prone to failure. SaaS vendors frequently update their outbound IP ranges without notifying their customers. If Salesforce provisions a new subnet for their outbound servers and you are using a static, manually flattened record, your Salesforce emails will instantly begin failing SPF checks.

Additionally, DNS records have a 512-byte limit for UDP packets. A manually flattened record with dozens of raw IP blocks will easily exceed this limit, causing DNS resolution timeouts that corrupt your email deliverability. For a detailed breakdown of these risks, see the AutoSPF guide on why manual SPF flattening breaks enterprise email deliverability (And what actually works).

The single-include solution

The only sustainable way to handle multiple third-party senders is with an automated SPF flattening engine. By replacing your complex, fragile SPF record with a single managed include pointing to the AutoSPF infrastructure, you hand over the tracking of vendor IP changes to a system designed to monitor them in real time.

The configuration process takes only a few seconds. You replace your existing record with:

v=spf1 include:_spf.autospf.com ~all

Behind the scenes, AutoSPF queries your authorized vendors every 15 minutes, de-duplicates their netblocks, and flattens the resulting IPs into an optimized list served via our Cloudflare-backed DNS network. This reduces your DNS lookup count from over 10 down to just 2 or 3, keeping your domain safely compliant without manual intervention.

If you are struggling with a complex marketing stack, we have step-by-step documentation on fixing the 10-lookup SPF limit for HubSpot and Salesforce integrations.

Deploy DMARC in stages to catch misconfigurations

The final component of a secure email architecture is DMARC (Domain-based Message Authentication, Reporting & Conformance). DMARC acts as the policy engine that tells receiving mail servers exactly what to do when a message fails SPF or DKIM checks. However, rushing into DMARC enforcement without a planned rollout is the fastest way to block your own legitimate business mail.

The correct implementation sequence relies on a multi-stage deployment. You must begin by monitoring your traffic before you attempt to enforce blocking.

First, use the AutoSPF DMARC Record Generator to publish your initial monitoring policy:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100

This policy tells receiving servers to process your mail normally but to send daily aggregate XML reports to your designated address. Keep your domain at p=none for two to four weeks. Use a parser to review these reports and identify any forgotten third-party senders—like transactional billing systems, form processors, or helpdesk platforms—that are currently failing authentication.

Once your reports show that all authorized SaaS senders are successfully passing SPF and DKIM with proper domain alignment, transition your policy to p=quarantine. After another two weeks of monitoring, move to full enforcement with p=reject.

For organizations aiming to achieve SOC-2 or ISO 27001 compliance, reaching actual enforcement is a hard requirement. As highlighted in the ISO 27001 Email DNS Records Guide, leaving a DMARC record at p=none for extended periods can result in an audit failure under Annex A.5.14. Auditors look for active control and enforcement over organizational communication channels, meaning a passive monitoring record will not satisfy security control requirements.

For a deeper look into setting up helpdesk platforms without disrupting your security posture, review our guide on how to authorize Zendesk and ServiceNow without breaking your SPF record.

Every SaaS tool you add to your corporate stack brings you one step closer to the 10-lookup limit. Do not wait for a deliverability failure to audit your domain's security. Check your current DNS configuration to see exactly how close you are to exhausting your lookups.

Enter your domain into the AutoSPF analyzer. If you are approaching the threshold, sign up for a 30-day free trial on the AutoSPF website to flatten your SPF record in under 60 seconds.