When are separate SPF records needed for a domain and its subdomains?
Michael Ko
Co-founder & CEO, Suped
Published 23 Jul 2025
Updated 17 Aug 2025
6 min read
Sender Policy Framework (SPF) records are a cornerstone of email authentication, helping recipient mail servers verify that incoming mail from a domain comes from an authorized host. This authentication is critical for preventing email spoofing and improving deliverability. While the general rule is to have one SPF record per domain, the situation becomes more nuanced when dealing with subdomains.
Many email administrators and marketers often wonder if an SPF record configured for a primary domain automatically applies to its subdomains, or if separate records are always needed. Understanding the distinction between how SPF and DMARC handle subdomain policies is key to correctly configuring your DNS records and ensuring your emails reach their intended inboxes without being flagged as spam or rejected.
SPF works by publishing a TXT record in a domain's DNS that lists all authorized mail servers for that specific domain. When an email is received, the recipient's mail server checks the Envelope From domain (also known as the Return-Path) and performs an SPF lookup on that domain. This lookup process queries the DNS for an SPF record associated with the sending domain. If no SPF record is found for the exact domain (or hostname) sending the email, the SPF check effectively fails or results in a neutral outcome.
Unlike DMARC, which can have a policy (the sp tag) that cascades to subdomains if no explicit DMARC record is found for them, SPF does not inherently extend its policy to subdomains. This means that each subdomain that sends email needs its own SPF record if it is to pass SPF authentication. If no SPF record is found on a subdomain, the receiving server will simply proceed without an SPF evaluation for that specific subdomain.
This fundamental difference is why domain owners must be careful when configuring their DNS. Assuming a primary domain's SPF record covers all subdomains can lead to legitimate emails failing SPF checks, impacting deliverability and potentially causing your emails to be sent to spam or blocked entirely. To correctly set up your DNS for email, it's essential to understand that SPF operates on a per-domain basis.
Why separate SPF records are crucial
The primary reason separate SPF records are necessary for subdomains is the way mail servers perform DNS lookups for SPF. When an email is sent, the receiving server queries the DNS for the SPF record specifically at the sending domain or subdomain level. It does not automatically ascend to the parent domain to check for an SPF record there if one isn't found at the exact sending domain. This means that each unique subdomain used for sending email requires its own dedicated SPF TXT record.
Another critical factor is the 10-DNS lookup limit. An SPF record cannot contain more than ten DNS lookups for mechanisms like a, mx, ptr, and include. Exceeding this limit will cause SPF validation to fail, often resulting in a PermError and impacting your email deliverability. Forcing all sending sources into a single primary domain SPF record is often impossible or leads to this lookup limit being exceeded.
SPF DNS lookup limit
Every a, mx, ptr, exists, and include mechanism in an SPF record counts as a DNS lookup. If a record has more than 10 lookups, recipient servers will return a PermError, causing emails to fail SPF validation and potentially affecting your sender reputation. Separate SPF records for subdomains can help manage this by distributing lookups.
Separate SPF records are needed in several common scenarios to maintain optimal email deliverability and security. If you use subdomains for different email purposes, such as transactional emails from transactional.yourdomain.com and marketing emails from marketing.yourdomain.com, each needs its own SPF record listing only the specific sending sources relevant to that subdomain. This segmentation helps isolate your email streams and protect your overall sender reputation.
Another scenario is when using third-party email service providers (ESPs). While some ESPs might handle SPF authentication for you by having you send from their own domain, others require you to set up SPF records on your subdomains. For instance, Microsoft 365 or Google Workspace might require specific SPF entries for your domain or subdomains. Always consult your ESP's documentation for precise instructions on how to configure SPF for their services.
SPF record for a primary domain using Google WorkspaceDNS
v=spf1 include:_spf.google.com -all
SPF subdomain policy
SPF policies do not automatically apply to subdomains. Each subdomain requires its own SPF record if it's used for sending emails. If a subdomain doesn't have an SPF record, the SPF check simply won't occur for that subdomain, which can lead to deliverability issues.
DMARC subdomain policy
DMARC policies, by default, do cascade to subdomains unless a specific DMARC record is published for the subdomain itself. This is controlled by the sp tag in the DMARC record. For more, see our guide on DMARC record placement for subdomains.
Best practices for SPF and subdomain management
To effectively manage SPF records for your domain and its subdomains, start by identifying all subdomains that are actively sending emails. Each of these sending subdomains requires its own SPF record. It's crucial to consolidate all legitimate sending sources for each specific domain or subdomain into a single SPF record for that domain or subdomain. Remember, having multiple SPF records for the same domain or subdomain is invalid and will cause SPF authentication to fail.
When structuring your SPF records, make strategic use of the include mechanism to refer to other SPF records, like those provided by your ESPs. However, always be mindful of the 10-DNS lookup limit. Regularly auditing your SPF records, perhaps with an email deliverability tester, ensures that they remain compliant and up-to-date, preventing unforeseen deliverability issues or your domain ending up on a blacklist or blocklist.
Views from the trenches
Best practices
Always create a separate SPF record for each subdomain that sends email, as SPF does not cascade.
Consolidate all legitimate sending IPs and includes into a single SPF record per domain or subdomain.
Regularly audit your SPF records to ensure they remain compliant with the 10-DNS lookup limit and reflect current sending sources.
Implement DMARC alongside SPF and DKIM to gain visibility into your email authentication results and to specify policies for unauthorized emails.
Utilize subdomains to segregate different email streams, such as marketing versus transactional, to protect your main domain's reputation.
Common pitfalls
Assuming a primary domain's SPF record covers all subdomains, leading to SPF failures for legitimate subdomain emails.
Creating multiple SPF records for the same domain or subdomain, which is invalid and causes authentication failures.
Exceeding the 10-DNS lookup limit within an SPF record, resulting in PermErrors and impacting deliverability.
Neglecting to publish an SPF record for non-sending subdomains, which can make them vulnerable to spoofing.
Not monitoring SPF authentication failures through DMARC reports, missing critical insights into deliverability problems.
Expert tips
If a subdomain doesn't send email, consider publishing an SPF record with "v=spf1 -all" to explicitly state no hosts are authorized to send, enhancing security.
Leverage DMARC reports to identify all sending sources, including those you might not be aware of, helping to build comprehensive SPF records.
When using third-party ESPs, always check their documentation to confirm whether SPF needs to be set up on your domain/subdomain or if they handle it via their own envelope domain.
Prioritize SPF record updates when adding new email sending platforms or changing existing ones to prevent service interruptions.
Consider a phased approach when implementing strict SPF policies, starting with a softer fail or neutral policy and gradually moving to a hard fail after monitoring DMARC reports.
Expert view
Email Geeks expert says that each domain and subdomain requires its own SPF record to properly authorize sending mail servers.
2023-12-01 - Email Geeks
Expert view
Email Geeks expert says SPF does not cascade down like DMARC, noting that it must be on the exact domain being evaluated, though it can use includes or redirects.
2023-12-02 - Email Geeks
Ensuring SPF compliance for all sending domains
The key takeaway is that SPF records are domain-specific. Any domain or subdomain from which you send email needs its own, correctly configured SPF TXT record. This ensures that recipient servers can verify your sending sources, reducing the likelihood of your emails being marked as spam or rejected. Proper SPF implementation, especially when combined with DKIM and DMARC, is vital for maintaining a strong sender reputation and achieving high email deliverability.
