DMARC p=none and BEC Bypass
Contoso has 6,000 mailboxes. Inbound mail flows through an on-premises Cisco Secure Email Gateway to Exchange Online. The domain publishes SPF with ~all, DMARC p=none, and DKIM only for a bulk marketing vendor. The ESA has an inbound sender allow list containing a partner's /16, added during a migration. Accounts payable received invoices from a lookalike domain with the CFO's display name. The messages passed SPF and DMARC because the lookalike domain publishes its own p=none policy. TLS is opportunistic. A user reported the message 26 hours after delivery; 3 payments were made. The CEO wants DMARC p=reject today and all external mail tagged.
1. Explain why the BEC messages were delivered and what evidence you would collect before changing policy.
Read the worked answer
The messages were delivered because authentication evaluated the lookalike domain, not Contoso:
- SPF passed because the sending IP was authorized by the lookalike domain's SPF record. SPF authenticates the envelope sender domain, not the display name.
- DMARC passed because the lookalike domain publishes p=none and the message aligned with that domain. Contoso's p=none did not apply to mail claiming to be from a lookalike.
- DKIM was irrelevant for the lookalike unless Contoso's domain was signed. The marketing vendor's DKIM key does not protect Contoso's executive display names.
- The ESA allow list may have bypassed content filters if the partner's /16 was the source or relay. A broad allow list is a common BEC bypass.
- No impersonation or display-name control flagged the mismatch between the CFO display name and the external From domain.
Collect the full headers, ESA message tracking, the allow-list entry history, recipient rules, and the lookalike domain's SPF/DMARC records. Determine whether the 3 payments were initiated from a replied-to thread. Preserve mailbox audit logs and the message trace before remediation deletes evidence.
2. Sequence the path to DMARC enforcement and the ESA controls you would add. Why is p=reject today unsafe?
Read the worked answer
Going to p=reject immediately can reject legitimate mail from unauthenticated but valid senders, including the marketing vendor, payroll, and any application that sends as Contoso. Sequence it:
- Inventory all senders using DMARC aggregate reports, ESA logs, and Exchange Online message traces. Identify third parties sending as or on behalf of Contoso.
- Fix authentication at the source. Publish DKIM for every legitimate sender and tighten SPF to
-allonly after the inventory is complete. Confirm alignment, not just pass. - Move DMARC to quarantine with a small percentage, monitor aggregate and forensic reports, and fix failures before increasing.
- Move to p=reject for the organizational domain, then add subdomain policy and strict alignment where feasible.
At the ESA, add external-sender tagging, display-name and lookalike-domain detection, DMARC verification, and a review of the partner /16 allow list. Require TLS for known partners where supported. Test against a sample set of legitimate vendor mail and BEC messages. Do not promise that p=reject stops lookalike domains; it protects Contoso's domain, while impersonation controls and user reporting address the lookalike case.