Why p=reject Silently Breaks Subdomain Mail: Fix It

The morning a DMARC expert's own monitoring caught them with their pants down

Someone who has worked in email authentication for 20 years, co-builds DMARC tooling, and writes subdomain guides woke up one morning to find their own DMARC aggregate monitoring had flagged a new return-path on a subdomain they did not know was sending mail. Every legitimate message from that subdomain was being rejected. The monitoring worked exactly as intended. The gap was real.

The subdomain was ar.glockapps.com. Microsoft 365 was sending mail from it. The SPF record for that subdomain did not exist. The DKIM signature was present and cryptographically valid but came from groups.office.net, which does not align with ar.glockapps.com. DMARC checked the subdomain against the root domain's p=reject policy. The mail was rejected. Not spam-filtered. Rejected outright.

The post-mortem was simple: devops had spun up the subdomain and handed the config to the team to wire into the sending setup. SPF for that subdomain was never published. Nobody did anything wrong on purpose. It fell through the cracks. The application said the mail was sent. The logs looked clean. The only signal was the DMARC aggregate report.

This is the subdomain DMARC trap, and it is more common than the number of "I got caught by my own monitoring" confessions in r/DMARC suggests. The expert had DMARCFlow (or equivalent aggregate monitoring) running. It caught the problem. The question for every other domain owner is whether their monitoring would have caught it before a business user reported a mail outage.

Why this happens: DMARC inheritance is one-way

The confusion starts with a reasonable assumption: if your root domain has p=reject, your subdomains are protected from spoofing. That part is true. But protection from spoofing and permission to send mail are two different things.

A subdomain inherits the root domain DMARC policy. It does not inherit SPF. It does not inherit DKIM.

Here is what actually happens when Microsoft 365 sends from ar.glockapps.com:

1. SPF check: looks for an SPF record on ar.glockapps.com. There is none. Result: fail.
2. DKIM check: finds a valid signature from groups.office.net. But groups.office.net is not ar.glockapps.com and is not a subdomain of ar.glockapps.com. Result: DKIM alignment fails.
3. DMARC check: SPF fail + DKIM alignment fail + root domain p=reject. Result: disposition reject.

This is the critical distinction that trips people up. DKIM can pass at the cryptographic level and still fail DMARC because of alignment. A valid signature from the wrong domain is not good enough. DMARC requires either relaxed alignment (signing domain is a subdomain of the From domain) or strict alignment (signing domain exactly matches the From domain). Microsoft 365 signing with groups.office.net is neither.

The fix in this specific case was to add an SPF record to ar.glockapps.com and configure Microsoft 365 to sign with a selector that aligns with the From domain. Once that was done, the subdomain passed DMARC and mail flowed normally.

The rule for every subdomain you manage

Every subdomain you control falls into one of two and only two states.

State 1: Active mail sender. If a subdomain sends mail, it needs its own SPF record and DKIM that aligns with the From domain. Optionally, it can have its own subdomain-level DMARC policy with sp=reject, but the SPF and aligned DKIM are non-negotiable.

State 2: Does not send mail. If a subdomain should never send mail, the correct DNS configuration is:

SPF: v=spf1 -all (this tells receivers no server is authorized to send mail from this domain)
DMARC: p=reject (or sp=reject if your org-level policy is softer)
MX: 0 . (the null MX, RFC 7505, which explicitly states this domain accepts no mail)

The null MX is often skipped because most administrators know not to publish an MX record for non-sending domains. But it is worth being explicit. RFC 7505 exists for a reason, and a null MX communicates to every receiver exactly what you intend.

One comment in the source thread put it precisely: "Subdomains are where clean DMARC rollouts go to die." The reason is always the same: a subdomain that should not be sending mail gets a sending subdomain's DNS records, or a subdomain that starts sending mail gets neither SPF nor DKIM, and p=reject does exactly what it was configured to do.

How to catch this before it breaks your mail

The silent part of this failure is what makes it dangerous. The application says the mail was sent. The logs say the mail was delivered to the mail transfer agent. The only place the failure shows up is in your DMARC aggregate reports.

What you are looking for in those reports:

New return-paths appearing on subdomains you did not expect to send mail
Failures on subdomains that should be inactive
DKIM signatures from domains that do not align with your From domain

The expert had aggregate monitoring running and it caught the failure. The gap had existed for months before the subdomain was activated. What DMARCFlow provides that general logging does not is anomaly alerting on new sending sources: a new return-path appearing on any of your domains triggers a critical alert before it becomes a mail rejection incident reported by a business user. The expert's own monitoring worked exactly as designed. The question is whether your monitoring catches it proactively or whether you find out when someone says their mail is not getting through.

Quick subdomain audit checklist

Use this now:

List every subdomain that resolves in DNS
Identify which ones send mail today (check your DMARC reports for evidence)
For each sending subdomain: verify SPF is published and DKIM aligns with the From domain
For each non-sending subdomain: verify v=spf1 -all and null MX (0 .) are published
Pull your DMARC aggregate reports and search for any subdomain failures you did not expect
Set up alerting for new return-paths on your domains before you have a problem to look for

DMARCFlow automates the last step. Daily aggregate report analysis with new-return-path alerting means you find out about a forgotten subdomain the moment it starts sending, not weeks later when someone files a support ticket.

Related failure modes

This is not a one-time configuration problem. Subdomain SPF gaps recur in predictable situations:

Third-party vendors starting to send as your subdomain without telling you
ESP changing DKIM signing domains without updating your DNS alignment
Acquired company subdomains brought under your DMARC policy after a merger
Forgotten dev or staging subdomains that get repurposed for production mail without DNS records being updated

Every one of these is a DMARC aggregate report problem before it becomes a mail rejection problem. Monitor your reports. Set up the alerts.

FAQ

Q: Does p=reject on my root domain protect my subdomains from being spoofed?
Yes. If a subdomain has no SPF and no aligned DKIM, outside parties cannot spoof that subdomain because receivers will apply the inherited p=reject. That is the good side of inheritance.

Q: Does p=reject on my root domain mean my subdomains can send mail without SPF?
No. The subdomain inherits the policy but must have its own SPF and aligned DKIM to send mail legitimately. Without those, p=reject blocks the subdomain's own legitimate mail, not just spoofed mail.

Q: My subdomain SPF is a subset of my root domain SPF. Do I still need to publish it?
Yes. Subdomains do not inherit SPF records. You must publish SPF for each subdomain that sends mail, even if it uses the same sending infrastructure as your root domain.

Q: What is a null MX and why does it matter?
Null MX (RFC 7505) is a DNS record that explicitly states a domain accepts no mail. Publishing MX 0 . for non-sending domains tells receivers unambiguously that the domain is notmail-enabled, which reduces bounce-back abuse and clarifies your intent.

Q: Can DKIM pass but DMARC still fail?
Yes. DKIM can be cryptographically valid while DMARC alignment fails. A DKIM signature from microsoft.com will not align with a From header from yourdomain.com unless the signing domain is yourdomain.com or a subdomain of yourdomain.com under relaxed alignment rules. Microsoft 365 sending with groups.office.net is an example: the signature was valid, but groups.office.net is neither yourdomain.com nor a subdomain of it, so alignment failed and DMARC rejected the mail.