Blog · Email security
Why Phishing Bypasses DMARC in Exchange Online
Your CEO's address is being impersonated in phishing campaigns. Your DMARC record says p=reject. SPF passes. DKIM passes. And the impersonation emails are still getting through.
The DNS is correct. Your Exchange Online configuration isn't enforcing it.
This is not a hypothetical problem. Sysadmins across recent r/sysadmin threads reported exactly this: DMARC passing at the DNS level, attacker mail delivered anyway, mail trace showing SPF and DKIM failures -- yet messages landed in inboxes.
The gap is in Microsoft 365, not in your DNS records.
The gap between DNS and enforcement
When you publish a DMARC record at the DNS level, you're telling receiving mail servers worldwide what to do with mail that fails authentication. A p=reject record means: reject anything that doesn't pass SPF or DKIM alignment.
But Exchange Online doesn't automatically enforce the DMARC policy from your DNS for all inbound mail. It has its own setting -- whether to "honor" the DMARC policy -- and this is not enabled by default in all scenarios, particularly when mail routes through third-party gateways.
Your DNS is correct. EXO is not enforcing it.
How third-party gateways break DMARC enforcement
If you route mail through a third-party email security gateway -- Barracuda, Cisco, Proofpoint, or similar -- and that gateway does not have enhanced filtering for connectors enabled in Exchange Online, DMARC enforcement is bypassed.
What happens:
- Attacker sends mail that passes through your gateway
- The gateway forwards to EXO as a new message, stripped of the original DMARC context
- EXO evaluates SPF and DKIM against the gateway's IP, not the attacker's
- Authentication passes because the gateway is authorized
- The impersonation email lands in the inbox -- your DNS DMARC was never evaluated
The Direct Send exploit path
Even without a gateway, Exchange Online has an exposed entry point that attackers actively exploit: Direct Send.
Your MX record points to .mail.protection.outlook.com -- publicly lookable. An attacker can send directly to that endpoint, claiming to be from your domain. Unless you've explicitly locked down Direct Send, EXO will accept it.
The mail trace will show SPF and DKIM as failed. The message will still be delivered.
One sysadmin described finding attacker mail that never touched their gateway -- it went straight to EXO, failed authentication on the trace, and was delivered anyway. The transport rule was the only thing that stopped it.
The transport rule fix
A transport rule in Exchange Online closes this:
IF inbound mail comes from outside the organization AND the From header matches your domain AND the source IP is not your approved gateway or on-premises IP THEN quarantine or reject
You need to enumerate your approved IPs: your gateway vendor's egress IPs, your on-premises mail server IPs, and any legitimate direct-send systems.
Microsoft's Change Optics Report (public preview as of late 2024) helps identify Direct Send traffic hitting your tenant -- so you can see how much exposed mail you have before locking it down.
Quick checklist
- Check whether enhanced filtering for connectors is enabled for your third-party gateway in EXO
- Audit whether Direct Send is open and whether you actually need it
- Create a transport rule blocking external mail claiming to be from your domain
- Run the Change Optics Report to quantify Direct Send volume
- Disable Direct Send if no internal systems depend on it
Your DMARC is working -- your visibility isn't
The DNS side of DMARC is doing its job. The gap is in your Exchange Online configuration. Close that gap and your p=reject policy actually does what you intended.
To catch bypass attempts before they become incidents, watch your DMARC aggregate reports. A monitoring tool that flags sudden changes in pass/fail ratios -- or new sources sending as your domain -- surfaces a misconfiguration or active attack while there's still time to respond.