Yes, a subdomain used as the actual SPF sending domain needs its own SPF record. 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 record needs to exist at send.example.com.
The caveat is important. If the subdomain only appears 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 instead. In that case, the subdomain still needs good authentication, but SPF alone might not be the check that passes DMARC. I always confirm the real envelope sender before changing DNS.
Fast rule: publish SPF where the receiving server will look, not where the brand team expects people to look. For a sending subdomain, that usually means a separate SPF TXT record on the subdomain itself.
The short answer
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 sends mail, mail.example.com needs a valid SPF record unless another explicit DNS mechanism covers that exact name.
- Sending subdomain: Publish an SPF record at that subdomain when it appears in the envelope sender or HELO identity.
- Parent domain: Keep the parent domain SPF record for mail that actually uses the parent domain as the SPF identity.
- Unused subdomain: Use a restrictive SPF record such as v=spf1 -all if the subdomain should never send mail.
- Visible From: 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 second record is missing, receivers checking send.example.com do not borrow the parent SPF record.
Where SPF actually 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. If MAIL FROM is empty, as with some bounce messages, SPF can check the HELO or EHLO identity instead.
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 domain matches the visible From domain closely enough under DMARC rules, or whether DKIM passes with a matching signing domain.
A flowchart showing how SPF moves from the envelope sender to DNS and DMARC.
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.
When parent records do not apply
The parent domain SPF record does not inherit downward. This is different from DMARC, where a policy at the organizational domain can affect subdomains unless a subdomain has its own DMARC record. SPF has no equivalent default inheritance rule.
SPF
- Exact name: The receiver checks the SPF record at the envelope sender domain.
- No inheritance: A record at example.com does not cover mail.example.com by default.
- One active record: A DNS name should publish only one SPF TXT record.
DMARC
- Policy scope: A parent DMARC record can apply to subdomains without separate DMARC records.
- Subdomain override: A subdomain can publish its own DMARC record when it needs a different policy.
- Domain match: DMARC needs either SPF or DKIM to pass with a domain that matches the visible From domain.
I usually explain it this way: 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. I prefer to write this down as an inventory before touching DNS: each mail stream, each vendor, each envelope sender domain, and each DKIM signing domain.
|
|
|
|---|---|---|
Subdomain sends | Subdomain | include |
Parent sends | Parent | include |
No mail | Exact name | -all |
Vendor bounce | Bounce name | vendor |
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" unused.example.com. TXT "v=spf1 -all"
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.
Wildcard TXT records can match names that do not have an explicit record, but I do not treat wildcards as the normal answer for SPF. They can hide configuration mistakes and create surprising results when a new subdomain is added.
How to set it up safely
The safe process is simple, but it needs evidence. I 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.
- Identify senders: List every application, server, and email service that sends using the subdomain.
- Check headers: Send test messages and confirm the envelope sender domain used by each stream.
- Publish one record: Create one SPF TXT record at the exact subdomain, with only the needed mechanisms.
- Validate DNS: Run an SPF checker after publishing to catch syntax errors, multiple records, and lookup issues.
- Review DMARC: 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 DNS lookup limit. SPF evaluation allows a maximum of 10 DNS-querying mechanisms and modifiers. Includes, redirects, a, mx, ptr, and exists can all consume lookups. If the subdomain has several services, the record can hit that limit faster than expected.
When a record has too many lookups, receivers can return a permanent error instead of a clean pass or fail. That is where SPF flattening or hosted SPF management becomes useful, especially when different teams add and remove senders throughout the year.
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. I keep the record narrow and make every mechanism earn its place.
- Multiple records: Do not publish two SPF TXT records at the same DNS name. Merge them into one record.
- Copied parent: Do not copy the parent record unless every authorized sender is truly needed for the subdomain.
- Soft fail forever: Do not leave ~all permanently when the sender list is known and stable.
- Missing DKIM: Do not rely only on SPF for DMARC. Configure DKIM for the same mail streams too.
- Old senders: 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. DMARC policy, DKIM, and monitoring still matter, but SPF should not be the missing piece on the domain that actually sends.
How Suped handles this workflow
For most teams, Suped is the best overall DMARC platform for this workflow because it connects the DNS record to real mail flow. Suped's product monitors DMARC, SPF, and DKIM together, then shows which sources pass, which fail, and which domains need attention.
This matters for subdomains because the hard part is not writing v=spf1 once. The hard part is knowing whether send.example.com, bounce.example.com, news.example.com, and the parent domain are all authenticated correctly after vendors, campaigns, and applications change.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS setup
Suped's Hosted SPF gives teams a managed way to update authorized senders without repeated DNS edits. That is useful when marketing, product, support, and transactional systems all send through separate subdomains.
Suped also includes automated issue detection, real-time alerts, DMARC monitoring, hosted DMARC, hosted MTA-STS, SPF lookup optimization, blocklist (blacklist) monitoring, and an MSP dashboard for managing multiple domains. The practical benefit is that a missing subdomain SPF record becomes a visible issue with fix steps, not a buried DNS assumption.
Views from the trenches
Best practices
Map each sending subdomain to its envelope sender before changing any SPF records.
Publish one exact-name SPF record per sending identity, then validate every lookup.
Use restrictive SPF on unused subdomains so receivers get a clear no-mail signal.
Common pitfalls
Teams copy the parent SPF record and authorize senders the subdomain never uses.
Multiple SPF TXT records at one name create errors instead of cleaner protection.
People check the visible From domain and miss the Return-Path SPF actually used.
Expert tips
Pair SPF with DKIM because DMARC can pass through either authenticated domain match.
Avoid wildcard SPF records unless DNS ownership and future subdomains are controlled.
Review SPF after each vendor change because stale includes keep old senders authorized.
Marketer from Email Geeks says they normally configure SPF on the sending subdomain because mailbox providers can check authentication in subtly different ways.
2019-01-09 - Email Geeks
Marketer from Email Geeks says the sending domain should never skip SPF, whether that sender is the organizational domain or a subdomain.
2019-01-10 - Email Geeks
The practical rule
If a subdomain sends mail as the SPF identity, give that subdomain its own SPF record. Do not rely on the parent domain SPF record. SPF is checked at the exact DNS name used by the envelope sender or HELO identity.
The clean setup is one SPF record per sending DNS name, restrictive records for names that should not send, DKIM on every mail stream, and DMARC monitoring to confirm real traffic matches the design. That keeps the subdomain authenticated without over-authorizing the rest of the domain.
