What is the best practice for using IP addresses in SPF records?
Matthew Whittaker
Co-founder & CTO, Suped
Published 4 May 2025
Updated 16 Aug 2025
8 min read
Setting up an SPF (Sender Policy Framework) record is crucial for email authentication, helping to prevent spoofing and improve deliverability. At its core, an SPF record tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain. If an email arrives from an unauthorized IP address, it might be flagged as spam or rejected outright.
The challenge often lies in correctly specifying these IP addresses, especially when dealing with various sending services or complex infrastructures. It can seem a bit opaque, but understanding the best practices for including IP addresses directly, or indirectly via other mechanisms, ensures your legitimate emails reach their intended inboxes without being mistakenly blocklisted (or blacklisted).
The Sender Policy Framework relies on a TXT record in your DNS that lists authorized senders. You can explicitly state IP addresses using the ip4 and ip6 mechanisms, or refer to them indirectly using a, mx, or include. The choice between these methods hinges on factors like how often your sending IPs change and whether you manage your own mail servers or use third-party providers.
For domains that send email directly from their own fixed servers, using ip4 and ip6 mechanisms to list specific IP addresses or CIDR ranges is often the most straightforward and efficient approach. This method avoids additional DNS lookups, which contributes to faster SPF validation and helps you stay within the important 10-DNS lookup limit.
However, directly listing IP addresses is not always suitable, particularly for dynamic IP environments or when using email service providers (ESPs) that frequently change their sending IPs. An example SPF record with direct IP inclusion might look like this:
Example SPF record with direct IP inclusionDNS
v=spf1 ip4:192.0.2.1 ip4:198.51.100.0/24 -all
Direct IP inclusion: when and why
Using direct IP addresses or CIDR ranges is ideal when your organization operates its own mail servers with static IPs. This method offers a high degree of control and transparency, as you precisely define the allowed sending sources. It also bypasses the need for DNS lookups for these specific IPs, which can marginally improve validation speed and reduce complexity for receiving servers.
For large organizations with a dedicated IP space, utilizing ip4 or ip6 mechanisms with CIDR notation (e.g., ip4:192.0.2.0/24) for IP ranges is a practical approach. This allows you to authorize an entire range of IP addresses with a single entry, which is more efficient than listing each individual IP address.
Best practice
Static IPs: Directly list IP addresses for on-premises mail servers or other stable sending infrastructure with fixed IP addresses. This avoids unnecessary DNS lookups.
CIDR notation: Use CIDR ranges for blocks of IP addresses that you own and control, rather than listing each IP individually. This keeps your SPF record concise.
You should generally avoid including dynamic IP addresses (like those assigned by residential ISPs) in your SPF record, as they change frequently and can lead to validation failures or make your domain appear suspicious. According to an article from AutoSPF, dynamic IP addresses should be excluded because they are often linked to residential networks and change often, increasing the risk of deliverability issues.
Leveraging domain-based mechanisms
While direct IP inclusion is straightforward, many organizations rely on cloud-based email service providers (ESPs) or use external mail servers. In these cases, it's often more practical to use mechanisms that refer to the provider's domain or servers, such as include, a, and mx. The include mechanism is particularly useful for third-party senders, as it points to another domain's SPF record, delegating the authorization of their sending IPs to them.
The a mechanism authorizes the IP addresses resolved from the domain's A records, while mx authorizes the IP addresses of the domain's MX (Mail Exchange) records. While convenient, both a and mx mechanisms consume DNS lookups, which must be carefully managed to avoid exceeding the SPF 10-lookup limit.
IP address inclusion
Directly lists specific IPv4 or IPv6 addresses or CIDR ranges. Example: ip4:192.0.2.1
DNS lookup mechanisms
Refers to IP addresses resolved from the domain's A records (a), MX records (mx), or delegated domains (include).
When using an ESP, it's almost always recommended to use their provided include mechanism, such as include:_spf.google.com. This ensures that as the ESP's sending IPs change, your SPF record remains valid without constant manual updates. Google's own support documentation advises to include the domains of all servers that send mail for your organization. This approach centralizes the management of complex IP lists with the service provider.
Managing the DNS lookup limit
One of the most critical aspects of SPF record management is staying within the 10-DNS lookup limit as defined by RFC 7208. Exceeding this limit will cause SPF validation to return a PermError, meaning your emails could fail SPF checks even if they originate from authorized sources. This can lead to significant deliverability problems, including emails landing in spam folders or being rejected entirely.
To mitigate this, always prioritize direct ip4 and ip6 mechanisms when possible, especially for your own dedicated IP addresses. When using third-party services, consolidate their SPF include directives. If multiple services share the same underlying SPF includes (e.g., two marketing platforms using a common SPF record), you only need to list that include once.
Another strategy is SPF flattening, which involves converting all include mechanisms into direct ip4 or ip6 entries. This bypasses the lookup limit entirely but requires diligent monitoring and updating of your SPF record whenever a third-party provider changes their sending IPs. An article from DuoCircle on SPF records highlights the benefits of using CIDR notation to simplify ranges and optimize lookups.
Strategic use of subdomains
For domains that use separate services for transactional emails, marketing emails, or other purposes, it's a best practice to configure SPF (and other authentication records like DKIM and DMARC) on separate subdomains. For instance, your primary domain (yourdomain.com) might handle corporate communication, while mail.yourdomain.com sends marketing newsletters.
This segregation isolates the reputation of your email streams. If one subdomain experiences deliverability issues (e.g., gets blocklisted), it's less likely to negatively impact the reputation of your primary domain or other subdomains. This strategy is particularly effective for marketing emails, which often have higher volume and potentially more variable engagement rates than transactional emails.
When setting up SPF for subdomains, the same principles apply: use direct IP addresses if you control the sending infrastructure for that subdomain, or use include mechanisms for third-party ESPs. Remember that each subdomain requires its own SPF record.
Key takeaways
Ultimately, the best practice for using IP addresses in SPF records boils down to precision, efficiency, and ongoing maintenance. Prioritize direct IP addresses and CIDR ranges for your stable, controlled infrastructure to save on DNS lookups. For third-party services, rely on their provided include mechanisms, ensuring you only add them once per unique underlying SPF record to prevent exceeding the 10-lookup limit. Segmenting your email sending via subdomains with dedicated SPF records is also a smart move for reputation management.
Regularly review and update your SPF records, especially when you change email service providers or adjust your sending infrastructure. An outdated SPF record is as ineffective as having none at all. By adhering to these practices, you'll significantly improve your email deliverability and protect your domain from impersonation and phishing attempts.
Views from the trenches
Best practices
Use direct ip4 or ip6 mechanisms for stable, owned IP addresses to avoid DNS lookups.
Utilize CIDR notation (e.g., /24) for IP ranges you control to keep records concise.
Employ 'include' mechanisms for third-party email service providers (ESPs).
Common pitfalls
Exceeding the 10-DNS lookup limit, which causes SPF validation to fail.
Including dynamic IP addresses that change frequently, leading to validation errors.
Failing to update SPF records when email sending infrastructure or providers change.
Expert tips
Regularly audit your SPF record to ensure all sending sources are authorized and no invalid entries exist.
Consider SPF flattening if you have many 'include' mechanisms and are nearing the lookup limit, but be prepared for more frequent manual updates.
For optimal email authentication, implement SPF alongside DKIM and DMARC.
Expert view
Expert from Email Geeks says that including direct IP addresses in SPF records is normal and it helps to avoid using a DNS lookup slot.
2022-04-27 - Email Geeks
Expert view
Expert from Email Geeks notes that MX servers are often used for inbound mail and might not be intended for outbound sending. It's important to understand the client's intent behind including the 'mx' mechanism in their SPF record.
