SPF With Multiple Senders: Stay Under 10 Lookups

The short answer

If several platforms send email for your domain, do not publish several SPF records. Publish one SPF TXT record that authorizes the right senders, keep it under the 10 DNS lookup limit, and use DKIM plus DMARC so mailbox providers have more than one way to trust your mail.

A typical combined record looks like v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all. The shape is right, but the risk is hidden: every include can trigger more DNS lookups inside the vendor record. RFC 7208 limits SPF evaluation to 10 DNS-querying mechanisms and modifiers per check, including nested work. If a receiver needs more than 10, SPF must return a permanent error, even though the record looks reasonable.

That failure can push legitimate mail toward spam or rejection at Gmail, Outlook, and other providers because SPF may no longer give DMARC an aligned pass. Gmail's sender guidance says third-party senders should be included in SPF and that authenticated messages are less likely to be rejected or marked as spam. Microsoft says multiple SPF records cause permerror, and that fewer than 10 visible include terms does not guarantee fewer than 10 actual lookups.

Before editing DNS, run a free InboxRadar domain check. It reads SPF, DKIM, DMARC, MX, and blocklist signals from live DNS, then shows which authentication issue is most likely to hurt delivery.

Build the record without breaking SPF

Treat SPF as an authorization list for the envelope sender, not as a place to dump every tool your company has ever tried.

• Keep exactly one SPF TXT record at each sending domain or subdomain. Two records such as v=spf1 include:_spf.google.com ~all and v=spf1 include:mailgun.org ~all are not additive. They create an SPF selection error.
• List only active senders. Remove retired CRMs, ticketing systems, webinar tools, old email service providers, and test relays before adding a new one.
• Count mechanisms and modifiers that query DNS: include, a, mx, ptr, exists, and redirect. ip4, ip6, and all do not count toward the 10 lookup limit.
• Prefer vendor includes when the provider uses changing cloud infrastructure. Do not flatten Google Workspace, Microsoft 365, or a cloud ESP unless their current documentation gives stable IP ranges and you can maintain them.
• Flatten only stable, documented sender IP ranges. Replacing include:vendor.example with ip4 or ip6 removes DNS lookups, but it also makes you responsible for tracking IP changes.
• Use subdomains for separate mail streams. Put marketing on mail.example.com, product mail on notify.example.com, and support on support.example.com when one root-domain SPF record is getting too crowded.
• End with ~all while you are auditing. Consider -all only after every legitimate sender is passing SPF or DKIM in a way that aligns for DMARC.

Subdomains are often the cleanest fix. Each subdomain gets its own SPF record and its own 10 lookup budget, so your newsletter platform no longer competes with Microsoft 365, payroll notices, transactional email, and support desk mail in one root record. The visible From address can still be branded, but the bounce domain and DKIM signing domain need to be configured carefully so DMARC alignment still passes.

Do not make SPF do DKIM and DMARC's job

SPF is important, but modern deliverability is not a single-record game. Gmail and Microsoft evaluate authentication, domain reputation, infrastructure, and user trust signals.

DKIM, defined in RFC 6376, lets a signing domain take responsibility for a message with a cryptographic signature. A selector such as selector1 points receivers to a public key at a DNS name like selector1._domainkey.example.com. For multiple providers, enable DKIM inside each provider and publish each selector they give you. Multiple DKIM selectors are normal because each selector is a separate DNS name, not a duplicate record at the same name.

DMARC, defined in RFC 7489, ties SPF and DKIM to the visible From domain. A message can pass DMARC through aligned SPF, aligned DKIM, or both. Start with p=none and a rua reporting address so you can see who is sending as your domain. After the legitimate streams are passing, move toward p=quarantine or p=reject. Do not jump to enforcement while a major provider is still failing alignment.

MX records matter for receiving mail, not for authorizing outbound mail by themselves. Blocklists can also affect delivery, especially after a compromised account or bad list upload, but do not chase blocklists before fixing SPF, DKIM, DMARC, reverse DNS, and complaint rate basics. Authentication is the part you control fastest.

A practical cleanup workflow

When an SPF record is near the limit, make it smaller by policy first and by syntax second.

• Export every service that sends mail as your domain: Google Workspace, Microsoft 365, transactional app, CRM, support desk, billing, scheduling, marketing automation, and any legacy SMTP relay.
• Send a test message from each active service and inspect the headers for SPF, DKIM, and DMARC results. Keep the services that actually send. Remove the rest.
• Ask whether each sender needs the root domain. High-volume or lower-trust platforms belong on a subdomain with its own SPF, DKIM, DMARC, and reputation.
• Replace stable includes with documented ip4 or ip6 ranges only when the vendor publishes durable ranges and you can review them regularly.
• Avoid ptr. RFC 7208 says it should not be published, and it is slow and less reliable than explicit sender mechanisms.
• Check the current Google sender guidelines and Microsoft SPF guidance before making provider-specific assumptions.
• Recheck after every DNS change, then keep monitoring. SPF breaks later when a vendor changes its include chain, a teammate adds a second TXT record, or an old provider is reactivated.

The safest end state is boring: one SPF record per sending domain, fewer than 10 DNS lookups, DKIM enabled for every provider, DMARC reporting turned on, and no mystery senders in the reports. InboxRadar exists for exactly this drift problem: check once, then watch the domain so you hear about changes before customers notice missing mail.