Why Email Gateways Still Miss BEC Attacks and What DMARC Can Do About It

The BEC Attack That Got Past Two Gateways

An organization recently posted to a Microsoft Exchange forum describing something that sounds paradoxical: they ran two email security gateways in sequence in front of Exchange Online, and a Business Email Compromise (BEC) attack still got through both of them.

Two SEG products. Both missed the same email. The attacker impersonated a vendor, sent a convincing payment request, and the money moved before anyone caught it.

This is not a configuration failure. The gateways were doing exactly what they were designed to do. The attack simply did not trigger any of their detection logic.

That is the BEC problem in a nutshell.

Why SEG Products Cannot Catch Sender Impersonation

Email security gateways are built around a specific threat model: email that carries something dangerous - a malicious attachment, a phishing URL, a known malware signature. SEG products have become sophisticated at inspecting those elements. They sandbox attachments, rewrite URLs, check against threat intelligence feeds, and apply machine learning to spot payloads that look wrong.

None of that helps when the email contains no payload at all.

A BEC attack often starts with display name spoofing - the attacker sets their free email account display name to match a trusted sender, like "John Smith" or "Accounts Payable." The From: header shows that name, but the actual email address behind it is something like attacker123@gmail.com. The SEG sees an email from a legitimate-looking sender, with clean text, no suspicious links, no attachments. It passes through.

Alternatively, the attacker uses a lookalike domain - @amaz0n-support.com instead of @amazon.com, or @micros0ft.com instead of @microsoft.com. To a busy accounts payable clerk, the display name looks right. The SEG has no reason to flag it.

The common thread: BEC attacks exploit the gap between what SEG tools inspect and what humans actually see. SEG products evaluate the machine-readable parts of an email - the headers, attachments, URLs. They do not evaluate the social engineering that makes the message compelling to a human recipient.

The FBI's Internet Crime Complaint Center reported over $2.7 billion in BEC losses in 2023. Those numbers reflect only reported cases. The real figure is higher because organizations often do not disclose successful attacks, especially wire transfer fraud.

How DMARC Closes the Gap

DMARC - Domain-based Message Authentication, Reporting, and Conformance - addresses the exact gap that SEG products cannot cover. Where SEG products inspect email content, DMARC verifies that the sending server is actually authorized to send email on behalf of the claimed domain.

DMARC works by checking two underlying authentication mechanisms:

SPF (Sender Policy Framework) verifies that the sending mail server's IP address is authorized for the domain in the envelope-from address.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to email headers that proves the email was authorized by the domain's mail servers and was not modified in transit.

Neither SPF nor DKIM alone stops BEC. An attacker can send email through a legitimate third-party mailer that has its own valid SPF and DKIM setup. The email passes authentication for the third-party domain, not for the impersonated domain.

This is where DMARC's alignment check matters. DMARC requires that the domain in the From: header matches the domain that was authenticated. If the From: header says @acme.com but the email was authenticated via a third-party sender's domain, DMARC alignment fails - regardless of whether SPF or DKIM individually passed.

A attacker running a BEC campaign from attacker123@gmail.com cannot produce a valid DMARC result for @acme.com because they cannot authenticate from @acme.com infrastructure. The email fails DMARC alignment and gets rejected or quarantined before it reaches the inbox.

This is why DMARC with a p=reject policy is the strongest defense against BEC impersonation. The attack never reaches the inbox, so there is no opportunity for a recipient to act on a fraudulent request.

Moving to p=reject Without Breaking Legitimate Mail

Many organizations run p=none (monitoring only) for months or years because they fear breaking legitimate email if they switch to p=reject too quickly. That fear is understandable, but it is solvable.

The right migration path:

Deploy SPF and DKIM correctly for all legitimate mail sources. Every service that sends email on your behalf - your mail server, your SaaS tools, your marketing platforms - needs valid SPF and DKIM before you can safely enforce DMARC.

Run p=none and read your aggregate DMARC reports. These reports tell you which IPs and domains are sending email for your domain and whether they are passing authentication. Look for sources that are failing - those are either attackers or misconfigured legitimate services.

Move to p=quarantine for a test period. Emails that fail DMARC go to spam instead of being rejected. This lets you catch any legitimate sources you missed before they cause real damage.

Switch to p=reject once your aggregate reports show zero legitimate failures for a consecutive period (typically 30 days or more).

Never rush the p=none to p=reject transition. The aggregate reports exist specifically so you can make that switch with confidence rather than hope.

What DMARC Monitoring Tells You About Impersonation Attempts

Aggregate DMARC reports are the operational output that makes DMARC actionable. They arrive daily from participating mail receivers and contain counts of every email sent using your domain - both passing and failing.

What to look for in your reports:

High-volume failures from unknown IPs - this often means someone is running a mass email campaign spoofing your domain. If you are not running any large email marketing campaigns, high failure counts are a signal worth investigating immediately.

Alignment failures - these are emails that passed authentication but failed the alignment check. In a properly configured domain with good sending hygiene, alignment failures are strong indicators of spoofing attempts. They represent emails that appeared to come from your domain but were actually sent from unauthorized infrastructure.

Failures that spike suddenly - a new wave of impersonation attempts often shows up as a sudden increase in DMARC failures before you hear about it from users or IT. DMARC reports can give you hours or days of early warning.

For organizations running Exchange Online, DMARC reports provide visibility into the entire inbound email environment - not just the small fraction that your users report as suspicious. Most impersonation attempts are never reported by users because they look legitimate to the recipient. DMARC aggregate reports surface them automatically.

This is the operational value that makes DMARC monitoring different from SEG-based detection. SEG products catch what they can analyze. DMARC reports show you everything that tried to use your domain - including the attacks your SEG missed.

SEG Products and DMARC Are Complementary Controls

The organizations with the strongest email security posture do not treat SEG products and DMARC as competing investments. They use SEG products to scan email content - attachments, URLs, malicious payloads - and they use DMARC to verify that the sender is actually who they claim to be.

SEG products catch the attacks that have payloads. DMARC catches the attacks that do not.

This layered approach matters because the threat environment is not homogeneous. A single category of email security tool will always have gaps. The question is whether those gaps are filled by complementary controls.

For organizations that have invested in SEG products and still experienced BEC incidents, the missing layer is almost always sender authentication. DMARC authentication is the direct solution - it verifies sender identity at the domain level, before the email reaches a human who might act on a fraudulent request.

If you have experienced a BEC incident through your gateway, the limitation is not your gateway vendor's fault. SEG products were built to catch a different class of attacks. DMARC fills the gap they cannot cover.