Does a subdomain used for sending emails need its own SPF record?
Updated on 25 Oct 2026: We clarified subdomain SPF placement, added DNS setup instructions, and corrected the guidance on soft fail and DMARC verification.
Yes, a subdomain used as the SPF sending identity needs its own SPF policy for SPF to pass. A TXT record at example.com does not automatically apply to send.example.com. SPF looks up the exact domain used in the SMTP envelope sender, also called the Return-Path or MAIL FROM domain. If that exact name is send.example.com, the SPF lookup starts at send.example.com, including any DNS alias or applicable wildcard.
If the subdomain appears only in the visible From address, but the email service uses a different bounce domain in the envelope sender, SPF is checked against that bounce domain. Do not publish SPF on the visible From subdomain solely because it appears there. Confirm the real envelope sender, then make sure SPF or DKIM passes with a domain that satisfies DMARC domain matching.
Publish SPF for the domain the receiving server checks in the envelope sender. For a sending subdomain, that usually means a separate SPF TXT record on the subdomain itself.
SPF records are separate for each subdomain
SPF is exact-name DNS authentication. DNS does not treat example.com and mail.example.com as one inherited authentication space. They are separate names. If mail.example.com is the envelope sender or HELO identity, publish a valid SPF policy for that name. The one-record rule applies to each DNS name, not the entire DNS zone; unrelated TXT records can coexist with SPF.
- Publish an SPF record at that subdomain when it appears in the envelope sender or HELO identity.
- Keep the parent domain SPF record for mail that actually uses the parent domain as the SPF identity.
- Use a restrictive SPF record such as v=spf1 -all if the subdomain should never send mail.
- Do not assume SPF checks the visible From address. It checks the SMTP identity first.
Parent SPF does not cover the subdomaindns
example.com. TXT "v=spf1 include:_spf.mailer.example -all" send.example.com. TXT "v=spf1 include:_spf.mailer.example -all"
Those two records are separate. The first authorizes sources for example.com. The second authorizes sources for send.example.com. If the subdomain lookup returns no SPF policy, receivers checking send.example.com do not borrow the parent SPF record. The SPF result is normally none, not a pass from example.com.
Which domain SPF checks
The SPF lookup domain normally comes from the SMTP MAIL FROM command. That domain receives bounces, so people often call it the Return-Path domain. SPF can also check the HELO or EHLO identity. When MAIL FROM has a null reverse path, SPF uses the HELO domain as the substitute MAIL FROM identity. DMARC does not use a separate HELO-only SPF pass.
This distinction explains most confusion. A message can show hello@example.com in the visible From header while using bounces@send.example.com for the envelope sender. SPF checks send.example.com. DMARC then checks whether the SPF-authenticated domain matches the visible From domain under relaxed or strict rules. A valid DKIM signature with a matching signing domain can support a DMARC pass when SPF does not.
SPF lookup flow from the envelope sender to DNS, SPF result, and DMARC domain matching.
If you are unsure which domain SPF is checking, send a test message and inspect the full headers. Look for Return-Path, smtp.mailfrom, and the Authentication-Results line. That tells you the exact DNS name SPF used.
How subdomain SPF works with DMARC
An SPF pass and a DMARC pass answer different questions. SPF confirms that the connecting IP is authorized for the MAIL FROM domain. DMARC then compares that authenticated domain with the visible From domain. Relaxed SPF alignment, the default set by aspf=r, accepts domains with the same organizational domain. Strict SPF alignment, set by aspf=s, requires an exact domain match.
|
|
|
|---|---|---|
example.com | example.com | Pass under relaxed or strict alignment |
example.com | bounce.example.com | Pass under relaxed alignment, fail under strict alignment |
example.com | bounce.example.net | No DMARC pass through SPF |
How SPF domain matching changes the DMARC result
Every row assumes SPF itself passes. In either case where SPF does not satisfy domain matching, DMARC can still pass through DKIM when a valid signing domain satisfies the selected DKIM alignment mode. Relaxed matching does not remove the need for an SPF record at bounce.example.com because SPF must pass before its domain can be compared.
Relaxed SPF alignment extends trust to authenticated subdomains under the same organizational domain. Do not delegate control of a sending subdomain to a party that should not be able to authenticate mail for the parent domain. Use strict SPF alignment only after verifying every legitimate MAIL FROM domain.
SPF does not inherit the parent record
The parent domain SPF record does not inherit downward. DMARC can use an organizational domain policy when the visible From subdomain has no DMARC record of its own. RFC 9989 defines a DNS tree walk for discovering that organizational domain and the applicable policy. SPF has no equivalent default inheritance rule.
SPF
- The receiver checks the SPF record at the envelope sender domain.
- A record at example.com does not cover mail.example.com by default.
- A DNS name should publish only one SPF TXT record.
DMARC
- A parent DMARC record can apply to subdomains without separate DMARC records.
- A subdomain can publish its own DMARC record when it needs a different policy.
- DMARC needs either SPF or DKIM to pass with a domain that matches the visible From domain.
A useful way to separate the two protocols: SPF is about authorization for a specific SMTP identity, while DMARC is about whether the authenticated identity matches the domain users see. That is why separate SPF records are common when subdomains send different streams of mail.
What to publish in DNS
The right record depends on how the subdomain is used. Start with an inventory before touching DNS: each mail stream, each vendor, each envelope sender domain, and each DKIM signing domain.
|
|
|
|---|---|---|
MAIL FROM uses send.example.com | send.example.com | Authorize only that mail stream |
MAIL FROM uses example.com | example.com | Authorize the parent domain senders |
A known subdomain never sends | That exact subdomain | v=spf1 -all |
MAIL FROM uses a provider-owned bounce domain | The provider-owned bounce domain | The provider manages its SPF policy |
A subdomain hosts only a website | No sending SPF identity | No sending authorization to add |
SPF placement for common subdomain cases
Example SPF records for subdomainsdns
send.example.com. TXT "v=spf1 include:_spf.mailer.example -all" news.example.com. TXT "v=spf1 include:_spf.news.example -all" alerts.example.com. TXT "v=spf1 redirect=_spf.example.com" unused.example.com. TXT "v=spf1 -all"
Use redirect= to reuse a complete shared SPF policy. Use include: to authorize another policy's senders inside the subdomain's own policy. Both explicitly associate a policy with the subdomain. Do not append -all to the redirect-only example: an all mechanism causes redirect= to be ignored.
If a vendor gives you a CNAME for the envelope sender, do not add an SPF TXT record at that same alias. A DNS name with a CNAME cannot also carry SPF TXT data. Confirm the canonical target has the SPF policy the vendor expects, then verify the result in message headers.
The unused subdomain example matters. A restrictive SPF record tells receivers that no source is authorized to send for that name. It does not stop spoofing by itself, but it removes ambiguity for that exact SPF identity.
Do not add a website IP to SPF just because a subdomain has an A record or now shares the main domain IP. SPF should include that IP only when it is the outbound SMTP connecting IP for the SPF identity. Separate SPF records do not guarantee inbox placement or isolate sender reputation when mail streams share an outbound IP.
A wildcard TXT record can supply SPF only when DNS wildcard synthesis applies. An existing DNS name can prevent the wildcard from answering even when that name has no SPF TXT record. Explicit records are easier to audit and avoid surprising results when subdomains are added.
How to enter a subdomain SPF record
For send.example.com in the example.com DNS zone, the Host or Name field is usually send. Using @ in that zone edits example.com instead. If send.example.com has its own delegated DNS zone, @ refers to send.example.com.
|
|
|---|---|
Type | TXT |
Host or Name | send |
Value | v=spf1 include:_spf.mailer.example -all |
TTL | Use the DNS provider default |
DNS panel example for send.example.com in the example.com zone
Replace the example include target with the exact value supplied by your email provider. Some panels require the full hostname; check the saved name to avoid send.example.com.example.com. Publish a TXT record, not the obsolete SPF DNS record type.
Check the authoritative DNS first, then allow cached answers to expire according to their TTL before testing again. Send another message and confirm spf=pass for the intended smtp.mailfrom domain in the receiving server's Authentication-Results header.
How to set it up safely
The safe process is simple, but it needs evidence. Do not start by copying the parent SPF record into every subdomain. That can authorize senders that should not use that subdomain, and it can push a record over the DNS lookup limit if too many includes are copied around.
- List every legitimate system that sends using the subdomain.
- Send test messages and confirm the envelope sender domain used by each stream.
- Create one SPF TXT record at the exact subdomain, with only the needed mechanisms.
- Run an SPF checker after publishing to catch syntax errors and detect duplicate records or lookup-limit problems.
- Confirm that SPF or DKIM passes with a domain that matches the visible From domain.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
The biggest practical constraint is the SPF processing limit. SPF evaluation permits no more than 10 terms that trigger DNS queries across the complete evaluation, including nested policies. The include, a, mx, ptr, and exists mechanisms count, as does the redirect modifier. The all, ip4, and ip6 mechanisms do not count. Receivers should also limit DNS terms that return no data or a nonexistent name, called void lookups, to two. Exceeding the 10-term limit returns permerror; exceeding the receiver's void-lookup limit also returns permerror. Each SPF evaluation has its own budget, so subdomains do not share one domain-wide allowance. The ptr mechanism remains valid syntax, but it is slow and should not be published.
When a record approaches the limit, remove stale mechanisms and consolidate the policy first. SPF flattening or hosted SPF management can reduce live lookup depth. Manual flattening needs continuous maintenance because provider IP ranges change, and stale IP entries can make legitimate mail fail SPF.
Avoid these SPF mistakes
Most SPF problems on sending subdomains come from assuming DNS inheritance exists, or from copying a record without checking the actual mail flow. Keep the record narrow and make every mechanism earn its place.
- Do not publish two SPF TXT records at the same DNS name. Merge them into one record.
- Do not copy the parent record unless every authorized sender is truly needed for the subdomain.
- Do not add a web or tracking host IP to SPF unless it sends mail over SMTP.
- Do not treat ~all as an SPF pass. Both ~all and -all produce non-pass results for unauthorized sources; DMARC then needs a valid DKIM signature with a matching domain. A -all failure risks rejection before DKIM is evaluated.
- Do not rely only on SPF for DMARC. Configure DKIM for the same mail streams too. Forwarding can break SPF because the connecting IP changes, so a surviving DKIM signature provides another route to a DMARC pass.
- Confirm every include target returns a valid SPF record. A missing or invalid target can cause permerror.
- Remove unused includes after a service is retired, or the subdomain stays over-authorized.
There is also a security angle. If a subdomain can be used in a Return-Path but lacks SPF, spoofed mail has less resistance at the SPF layer. SPF does not stop spoofing on its own. DKIM and DMARC policy still matter, and monitoring verifies that legitimate sources authenticate as intended.
How Suped handles this workflow
Suped, our DMARC reporting and email authentication platform, connects reported SPF and DKIM results with the domains used by each mail stream. Use those reports to identify sending subdomains that need header and DNS checks.
Review those results whenever a vendor or application changes its envelope sender. A new bounce subdomain needs its own SPF policy even when the visible From address stays the same.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
Suped's Hosted SPF gives teams a managed way to update authorized senders without repeated DNS edits. That is useful when separate organizational systems send through different subdomains.
After a DNS or Hosted SPF change, use incoming DMARC reports in Suped to check reported SPF results and domain matching. Reports cover mail observed by reporting receivers; they do not verify every subdomain or message. Confirm the published DNS policy and test-message headers separately.
Views from the trenches
Best practices
Map each sending subdomain to its actual envelope sender before changing any SPF records.
Publish one SPF TXT record per sending identity, then check syntax and nested DNS lookups.
Use restrictive SPF on known unused subdomains to give receivers an explicit no-mail result.
Common pitfalls
Copying the parent SPF record can authorize email senders that the subdomain never uses.
Multiple SPF TXT records at the same name cause permerror rather than stronger protection.
Checking only the visible From domain misses the actual Return-Path domain that SPF uses.
Expert tips
Pair SPF with DKIM so a surviving signature can support DMARC when forwarding breaks SPF.
Avoid wildcard SPF records unless DNS ownership and future subdomains are fully controlled.
Review SPF after every vendor change because stale includes keep old senders authorized.
Marketer view
Marketer from Email Geeks says SPF does not extend from example.com to foo.example.com, while DMARC can apply differently under its own policy rules.
2019-01-10 - Email Geeks
Expert view
Expert from Email Geeks says DNS treats example.com and foo.example.com as separate names, so protocols need exact records unless they define inheritance.
2019-01-10 - Email Geeks
Frequently asked questions
No. SPF on example.com does not automatically cover mail.example.com. Publish a separate SPF record at mail.example.com if that exact name is used as the SPF identity.
Check the full headers first. SPF usually checks the Return-Path domain, not the visible From address. If the Return-Path is a different domain, SPF is evaluated there.
A restrictive record such as v=spf1 -all is a useful defensive practice for known subdomains that should never send mail, but SPF does not require a record on every unused subdomain. The record gives receivers an explicit no-mail answer for that exact name.
A wildcard TXT record can supply SPF for an otherwise nonexistent DNS name. It does not reliably cover every subdomain because an existing DNS name can prevent wildcard synthesis even when it has no SPF TXT record. Explicit records are easier to audit.
No. DMARC does not move the SPF lookup. It checks whether SPF or DKIM passed and whether the authenticated domain matches the visible From domain under relaxed or strict rules.
Only when that IP becomes the outbound SMTP connecting IP for the SPF identity. A web-only A record change does not require adding the web IP to SPF.
