Catch Your Own DMARC Mistakes Before Attackers Do

The Trap: p=reject Covers Your Subdomains But SPF and DKIM Do Not Follow

Here is the DMARC gap that catches experienced operators off guard: your root domain has p=reject, and that policy silently applies to every subdomain. SPF and DKIM do not follow. If a subdomain starts sending mail without its own SPF record and aligned DKIM signature, p=reject blocks it. To a mailbox provider, a forgotten-SPF subdomain and an actual spoofing attempt look identical. That is the point of reject, and it is also how you can silently shoot your own foot.

The trap is structural. When someone sets up a new sending subdomain, the domain gets handed off between teams. Devops creates the DNS entry. The email team configures the sending service. Nobody publishes SPF because the handover assumed it was already done. The record is missing, but nobody finds out until a mailbox provider starts rejecting mail. Or until a DMARC report surfaces the failure.

Real Case Study: How Legitimate Mail Got Rejected Silently

Here is what this looks like in practice. One morning, a DMARC monitoring tool flagged a new return-path on a subdomain that had not been seen sending mail before. The alert said: new return-path detected on ar.glockapps.com, and the SPF record is missing. Critical.

The operator pulled the aggregate data. Microsoft 365 was sending from that subdomain. The From address was correct. But the DMARC report showed this:

SPF: fail. The subdomain had no SPF record at all.
DKIM: signature from groups.office.net validated cryptographically, but the signing domain did not align with the From domain. Alignment fail.
DMARC: fail. Disposition: reject.

Every single message from that subdomain was landing in the recipient's spam folder or being rejected outright. Not flagged. Not quarantined. Rejected. The mail was dead at the receiver before it ever reached a inbox.

The root cause was ordinary: devops spun up the subdomain, handed it to the team to configure, and the team never published the SPF record. Nobody did anything wrong on purpose. It fell through the gap between infrastructure setup and the sending configuration. Twenty years of email authentication experience did not prevent it. The tooling caught it. The process did not.

Why Application Logs Will Not Tell You This

This is the part that makes these failures so insidious. Your application logs say the mail was sent successfully. Your sending service logs are clean. There is no bounce, no error response, no indication at your end that anything went wrong. The rejection happens at the receiver, outside your infrastructure, invisible to your logs.

The only evidence is in your DMARC aggregate reports. And if nobody is actively reading those reports, or if the monitoring does not flag the specific signals that indicate your own infrastructure is failing, you will not find out until a user reports that their password-reset emails are not arriving, or until a business-critical message gets silently blocked.

This is not a theoretical risk. A new return-path appearing on a subdomain that is not in your sending inventory is a documented signal for exactly this kind of configuration error. It is also one of the signals attackers look for when probing your domain. Both cases require the same response: you need to see it before someone else does.

The Specific DMARC Report Signals to Watch

Your DMARC aggregate reports contain the signals that reveal your own configuration gaps. The specific indicators worth alerting on:

New return-path on a subdomain you do not recognize. A return-path (also called the envelope-from or bounce address) that you did not authorize appearing on your domain is the earliest warning that something is sending from your infrastructure without proper authentication. This is what caught the ar.glockapps.com case within hours of the first send.

SPF failures on domains you control. If your own sending IPs are producing SPF failures on your own domains, something is misconfigured. Either the SPF record is missing, the record has the wrong include, or the sending IP is not in the record.

DKIM alignment failures on sending subdomains. A valid DKIM signature from your ESP's domain is cryptographically correct but DMARC-irrelevant if it does not align with your From domain. If you see DKIM pass in the DKIM result but DKIM alignment fail in your DMARC report, the signing domain is wrong for your From address.

Unexpected sending volume on a subdomain with p=none or sp=none. Subdomains that should not be sending bulk mail but suddenly show high message counts are worth investigating regardless of authentication result.

None of these signals are visible without DMARC report ingestion and active monitoring. Reading reports manually once a month is not sufficient. These failures are silent between the time they start and the time you catch them.

How to Lock Down Non-Sending Subdomains

