How to Fix SPF Too Many DNS Lookups

What is the SPF 10-lookup limit?

RFC 7208 (the SPF specification) states that an SPF evaluation must not require more than 10 DNS lookups to complete. This limit exists to prevent SPF records from being used as a denial-of-service amplification vector; without it, a single inbound email could trigger hundreds of recursive DNS queries on the receiving server.

The following SPF mechanisms each consume one lookup:

• include
• a
• mx
• redirect
• exists

The ip4 and ip6 mechanisms do not count because they contain literal addresses and require no additional DNS resolution.

When the total exceeds 10, the receiving mail server returns a PermError. This is not a soft failure or a temporary problem; it means SPF evaluation is permanently broken for every message sent from that domain until the record is fixed.

How to count your current lookups

Start by querying your domain's SPF record:

dig TXT example.com +short | grep "v=spf1"

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all"

At first glance this record has three include mechanisms, so three lookups. But each include can contain its own nested lookups. For example, _spf.google.com itself includes three more records:

That is already 8 out of 10. Add one more service (a CRM, helpdesk, or transactional email provider) and you are over the limit. Many organisations discover the problem only after adding a new sender and finding that all their email suddenly fails SPF.

Use our free SPF Flattener to automatically resolve and count every nested lookup in your record. If you are building an SPF record from scratch, our SPF Generator creates a valid record with your chosen providers and fail policy.

Why this breaks DMARC

When SPF returns a PermError, the result is treated as a fail. For DMARC to pass, at least one of SPF or DKIM must pass and be aligned with the From header domain. If SPF permanently fails due to too many lookups, you are left relying entirely on DKIM.

That works fine until DKIM also fails for a particular message, which can happen for several reasons: the message was forwarded through a mailing list, the body was modified by a gateway, or DKIM signing was never configured for one of your sending services. In those cases, DMARC fails entirely and your own policy (quarantine or reject) is applied to your legitimate email.

In short, exceeding the SPF lookup limit does not just break SPF; it weakens your entire DMARC deployment. If you are new to DMARC, read our guide: What is DMARC?

Option 1: Remove unused includes

The simplest fix is often the most effective. Audit every include in your SPF record and ask: does this service still send email on behalf of our domain?

Common culprits include:

• A previous email marketing platform that was replaced months ago but never removed from SPF.
• A helpdesk or ticketing system that was trialled but never fully adopted.
• A legacy mail server that has been decommissioned.
• An a or mx mechanism pointing to infrastructure that no longer sends email.

Check your DMARC aggregate reports to see which sources are actually sending. If a service does not appear in your reports over a 30-day period, it is safe to remove its include. This approach costs nothing and often frees up 2 to 4 lookups immediately.

Option 2: SPF flattening

SPF flattening replaces include mechanisms with the resolved ip4 and ip6 addresses they contain. Because IP mechanisms do not count towards the 10-lookup limit, a fully flattened record can authorise dozens of sending services with zero DNS lookups.

For example, instead of:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

A flattened record looks like:

v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:167.89.0.0/17 ... ~all

The downside is that cloud email providers regularly change their IP ranges. If Google adds a new netblock and your flattened record does not include it, mail from that IP will fail SPF. This means you need a process to re-resolve and update the record on a regular schedule.

Automated flattening tools handle this for you. Use our free SPF Flattener to automatically resolve and flatten your record.

Note: Flattened records can become quite long. DNS TXT records have a 255-character string limit per segment (though multiple segments are concatenated). If the flattened record exceeds the practical limit, you may need to combine flattening with the subdomain approach described below.

Option 3: Use subdomains for different senders

Each domain (and subdomain) gets its own independent SPF record with its own 10-lookup budget. By routing different email streams through dedicated subdomains, you can spread the lookup cost across multiple records.

A typical setup might look like this:

Each subdomain stays well under the 10-lookup limit because it only needs to authorise one or two services.

For this to work with DMARC, you need to set the alignment mode to relaxed. In your DMARC record, ensure you have aspf=r (relaxed SPF alignment). Relaxed alignment allows marketing.example.com in the Return-Path to align with example.com in the From header, because they share the same organisational domain.

v=DMARC1; p=quarantine; aspf=r; adkim=r; rua=mailto:[email protected];

Tip: If your DMARC record does not specify aspf, the default is already relaxed. However, it is good practice to set it explicitly so the intent is clear to anyone reading the record.

How to verify your fix

After making changes, follow these steps to confirm the problem is resolved:

1. Re-count your lookups. Query your updated SPF record and walk through every include chain again. The total must be 10 or fewer. Our SPF Flattener shows the exact count.
2. Send a test email. Send a message from each of your sending services to a test address. Check the email headers for spf=pass in the Authentication-Results header.
3. Check DMARC reports. Wait 24 to 48 hours and review your DMARC aggregate reports. Look for SPF pass rates across all your sending sources. Any source still showing SPF PermError needs further investigation. Verify your DMARC alignment with our free DMARC Checker.
4. Run a full health check. Check your Security Grade to confirm SPF, DKIM, DMARC, and your other DNS records are all correctly configured.

If you use SPF flattening, remember that IP addresses can change at any time. ShieldMarc continuously monitors your SPF record and alerts you when the resolved IPs change, so you never fall out of compliance without knowing.