How to Check Whether an SPF Record Is Too Complex

SPF (Sender Policy Framework) has a strict limit of 10 DNS lookups during evaluation. If this limit is exceeded, SPF validation fails with a PermError.

This behaviour is defined in RFC 7208.

As environments evolve, SPF records often grow organically through additional include statements, redirects, and third-party services.

Over time, this can lead to policies that are difficult to understand, exceed lookup limits, and cause intermittent or consistent email delivery issues.

• Multiple include statements referencing external providers
• Nested includes that expand into additional lookups
• Use of redirect without understanding the final evaluated policy
• Legacy providers still included after migrations
• Use of mechanisms like a, mx, or exists that trigger additional lookups

SPF evaluation counts DNS lookups triggered by mechanisms such as include, a, mx, exists, and redirect.

Each of these can generate one or more DNS queries, and the total must not exceed 10 during evaluation.

If the limit is exceeded, SPF returns a PermError, which can negatively impact deliverability and DMARC alignment.

This is one of the most common real-world SPF issues in complex environments.

A common source of confusion is that the published SPF record is not always the final effective policy.

The redirect mechanism can completely replace the evaluation path, meaning the effective SPF policy may exist in a different domain.

Similarly, nested includes can expand into a much larger policy than what is immediately visible.

To properly assess SPF complexity, you must evaluate the fully expanded policy, not just the top-level record.

Tools can help analyse SPF records and reveal their effective structure.

• SPF Checker

• Count the total number of DNS lookups triggered by the policy
• Expand all include statements to understand the full structure
• Check whether redirect is being used and where it points
• Identify unused or legacy include entries
• Confirm the final all qualifier such as ~all or -all in the effective policy
• Use an SPF analysis tool to validate lookup count and structure

• Exceeding the 10 lookup limit resulting in PermError
• Unexpected behaviour due to redirect overriding the main policy
• Includes referencing deprecated or unused services
• Policies that are difficult to audit or maintain
• Inconsistent results across different sending scenarios

SPF flattening is often suggested as a solution, but it should not be the first step.

Before flattening, you should audit and simplify the policy by removing unused includes and confirming which systems actually send email.

Flattening without understanding the policy can introduce risk and make future changes more difficult.

In many cases, reducing complexity through cleanup resolves SPF issues without the need for flattening.

If SPF evaluation fails due to excessive lookups, receiving servers may treat the message as unauthenticated.

This can lead to spam classification or rejection, particularly when combined with strict DMARC policies.

• DMARC

Even if email appears to be working in some cases, inconsistent SPF evaluation can cause unpredictable delivery behaviour.

For reliable email authentication, SPF should be kept simple, accurate, and within lookup limits.

SPF should always be reviewed alongside other email authentication mechanisms.

• DKIM
• DNS propagation

You should also verify DKIM configuration and ensure DMARC alignment is correct. If issues persist, consider whether the problem may be related to DNS behaviour rather than SPF itself.

If you want to validate this topic in practice, these DNS Pro tools are the fastest next step.

• SPF Checker
• SPF Flattener
• Email Security Check