How do SPF 'a' records affect DNS lookups and the 10-lookup limit, and what are the best practices?
Matthew Whittaker
Co-founder & CTO, Suped
Published 28 Jun 2025
Updated 19 Aug 2025
6 min read
Email deliverability relies heavily on proper authentication, and the Sender Policy Framework (SPF) is a cornerstone of this process. It helps recipient mail servers verify that incoming mail from a domain is authorized by that domain's administrators. This is done by checking the SPF record, a TXT record in your domain's DNS, against the sending server's IP address. However, the evaluation of SPF records involves DNS lookups, which are subject to a crucial limitation: the 10-lookup limit.
This limit is in place to prevent abuse and ensure efficient processing. Understanding how different SPF mechanisms, particularly the 'a' mechanism, contribute to this count is essential for maintaining healthy email deliverability. If you exceed this limit, your legitimate emails may be flagged as spam or rejected outright.
SPF works by publishing a list of authorized sending IP addresses or hostnames in your domain's DNS. When an email arrives, the receiving server queries your DNS to retrieve this record and compare the sending IP. The process of retrieving information from DNS servers, like looking up an IP address associated with a hostname, is what we refer to as a DNS lookup. Each time the SPF record needs to resolve a hostname or an IP range from a referenced domain, it performs a DNS lookup.
RFC 7208, dictates which mechanisms trigger a DNS lookup. Not all mechanisms contribute to the limit. For instance, ip4 or ip6 mechanisms, which directly list IP addresses, do not count towards the 10-lookup limit because no additional DNS query is needed to resolve them.
Mechanism
Description
Counts as lookup?
a
Checks if the sender's IP address matches any of the A records for the specified domain.
Yes
mx
Checks if the sender's IP address matches any of the MX records for the specified domain.
Yes
include
References another domain's SPF record. This is common when using third-party email services.
Yes
ptr
Performs a reverse DNS lookup. (Deprecated and generally discouraged).
Yes
exists
Checks if a domain's A record exists, without checking its IP.
Yes
redirect
Redirects to another SPF record. This consumes a lookup.
Yes
ip4
Specifies an IPv4 address or range.
No
ip6
Specifies an IPv6 address or range.
No
The 10-lookup limit: why it matters
The SPF specification strictly limits the number of mechanisms and modifiers that cause DNS lookups to 10 per SPF check. This limit is a security and performance measure. Each DNS lookup requires resources from both the querying server and the DNS infrastructure itself. Without this limit, a malicious actor could craft complex SPF records that trigger an excessive number of DNS queries, potentially leading to denial-of-service (DoS) attacks on DNS servers or email infrastructure.
Exceeding this 10-lookup threshold results in an SPF PermError, short for Permanent Error. When a receiving server encounters a PermError, it often treats the email as suspicious or unauthorized, even if it originated from a legitimate sender. This can significantly impact your email deliverability, leading to emails being sent to spam folders, delayed, or outright rejected.
The consequences of exceeding the limit
When your SPF record exceeds the 10-lookup limit, it creates an authentication failure known as a PermError. Mailbox providers such as Microsoft and Google are increasingly strict with email authentication, as detailed in their new sender requirements. A PermError can lead to:
Increased spam scoring: Your emails are more likely to be delivered to the spam or junk folder.
Email rejection: Receiving mail servers may outright reject your messages.
Reputation damage: Consistent SPF failures can negatively impact your domain's sending reputation, affecting future email campaigns.
How 'a' records affect DNS lookups
The 'a' mechanism in SPF specifies that the IP address of the sending host should be checked against the A records (and AAAA records for IPv6) of the domain specified in the 'a' mechanism. For example, a:example.com tells the receiving server to look up the A records for example.com. If no domain is specified, it defaults to the current domain. This action, by its nature, requires a DNS lookup and counts towards the 10-lookup limit.
Example SPF record with 'a' mechanismDNS
v=spf1 a ip4:24.106.95.34 ~all
In the example above, the a mechanism will trigger a DNS lookup for the domain's A records, and the ip4 mechanism directly specifies an IP address, which does not count as a lookup. If you are not sending email directly from the IP addresses associated with your domain's A records, including the a mechanism is an unnecessary lookup that consumes part of your valuable 10-lookup budget.
A mechanism
Action: Queries DNS for A and AAAA records of the current or specified domain.
Lookup count: Consumes 1 DNS lookup.
Use case: For mail servers sending directly from IP addresses listed in the domain's A records.
IP4/IP6 mechanisms
Action: Directly lists IP addresses or CIDR ranges. No DNS query is performed.
Lookup count: Does not consume any DNS lookups.
Use case: For directly owned or static IP ranges used by sending servers.
Best practices for managing SPF records
To ensure your SPF record remains compliant and effective, especially with the strict 10-lookup limit, adopting certain best practices is crucial. Managing your SPF record diligently can prevent email delivery issues and maintain your domain's reputation. I often see domains with redundant or outdated entries that unnecessarily consume lookups.
Consolidate services: Evaluate all your email sending services and determine which ones are truly necessary. Remove unused SPF includes or mechanisms that point to services you no longer use.
Use IP addresses directly: If you know the static IP addresses of your sending servers, use ip4 or ip6 mechanisms instead of a or mx when possible. This eliminates the need for DNS lookups.
SPF flattening (or compression): This technique replaces include mechanisms with the direct IP addresses from the included SPF records. This effectively reduces DNS lookups but requires careful management to keep up with changes in third-party IPs. Explore the best practices for SPF flatteners.
Subdomain delegation: For extensive email sending, consider delegating specific sending responsibilities to subdomains, each with its own SPF record. This isolates the SPF lookups for different services.
Regular auditing: Periodically check your SPF record for compliance using an email deliverability tester. Services like SendGrid provide documentation on SPF limitations to guide your configuration.
While exceeding the limit can cause a PermError, remember that even being close to the limit can introduce DNS overhead and slight delays in email processing. Minimizing lookups whenever possible is generally a good practice for optimal email performance.
Maintaining SPF health for reliable email
Properly configured SPF records are critical for email authentication and ensuring your messages reach the inbox. The 'a' mechanism, like 'mx' and 'include', counts towards the 10-lookup limit. Overlooking this detail can lead to authentication failures and compromised email deliverability. By understanding how each mechanism affects DNS lookups and adopting best practices like consolidation and SPF flattening, you can proactively manage your SPF records and prevent common pitfalls that lead to emails landing in spam or being rejected. Regular monitoring and optimization are key to maintaining a robust email sending infrastructure.
Views from the trenches
Best practices
Ensure your SPF record is always kept under the 10 DNS lookup limit to avoid 'PermError' failures, which can lead to emails being rejected.
Remove any 'a' or 'mx' mechanisms from your SPF record if you are not actively sending mail from the IP addresses associated with those DNS entries.
Consolidate multiple third-party service includes into a single, optimized record, or use SPF flattening services to combine lookups into IP ranges.
Implement a DMARC policy with reporting to monitor SPF authentication results and identify any unexpected lookup failures or 'PermErrors'.
Common pitfalls
Leaving 'a' or 'mx' mechanisms in your SPF record when the associated IP addresses are not actually used for sending mail, unnecessarily consuming lookups.
Adding too many 'include' statements for various email services, quickly exceeding the 10-lookup limit and causing SPF validation failures.
Failing to regularly review and update SPF records after adding or removing email sending services, leading to outdated or non-compliant entries.
Not understanding that 'redirect' mechanisms also count as a DNS lookup, leading to unexpected lookup limit breaches.
Expert tips
Always prioritize explicit IP addresses over mechanisms like 'a' or 'mx' when possible, as they do not count towards the 10-lookup limit and reduce DNS overhead.
Regularly audit your SPF record for unused or redundant 'include' statements that might be consuming unnecessary lookups and impacting performance.
Consider using SPF flattening for complex setups, but be aware that this requires ongoing maintenance to reflect changes in included domains' IP addresses.
Utilize subdomains to segment email sending, each with its own SPF record, to help manage lookup counts for different services.
Marketer view
A marketer from Email Geeks says they were surprised to learn that SPF 'a' mechanisms also count towards the 10-lookup limit, similar to 'mx' records. They thought 'a' might not incur DNS overhead.
March 12, 2019 - Email Geeks
Expert view
An expert from Email Geeks says that while one extra lookup might not severely impact modern DNS services, it is best practice to include only necessary records and exclude any redundant ones. If an 'a' or 'mx' record's IPs are already covered by an 'ip4' or 'ip6' range, the redundant lookup should be skipped.
Microsoft and 
Google are increasingly strict with email authentication, as detailed in their new sender requirements. A PermError can lead to: 
SendGrid provide documentation on SPF limitations to guide your configuration.
