The DMARC Blind Spot: Why Your Monitoring Misses Mail Failures

Your DMARC aggregate reports look fine. Your sending application logs say the mail left. And then you find out that Outlook has been silently rejecting your legitimate subdomain mail for the past three weeks.

That is not a hypothetical. It happened to someone who writes DMARC documentation for a living. Their own monitoring caught it: a new return-path had appeared, SPF was missing on the subdomain, and every message was failing DMARC with a reject disposition. The application logs said sent. The inbox said nothing.

This is the DMARC blind spot. And the uncomfortable truth is that your own DMARC monitoring might be part of it - not because the data is wrong, but because aggregate reports do not alert you to new sending sources unless you are actively looking. A DMARC monitoring tool that flags new return-paths and authentication spikes is what caught this case. Without that alerting layer, the rejections would have continued until someone noticed delivery rates dropping.

What the blind spot looks like in practice

The failure plays out like this. Your organisation domain has p=reject. A subdomain starts sending mail through Microsoft 365 or another platform. Nobody publishes an SPF record for that subdomain. The DKIM signature comes from the ESP domain (groups.office.net or similar), not from your own domain, so it does not align. DMARC checks out: SPF fail, DKIM alignment fail, reject.

At the receiver, the message disappears. Not spam-foldered. Rejected. Your application logs show nothing wrong. Your DMARC aggregate report shows the reject, but only if something flags the anomaly. Most aggregate reports sit in a dashboard nobody checks daily. By the time the problem surfaces, you have weeks of silent failures behind you.

One DMARC expert described it plainly: "A subdomain inherits the org domain's DMARC policy, but it does not inherit SPF or DKIM." Your p=reject protects you from spoofers. It also silently blocks your own forgotten subdomains.

Why your aggregate report might be showing an incomplete picture

DMARC aggregate reports tell you what receivers saw. They do not always tell you what to look for.

DKIM passing is not the same as DKIM aligning. A valid cryptographic signature from your ESP's domain will pass DKIM checks at the receiver. If the signing domain (d=) does not match your From domain, DMARC alignment still fails. Most aggregate reports show DKIM pass as a green result without flagging the alignment mismatch.

SPF has the same trap. A passing SPF check on your org domain does not mean every subdomain has coverage. If a new ESP starts sending from a subdomain and that subdomain's SPF record is missing, SPF fails for that return-path only. Your org-level SPF record still passes. Your aggregate report may show both pass and fail results in the same file, buried in the XML.

The result is a false sense of security. You see authentication passing. You do not see that the alignment is wrong for a specific sending subdomain until a receiver rejects the mail.

The forwarding problem that makes it worse

External forwarding adds another layer of uncertainty. When a recipient server forwards your message to another mailbox, the SPF check runs against the forwarder's IP, not yours. Forwarded mail breaks SPF by design. The forwarder's DMARC policy then applies to your mail, and if their domain has a strict policy, your message fails.

You cannot control how every receiver in the forwarding chain handles your mail. Your aggregate reports show forwarded mail failures that you cannot fix without changing how recipients forward, which is not possible. What you can do is ensure your own sending infrastructure is airtight so that forwarded mail has the best chance of passing at the final destination.

How to find your subdomain mail gaps before they cause outages

Run this audit for every subdomain that might send mail, including apps, marketing tools, internal platforms, and ESP integrations.

Step 1: List every sending subdomain. Include anything that sends from an address at your domain. That includes no-reply@, support@, app-generated mail, and anything your ESP controls.

Step 2: Check SPF for each subdomain. Does v=spf1 include the sending IP or include mechanism for the ESP? If the subdomain has no SPF record and inherits p=reject from the org domain, it will fail DMARC as soon as it sends mail.

Step 3: Check DKIM alignment. The DKIM signature must use a selector where the domain (d= value) matches your From domain exactly. A signature from the ESP's domain will pass DKIM but fail alignment.

Step 4: Check DMARC record existence. Does the subdomain have its own DMARC record, or is it relying on inheritance from the org domain? Inheritance is valid if intentional. It is a gap if forgotten.

Step 5: Lock down non-sending subdomains. For any subdomain that should never send mail, publish these three records:

v=spf1 -all - tells receivers nothing authorised to send from this domain
p=reject - tells receivers to reject mail that fails DMARC
MX 0 . (null MX, RFC 7505) - tells receivers this domain accepts no mail at all

These three records together are the cheapest anti-spoofing you can add to a non-sending subdomain. They cost nothing and they stop your domain being used to impersonate you.

Step 6: Set up active alerting, not just dashboards. The case described at the start of this article was caught by a DMARC monitoring tool that alerted on a new return-path appearing on the domain. Aggregate report dashboards show you what happened. Alerting tells you when it is happening. DMARCFlow monitors your reports continuously and sends alerts when a new sending source appears, when authentication failure rates spike, or when a subdomain that has never sent mail suddenly generates DMARC failures. Without this layer, you are reviewing what already went wrong.

FAQ

Can a subdomain inherit my SPF record?

No. SPF records are not inherited. Each domain and subdomain must have its own SPF record. If a subdomain sends mail without an SPF record, SPF fails for that subdomain at every receiver that checks it.

Does DKIM work across subdomains?

DKIM signatures are tied to the selector domain (d=). If your ESP signs with their domain, that signature will not align with your From domain and will fail DMARC alignment. You need DKIM selectors that sign from your own domain.

What does p=reject actually do?

It tells receivers to reject messages that fail DMARC. Reject means the message is refused at the SMTP level, not delivered to spam. It is the strongest DMARC policy and requires correct SPF and DKIM alignment for every sending subdomain.

How do I stop subdomains from being used to spoof my domain?

For subdomains that send mail: publish correct SPF and aligned DKIM. For subdomains that do not send mail: publish v=spf1 -all, p=reject, and null MX. This combination prevents both accidental and deliberate impersonation from those subdomains.

Why did my mail start failing when nothing changed?

Likely causes: a new ESP or sending platform was added to a subdomain without updating DNS, an existing sending platform changed its sending IP or DKIM selector, or a receiving domain strengthened their DMARC enforcement. Check your DMARC reports for new failure patterns and compare against recent DNS or sending platform changes.