SPF Records for Subdomains and Multiple Domains
Learn how SPF records work across subdomains and multiple domains. Each subdomain needs its own record — covers setup and redirect.
Last updated: 2026-05-13
If your business uses subdomains for email — like marketing.yourdomain.com for campaigns or support.yourdomain.com for helpdesk replies — there is one critical fact you need to understand: subdomains do not inherit SPF records from the parent domain. Each domain and subdomain needs its own SPF record, or email sent from that subdomain has no SPF authentication at all.
This catches a lot of people off guard. This guide explains how SPF works across domains and subdomains, and how to set it up correctly. For a full overview, see our complete SPF guide.
Subdomains Do Not Inherit SPF Records
This is the most important takeaway from this article. If your parent domain has this SPF record:
yourdomain.com TXT "v=spf1 include:_spf.google.com ~all"
And you send email from news.yourdomain.com, the receiving server checks the SPF record for news.yourdomain.com — not yourdomain.com. If news.yourdomain.com has no SPF record, the SPF check returns "none," which means no authentication.
No inheritance means no protection
A subdomain without its own SPF record is completely unprotected. Anyone can spoof emails from that subdomain because there is no SPF policy telling receiving servers what to accept or reject. This applies even if your parent domain has a strong SPF record with -all.
This behavior is defined in the SPF specification (RFC 7208). It is not a bug or a quirk of certain DNS providers — it is how the protocol works everywhere.
When to Use Subdomains for Email
Many businesses use subdomains to separate different types of email traffic. This is actually a best practice for email deliverability because it isolates reputation. If your marketing emails get complaints, it does not affect your transactional email reputation.
Common patterns include:
| Subdomain | Purpose | Typical Services |
|---|---|---|
| yourdomain.com | Corporate email (person-to-person) | Google Workspace, Microsoft 365 |
| mail.yourdomain.com | Marketing campaigns | Mailchimp, Brevo, Constant Contact |
| notify.yourdomain.com | Transactional email (receipts, alerts) | SendGrid, Amazon SES, Postmark |
| support.yourdomain.com | Helpdesk and support tickets | Zendesk, Freshdesk, Intercom |
Each of these subdomains needs its own SPF record that authorizes the service sending from it. This is also an effective strategy for staying under the 10 DNS lookup limit when you use multiple email providers.
Setting Up SPF for Each Subdomain
The process is the same as setting up SPF for your main domain — you add a TXT record in your DNS settings. The only difference is the hostname field.
Identify which subdomains send email
List every subdomain that sends email for your business. Check your email service configurations — each one will show the "from" domain or "sender domain" it uses.
Determine the authorized senders for each subdomain
For each subdomain, note which service sends email from it. You will need the SPF include value for each service (for example, include:sendgrid.net for SendGrid or include:servers.mcsv.net for Mailchimp).
Add a TXT record for each subdomain
In your DNS settings, create a TXT record for each sending subdomain. Set the hostname to the subdomain name (for example, mail for mail.yourdomain.com) and the value to the appropriate SPF record.
Add v=spf1 -all for non-sending subdomains
Any subdomain that should never send email should have v=spf1 -all as its SPF record. This tells receiving servers to reject any email claiming to come from that subdomain.
Verify each subdomain
Use the checker tool above to look up each subdomain individually. Confirm that the SPF record is published and valid for every one.
Example: Multi-Subdomain SPF Setup
Here is what a complete setup might look like for a business using three subdomains:
yourdomain.com (corporate email via Google Workspace):
v=spf1 include:_spf.google.com ~all
mail.yourdomain.com (marketing via Mailchimp):
v=spf1 include:servers.mcsv.net ~all
notify.yourdomain.com (transactional via SendGrid):
v=spf1 include:sendgrid.net ~all
Each subdomain has exactly one SPF record that authorizes only the service that actually sends from it. This keeps each record simple and well within the 10 DNS lookup limit.
The Redirect Modifier: Sharing SPF Across Domains
If you manage multiple domains that all use the same email services, maintaining identical SPF records on each one is tedious and error-prone. The SPF redirect modifier solves this by pointing one domain's SPF evaluation to another domain's record.
v=spf1 redirect=_spf.yourdomain.com
With this setup, when a server evaluates SPF for a domain using the redirect, it fetches and uses the SPF record at _spf.yourdomain.com instead. You maintain one central SPF record and point all your domains to it.
redirect replaces the entire evaluation
The redirect modifier is not like include. With include, the included record is one part of the evaluation. With redirect, the entire SPF evaluation is handed off to the target domain. You cannot combine redirect with an all mechanism — redirect is used when no other mechanisms match.
This is especially useful for businesses that own several domains (brand domains, country-specific domains, or acquired company domains) that all send from the same email infrastructure.
Protecting No-Send Subdomains and Domains
Any domain or subdomain that does not send email should still have an SPF record — specifically:
v=spf1 -all
This hardfail tells receiving servers that no one is authorized to send email from this domain. Without it, attackers can spoof your unused domains and subdomains, potentially damaging your brand.
Common domains and subdomains to protect:
- Parked or redirect-only domains
- Legacy domains you no longer use for email
- Subdomains used exclusively for websites, APIs, or other non-email purposes
- Country-specific domains you own but do not email from
Combine this with DMARC records on these domains for even stronger protection. A DMARC policy of p=reject on a no-send domain tells receiving servers to reject any spoofed emails outright.
Managing SPF Across Multiple Business Domains
If your business operates several domains, here are practical tips for keeping SPF manageable.
Centralize your SPF policy. Use the redirect modifier to point all domains to a single SPF record. When you add or remove an email service, you update one record instead of many.
Audit regularly. Periodically check each domain and subdomain with the checker tool to make sure records are still valid, especially after acquisitions or rebrands.
Use consistent subdomain naming. Decide on a convention (like mail. for marketing and notify. for transactional) and use it across all domains.
Set up monitoring. When you have many domains, manual checking does not scale. The Email Deliverability Suite monitors SPF, DKIM, and DMARC across all your domains and alerts you when any record breaks.
Do Not Forget DKIM and DMARC
SPF is just one part of email authentication. Each subdomain that sends email should also have DKIM (RFC 6376, set up through your email provider) and DMARC (RFC 7489, set up on your parent domain — subdomains inherit DMARC policies, unlike SPF).
References
- RFC 7208: Sender Policy Framework (SPF) — The current SPF specification; subdomains do not inherit SPF records
- RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM specification
- RFC 7489: DMARC — DMARC specification; subdomains inherit DMARC policies from parent domains
Never miss an SPF issue
Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.
Start Monitoring