How to Format an SPF Record With Multiple Providers

When your domain sends through more than one email provider, your SPF record needs to authorize all of them - without breaking.

The basic structure is simple: stack multiple include: mechanisms, end with a qualifier. But the 10-DNS-lookup limit catches people fast once you add a second or third provider. This is what you need to know to write a multi-provider SPF record that actually works.

When Do Multi-Provider SPF Setups Happen?

It is more common than it sounds. A company might run Microsoft 365 for internal mail, SendGrid for transactional alerts, and Mailchimp for campaigns - three services, one domain.

Migration paths create temporary multi-provider setups: switching from Google Workspace to Microsoft 365 leaves both active during the transition. Acquisitions bring inherited mail systems. Backup SMTP services get added and never removed.

Each additional provider adds complexity to your SPF record. The syntax does not change - but the lookup chain grows, and the 10-lookup ceiling gets closer than you expect.

How to Write an SPF Record for Multiple Providers

The structure:

v=spf1 include:_spf.provider1.com include:_spf.provider2.com ~all

The record evaluates left to right. If an IP matches one of your includes, it passes SPF. If it does not match any include, the ~all at the end applies and it softfails.

One thing that does not matter: the order of your include: statements. SPF evaluators do not weight earlier includes differently. More frequently used providers can go first to avoid unnecessary downstream lookups, but it does not affect correctness.

What does matter: the lookup count.

The 10-DNS-Lookup Limit That Actually Breaks Multi-Provider Setups

An SPF record can trigger no more than 10 DNS lookups during evaluation. This is where multi-provider setups fail silently.

Every include: counts as a lookup - and if the included record has its own includes, those count too. Each a, mx, and exists: mechanism counts. The redirect= modifier counts as 1 lookup.

If your record triggers 11 lookups, receivers that enforce the SPF spec stop evaluating. Email from any sending source not captured in the first 10 lookups fails SPF - silently, no error, just broken email that does not arrive.

A real count. Three providers:

v=spf1 include:spf.protection.outlook.com include:sendgrid.com include:mailchimp.com ~all

Outlook: 1 lookup. SendGrid: 1. Mailchimp: 2. Total so far: 4.

But if Mailchimp's record has further includes in its chain, you could be at 8 before you finish evaluating Mailchimp. Add an mx mechanism and you are at 9. Push past 10 and some mailbox providers stop processing your record entirely.

Most reputable providers document their lookup counts. DMARCFlow's SPF analyzer shows the total count and the full downstream chain so you can see exactly where the count comes from.

How to Count Your SPF Lookups Before Something Breaks

Use an SPF lookup tool to check your published record. MXToolbox, Ultra инструмент, and DMARCFlow's analyzer all show the total lookup count and what triggered each one.

If the count is 10 or fewer: within spec. If it is 11 or more: some receivers will stop processing and your non-matched sending sources will fail SPF silently.

A two-provider setup under the limit:

v=spf1 include:spf.protection.outlook.com include:sendgrid.com ~all

Two lookups for the includes. No additional lookup from the ~all. Total: 2. Plenty of room.

What to Do When You Have Already Exceeded the Limit

If your record is over the limit, you will not get a warning. Email from sending sources beyond lookup 10 just fails SPF at most major mailbox providers, silently.

Flatten the includes. Replace include:provider.com with static ip4: entries for the provider's IP ranges. This removes the recursive lookup chain. Downside: you need to update the IPs manually when the provider changes them.

Remove redundant mechanisms. If you have an mx mechanism and your mail is already handled by an included provider, the mx is already covered. Removing it reduces your count by 1.

Use redirect= for consolidation. The redirect= modifier replaces your record with another, counting as 1 lookup. Not helpful for genuinely multi-provider setups, but useful for record consolidation.

Use an SPF flattening service. Third-party services maintain updated IP lists for major ESPs and flatten records automatically. DMARCFlow's SPF monitoring alerts you when you approach the limit so you can flatten before something breaks.

Common Mistakes That Break Multi-Provider SPF Records

Two redirect= modifiers. Only one is allowed. Two produces undefined behavior - receivers may ignore your record entirely.

Switching to -all before validating all senders. Hard fail means any unauthorized IP gets rejected, including legitimate ones. Move to -all only after auditing every sending source.

Using ?all (neutral) without knowing it kills the SPF signal. ?all tells receivers "I make no claim about this mail." It removes the pass/fail signal entirely.

Forgetting subdomains are separate domains. example.com and marketing.example.com need separate SPF records.

Using exists: without tracking lookup cost. It counts as a lookup each evaluation and can silently push you over the limit.

Frequently Asked Questions

Does the order of include statements matter? No. SPF evaluators treat all authorized sources equally regardless of order. More frequently used providers can go first to avoid unnecessary downstream lookups, but ordering does not affect correctness.

Can you use more than one redirect= modifier? No. An SPF record may contain only one redirect=. Having more than one produces undefined behavior. Use separate include: mechanisms instead.

What happens if a record exceeds 10 lookups? Receivers that enforce the SPF specification - most major mailbox providers - stop evaluating at 10 lookups and treat unmatched IPs as if the record returned no match. Email from legitimate sources not captured in the first 10 lookups fails SPF silently with no error message.

Should you use -all or ~all? ~all (softfail) is appropriate while you are still validating. Move to -all (hard fail) only after confirming every legitimate sending source is in your record and testing thoroughly.

How do you check your lookup count? Use an SPF lookup tool. DMARCFlow's analyzer shows the total count and the full lookup chain for any published record, so you can see where the count comes from and whether you are approaching the limit.

If you are managing SPF across multiple providers, DMARCFlow's SPF monitoring tracks your record's lookup count and alerts you when a provider changes their IP ranges or your record approaches the limit.