Yes, the redirect modifier in an SPF record absolutely counts towards the 10 DNS lookup limit. This is a common point of confusion, but understanding how it works is crucial for maintaining a valid SPF setup and ensuring your emails are authenticated correctly.
An SPF record can become complex very quickly, especially when you use multiple third-party services to send email. Each service often requires an include statement, and before you know it, you’ve exceeded the limit. Let's break down how the redirect modifier fits into this picture.
Understanding the SPF 10-lookup limit
The Sender Policy Framework (SPF) specification was designed with a safeguard to prevent abuse. Mail servers evaluating an incoming email must check the sender's SPF record to verify the sending server is authorized. This check involves DNS lookups. To prevent bad actors from creating complex SPF records that could trigger an excessive number of DNS queries and launch a denial-of-service (DoS) attack against a mail server, the standard imposes a hard limit.
As stated in RFC 7208, there is a maximum of 10 lookups. This limit applies to specific mechanisms and modifiers that require a DNS query to resolve. These include:
- include
- a
- mx
- ptr
- exists
- redirect
Mechanisms like ip4, ip6, and all do not perform DNS lookups and therefore do not count towards the limit.
How 'redirect' contributes to the count
The redirect modifier is used to delegate SPF authentication entirely to another domain. When a receiving mail server encounters a redirect, it stops processing the current SPF record and starts evaluating the SPF record of the domain specified in the redirect.
This act of looking up the new domain's SPF record consumes one of your 10 available lookups. After the redirect, any additional lookups required by the new domain's SPF record (for instance, its own include mechanisms) are added to the count. If the total count from the original domain and the redirected domain exceeds 10, the check will fail.
Differences between 'redirect' and 'include'
While both redirect and include consume a DNS lookup, they function differently. The key distinction is that a redirect is terminal. Once a redirect is processed, the evaluation of the original SPF record stops completely. Any mechanisms listed after the redirect modifier are ignored.
An include mechanism, on the other hand, is not terminal. The receiver checks the included record, and if it doesn't produce a match, the evaluation returns to the original record to process any subsequent mechanisms. A redirect is therefore only useful if you want a single, external SPF record to handle all of your authentications.
The consequence: SPF permerror
Exceeding the 10-lookup limit, whether through too many include statements or the use of a redirect, results in an SPF PermError, short for Permanent Error. This specific error is often reported as "Too Many DNS Lookups".
A PermError invalidates your SPF record. When a mail server cannot validate your SPF record, it may treat your emails with suspicion. This often means your legitimate emails are more likely to be filtered into the spam folder or rejected outright, severely damaging your email deliverability.
In conclusion, you must treat the redirect modifier as a lookup that counts against your 10-lookup limit. Carefully audit your SPF record, paying close attention to every include and redirect, to ensure you stay within the limit and maintain a healthy email authentication posture.
Does DKIM signature verification involve a DNS lookup?
What is the maximum number of DNS lookups allowed in an SPF record?
Does the 'all' mechanism in SPF always mean a hard fail?
What SPF mechanism refers to other SPF records?
What is the purpose of the 'ptr' SPF mechanism?
What SPF mechanism includes the A records of a domain?
