Why Your Own Legitimate Mail Gets Rejected by Your DMARC Policy

A practitioner with 20 years in email authentication had his own subdomain mail rejected by his own p=reject policy. The application logs showed nothing. The mail server logs were clean. His DMARC monitoring caught it in under an hour.

If you manage domains with p=reject configured, this story is for you.

The incident that exposed a gap even the expert missed

The alert came through his DMARC monitoring system: a new return-path had appeared on ar.glockapps.com, and the SPF record was missing. When he pulled the aggregate data, the picture was clear:

• SPF: fail -- the subdomain had no SPF record at all
• DKIM: fail -- a valid signature existed from groups.office.net, but that domain does not align with the From domain, so DKIM alignment fails
• DMARC: fail, disposition: reject

Microsoft 365 was rejecting his own legitimate mail. Not spam-foldering it. Rejecting it.

The cause was mundane: when the subdomain was set up, the configuration work was handed off, and SPF for that subdomain was never published. No one broke anything deliberately. It fell through the gap between infrastructure setup and email team configuration.

The real rule subdomains and DMARC

Here is what trips people up:

A subdomain inherits the root domain DMARC policy, but it does not inherit SPF or DKIM.

Your root domain has p=reject. A subdomain with no record of its own inherits that reject. Good for anti-spoofing. But when that subdomain starts sending mail without its own SPF and aligned DKIM, p=reject does its job and blocks it. To the receiver, your forgotten-SPF legitimate mail and a spoofing attack look identical. That is the point of reject, and it is also how the policy can quietly block your own sending.

Related confusion: DKIM passing is not DKIM alignment. A valid signature from your ESP's domain still fails DMARC if it does not match your From domain. Cryptographically valid, semantically wrong.

For subdomains that should never send mail, publish all three:

• v=spf1 -all -- this domain sends no mail
• p=reject -- enforce DMARC reject for this subdomain
• MX 0 . (RFC 7505 null MX) -- this domain accepts no mail

Cheap, definitive, and underused.

Why your application logs are silent

The rejection does not appear in your application logs because SMTP acceptance happens before DMARC evaluation runs. The receiving server accepts the message at the transfer level, then evaluates DMARC and rejects it silently. Your sending application never gets a bounce notification.

The only timely signal is a DMARC aggregate report. A new sending source on a subdomain, an unexpected return-path, an authentication failure spike -- these all show up in the aggregate data before your users start asking why their messages were not received.

This is where aggregate report monitoring matters most: not for the daily digest, but for the anomaly alert that fires when something new and wrong appears on your domain.

How DMARCFlow catches this before your users do

DMARCFlow monitors aggregate reports across all your domains and tracks new return-paths as they appear. When a subdomain starts sending from a source you have not seen before, you get an anomaly alert immediately -- not hours later when a user reports a missing message.

The alert tells you which domain, which subdomain, and what the authentication result was. You can then investigate the sending source and either provision proper SPF/DKIM for a legitimate new sender, or shut down an unauthorized one.

Without this kind of monitoring, you find out about new sending sources the hard way: when a mailbox provider starts rejecting your mail and users start complaining.

The checklist every domain owner needs

• Every sending subdomain needs its own SPF record. The root domain policy does not provision subdomain authentication.
• Every sending subdomain needs DKIM that aligns with the From domain. The ESP's domain signing key must publish under your domain, not the ESP's.
• Every non-mail subdomain needs v=spf1 -all, p=reject, and a null MX. No exceptions.
• Check aggregate reports before, during, and after any new subdomain or sending source rollout.

FAQ

Q: Can I just use a softer policy on subdomains?

A: You can set sp=quarantine or sp=none on the root domain record to give subdomains a different policy. But this also reduces anti-spoofing protection for those subdomains. Use it only as a deliberate, time-limited migration step -- not as a substitute for provisioning proper authentication.

Q: Why did the mail server logs show no error?

A: SMTP acceptance occurs before DMARC evaluation. The receiving server accepted the message at the transfer level, then applied DMARC checks and rejected it. The bounce is invisible to your sending system because it happens at the receiver's mail transfer agent, not at submission.

Q: Does this mean p=reject is too aggressive for complex domain portfolios?

A: No. It means complex portfolios need tighter process discipline around provisioning new sending sources. The policy is correct. The gap is in the change management between infrastructure teams and email configuration teams.

Q: Are some receivers ignoring DMARC entirely?

A: Yes. Some legacy systems do not enforce DMARC at all, so failing messages may still be delivered. This creates a false sense of security. Your actual enforcement level is determined by the lowest common denominator among your receivers. Major mailbox providers enforce it; many smaller ones do not.

Q: How quickly do aggregate reports show new sending sources?

A: Most large receivers send aggregate reports daily. Some send more frequently. You will typically see a new sending source within 24 to 48 hours of it first appearing. Anomaly alerts fire as soon as a report containing the new source is processed.