Business Email Compromise (BEC): Protect Your Domain, Invoices, and Users

Business Email Compromise (BEC) is one of the highest-impact “low-tech” cybercrime categories: it often relies on social engineering + weak email/domain controls—not exotic malware. The result can still be catastrophic: invoice reroutes, payroll fraud, vendor account takeover, and long-tail reputational damage.

This guide is a practical blueprint for:

• understanding the most common BEC patterns,
• hardening your domain and email posture, and
• investigating suspicious messages quickly.

What BEC looks like (real-world patterns)

Most BEC incidents fall into a few repeatable shapes:

1. Invoice redirection: attackers impersonate a vendor and send “updated bank details” right before payment.
2. CEO/CFO fraud: a senior leader’s name is spoofed to pressure urgent wire transfers.
3. Payroll diversion: HR requests “update my direct deposit” from a spoofed employee.
4. Mailbox takeover: attackers compromise a real mailbox and reply from the actual thread (harder to detect).
5. Vendor portal compromise: attackers reset credentials to invoice/ordering portals, then pivot.

The technical side of BEC is often domain spoofing or lookalike domains.

Spoofing vs lookalike domains (and why people miss it)

Spoofing (same visible domain, forged sender)

This is when the email claims to be from finance@yourcompany.com but was sent by a different system. The recipient sees the “From” name and address and trusts it.

Your defenses here are SPF, DKIM, and DMARC—especially DMARC alignment and enforcement.

Lookalike domains (similar domain, real domain)

Examples:

• yourcornpany.com (rn vs m)
• yourcompany-payments.com
• yourcompany.co instead of .com

These emails can pass SPF/DKIM/DMARC—because they’re sent from the attacker’s domain, not yours. The defense becomes:

• user training + inbox UI improvements,
• brand/domain monitoring,
• strong verification steps for payment changes.

Domain hardening: the controls that matter

1) SPF (Sender Policy Framework)

SPF is a DNS record that lists which servers are allowed to send mail for your domain.

Key advice:

• Keep SPF under the DNS lookup limit (flattening or consolidation may be needed).
• Don’t end SPF with +all (that means “everyone is allowed”).
• Prefer -all (hard fail) when you’re confident.

2) DKIM (DomainKeys Identified Mail)

DKIM signs outbound mail with a key referenced in DNS, giving recipients integrity + some authenticity signals.

Key advice:

• Rotate DKIM keys on a schedule.
• Avoid sharing selectors across unrelated systems.
• Make sure critical mail streams are actually DKIM-signed.

3) DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC ties SPF/DKIM together with alignment and tells receivers what to do when checks fail.

Minimum recommended path:

1. Start with monitoring:
   • p=none (collect reports)
2. Move to quarantine:
   • p=quarantine
3. Enforce:
   • p=reject

If you’re not already enforcing DMARC, read: SPF, DKIM, DMARC — a practical guide.

Investigation workflow (10–15 minutes)

When you receive a suspicious payment-change email:

Step 1: verify the sender domain

• Is it your exact domain? A partner’s exact domain? Or a lookalike?
• Run Domain Lookup on the sender domain to pull DNS signals fast.

Step 2: check the sending IP and ASN

Even if the displayed sender looks plausible, the sending infrastructure can be a giveaway:

• unusual ASN / hosting org for that vendor
• suspicious geolocation / datacenter patterns
• proxy/VPN signals (not definitive, but helpful)

Use IP Lookup and paste the sending IP from the message headers (or from your mail gateway logs).

Step 3: validate with an out-of-band process

This is the real BEC kill switch:

• For invoice changes: call a known number from your vendor master data (not the email signature).
• Require dual approval on payment destination changes.
• Log who approved and how it was verified.

A simple BEC prevention checklist

• DMARC policy enforced (progressing to quarantine/reject)
• SPF is strict and maintained (no +all)
• DKIM signing enabled across mail sources
• Payment-change process requires out-of-band verification
• Vendor banking changes require two-person approval
• High-risk actions generate alerts (mail rules created, forwarding enabled, new OAuth grants)
• Staff know “urgent payment” is a red flag, not a priority

Where this fits in your broader security program

BEC controls are high-leverage because they reduce fraud risk without needing perfect endpoint security. But BEC also overlaps with:

• identity security (MFA, conditional access, phishing-resistant auth)
• audit logging + alerting (mailbox forwarding rules, OAuth grants)
• vendor management (trusted contact records, payment processes)

If you want a technical triage companion to this guide, read: Phishing Triage Workflow.