Can I have two SPF records for different providers?

No. A domain may publish only one SPF TXT record. Two records cause a permerror that fails authentication for all senders. Combine every provider into a single record using the include mechanism.

Why does my SPF record fail even though the syntax looks correct?

The most common cause is exceeding the 10 DNS-lookup limit. Each include counts, and provider includes nest recursively, so a handful of providers can push you over ten and trigger a permerror that receivers treat as no SPF at all.

Should I end my record with ~all or -all?

Start with ~all (soft fail) while you confirm every legitimate sender is listed, so nothing is rejected during rollout. Once you have verified the record and monitored results, switch to -all (hard fail) for stronger protection against spoofing.

SPF include Mechanism: Adding Multiple Email Providers to One Record

VigilDog Team · September 4, 2026 · 6 min read

You send staff mail through Google Workspace, newsletters through Mailchimp, and receipts through a billing app on SendGrid. Each provider hands you an SPF snippet and says "add this." The trap is that SPF is not a list you keep appending to. It is a single TXT record with a hard limit on DNS lookups, and quietly pushing past that limit breaks authentication for every sender at once.

One domain gets exactly one SPF record

This is the rule most people miss when they need SPF for multiple providers: a domain may publish only one SPF (v=spf1) TXT record. If you create a second one, receivers see two SPF records, treat that as a permerror, and many will fail the check outright. So you never add a new record per provider. You edit the single record you already have and combine every authorized sender inside it.

The include mechanism is how you fold another provider's sending infrastructure into your record without copying their IP addresses by hand. When you write include:sendgrid.net, the receiver fetches SendGrid's own SPF record and evaluates it as part of yours. SendGrid can add or retire mail servers on their side, and your record keeps working because you delegated the IP list to them.

How the include mechanism actually works

A record for three providers looks like this:

During evaluation the receiver reads left to right. For each include, it performs a DNS lookup to pull that provider's SPF record and checks whether the sending server's IP appears there. If any mechanism matches, the message passes. The ~all at the end is the catch-all: it says "anything not listed above is a soft fail." Ordering does not change the pass or fail verdict, since evaluation is deterministic, but putting your highest-volume sender first means most messages match on the first lookup.

v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all
include: delegates to another domain's SPF record, the mechanism you use for each provider.
~all = soft fail (accept but mark), -all = hard fail (reject). Start with ~all, tighten to -all once you trust the record.
+all authorizes the entire internet to send as you. Never use it.

How SPF, DKIM and DMARC verify an email

The 10-lookup limit is the real ceiling

SPF caps the number of DNS-querying mechanisms a receiver will resolve at ten. Every include, a, mx, ptr, exists, and redirect counts, and includes count recursively. This is where multiple providers get dangerous: include:_spf.google.com is not one lookup. Google's record nests further includes, so it alone can consume three or four of your ten. Stack Google, Microsoft 365, a marketing platform, and a helpdesk, and you can blow the budget without realizing it.

When you exceed ten lookups the result is permerror, and most receivers treat a permerror the same as having no SPF at all. The failure is silent: nothing bounces on your end, but DMARC-enforcing inboxes start rejecting or spam-foldering legitimate mail. You will hear about it from a client, not from a log.

Building and trimming the record

Work in this order. First, inventory who genuinely sends mail as your domain right now, not who did two years ago. Every retired platform still in the record is wasted lookups. Second, prefer the narrowest include a provider offers; some publish a lighter subdomain (for example a regional or transactional-only include) that resolves to fewer lookups than their catch-all. Third, if you are still over ten after cleanup, flattening is the last resort: you replace an include with the literal ip4:/ip6: ranges it resolves to. Flattening frees lookups but transfers maintenance to you. The day the provider changes their IPs, your hardcoded ranges go stale and mail fails. Only flatten a provider whose ranges are stable and documented, and set a reminder to re-check.

After every edit, verify with a DMARC and SPF checker that counts your actual lookups against the limit, and read our walkthrough on how to fix SPF, DKIM, and DMARC together, because SPF alone does not survive forwarding, you need DKIM aligned for that.

Test before you trust it, then keep watching

A change that parses cleanly today can break silently in three months, when a provider restructures their nested includes and your total tips from nine lookups to eleven. Nothing in your workflow announces that. The only way to catch it is to keep checking the resolved lookup count and record syntax on a schedule, not just at setup. That drift, a record that was valid becoming invalid without anyone touching it, is exactly what continuous email and DNS monitoring is for.