When are separate SPF records needed for a domain and its subdomains?
Updated on 20 Oct 2026: We clarified when subdomains need separate SPF records and how to publish and verify them.
Separate SPF records are needed when the root domain and a subdomain are both used as SPF-authenticated sending identities. SPF normally checks the exact domain in the envelope sender, also called the Return-Path or RFC5321.MailFrom. When the reverse-path is null, SPF uses the HELO domain. It does not automatically reuse the SPF record from the parent domain.
Publish one SPF TXT record at each DNS name used as an SPF sending identity. A root domain and a subdomain can each have one because they are different DNS names. Publishing multiple TXT records beginning with v=spf1 at the same name causes SPF PermError. Other TXT records, such as domain-verification records, can coexist with SPF.
A root domain can include a helper record on a subdomain, and a mail platform can ask for a branded bounce domain. Those patterns are valid when the evaluated record authorizes the correct sender and stays within the SPF lookup limit.
One SPF record per sending domain
A sending subdomain needs its own SPF policy when receivers evaluate that subdomain as the SPF identity. This means its domain is used in MAIL FROM or in a HELO/EHLO identity that receivers check. If mail uses only the root domain as its SPF identity, the authorizing SPF record belongs at the root. A defined domain or subdomain that must never send can instead publish v=spf1 -all, provided the name can accept a TXT record.
DMARC policy discovery can find an applicable policy at an ancestor domain. SPF has no equivalent policy inheritance. If a receiver checks SPF for mail.example.com, its TXT lookup starts at mail.example.com. It does not fall back to example.com.
The rule is one SPF record per DNS name, not one SPF record for the whole domain tree. example.com and mail.example.com can each have one SPF TXT record because they are separate names.
- One SPF record at example.com and one at mail.example.com is valid.
- Two SPF records at example.com for different senders cause PermError.
- An SPF record can explicitly reference a shared helper with include or redirect.
|
|
|
|---|---|---|
Employee mail with MAIL FROM at example.com | example.com | example.com |
Campaign mail with MAIL FROM at bounces.example.com | bounces.example.com | bounces.example.com |
Explicitly included shared helper | _spf.shared.example.com | At the helper, plus a referencing SPF record at each sending name |
Defined name that never sends | unused.example.com | v=spf1 -all at that exact name, if it can accept TXT records |
Where SPF belongs depends on the exact domain receivers evaluate.
For a related single-scenario walkthrough, the question does a subdomain need SPF comes down to the same test: is that subdomain the SPF domain receivers see?
How SPF chooses the domain to check
SPF authenticates the envelope sender domain, not the visible From header people see in their inbox. That is why a message can appear to come from example.com while SPF is checked against bounce.mail.example.com or even a vendor-owned domain. If the SMTP reverse-path is empty, as it can be for a delivery status notification, the receiver uses the HELO identity for the MailFrom SPF check. The visible From domain matters for DMARC, but SPF starts with an SMTP identity used during delivery. Receivers can also perform a separate HELO/EHLO SPF check when MAIL FROM is not empty.
SPF lookup flow showing the envelope sender domain, exact DNS name, SPF TXT record and authentication result.
That distinction explains most root-domain versus subdomain confusion. If an employee mail service sends user@example.com with example.com in the envelope sender, its authorization belongs at example.com. If a marketing platform uses bounces.example.com as its branded bounce domain, that subdomain needs the policy authorizing the platform.
Separate valid SPF records at separate DNS namesDNS
example.com. TXT "v=spf1 ip4:192.0.2.10 -all" mail.example.com. TXT "v=spf1 include:esp.example.net -all"
The two records above do not conflict. Each DNS name has one SPF record. Receivers checking example.com read the first record. Receivers checking mail.example.com read the second record. These are illustrative records; replace the documentation IP address and placeholder include with your actual sending configuration.
Under RFC 9989, an SPF pass satisfies DMARC only when the authenticated domain meets the visible From domain's matching requirement. With the default aspf=r, bounces.example.com and example.com match when they share example.com as their organizational domain. With aspf=s, the domains must be identical. Passing DKIM with the required domain match can satisfy DMARC when SPF does not.
Common SPF layouts that are valid
Each SPF sending identity needs a policy at its own DNS name. Those policies can authorize different systems or reuse the same helper record. Sharing a helper changes how you manage the sender list; it does not create SPF inheritance or reset the lookup budget.
Separate records
Use this when the root domain and subdomains send through different systems.
- Each sending name has its own authorized sources.
- Changing a vendor for one subdomain does not change the root policy.
- Separate policies suit employee mail and campaign mail using different SPF identities.
Shared helper record
Use this when several names should reuse the same sender list.
- One helper can supply a shared sender list to several SPF records.
- Each evaluated include and its nested terms consume the same lookup budget.
- A generated helper is valid when a sending name explicitly references it and it resolves correctly.
A valid helper record patternDNS
example.com. TXT "v=spf1 include:_spf.shared.example.com -all" _spf.shared.example.com. TXT "v=spf1 ip4:192.0.2.10 -all"
In that helper pattern, example.com still has its own SPF record. The helper record does not become the SPF record for every subdomain by itself. It is only used when another SPF record explicitly points to it with include or redirect.
An include matches when its target returns SPF pass. A redirect uses its target's result when no mechanism matches. Do not add all to a policy that relies on redirect, because any all mechanism disables redirect. Neither method changes the original MAIL FROM domain used for DMARC matching.
An invalid duplicate record patternDNS
example.com. TXT "v=spf1 ip4:192.0.2.10 -all" example.com. TXT "v=spf1 include:esp.example.net -all"
Under RFC 7208, selecting multiple SPF records at one owner name returns PermError. Merge the required mechanisms into one record, with one v=spf1 prefix and one final all mechanism. Moving a sender to a subdomain works only if its actual MAIL FROM identity changes too.
Merge both senders into one SPF recordDNS
example.com. TXT "v=spf1 ip4:192.0.2.10 include:esp.example.net -all"
Keep unrelated TXT records when replacing duplicate SPF records. Use the final ~all or -all policy appropriate to your verified senders. -all produces SPF fail for an unauthorized IP address; the receiver decides message handling, and DKIM with the required domain match can still satisfy DMARC.
When a subdomain needs its own SPF
A subdomain needs its own authorizing SPF record when it is part of the sending identity being checked. Start with one practical question: what domain appears in the envelope sender when the message is delivered? The answer tells you where SPF belongs.
- A platform uses bounces.example.com as the Return-Path domain for campaigns.
- Transactional mail uses mail.example.com in MAIL FROM.
- Separate mail streams use different envelope sender subdomains.
- A server uses a subdomain as its HELO/EHLO identity and receivers check that identity.
- A provider assigns an envelope sender subdomain and supplies DNS instructions for that exact name.
A subdomain used only for a website, a visible From address or a DKIM selector does not need an authorizing SPF record for that reason alone. SPF placement depends on the SMTP identity being checked. An existing CNAME needs special care because a TXT record cannot coexist at the same DNS name.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
When the record looks unclear, run the exact domain through an SPF checker. Check both the root and any suspected subdomain. If an evaluated include target has no SPF record, it causes PermError; repair or remove the reference after confirming which senders still need it.
How to protect non-sending names
A parked domain or defined subdomain that never sends mail can publish v=spf1 -all. This SPF TXT record authorizes no sending IP address, so a receiver evaluating that exact MAIL FROM or HELO name gets an SPF fail instead of SPF none. It is a defensive record, not an authorizing record.
Fail-all SPF for non-sending namesDNS
example.net. TXT "v=spf1 -all" *.example.net. TXT "v=spf1 -all" unused.example.com. TXT "v=spf1 -all"
Wildcard SPF is not a substitute for checking exact names. An existing DNS name, including a name implied by records below it, can prevent a wildcard from supplying TXT data. Defined names can need explicit v=spf1 -all records. A CNAME cannot also hold that TXT record, so check the zone structure before publishing.
Do not publish -all at a domain or subdomain until you have confirmed that no legitimate system uses it for MAIL FROM or HELO. DMARC policy can cover visible From subdomains, but it does not create an SPF record for an unused name. SPF alone does not authenticate the visible From header; use DMARC enforcement to address that identity after checking legitimate SPF and DKIM authentication.
How to decide where to add a sender
Add a vendor include only to the SPF policy for the MAIL FROM domain that vendor actually uses. Adding it to every root and subdomain record creates unnecessary authorizations and increases lookup-limit risk.
|
|
|
|---|---|---|
example.com | Receiver-reported smtp.mailfrom | Authorize the sender at example.com |
bounces.news.example.com | Receiver-reported smtp.mailfrom | Authorize the sender at that subdomain |
A provider-owned domain | SPF domain and DKIM signing domain | Use custom MAIL FROM or passing DKIM that meets DMARC domain matching |
A generated helper | The referencing SPF record and helper TXT | Confirm it resolves and supplies the intended sender policy |
Use the actual SPF domain, not the visible brand domain alone.
If employee mail uses example.com in MAIL FROM, its sender authorization belongs at example.com. If a platform uses bounces.news.example.com as its envelope domain, its SPF policy belongs at that name. If the platform uses its own envelope domain, adding an include to your domain does not affect that SPF check. Configure a custom MAIL FROM domain or branded DKIM that meets DMARC domain matching instead.
Inspect Authentication-Results added by the receiving mail system. Its smtp.mailfrom value identifies the domain evaluated for MAIL FROM SPF; smtp.helo identifies a HELO check. Return-Path is also useful, but forwarding can change the envelope sender, so compare a direct test message when diagnosing your original sender.
- Find the SPF result and smtp.mailfrom or smtp.helo identity in the receiver's Authentication-Results header.
- Compare that exact domain with the root and subdomain records in DNS.
- Update only the SPF policy for the evaluated domain, including any referenced helper that needs repair.
If you manage several domains, a domain health checker is useful because it checks SPF alongside DKIM and DMARC. That avoids fixing one record while missing a related authentication gap.
How to publish and verify subdomain SPF
Publish SPF as a DNS TXT record. The obsolete SPF DNS record type is not a substitute. Edit the authoritative DNS zone for the exact SPF identity; a delegated subdomain can use a different DNS host than its parent.
- Choose the correct Host or Name field. In the example.com zone, @ usually means example.com, mail means mail.example.com, and bounces.news means bounces.news.example.com. Check whether the DNS host expects a relative name or a full name to avoid appending example.com twice.
- Check for an existing CNAME. A CNAME cannot coexist with an SPF TXT record at the same name. If a sending provider manages SPF through a CNAME, follow its instructions and verify that a TXT lookup follows the alias to a valid SPF policy.
- Replace duplicate SPF records with one complete policy. Preserve required IP addresses and includes, then validate syntax and the full lookup chain before saving.
- Verify the published TXT at the authoritative DNS server, then check a recursive resolver. Cached records remain until their TTL expires; a previously absent record can also be cached. Send a direct test message and confirm the receiver reports SPF pass for the intended domain.
The 255-octet limit applies to each character-string inside a TXT record, not to the entire SPF policy. A longer policy can use multiple strings in one TXT record; receivers concatenate them without inserting spaces. Preserve spaces between mechanisms and do not split the policy into separate SPF records.
Keeping SPF under the lookup limit
SPF allows no more than 10 evaluated terms that cause DNS queries in one check. The include, a, mx, ptr and exists mechanisms count, as does redirect. Nested evaluations share this limit. The all, ip4 and ip6 mechanisms do not consume it. Avoid ptr because its DNS processing is slow and unreliable.
SPF lookup budget
The 10-term limit is defined by SPF. The lower bands are planning guidance, not additional protocol thresholds or guarantees of a pass.
More headroom
0-6
A planning range with room for some sender changes; other SPF errors are still possible.
Less headroom
7-10
Up to 10 evaluated terms is allowed. At 10, one additional term exceeds the limit.
PermError
Over 10
Evaluating more than 10 DNS-querying terms causes SPF PermError.
Separate MAIL FROM domains have separate SPF evaluations, but moving includes into a helper does not reset the counter. To reduce the root domain's sender list, move the relevant mail stream's MAIL FROM identity to its own subdomain and authorize it there. Changing only the visible From address does not change the SPF lookup budget.
When a record gets crowded, SPF flattening can help, but it needs monitoring because vendor IPs change. Reduce unnecessary includes first, then use flattening or hosted SPF when the sender mix still needs tighter control.
Manage domain and subdomain SPF in Suped
Use DMARC reports in Suped to identify legitimate sending sources before changing SPF. Inspect delivered headers to confirm each source's MAIL FROM domain, then check the corresponding DNS name. Suped's SPF checks help identify duplicate records and broken includes during that review.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
For this specific problem, Suped's Hosted SPF lets you manage authorized senders in the dashboard after publishing the SPF pointer supplied for that name. Configure each SPF identity separately: hosting the root domain's policy does not automatically cover its subdomains.
- Review DMARC reports for legitimate senders before removing SPF authorizations.
- Check the root domain and each active envelope sender subdomain for duplicate records or invalid includes.
- After configuring Suped's Hosted SPF at a sending name, manage its authorized senders in the dashboard.
- Send direct test messages after changes and review subsequent authentication reports for unexpected failures.
Check SPF at the exact sending name
Separate SPF policies are needed when the root domain and its subdomains are distinct SPF sending identities. A parent policy does not automatically authorize subdomain senders. Referencing a subdomain helper with include or redirect can share authorizations, but does not change which MAIL FROM domain was authenticated.
Use this decision path: identify the envelope sender domain, check whether that exact DNS name has one SPF record, confirm every included helper exists, then count DNS lookups. If the message uses the root, fix the root. If it uses a subdomain, fix the subdomain. If a vendor uses its own SPF domain, focus on DKIM and DMARC matching instead of adding unnecessary includes.
Keep one SPF record per sending identity, retain unrelated TXT records, and remove stale helper references only after checking their sending sources.
Frequently asked questions
No. SPF does not inherit downward. A receiver checking mail.example.com looks for SPF at mail.example.com, not at example.com.
Yes. Each DNS name can have one SPF TXT record. Multiple records beginning with v=spf1 at the same name cause PermError, while unrelated TXT records can coexist with SPF.
Only when the vendor sends mail using both SPF domains. If the vendor only uses a subdomain as the envelope sender, add the include to that subdomain only.
No. SPF is evaluated at the MAIL FROM domain, or the HELO domain when MAIL FROM is empty. DMARC requires passing SPF or DKIM with the appropriate match to the visible From domain; it does not move the SPF record.
Check whether another SPF record references it with include or redirect and whether it resolves to a valid policy. Repair a missing referenced helper before deleting records, and confirm which sender still needs it.
If the subdomain must never send mail, publish v=spf1 -all at that exact name when it can accept a TXT record. Confirm no legitimate MAIL FROM or HELO use first. A CNAME cannot coexist with that TXT record, and wildcard SPF does not cover every existing name.
