SPF Record Optimization Tips: Fix Failures and Stay Under the 10-Lookup Limit

A published SPF record is not the same as a working SPF record. Many organisations set up SPF once, add a few email service providers, and never revisit it. Over time the record accumulates stale entries, approaches the DNS lookup limit, or develops alignment mismatches that silently cause DMARC failures. Optimising your SPF record is not a one-time task — it is ongoing maintenance that directly affects your email deliverability and your ability to enforce DMARC.

Why SPF Optimization Matters

Every time your domain sends email, the receiving mail server looks up your SPF record and evaluates whether the sending IP is authorised. If that evaluation returns anything other than pass with a correctly aligned domain, DMARC SPF fails. A broken SPF record cascades immediately into lower DMARC pass rates, which in turn affects your ability to move your DMARC policy from none to quarantine or reject.

Common causes of SPF-driven DMARC failures include exceeding the DNS lookup limit (permerror), sending from an IP that is not listed in your record, or using an email service provider that sets its own domain in the MAIL FROM field rather than yours. Each of these issues has a specific fix — but you need visibility to find them first.

Stay Under the 10 DNS Lookup Limit

RFC 7208 defines a hard cap: evaluating a single SPF record must not trigger more than 10 DNS lookups. Mechanisms that consume lookups are include, a, mx, ptr, and exists. The ip4 and ip6 mechanisms do not require DNS resolution and therefore do not count toward the limit.

The tricky part is that the limit is recursive. Each include counts as one lookup, but any include mechanisms inside the referenced domain also count. A single include:_spf.google.com may resolve to two or three additional lookups internally. Add Mailchimp, HubSpot, Salesforce, and a transactional mail provider and you can exceed 10 lookups before you realise it.

When the limit is exceeded, the result is permerror — a permanent error that counts as an SPF failure for DMARC. To count your current lookups, audit each mechanism in your record and recursively count the lookups it triggers. Here is an example of a record that is close to the edge:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:_spf.salesforce.com include:mail.zendesk.com ~all

This record already uses five include mechanisms at the top level. Each of those may reference additional nested lookups, making it very likely that the total exceeds 10. Any new ESP you add risks pushing you into permerror territory.

Flatten Your SPF Record

SPF flattening replaces include references with the actual IP addresses or CIDR ranges they resolve to. Instead of include:_spf.google.com (which itself resolves to several IP ranges through nested lookups), you list the raw IP blocks directly:

v=spf1 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.233.160.0/19 ~all

Because ip4 and ip6 mechanisms require no DNS resolution, a fully flattened record can list dozens of sending IPs while consuming zero lookups. This completely eliminates the risk of hitting the 10-lookup limit.

The trade-off is maintenance. Email service providers periodically change their IP ranges. If you have a static flattened record and an ESP adds a new sending IP, emails from that IP will fail SPF until you update your record. You either need a reliable process for tracking ESP IP range changes or you use a managed SPF service that automatically keeps your flattened record current. Managed SPF services typically use a single include pointing to a provider-managed subdomain that they update on your behalf whenever upstream IP ranges change.

Remove Unused Includes

SPF records accumulate over time. Every new email tool, CRM integration, or marketing platform gets added — but old vendors rarely get removed. A former transactional email provider you stopped using two years ago may still be in your SPF record, consuming one or more of your precious 10 lookups and potentially authorising an IP range you no longer control.

To audit your includes:

1. List every include in your current SPF record.
2. For each include, identify the email service it corresponds to.
3. Confirm whether your organisation is actively sending email through that service today.
4. If a service is no longer in use, remove its include from your record.
5. Check your DMARC aggregate reports to see which sending IPs are actually appearing — any IP not in your current tool stack is a candidate for removal.

Common stale entries include former marketing automation platforms (Marketo, Pardot, old versions of Mailchimp), transactional providers that were replaced (SendGrid, Mandrill, SparkPost), and CRM tools with outbound email capabilities that are no longer configured. Even a single unused include that contains two or three nested lookups can free up enough headroom to add a new legitimate sender without hitting permerror.

Fix Alignment Issues

