What Your SEG Catches When BEC Gets Through: Detection

The BEC problem SEG vendors do not advertise

Your Secure Email Gateway catches a lot. Spam, malware, phishing with malicious links, credential-harvesting pages. All of that is content-scannable, and SEG products have gotten reasonably good at it.

But then there is BEC (Business Email Compromise). No payload. No malware signature. No malicious URL to check against a blocklist. No attachment to sandbox. Just an email, often from a lookalike domain or a compromised personal account, asking your CFO to approve an urgent wire transfer.

SEG vendors advertise "BEC detection" as a feature. What they mean by that varies widely, and most of what they catch is BEC that happens to also have something a traditional scanner can flag. The genuinely payloadless variant often sails straight through.

This guide covers what SEG products actually catch when they catch BEC, what slips through, and what you can do about it.

Why payloadless BEC evades content scanning

A SEG product inspects email on several layers. It checks IP reputation against known blocklists. It scans attachments for malware signatures or sends them to a sandbox. It analyzes URLs and compares them against threat intelligence feeds. It applies machine learning models trained on large corpora of malicious email.

None of that works when the email contains only legitimate text. No malicious payload. No suspicious domain. Just a human-readable request that happens to be fraudulent.

This is what "payloadless" means. The attack is entirely in the social engineering. The sender might be using a domain that is weeks old and has no reputation data yet. The email body might reference real company names, real people, real invoice numbers pulled from public sources. The reply-to address might be a free Gmail account that has never been flagged.

Content scanning has nothing to work with. The signal is entirely behavioral and contextual, which is exactly what automated scanners struggle with.

What SEG products actually catch (and what they miss)

SEG products vary in their detection approaches. Most fall into four categories, with varying coverage against payloadless BEC.

Signature-based detection catches known-bad patterns: specific sender IPs, known attacker domains, file hashes of malicious attachments. This catches nothing when the BEC email has no attachments and comes from a fresh domain.

Reputation-based detection scores senders by their historical behavior. A sender with no history, a new domain, or a domain that has only ever sent legitimate email gets a high reputation score. Payloadless BEC operators deliberately use high-reputation-looking senders. This method often fails here too.

Behavioral and anomaly detection looks for unusual patterns: a CEO who never emails a vendor suddenly requesting an urgent invoice, or an executive emailing an unusual recipient list. SEG products with genuine behavioral analytics can catch some of these cases. The effectiveness depends heavily on how much context the SEG has about your normal communication patterns. Products that only analyze the individual email, not the organizational communication graph, miss most of this.

Authentication-based detection checks whether the sender's domain passes SPF, DKIM, and DMARC checks. A domain that passes DMARC is cryptographically verified as authorized by its domain owner. A domain that fails all three is suspicious but not automatically malicious. The gap is in domains that pass SPF or DKIM but not DMARC, which is a large gray area that many legitimate bulk senders occupy.

The bottom line: traditional SEG detection layers catch BEC when it has something scannable. The genuinely payloadless variant bypasses most of them.

The authentication gap SEG products cannot close

SEG products inspect email in transit. They do not tell you whether your domain is being used to impersonate your executives in attacks sent to other organizations. That visibility requires a different data source: your own DMARC aggregate reports.

When someone spoofs your CFO's domain in a BEC campaign, the spoofed emails are sent from attacker-controlled infrastructure. Those servers fail SPF and DKIM checks against your domain. The failures accumulate in your DMARC aggregate reports as a pattern you can detect before any user reports an incident.

DMARCFlow is built for this. It parses the XML output from your domain's DMARC policy and turns it into structured data: which sending IPs are failing authentication, which domains are being spoofed most often, which patterns match known BEC infrastructure. Without tooling, aggregate reports require manual XML parsing. With DMARCFlow, the signal surfaces as an actionable alert.

This is the practical layer SEG products do not provide. They catch malicious email aimed at your users. DMARC aggregate reports tell you whether your domain is the impersonation source in attacks aimed at your vendors, partners, or customers.

