Why Your DMARC-Reject Domain Still Can't Stop Wire Fraud

Even companies with DMARC at p=reject get hit by wire fraud. The FBI's 2023 IC3 data puts BEC losses at over $2.9 billion annually in the US alone - and those are just the reported cases. Domain authentication passes. The money still leaves. Here's what happened, and why DMARC alone was never the right tool for this fight.

What DMARC actually protects

DMARC is a domain-level authentication protocol. It checks whether an email that claims to be from your domain was actually sent by a server your domain's SPF and DKIM records authorize. If those checks fail and your policy is reject, receivers refuse the message.

That covers external spoofing. Someone outside your organization trying to send mail as yourdomain.com - DMARC catches that.

Phishing from lookalike domains, impersonation attacks using similar-but-wrong addresses, and forged senders from external infrastructure - those are in DMARC's protective scope. Getting to p=reject is a real achievement worth having.

What DMARC explicitly does not protect

DMARC does not authenticate the sender account. It has no mechanism to verify that the person clicking "send" in your organization is who they say they are.

When an attacker compromises a real executive's mailbox - via credential stuffing, a targeted phishing campaign, or a third-party SaaS app with too many permissions - they send mail from your actual mail servers, with your actual SPF and DKIM passing, because they're logged in as the real user. DMARC sees a passing message. It has no signal that anything is wrong.

This is business email compromise, and it runs on legitimate infrastructure, legitimate authentication, and your own domain's reputation. The reputation you built over years of legitimate sending works in the attacker's favor - receivers see a trusted sending domain and let the message through.

The BEC attack sequence, step by step

1. Attacker gains access to an internal account - finance, C-suite, or IT admin are the most valuable targets
2. They read past emails to learn the wire transfer approval process, who signs off, what language sounds normal in internal requests
3. They draft a request that matches the normal pattern, from the normal account, via the normal mail infrastructure
4. SPF passes. DKIM passes. DMARC passes. Approval is given. Money moves.

All three authentication layers pass because the sender is exactly who they claim to be - authenticated, inside the network, authorized to send. DMARC's job is to verify the domain. It does not and cannot verify the person using the account.

Real case: In 2019, the CEO of a German packaging company lost €1.2 million in a BEC incident after the attacker, posing as a vendor, requested that all invoice payments be redirected to a new bank account. The email came from the actual CEO's Office 365 account - fully authenticated, normal behavior patterns in the tenant. No domain spoofing involved whatsoever.

Why "DMARC compliant" started meaning less than it used to

Once a domain reaches p=reject, it satisfies most security frameworks and compliance checklists. That is a real improvement. External spoofing targeting your domain gets blocked.

But that checkpoint creates a misleading mental model. "We have DMARC reject" became shorthand for "email is protected" in board presentations and security reviews. It is not. BEC operates through legitimate accounts, not through domain impersonation.

Organizations with strong DMARC posture still have the same conversation they would have had before DMARC - "please wire this to the new account" from a known email address, processed through normal approval flows, now with real financial losses attached.

DMARCFlow's aggregate reporting helps here: it surfaces unusual sending sources and subdomain patterns that often precede BEC campaigns, giving security teams signal before a fraudulent request lands.

The threat model gap

Most DMARC rollout documentation focuses on external spoofing. That is correct and important. It is not complete.

A domain at p=reject eliminates one attack vector. BEC is a different attack vector operating through different mechanisms. You need both.

Specifically:

• DMARC at reject stops external senders from forging your domain
• It does not stop a compromised internal account from requesting a wire transfer
• It does not flag unusual wire requests from legitimate addresses
• It does not detect high-value invoice patterns or new beneficiary accounts

What supplemental controls actually help

Lookalike domain monitoring: Attackers register domains that look like your company - slightly different spelling, different TLD - and use those in the "reply-to" or display name. DMARCFlow monitors for these patterns in your aggregate report data, catching the reconnaissance phase before the BEC email is sent.

Behavioral anomaly detection: Microsoft 365 and Google Workspace can flag unusual forwarding rules, anomalous sending patterns, and sign-in from unusual locations. These catch the account compromise stage before the BEC email goes out.

Process controls for high-value transfers: Wire transfer policies requiring out-of-band confirmation - a phone call to a known number, not the number in the email - are the most effective BEC control available. No email authentication protocol replaces a phone call for large transfers.

Internal senders policy: If wire requests from the CFO always come from specific source IPs and contain certain patterns, flag deviations. DMARCFlow's aggregate reporting surfaces unusual sending sources that warrant investigation.

FAQ

Does DMARC help with BEC at all?

Indirectly. DMARC at reject prevents the most common external spoofing attack. It generates aggregate data that can reveal unusual sending patterns - high volumes of failed authentication from a single source, for example. But DMARC cannot distinguish between a legitimate CFO request and a compromised CFO mailbox.

If DMARC passes, how do receivers know something is wrong?

They don't. A BEC email with valid SPF, DKIM, and DMARC alignment is indistinguishable from legitimate internal mail at the authentication layer. BEC prevention requires controls beyond domain authentication: behavioral analysis, process controls, and user education.

What tools help beyond DMARC?

Email security platforms that analyze behavioral patterns and anomalous forwarding - combined with DMARCFlow for domain-level monitoring and aggregate report analysis. DMARCFlow catches lookalike domain patterns that often precede BEC campaigns, giving security teams time to investigate before a request lands.

Why do attackers prefer BEC to domain spoofing now?

Because DMARC at reject is widespread enough that external spoofing is reliably blocked. A successful wire transfer can be six or seven figures. Attacking through a legitimate account requires more effort than registering a fake domain, but the ROI is dramatically higher - and the email passes every authentication check the receiver runs.

Bottom line

DMARC at p=reject is a real security control worth having. It is not a comprehensive email security posture. The threat model it addresses - external domain spoofing - is real and important. The threat model it misses - BEC through compromised internal accounts - is responsible for the majority of financial email fraud today, with losses measured in billions annually.

Add the supplemental controls. Update the threat model. Stop measuring email security by DMARC status alone.