p=reject Silently Blocks Subdomain Mail

The Morning the DMARC Expert Got Paged

A DMARC specialist with 20 years in email authentication woke up to an alert: a new return-path had appeared on one of their subdomains, ar.glockapps.com, and the SPF record was missing. Critical. They pulled the aggregate report and found the problem immediately. Microsoft 365 was sending mail with a From address of ar.glockapps.com, and every single message was failing DMARC. SPF: fail, because there was no SPF record on that subdomain at all. DKIM: the signature from groups.office.net validated cryptographically, but the signing domain did not align with the From domain, so alignment failed. DMARC: fail, disposition reject.

Their own legitimate subdomain mail was being rejected at Outlook. Not spam-filtered. Rejected.

No application error. No mail queue problem. The app said the message was sent. The sending logs were clean. The only reason anyone knew something was wrong was the DMARC aggregate report and an anomaly alert that flagged the unexpected return-path.

Why p=reject on the Root Domain Does Not Protect Your Subdomains

This is the trap most people do not see coming. When you set p=reject on your root domain, subdomains inherit that policy. That is correct and intentional. A subdomain with no DMARC record of its own automatically gets the parent policy applied to it. If your root has p=reject, your subdomains are protected by rejection.

But protection and liability arrive together. That inherited reject policy does not just block spoofers. It blocks anything that fails DMARC on that subdomain, including your own forgotten SPF record.

To the receiving mail system, a spoofer forging your subdomain and your own legitimate mail that forgot SPF look identical. Both fail DMARC. Both get rejected. That is exactly what reject is supposed to do. The problem is not the policy. The problem is that SPF and DKIM are not inherited the way the policy is.

The Specific Gap: SPF and DKIM Are Not Inherited

A subdomain inherits your DMARC policy. It does not inherit your SPF record or your DKIM key.

When your devops team spins up a new subdomain and hands it to the sending team to wire into the M365 or SendGrid or Mailgun setup, there is a gap between those two steps. If SPF never gets published for that subdomain, it has no SPF record at all. If the DKIM signature comes from the provider domain instead of your own domain, DKIM alignment fails. And if your root domain has p=reject, both of those failures result in silent mail rejection.

Your sending application does not know. Your SMTP logs do not show a problem. The mail is gone before anyone notices.

The comment that summed it up best in the original thread: "Subdomains are where clean DMARC rollouts go to die." Another practitioner confirmed the same gap in their own tooling, noting that the record preview in their own DMARC management interface was not even showing the discrepancy.

How to Catch This Before It Reaches Your Users

There are two parts to catching this. The first is monitoring your DMARC reports. The second is proactive checks when you add any new sending subdomain.

For ongoing monitoring, DMARC aggregate reports are the only reliable source. They show you every sending source that is touching your domain, what IP it is sending from, what SPF and DKIM results it is getting, and what the end disposition was. If a new return-path shows up and starts generating failures, you want an alert, not a user complaint.

For ongoing monitoring, DMARCFlow is designed specifically for this. It aggregates your DMARC reports across all subdomains, flags new sending sources as they appear, and surfaces authentication failures before they become user-facing mail problems. A forgotten SPF record on a new subdomain is exactly the kind of signal DMARCFlow catches: new return-path detected, SPF fail, DKIM alignment fail, disposition reject. Alert while the mail is still being rejected, not after the user complaint comes in.

For new subdomains, the rule should be: no sending subdomain gets added to any production flow without first verifying that its SPF record exists and that its DKIM aligns with the From domain. Test with a DMARC check tool before the first real message goes out.

The Complete Subdomain Email Authentication Checklist

If a subdomain sends mail, it needs all three:

SPF record published on the subdomain itself. The root domain SPF does not cover it. Example: subdomain.example.com must have its own v=spf1 record listing the IPs or include mechanisms that send from that subdomain.

DKIM signature aligned with the From domain. The signature must be from the subdomain or the root domain. A signature from the ESP's generic domain (like groups.office.net or sendgrid.net) fails alignment even if the signature is cryptographically valid.

DMARC record on the subdomain (optional but recommended for sending subdomains). Either inherit from root or publish a subdomain-specific record with the same or stricter policy.

If a subdomain does not send mail, it needs all three of these:

v=spf1 -all - this tells receivers the subdomain sends no mail from anywhere
p=reject - this tells receivers to reject any mail forging this domain
MX 0 . - null MX per RFC 7505, explicitly stating this domain accepts no mail

The combination of those three tells the world exactly what the domain is for and blocks every possible spoofing vector on it.

Non-Sending Subdomains: How to Lock Them Down

For subdomains that should never send mail, the minimum viable lockdown is:

SPF: v=spf1 -all
DMARC: p=reject (or p=quarantine if you are in a migration)
MX: MX 0 . (null MX, RFC 7505)

The null MX is the part most people skip. Without it, receivers may still try to deliver mail to that subdomain based on A or MX records that exist for web hosting. A null MX explicitly says "this domain does not accept mail and will not accept any delivery attempts."

For subdomains that will eventually send mail, the rule is: lock them down now with -all and p=reject, then update the records when the sending setup is ready. A subdomain that cannot receive mail is much harder to abuse than one waiting to be configured.

FAQ

Does p=reject on the root domain cover subdomains?

Yes, but only the policy. The subdomain inherits the p=reject disposition, but it still needs its own SPF record and its own aligned DKIM to actually pass DMARC. Inheritance of the policy is not the same as inheritance of the authentication mechanisms.

My subdomain has SPF. Why is my mail still failing DMARC?

SPF passing and DMARC passing are different things. SPF must pass on the subdomain itself, and the DKIM signature must be from either the subdomain or the root domain. If your DKIM is signed by your ESP's domain (like sendgrid.net or mailgun.org) and that does not match your From address, DKIM alignment fails even if the signature is cryptographically valid. Both SPF pass AND DKIM alignment are required for a subdomain to pass DMARC when the policy is reject.

How do I check if a subdomain is protected?

Use a DMARC lookup tool to check the subdomain directly. Do not assume the root domain DMARC record covers it properly. Run a test message if possible, and check the aggregate report to see what the receiving systems are actually seeing.

What should a non-sending subdomain have for DNS records?

At minimum: v=spf1 -all, p=reject, and MX 0 . (null MX). These three together block inbound spoofing, outbound spoofing, and accidental mail delivery attempts.