An SPF pass does not automatically mean a DMARC pass. DMARC requires that the domain authenticated by SPF — the MAIL FROM domain, also called the envelope sender or return-path — aligns with the domain in the visible Header-From address. If your ESP uses its own domain as the MAIL FROM, SPF passes for their domain, not yours, and DMARC SPF alignment fails.

This is one of the most common sources of DMARC failures for organisations using third-party email platforms. The fix is to configure a custom return-path at your ESP — a subdomain of your own domain that the ESP uses as the MAIL FROM address. For example, instead of bounce.sendgrid.net as the MAIL FROM, you configure em.yourdomain.com. Under DMARC relaxed alignment (the default), em.yourdomain.com aligns with yourdomain.com, and SPF alignment passes.

Most major ESPs support custom return-path domains:

• Mailchimp — configure a custom domain in Audience settings; requires a CNAME at your registrar.
• SendGrid — set up domain authentication with a custom return path in Settings → Sender Authentication.
• HubSpot — configure a connected email sending domain with a custom MAIL FROM subdomain.
• Amazon SES — use a custom MAIL FROM domain in your verified identity settings.
• Salesforce Marketing Cloud — SAP configuration through a private domain and custom bounce domain.

After configuring a custom return-path, you also need to add that subdomain's SPF record (or include it in your root domain's SPF) so the SPF check for the MAIL FROM domain passes. Some ESPs handle this automatically; others require you to add a specific include for the subdomain.

Use -all Instead of ~all

Most SPF records end with ~all (softfail), which means: emails from IPs not listed in the record are probably not authorised, but receiving servers may still deliver them. This is appropriate during initial deployment when you are still discovering all your sending infrastructure. However, staying on ~all indefinitely is a missed opportunity.

Switching to -all (fail) signals to receiving mail servers that any IP not explicitly listed in your SPF record is definitively not authorised to send mail for your domain. Combined with a DMARC reject policy, this gives you the strongest possible signal against spoofed email.

When is it safe to switch? Once you are confident that your SPF record covers every legitimate sending source — your own mail servers, all ESPs, transactional providers, and any automated systems that send on your behalf. If you have DMARC monitoring in place, check that your SPF pass rate for legitimate sources is consistently high (ideally above 95%) before making the switch. Any remaining failures need to be diagnosed and resolved first.

One important nuance: -all vs ~all does not directly affect DMARC enforcement. DMARC policy (p=none, p=quarantine, p=reject) is what governs how receivers handle authentication failures for your domain. But using -all removes ambiguity and aligns your SPF stance with a fully enforced posture.

How DMARCFlow Helps

Optimising an SPF record in isolation is one thing. Doing it correctly in the context of real email traffic across multiple sending services requires visibility into what is actually happening. DMARCFlow provides that visibility directly from your DMARC aggregate reports.

• Permerror detection. DMARCFlow flags every permerror result across all records in your DMARC reports. When the 10-lookup limit is the root cause, it is surfaced clearly so you know to flatten your record or remove unused includes — not just that SPF failed.
• Per-record SPF alignment insight. Every record in every incoming DMARC report is individually analysed against your DMARC policy's alignment mode. DMARCFlow identifies not just whether SPF passed or failed, but whether the authenticated MAIL FROM domain aligns with your Header-From. You can see at a glance which senders are passing with alignment, which are passing without alignment (and therefore failing DMARC), and which are failing outright.
• Sending source breakdown. DMARCFlow groups results by sending source — IP address and reported source domain — so you can identify exactly which ESP or server is causing alignment failures. This makes it straightforward to know which return-path configuration to fix first.
• Recommendations engine. Based on your actual data, DMARCFlow generates prioritised, actionable recommendations. If an unaligned MAIL FROM at a specific ESP is causing DMARC failures, the recommendation tells you what to configure and at which provider. If your lookup count is approaching the limit, it flags this before you hit permerror.
• Maturity tracking. SPF alignment is a direct input into your domain's DMARC maturity level. DMARCFlow shows you exactly which optimisations are required to reach higher maturity levels and move safely from none toward full reject enforcement.

Use the DMARCFlow SPF Checker to immediately inspect your current SPF record, count your DNS lookups, and identify misconfigurations before they affect deliverability.