Why Your Subdomains Need Their Own SPF and DKIM Records Even When They Inherit Your DMARC Policy

You published a DMARC record on your root domain with p=reject. Your subdomains are covered, you think. They inherit the policy automatically.

What you missed: DMARC policy inheritance is real. SPF and DKIM do not follow the same rule.

A subdomain that sends mail without its own aligned SPF and DKIM will silently fail DMARC p=reject, even though the root domain policy was set with the best intentions. The mail gets blocked. The sending application shows no error. The only place you find out is the aggregate report.

If you use DMARCFlow, the failure shows up in your parsed report within the next reporting period -- a source IP sending for your subdomain with zero DKIM results and no aligned SPF. Without aggregate report monitoring, you may not find out until a user reports that a password reset or order confirmation never arrived.

How DMARC policy inheritance actually works

DMARC has a subdomain policy tag sp to set a different policy for subdomains. If you do not set it, subdomains inherit the root domain policy by default. Set p=reject on your root domain and your subdomains are covered by reject too -- unless you override them with sp=none.

This sounds convenient. One record, full coverage.

The catch: DMARC inheritance stops at the policy level. SPF and DKIM records do not inherit from parent to subdomain. A subdomain that sends mail needs its own SPF record authorizing its own sending infrastructure, and its own DKIM key configured on whatever service sends its mail. Without those, the subdomain is a sending entity with no valid authentication, covered by a reject policy that will silently block it.

Why this failure is silent

When a subdomain fails DMARC p=reject, the receiving server rejects the message. No bounce goes back to the sending application. The sending application logs the mail as delivered. There is no error in your ticketing system, no alert in your monitoring dashboard.

The only evidence is in your aggregate report: a source IP sending mail with your subdomain From header, zero DKIM results, zero aligned SPF.

This is not hypothetical. A DMARC practitioner we have heard from -- someone who runs a DMARC monitoring service for a living -- discovered his own subdomain was silently failing DMARC because a new sending path had been set up without aligned DKIM. His daily job is email authentication. He still got caught.

For organizations without aggregate report monitoring, this can persist for weeks. Transactional emails, password resets, internal alerts -- gone, with no explanation in any application log.

Common ways the inheritance trap gets triggered

A new sending service starts on a subdomain without proper DNS setup

A team launches notify.example.com to send status alerts. The sending service is configured. The team forgets to add the service's mail servers to an SPF record for notify.example.com and forgets to set up DKIM for the subdomain. The root domain has p=reject. Every alert silently dies at receiving servers.

A marketing platform sends from a subdomain

The marketing team runs campaigns through a SaaS platform. The From header is newsletter.example.com. The platform sends from its own infrastructure and signs with its own DKIM selector by default. The root domain has p=reject. Unless the platform is reconfigured to sign for newsletter.example.com with proper alignment, every campaign email fails.

An engineering team adds a transactional email API

The team adds a new service that sends from order-confirmation.example.com. The API provider's servers are included in the root domain SPF record. But the DKIM key for the subdomain is not configured. The root domain p=reject catches the DKIM alignment failure and blocks the transactional emails.

The fix: aligned SPF and DKIM for every sending subdomain

Each subdomain that sends mail needs two DNS records.

SPF record: Authorize the servers that send mail for that subdomain. If only one service sends, a minimal record looks like:

v=spf1 include:_spf.sendgrid.net -all

Replace sendgrid.net with your actual sender.

DKIM record: Publish the public key on the subdomain, install the private key on your sending service. The DKIM selector must sign with the subdomain as the signing domain, not the root.

With both in place, the subdomain's mail passes DMARC alignment and the root domain policy applies cleanly.

Locking down subdomains that do not send mail

For subdomains that should never send mail -- ftp.example.com, legacy-app.example.com, old.example.com -- publish a null MX and a reject-all SPF to make that explicit:

# Null MX: this domain does not accept mail
example.com. IN MX 0 .

# Reject all SPF: nothing is authorized to send from this subdomain
v=spf1 -all

This prevents these subdomains from being used in spoofing campaigns and removes any ambiguity about mail acceptance. Receiving servers that see p=reject on your root domain will also reject spoofed mail appearing to come from these subdomains.

Quick-reference summary

• DMARC policy on the root domain applies to subdomains automatically
• SPF and DKIM do not inherit from the root domain to subdomains
• Each sending subdomain needs its own SPF record and DKIM key
• Without both, subdomain mail silently fails DMARC p=reject
• Non-sending subdomains should use null MX and v=spf1 -all to lock them down
• Aggregate reports are the only way to catch silent subdomain failures without user reports
• DMARCFlow flags new subdomain sending sources and auth gaps in parsed reports

Before you move your root domain to p=reject, check your aggregate report for every subdomain that appears as a sending source. If any lack aligned SPF and DKIM, configure both before the policy takes effect. The failure will not appear in your application's sent mail log.

Frequently asked questions

Does a subdomain inherit the root domain DMARC policy?

Yes. A subdomain inherits the root domain DMARC policy by default. You can override it with the sp tag in your root domain record -- for example, sp=none if you want subdomains to be exempt -- but if you do not set sp, subdomains fall under the root domain policy.

Does SPF inherit to subdomains?

No. SPF records do not inherit. Each subdomain needs its own SPF record authorizing the servers that send mail for that specific subdomain. The parent domain SPF record covers only the parent.

Does DKIM inherit to subdomains?

No. DKIM keys are published per-domain. A subdomain that sends mail needs its own DKIM configuration -- private key on the sending service, public key published on the subdomain. The root domain DKIM record does not cover subdomains.

How do I find out if a subdomain is silently failing DMARC?

Your aggregate reports are the only place this shows up. Look for any subdomain in the From header that has sending source IPs listed but shows zero DKIM pass and zero aligned SPF pass. That pattern is a silent failure. If you do not have aggregate report monitoring, set it up before moving to p=reject.

What is the null MX record for subdomains?

A null MX record declares that a domain does not accept mail. Publishing IN MX 0 . on a subdomain that never sends, combined with v=spf1 -all, makes that explicit to receiving servers and prevents the subdomain from being used credibly in spoofing attacks.

Can I use sp=none to avoid subdomain DMARC failures?

You can, but it creates a security gap. Setting sp=none tells receiving servers not to apply DMARC checks to subdomain mail, which means spoofed mail from those subdomains will not be blocked. The correct approach is to configure SPF and DKIM for subdomains that send mail, and use null MX with v=spf1 -all for subdomains that do not.