What Happens When a Subdomain Has DMARC p=reject But No SPF Record

When a subdomain inherits p=reject from your org domain but has no SPF record, legitimate mail fails silently. And p=reject cannot tell the difference between a spoofer and a forgotten SPF record.

The failure does not look like an error. It looks like success. The sending application reports that the message was delivered. SMTP logs show a clean handoff. Only the DMARC aggregate report reveals what actually happened: every single message was rejected.

This is not a hypothetical problem. It happens to people who should know better.

The Trap: Your Subdomain Inherits the Policy, Not the Setup

DMARC has two inheritance rules that do not work the way most people expect.

First: when you set p=reject at the org domain level, that policy applies to every subdomain that does not have its own explicit DMARC record. The subdomain inherits the policy automatically. There is no action required on your part.

Second: SPF and DKIM do not work the same way. SPF is not inherited. If your org domain has a valid SPF record and a subdomain does not, the subdomain has no SPF record at all. The same is true for DKIM selectors - they must be explicitly configured for each sending subdomain.

This means a subdomain can have a strict DMARC policy while simultaneously having no SPF record and no aligned DKIM selector. The policy fires. The mail fails. Nothing logs an error at the sending end.

What the Receiver Sees When SPF Is Missing

Here is the authentication sequence when a subdomain sends mail with no SPF record:

The sending MTA connects and delivers the message. The receiving MTA looks up the SPF record for the subdomain. There is no SPF record, so the check returns none. The DMARC alignment check then evaluates DKIM. If the subdomain has no DKIM selector, there is no DKIM signature to verify. If it has a DKIM selector but it is not aligned with the From domain, DKIM alignment fails.

With both SPF and DKIM failing alignment, the DMARC check fails. The receiving server applies the inherited p=reject policy and rejects the message.

The receiver cannot tell the difference between a spoofer forging your subdomain and a legitimate sending system that was configured without SPF. The authentication result is identical.

A Real-World Failure: Microsoft 365 Mail Silently Rejected

A domain operator with two decades of email security experience set p=reject on their org domain. They had SPF and DKIM configured for the root domain. They onboarded a new sending subdomain for Microsoft 365 delivery.

The From address used the subdomain. Microsoft 365 authenticated correctly with its own SPF and DKIM at the Microsoft infrastructure level. But the subdomain had no SPF record published in DNS.

Every message was rejected. The Microsoft 365 admin portal reported successful delivery. The SMTP logs showed no errors. The mail appeared to arrive at the destination. The DMARC aggregate report, which they happened to be monitoring, told a completely different story: 100% rejection rate, zero messages authenticated.

The gap was only caught because they were watching the reports. Without that monitoring, the rejection would have continued indefinitely. The domain operator later described it as the most embarrassing email failure they had experienced in twenty years.

The Detection Problem: Mail Appears to Send

This failure mode is particularly dangerous because it does not behave like an outage. An SPF hard fail produces a bounce message that the sending server logs and flags. A DMARC p=reject rejection produces nothing visible at the sending end.

The sending application reports the message was handed to the MTA successfully. The MTA logs show a 250 OK response from the receiving server. The message was delivered to the destination server and silently discarded before reaching the recipient's inbox.

Only the DMARC aggregate report, sent daily by RFC 7489, reveals the rejection. If nobody is reading those reports, this can go on for weeks. The first sign of the problem is a user complaint: "I sent that invoice yesterday, they never got it."

The root cause of the Microsoft 365 failure above was caught by a DMARC monitoring alert - not by any user report.

How to Find All Your Sending Subdomains Before They Fail

Before moving to p=reject, audit every subdomain that might send mail:

• Pull your DMARC aggregate reports for the org domain and list every subdomain that appears as a From address. Any subdomain in a DMARC report is sending mail or is being spoofed - either way, you need to know.
• Check your DNS for any subdomain with an MX record pointing to an external mail service. MX records mean the subdomain receives mail, but they do not mean it sends mail - some configurations use MX for inbound-only routing.
• Query your DNS for subdomains with SPF records. Any subdomain sending mail through a third-party service needs its own v=spf1 include mechanism.
• Review your email sending infrastructure: marketing automation platforms, SaaS tools with their own sending domains, internal relay servers, and any application that sends transactional email.
• Check your DKIM selectors. If you use a third-party sender, they should provide a DKIM selector to publish in your DNS under their sending subdomain.

Every Subdomain Needs One of Three Things

For each subdomain you find, the correct action is one of three:

The subdomain sends mail. Publish an explicit DMARC record with a policy appropriate to your authentication coverage (p=quarantine until you are confident, then p=reject). Publish an SPF record that includes only the senders that actually use this subdomain. Set up DKIM signing through your email infrastructure and publish the selector in DNS.

The subdomain never sends mail. Publish v=spf1 -all to explicitly state that no mail comes from this subdomain. Publish a DMARC record with p=reject. This stops spoofing attempts cold and generates actionable DMARC reports showing who tried.

The subdomain does not exist in DNS yet but might be claimed later. Publish a null MX record (RFC 7505) with priority 0 to explicitly mark it as non-receiving. Publish v=spf1 -all. This prevents the subdomain from ever being claimed by an external party without your knowledge.

The Monitoring Requirement: You Cannot Catch What You Do Not See

The Microsoft 365 case above was caught only because the domain operator was reading their DMARC aggregate reports. Most organizations are not.

DMARC aggregate reports are the only reliable way to detect this failure mode before users complain. A tool that specifically monitors for new return-paths, flags subdomains appearing in From addresses without corresponding SPF coverage, and alerts on SPF alignment failures will catch this before the first user complaint arrives.

DMARCFlow was built for exactly this: it continuously monitors DMARC aggregate reports and automatically flags new sending subdomains, gaps in SPF coverage, and alignment failures - including the silent failure pattern where the sending application reports success but every message is being rejected.

The policy you publish is only as good as the monitoring you set up alongside it. Without watching the reports, you are flying blind.

FAQ

Does p=reject apply to subdomains automatically?

Yes. Any subdomain without its own explicit DMARC record inherits the policy from the org domain. This inheritance is automatic and immediate.

Can a subdomain have SPF without the root domain having SPF?

Yes. SPF records are per-domain. A subdomain can have a completely different SPF record from the root domain, or no SPF record at all, independent of what the root domain publishes.

What does "no SPF record" mean for a subdomain?

It means DNS has no TXT record at that subdomain starting with v=spf1. RFC 7208 says a none result from the SPF check means the domain makes no statement about authorized senders. Receiving servers handle this in various ways, but in a DMARC context with p=reject and no aligned DKIM, the message fails authentication.

How do I check which subdomains are sending mail without monitoring reports?

Query your DNS for MX records and SPF records across your domain namespace. Review your email infrastructure for any service that uses a custom sending domain. Any third-party sender - marketing platform, SaaS tool, internal system - should have documented its sending subdomain and SPF mechanism.

What is a null MX and when should I publish one?

A null MX (RFC 7505) is a DNS record that explicitly states a domain does not accept mail. Publish it for any subdomain that should never receive mail but could be claimed by an external party. The format is: IN MX 0 . It takes priority over A and AAAA records for mail delivery purposes.