What are the best practices for SPF records and avoiding CNAMES for email authentication?
Michael Ko
Co-founder & CEO, Suped
Published 20 Jun 2025
Updated 17 Aug 2025
7 min read
Email authentication protocols like SPF are critical for protecting your domain from spoofing and ensuring your messages reach the inbox. Sender Policy Framework (SPF) allows domain owners to specify which mail servers are authorized to send email on their behalf, a foundational step in building and maintaining strong email deliverability.
However, navigating the nuances of SPF record configuration can be complex, especially concerning practices like using CNAMEs. Misconfigurations can lead to emails being rejected, marked as spam, or even blocklisted (blacklisted). Let's explore the best practices to ensure your SPF records are robust, secure, and deliverable.
SPF works by publishing a DNS TXT record that lists all authorized sending IP addresses and mail servers for a domain. When an inbound mail server receives an email, it checks the sending domain's SPF record to verify if the sending IP address is authorized. If the IP isn't listed, the email might be flagged or rejected, preventing unauthorized use of your domain in phishing and spam attacks.
A crucial aspect of SPF is the DNS lookup limit. The SPF specification (defined in RFC 7208) states that an SPF record must not result in more than 10 DNS lookups during evaluation. Each mechanism in your SPF record, such as a, mx, ptr, and include, can count as a DNS lookup. Exceeding this limit causes a PermError, which instructs receiving servers to ignore your SPF record, often leading to delivery failure.
Properly structuring your SPF record is crucial for maximizing email deliverability. This means carefully listing all legitimate sending sources and avoiding unnecessary lookups. If you have multiple services sending on your behalf, such as a marketing email platform and a transactional email provider, you must include them all within your single SPF record.
The risks of CNAMEs in SPF records
While CNAME records are generally useful for delegating DNS responsibilities, they can introduce complications for SPF, especially when used for authentication. Some Email Service Providers (ESPs) might suggest using CNAMEs to manage SPF records for convenience, allowing them to update the record on their end without requiring you to manually modify your DNS each time their IP addresses change.
The primary issue with using CNAMEs for SPF lies in the DNS lookup limit. A CNAME record, by definition, requires an additional DNS lookup to resolve to its canonical name. If that canonical name then points to another record that also triggers lookups (like an include statement), you can quickly exceed the 10-lookup limit, leading to PermError and SPF authentication failures. This is particularly problematic for domains using multiple sending services.
Moreover, relying on CNAMEs can expose your subdomains to security risks. A recent example is the SubdoMailing campaign, where attackers exploited abandoned or misconfigured subdomains, including those pointed via CNAMEs, to send spam and phishing emails that passed authentication checks. This highlights a critical vulnerability: if a CNAME points to an external service that expires or is compromised, your domain can be leveraged for malicious activities without your immediate knowledge. This means ensuring your SPF record is configured optimally is critical. It also means you should understand how to set up your DMARC, DKIM, and SPF records.
For anyone on a dedicated IP, the more secure way to publish SPF records is by explicitly listing those IP addresses using the ip4 or ip6 mechanisms. For shared IPs, verify if your ESP provides a dedicated return-path domain that can be used for SPF alignment. If you're encountering issues, understanding how to troubleshoot SPF authentication issues is key.
CNAME-based SPF
Ease of management: ESPs can update their IP addresses without requiring client DNS changes.
Dynamic updates: Simplifies management for providers with frequently changing IPs.
Risks and limitations
DNS lookup limit: Each CNAME adds a lookup, increasing the chance of exceeding the 10-lookup limit and causing SPF PermError.
Security vulnerabilities: Risk of subdomain hijacking if the CNAME target expires or is compromised, allowing unauthorized sending.
Complex troubleshooting: Can obscure the actual sending IPs, making it harder to diagnose issues.
Direct IP/Include-based SPF
Direct control: You explicitly list authorized IPs or trusted include statements from ESPs.
Transparency: Easier to audit and understand your sending sources.
Benefits and recommendations
Reduced lookups: Directly listing IPs or using specific includes minimizes lookups, staying within the limit.
Enhanced security: Mitigates risks associated with third-party CNAME expiry or compromise.
Clear alignment: Ensures clear SPF alignment for DMARC, improving deliverability and trust.
Best practices for crafting SPF records
Creating an effective SPF record requires careful planning. First, identify all legitimate services that send email on behalf of your domain. This includes your own mail servers, marketing platforms, transactional email services, CRM systems, and any other third-party providers. Each of these should be represented in your SPF record.
The SPF record should be as restrictive as possible while still allowing all legitimate senders. Use the -all mechanism (hard fail) at the end of your record if you are confident that all authorized sending sources are listed. This instructs receiving mail servers to reject messages from unauthorized senders, significantly enhancing your domain's protection against spoofing. If you're unsure, ~all (soft fail) can be used during a transition period, but -all is the preferred policy for maximum security. You also need to ensure your email domain authentication is effective across all your corporate and marketing mail streams.
Furthermore, consider publishing SPF records for domains that do not send email. This helps protect against abuse of inactive or parked domains. For such domains, a simple SPF record like "v=spf1 -all" effectively tells receiving servers that no email should ever originate from that domain. This also applies to subdomains. If you are using subdomains for email, ensure their SPF records and DNS lookups are optimized.
The landscape of email security is constantly evolving, with bad actors finding new ways to circumvent authentication protocols. This makes proactive SPF management more critical than ever. Regularly review your SPF records to ensure they are up to date and accurately reflect your current sending infrastructure. Any changes to your email service providers, IP addresses, or even the addition of new subdomains for sending should prompt a review of your SPF record.
For organizations using multiple ESPs, consolidating SPF records can be challenging. Each ESP might provide an include statement for their services, which can quickly lead to exceeding the 10-lookup limit. In such cases, consider options like SPF flatteners or manually combining IP addresses where feasible. This proactive approach helps avoid SPF PermErrors, which can cause your emails to be treated as suspicious.
Ultimately, your SPF record is a critical component of your email deliverability strategy. By understanding its mechanisms, avoiding common pitfalls like unnecessary CNAME usage for SPF, and maintaining your records diligently, you can significantly enhance your email security and ensure your messages consistently reach your recipients' inboxes without being flagged or blocklisted (blacklisted).
Key SPF pitfalls to avoid
Exceeding 10 DNS lookups: Leads to a PermError, causing authentication failure.
Multiple SPF records: Only one SPF TXT record per domain is allowed. Multiple records will invalidate SPF.
Incorrect syntax: Small errors can render the entire record ineffective.
Outdated records: Failing to update records when senders change can cause legitimate emails to fail SPF.
Views from the trenches
Best practices
Always use a hard fail (-all) once your SPF record is fully verified and stable.
Explicitly list IP addresses or use specific 'include' mechanisms rather than broad ranges.
Regularly audit your SPF records to ensure all legitimate sending sources are included and outdated ones are removed.
Common pitfalls
Exceeding the 10 DNS lookup limit, leading to SPF PermError.
Using multiple SPF records for the same domain, which invalidates them all.
Forgetting to update SPF records when adding or removing email service providers.
Expert tips
Consider using an SPF flattening service if you have many includes and are nearing the lookup limit.
Publish a simple 'v=spf1 -all' record for domains and subdomains that should never send email.
Prioritize listing your most frequently used email sending services first in your SPF record for efficiency.
Expert view
Expert from Email Geeks says they stopped recommending CNAMEs a few years ago because it seemed like it was asking for trouble, and recent events prove it was worse than anticipated.
2024-02-27 - Email Geeks
Marketer view
Marketer from Email Geeks says it is annoying when ESPs tell clients to blindly update their organization's SPF to include their domain, especially when the domain is not even used in the return-path, as it leads to DNS records with unnecessary bloat.
2024-02-28 - Email Geeks
Elevating your email security posture
Mastering SPF records is a crucial step in safeguarding your email ecosystem and ensuring optimal deliverability. By meticulously configuring your SPF records, prioritizing direct IP or precise include mechanisms over CNAMEs, and maintaining vigilance against DNS lookup limits and potential vulnerabilities, you can build a robust defense against email fraud and improve your sender reputation.
