How to Add Multiple Email Services to Your SPF Record Without Breaking Authentication

The 10-lookup limit is a real wall

When you send email through Brevo for transactional messages, SendGrid for marketing, and Mailgun for one-off campaigns, each of those providers needs an SPF include: statement in your DNS. Stack up too many and you hit a wall: SPF permits a maximum of 10 DNS lookups during record evaluation. When that limit is exceeded, receivers return permerror - a permanent failure that is treated like a hard reject by most major mail systems. Your mail disappears with no bounce explanation.

The trap is that the 10-lookup limit is not obvious from looking at your SPF record. Each include: triggers one lookup. But that lookup may itself contain further include: statements, and those count too. A chain of five providers can quietly consume 12 or 15 lookups even though your record only shows five lines.

How to count your current SPF lookups

Before adding another service, count what you already have. Each of these SPF mechanisms triggers at least one DNS lookup:

• include: - counts one lookup for the referenced domain
• a and mx - count one lookup when they are actually evaluated during SPF processing
• ptr - counts one lookup, but is deprecated and should not be used
• exists - counts one lookup
• redirect= - counts one lookup for the target domain

The total is the sum of all these mechanisms across every path in your SPF record chain. Do not just count the include: lines at the top.

Free tools such as MxToolbox SPF Record Lookup trace every chain automatically and report the final lookup count. If the count is already above 7, adding another service is risky without consolidation first.

Solution 1: Flatten your SPF includes

SPF flattening means replacing each provider's include: domain with the actual IP addresses or CIDR ranges that provider uses for sending. This eliminates the lookup entirely because the record now specifies IPs directly instead of pointing to another DNS record that must be resolved.

The process is straightforward:
1. Look up the sending IPs for each provider (Brevo publishes theirs, SendGrid publishes theirs, etc.)
2. Replace include:brevo.com with the Brevo sending IPs using ip4: or ip6: mechanisms
3. Do the same for each other provider
4. Publish the flattened record

The tradeoff is that provider IPs can change. A flattened record that is not updated when a provider adds new IP ranges will silently fail for mail sent through the new IPs. Set a quarterly reminder to recheck provider IP lists, or use a monitoring tool that alerts you when your SPF record stops matching your actual sending sources.

Solution 2: Consolidate through one relay

The cleanest long-term solution for organizations with many email senders is to route all outbound mail through one infrastructure relay that handles SPF on your behalf. Instead of managing include: statements for Brevo, SendGrid, Mailgun, and your own mail server, you publish one SPF record for your relay's IPs and configure each sending service to relay through that infrastructure.

This brings your record down to one include: plus your own infrastructure, which is well under the 10-lookup limit. The relay provider also handles DKIM signing for all sending sources, which simplifies your DMARC alignment at the same time.

The tradeoff is you add a dependency on the relay provider. If that provider has downtime or changes their IP ranges, all your sending is affected at once.

Solution 3: Use the redirect modifier to share one SPF record across domains

SPF supports a redirect= modifier that tells receivers to evaluate a different record instead of the current one. If multiple domains in your organization send email, you can publish a single canonical SPF record and have all other domains use redirect= to point to it. This centralizes your SPF management and prevents each domain from independently hitting the lookup limit.

Example:

v=spf1 include:_spf.brevo.com ~all
redirect=_spf.yourcompany.com

This approach works when the domains you control share the same sending infrastructure. It does not reduce lookups within a single domain that has too many external includes.

How to validate before you publish

Do not publish a changed SPF record without testing it first. Use MxToolbox SPF Record Lookup or dmarcian SPF Surveyor to check:

• Lookup count stays at 10 or below
• No permerror is returned
• All your known sending IPs are covered
• The record evaluates to Pass for each sending source

After publishing, watch your delivery rates and DMARC reports for 24-48 hours. A broken SPF record shows up as sudden drops in delivery to Gmail, Yahoo, and Microsoft addresses, which are the three largest receivers that give actionable feedback through DMARC aggregate reports.

Why ongoing SPF monitoring matters more than getting it set up once

The hard part is not writing an SPF record. It is keeping it accurate as your infrastructure changes. Providers add new sending IPs. Your own team may add a new mail relay without updating the DNS. A vendor migration can introduce a new sending source that is not covered by your record. When SPF breaks silently for one sending source, it often does not show up in your regular monitoring because you are not watching SPF pass/fail rates per sending domain.

DMARCFlow reads your DMARC aggregate reports and tracks SPF pass/fail rates across all your sending sources. When a provider change causes SPF to start failing for a subset of your mail, DMARCFlow alerts you before your delivery rates drop to Gmail and Microsoft. That is the practical difference between SPF configuration as a one-time task and SPF maintenance as an ongoing process.

FAQ

How many SPF includes can I add before hitting the limit?

The limit is 10 DNS lookups, not 10 include: statements. One include: can trigger multiple lookups if the referenced record contains further includes. Count the actual lookups using a tool like MxToolbox before adding a new service.

What happens if my SPF record exceeds 10 lookups?

Receivers return permerror, which is a permanent failure. Most receivers treat permerror as a hard reject. Your mail is silently dropped with no notification to the sender.

How do I flatten SPF includes?

Replace each include: mechanism with the provider's actual sending IP addresses using ip4: or ip6: mechanisms. This eliminates the DNS lookup but requires you to update the record when the provider changes their IPs.

What is the redirect modifier in SPF?

redirect=_spf.example.com tells receivers to evaluate the SPF record at _spf.example.com instead of the current record. It counts as one lookup and is useful for centralizing SPF management across multiple domains.

Can I use a third-party relay to reduce SPF lookups?

Yes. Routing all outbound mail through one relay and publishing SPF only for the relay's IPs reduces your record to a single include: plus your own infrastructure. This is the cleanest solution for organizations with three or more third-party email senders.