SPF Records for Subdomains: Do You Need Them?

Here's the misconception that trips up most people: they assume subdomains inherit the parent domain's SPF record. They don't. If you have a perfect SPF record on example.com, your mail.example.com subdomain has no SPF protection at all -- unless you create a separate record for it.

This matters because attackers know it too. Unprotected subdomains are a common spoofing target. And if you're sending email from subdomains (transactional, marketing, support), those messages are flying without SPF authentication.

Subdomains Do Not Inherit SPF

This is the single most important thing to understand. The SPF specification (RFC 7208) is explicit: SPF records are evaluated per-domain. When a receiving server checks SPF for mail.example.com, it queries the DNS TXT records for mail.example.com -- not example.com.

If mail.example.com doesn't have its own SPF record, the SPF check returns none. That's the same result as having no SPF at all.

This is different from DMARC, where subdomains can inherit the parent domain's policy (unless overridden with sp=). SPF has no inheritance mechanism whatsoever.

When You Need a Subdomain SPF Record

Not every subdomain needs an SPF record, but many do. Here's how to decide.

The pattern is straightforward: if a subdomain sends email, it needs an SPF record authorizing the senders. If it doesn't send email, publish a null record to block spoofing.

The Null SPF Record

For subdomains that should never send email, publish this record:

v=spf1 -all

This tells every receiving server that no IP address is authorized to send email from this subdomain. Any message claiming to come from www.example.com or api.example.com will fail SPF.

It takes 30 seconds to add and closes a gap that attackers actively exploit. Subdomains like www, cdn, static, api, dev, and staging should all have null SPF records if they don't send email.

Using Subdomains to Solve the 10-Lookup Limit

This is where subdomains become a powerful architectural tool. The SPF 10 DNS lookup limit applies per-domain. If your root domain is running out of lookup budget because you have too many sending services, splitting those services across subdomains gives each one its own budget of 10 lookups.

Before: Everything on the Root Domain

example.com: v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:mail.zendesk.com include:_spf.salesforce.com -all

This record is already at 8-10 lookups when you count nested includes. Adding one more service pushes you over the limit.

After: Split by Function

example.com:           v=spf1 include:_spf.google.com -all
mail.example.com:      v=spf1 include:sendgrid.net -all
marketing.example.com: v=spf1 include:servers.mcsv.net -all
support.example.com:   v=spf1 include:mail.zendesk.com -all
crm.example.com:       v=spf1 include:_spf.salesforce.com -all

Each subdomain uses 1-4 lookups. None is anywhere near the limit. And you can add more services to any subdomain without affecting the others.

Setting Up SPF for a Subdomain: Step by Step

Let's walk through setting up SPF for transactional email on a subdomain. In this example, you're moving SendGrid from your root domain to mail.example.com.

Example Records: Multi-Subdomain Setup

Here's a realistic setup for a company using Google Workspace for corporate email, SendGrid for transactional, and Mailchimp for marketing.

Root Domain: Google Workspace

example.com TXT "v=spf1 include:_spf.google.com -all"

This handles employee email. Google Workspace is the only service sending from @example.com.

Transactional Subdomain: SendGrid

mail.example.com TXT "v=spf1 include:sendgrid.net -all"

Order confirmations, password resets, and system notifications go through SendGrid using noreply@mail.example.com.

Marketing Subdomain: Mailchimp

marketing.example.com TXT "v=spf1 include:servers.mcsv.net -all"

Newsletters and campaigns send from news@marketing.example.com.

Non-Sending Subdomains: Null Records

www.example.com       TXT "v=spf1 -all"
api.example.com       TXT "v=spf1 -all"
staging.example.com   TXT "v=spf1 -all"

These subdomains don't send email. The null record blocks spoofing attempts.

DMARC Alignment With Subdomains

When you move email to subdomains, DMARC alignment becomes important. DMARC checks whether the domain in the From header aligns with the domain that passed SPF or DKIM. There are two alignment modes.

Relaxed Alignment (aspf=r)

This is the default. With relaxed alignment, SPF passes DMARC alignment if the SPF-authenticated domain and the From domain share the same organizational domain.

• Email from noreply@mail.example.com with SPF passing for mail.example.com aligns with a From header of user@example.com. The organizational domain is example.com in both cases.

This is the mode most domains use, and it works well with subdomain-based sending.

Strict Alignment (aspf=s)

With strict alignment, the SPF domain must exactly match the From header domain.

• Email from mail.example.com does not align with From: user@example.com under strict mode.
• Email from mail.example.com only aligns with From: noreply@mail.example.com.

If you're using subdomains with relaxed DMARC alignment, messages sent from subdomains will align with your root domain's From address. If you're using strict alignment, the From address must match the subdomain.

Common Mistakes With Subdomain SPF

Assuming Inheritance

The biggest mistake. You set up v=spf1 include:_spf.google.com include:sendgrid.net -all on example.com and assume mail.example.com is covered. It isn't. Every subdomain that sends email needs its own record.

Forgetting to Protect Non-Sending Subdomains

If blog.example.com exists but doesn't send email, an attacker can spoof ceo@blog.example.com. Without an SPF record on the subdomain, there's nothing to stop it. Add v=spf1 -all to every non-sending subdomain.

Not Setting Up DKIM on Subdomains

SPF on the subdomain is only half the picture. Each subdomain also needs DKIM configured, and your DMARC policy needs to cover subdomain behavior. The three protocols work together -- setting up one without the others leaves gaps.

Using the Wrong DNS Level

When adding an SPF record for mail.example.com, make sure you're creating the TXT record on mail.example.com, not adding a record named mail to a different zone. Check your DNS provider's interface carefully.

When to Use Subdomains vs. Keep Everything on the Root

Monitor Your New SPF Record

You've created your SPF record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.