Every subdomain on your domain is either a real sender or a liability. The fix for subdomains that should never send mail is comprehensive lockdown. For any subdomain that should not send or receive mail:

Publish `v=spf1 -all` to tell receivers this domain has no authorized senders.
Set DMARC to `p=reject` so any attempt to send from this subdomain without aligned authentication is rejected.
Add a null MX record (`MX 0 .` per RFC 7505) to explicitly state this domain accepts no mail.

This combination makes the subdomain useless for both spoofing and accidental misconfiguration. It is the cheapest anti-spoofing you can buy, and it eliminates the silent failure mode entirely for domains that are not supposed to send.

For subdomains that do send mail, every one needs its own SPF record that includes all authorized sending sources, and its own DKIM key pair where the selector domain aligns with the From domain. Inheriting the root domain's p=reject policy is good. Inheriting the SPF and DKIM setup is not.

How Automated Monitoring Catches What Manual Review Misses

The ar.glockapps.com case was caught because the monitoring system sent an anomaly alert within hours of the first unauthorized return-path appearing. The operator did not need to manually check reports. The tooling surfaced the signal. Without it, the failure would have been silent until a user complained.

That is the practical value of automated DMARC monitoring. The signals that matter are specific: new return-paths on your domain, alignment failures on sending subdomains, and authentication results that do not match what you expect from your sending inventory. These signals separate active monitoring from passive report collection. Without automated alerting on these conditions, you are relying on users to report the problem after it has already affected delivery.

This is exactly what DMARCFlow does. It continuously monitors your DMARC reports for these conditions and sends anomaly alerts when new return-paths appear, when alignment failures spike on subdomains you control, or when sending patterns deviate from your established baseline. The alerts include the specific cause of the failure so you are not guessing what went wrong when you read the report. For the ar.glockapps.com case, the alert would have been: new return-path on ar.glockapps.com, SPF record missing. Immediate action, no manual report archaeology required.

If you are not actively monitoring your DMARC reports, you are flying blind on the authentication health of your domain. Your application logs will not show you this. Your users will not tell you until the problem is large enough to generate complaints. Only your DMARC reports, and the monitoring that makes them actionable, will show you.

FAQ

Does p=reject protect subdomains automatically?

Yes, but not the way most people assume. The p=reject policy at your root domain applies to all subdomains by default. Any subdomain without its own SPF and aligned DKIM will fail DMARC when the root policy is reject. That protection is real. But it also means a subdomain that starts sending without proper authentication will be silently rejected, just like an external spoofing attempt. The policy protects against attackers. It also blocks your own misconfigured sends. You need monitoring to know which case you are looking at.

Why does DKIM passing not mean DKIM aligned?

DKIM passing means the cryptographic signature is valid. DKIM aligned means the signing domain matches your From domain. A valid signature from your ESP's domain (such as groups.office.net or us1._domainkey.example.com) will pass DKIM checking at the receiver. But DMARC requires the signing domain to align with the From domain in the message header. If the ESP signs with their own domain and you have not set up DKIM on your own domain, DKIM will pass and alignment will fail. Your DMARC report will show DKIM pass and DKIM alignment fail simultaneously. This is a common misconfiguration with subdomains using third-party sending services.

What is a new return-path alert and why does it matter?

The return-path (also called the envelope-from or bounce address) is the domain that receives delivery status notifications and bounce messages. It is also a reliable signal of what infrastructure is sending mail on behalf of your domain. When a new return-path appears on your domain that you did not authorize, it means something is sending mail using your domain in the envelope without your knowledge or with a configuration you have not accounted for. This is often a misconfigured subdomain. Sometimes it is an attacker testing your domain. Either way, you need to know about it immediately.

How do I lock down a subdomain that should never send mail?

Set three DNS records. First, v=spf1 -all as the SPF record. This tells every receiver that no IP address is authorized to send mail from this subdomain. Second, a DMARC record with p=reject to enforce strict authentication. Third, a null MX record: MX 0 . (per RFC 7505). This explicitly tells receivers the domain accepts no mail at all. Together these records make the subdomain useless for spoofing and prevent accidental mail leakage from misconfigured internal tools.