SPF Subdomain Inheritance

Here is the short answer: no, subdomains do not inherit SPF records from the parent domain. If your domain yourdomain.com has a perfectly configured SPF record, that record does absolutely nothing for billing.yourdomain.com, mail.yourdomain.com, or any other subdomain. Each one needs its own SPF record, or it has no SPF protection at all.

This is one of the most common misunderstandings in email authentication, and it leaves a lot of businesses with unprotected subdomains that attackers can spoof freely. This guide explains how SPF inheritance actually works (or rather, does not work), why it matters, and exactly what to do about it. For a full overview of SPF, see our complete SPF guide.

How SPF Checks Work for Subdomains

When a receiving email server gets a message claiming to be from [email protected], it looks up the SPF record for billing.yourdomain.com — not yourdomain.com. Per RFC 7208, the server checks the exact domain in the envelope sender address, with no fallback to the parent domain.

If billing.yourdomain.com has no SPF record, the SPF check returns a result of "none." This means there is no SPF policy for that subdomain. The receiving server has no guidance on whether to accept or reject the message. In practice, "none" usually means the email is delivered, since there is no policy telling the server to reject it.

'None' is not the same as 'pass'

An SPF result of "none" means no SPF record exists. It does not mean the email passed authentication. It means there is no authentication at all for that subdomain. Attackers rely on exactly this gap.

Why This Matters for Your Business

Imagine you run a business at yourdomain.com. You have carefully set up SPF, DKIM, and DMARC on your main domain. Your corporate email is well-protected.

But you also have subdomains: billing.yourdomain.com for invoicing and support.yourdomain.com for your helpdesk. If neither has its own SPF record, an attacker can send phishing emails from [email protected] or [email protected] — and there is no SPF policy to reject them. Your customers may receive convincing phishing emails that appear to come from your business, despite the strong SPF record on your main domain.

The Difference Between SPF and DMARC Inheritance

This is where things get confusing, because DMARC does work differently. Per RFC 7489, DMARC policies on a parent domain do apply to subdomains (unless the subdomain has its own DMARC record). So if yourdomain.com has a DMARC policy of p=reject, that policy also covers billing.yourdomain.com by default.

Protocol	Subdomain Behavior	What This Means
SPF	No inheritance — each subdomain needs its own record	billing.yourdomain.com must have its own SPF TXT record
DMARC	Inherits from parent domain (unless overridden)	billing.yourdomain.com uses the parent's DMARC policy automatically
DKIM	No inheritance — keys are configured per domain	Each subdomain needs its own DKIM keys set up

Having a DMARC policy on your parent domain helps, but it works best when SPF (and DKIM) are also configured on each subdomain. DMARC checks whether SPF or DKIM pass and align with the "From" domain — if neither is set up on a subdomain, DMARC has nothing to evaluate.

Which Subdomains Need SPF Records

The answer depends on whether the subdomain sends email or not.

Subdomains That Send Email

Any subdomain used as a sending domain needs an SPF record that authorizes the specific service sending from it. Common examples:

mail.yourdomain.com used by your marketing platform (Mailchimp, Brevo, etc.)
notify.yourdomain.com used by your transactional email service (SendGrid, Postmark, etc.)
support.yourdomain.com used by your helpdesk (Zendesk, Freshdesk)

Each needs its own SPF record with the correct include: for the service that sends from it. If you use multiple providers, see our guide on combining SPF for multiple ESPs.

Subdomains That Do Not Send Email

Subdomains that never send email — like api.yourdomain.com, cdn.yourdomain.com, or staging.yourdomain.com — should still have an SPF record. The record is simple:

v=spf1 -all

This tells receiving servers: "No one is authorized to send email from this subdomain. Reject everything." Without this record, the subdomain is unprotected and can be spoofed.

The Wildcard Myth

A question that comes up frequently: "Can I use a wildcard DNS record to cover all subdomains with one SPF record?" The answer is no, not reliably.

While DNS does support wildcard records (*.yourdomain.com), they only apply to subdomains that do not have any DNS records of their own. If billing.yourdomain.com already has an A record or MX record, a wildcard TXT record will not apply to it.

The correct approach is to add an explicit SPF record for each subdomain individually.

How to Audit and Protect Your Subdomains

Here is a practical approach to finding and securing all your subdomains:

List all your subdomains

Check your DNS zone file for all subdomains. Look at A records, AAAA records, CNAME records, and MX records. Each unique subdomain you find is one that needs an SPF record. Your DNS provider's dashboard will show all of these.

Identify which subdomains send email

Check your email service configurations. Each service shows which domain or subdomain it sends from. Also check your MX records — any subdomain with MX records is set up to handle email.

Add SPF records for sending subdomains

For each subdomain that sends email, add a TXT record with the appropriate include: mechanisms for the services that send from it. Use the checker tool above to verify each one.

Add v=spf1 -all for non-sending subdomains

For every subdomain that does not send email, add v=spf1 -all as a TXT record. This blocks spoofing attempts on those subdomains.

Verify everything

Use the checker tool to look up each subdomain individually. Confirm that every subdomain has a valid SPF record — either authorizing its legitimate senders or blocking all senders with -all.

For a broader view of your domain's email authentication health, the SPF Record Audit guide walks through a complete review process. You can also check your SPF alongside DKIM and DMARC using the Email Deliverability Suite.

Keep Your Subdomains Protected Over Time

Subdomains get created and forgotten. Make SPF part of your subdomain creation process: any time a new subdomain is created, add either a proper SPF record (if it will send email) or v=spf1 -all (if it will not). Monitoring tools can alert you when new subdomains appear without SPF records, so nothing slips through the cracks.

For more on managing SPF across multiple domains and subdomains, including the redirect modifier for sharing SPF policies, see our detailed guide.

References

RFC 7208: Sender Policy Framework (SPF) — The current SPF specification; SPF records are not inherited by subdomains
RFC 7489: DMARC — DMARC specification; unlike SPF, DMARC policies are inherited by subdomains

Never miss an SPF issue

Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.

Start Monitoring

SPF Subdomain Inheritance: Why Subdomains Do Not Inherit SPF Records