Detection methods that work against payloadless BEC

Beyond authentication monitoring, several approaches have proven more effective against genuinely payloadless BEC.

Sender behavior analytics. SEG products with genuine behavioral analytics build models of normal communication patterns per user and across the organization. A CFO who never requests wire transfers suddenly doing so triggers an alert. The effectiveness here depends entirely on how long the system has been observing your organization and how much context it has.

Reply-chain analysis. BEC emails often start a new thread rather than replying to an existing conversation. Some SEG products flag new threads from known executives to external recipients as higher-risk. This catches some variants but is easily circumvented by cc-ing the actual executive on the attack email.

Free-text anomaly detection. Some SEG products analyze email body text for financial language patterns: invoice, wire transfer, ACH, payment details, urgent, confidential. This catches the loud, obvious BEC attempts. Sophisticated social engineering that reads like normal business correspondence slips through.

External threat intelligence. If the same BEC campaign is hitting multiple organizations, shared threat intel can flag the sender domain or infrastructure. This only works for campaigns that reuse infrastructure, which advanced BEC operators avoid.

No single method catches all payloadless BEC. The defense is layering multiple approaches, with authentication monitoring via DMARC aggregate reports providing the signal that content scanning cannot.

Practical checklist for security ops teams

If you are evaluating your SEG's BEC detection or building additional detection layers, here is what to check.

Does your SEG apply DMARC alignment checks as part of its filtering? Some do, some do not. If DMARC is not in the filtering logic, the SEG is flying blind on authentication-based BEC.
Does your SEG have behavioral analytics that model per-user communication patterns? If not, you are relying on content-only detection which payloadless BEC bypasses.
Are you receiving and reviewing DMARC aggregate reports? Most organizations are not. If no one is reading them, you have no visibility into domain spoofing that is happening right now.
Do your incident response procedures include DMARC failure triage? When a BEC attempt is reported, checking whether DMARC failures exist for the targeted domain takes minutes and tells you whether the attack used spoofing.
Do your SEG vendor's BEC catch claims include authentication-based detection? Ask specifically about DMARC, SPF/DKIM alignment, and aggregate report monitoring. If they cannot explain their authentication layer, their BEC detection is content-only.

The gap SEG products leave is real. Payloadless BEC is specifically designed to evade content scanning. Closing that gap requires authentication monitoring, which is exactly what DMARC aggregate reports provide.

FAQ

Can a SEG catch all BEC emails?

No. SEG products catch BEC that has scannable content: malicious attachments, known-bad URLs, known attacker infrastructure. Payloadless BEC, which relies entirely on social engineering and legitimate infrastructure, bypasses most SEG detection layers.

Does DMARC stop BEC?

DMARC does not stop BEC directly. It authenticates that the sender is authorized to use a domain. If your domain passes DMARC, the sender is authorized. If it fails, the email may be spoofed. DMARC aggregate reports give you visibility into who is trying to use your domain without authorization. That visibility is the detection advantage.

Is DMARC difficult to set up?

DMARC setup ranges from straightforward to complex depending on your email infrastructure. A basic p=quarantine policy is relatively easy. Moving to p=reject requires understanding your legitimate sender inventory first, which is where most organizations get stuck. DMARCFlow automates the sender discovery and reporting that makes safe p=reject deployment possible.

What is the single most effective BEC detection method SEG products miss?

Authentication-based monitoring via DMARC aggregate reports. SEG products do not provide visibility into whether your domain is being used in attacks, because that data comes from your own domain's DMARC policy, not from inspecting inbound email.

Does DMARCFlow help with BEC detection specifically?

DMARCFlow processes DMARC aggregate reports and surfaces patterns that indicate domain spoofing. If your domain is being used in a BEC campaign, the DMARC failure data in your aggregate reports will show the sending infrastructure. This is not BEC detection in the traditional SEG sense. It is authentication monitoring that tells you whether your domain is the source of a problem your users are being targeted with.