Preventing Business Email Compromise (BEC): Technical Defenses That Work

What Is Business Email Compromise?

Business Email Compromise (BEC) is a targeted attack where an adversary impersonates a trusted party via email to trick an employee into transferring funds, sharing sensitive data, or taking some other action that benefits the attacker. Unlike mass phishing campaigns that cast a wide net with generic lures, BEC attacks are crafted for specific targets using researched context about the organization, its executives, its vendors, and its business processes.

The financial impact of BEC is enormous. The FBI's Internet Crime Complaint Center consistently ranks BEC as the highest-loss cybercrime category, with reported losses in the billions annually. The average BEC incident costs significantly more than the average ransomware incident because BEC directly targets financial transactions -- wire transfers, invoice payments, payroll redirections -- where single transactions can reach six or seven figures.

BEC works because email was designed for communication, not authentication. The "From" field in an email is trivially spoofable. Without technical controls that verify sender identity, there is no reliable way for a recipient to distinguish a legitimate email from the CEO requesting a wire transfer from a spoofed email sent by an attacker using the CEO's display name and, potentially, the organization's actual domain.

This is where external security posture directly connects to BEC risk. The technical controls that prevent email spoofing -- SPF, DKIM, and DMARC -- are externally observable and measurable. An organization's email authentication configuration is a direct indicator of their susceptibility to domain spoofing attacks, which are the foundation of the most damaging BEC variants.

BEC Attack Techniques

Understanding how BEC attacks work reveals where technical controls intervene.

Direct Domain Spoofing

The attacker sends an email with a forged "From" header using your exact domain. The email appears to come from ceo@yourdomain.com but was actually sent from an attacker-controlled server.

Prevention: DMARC at p=reject. When your domain has DMARC enforcement, receiving mail servers check whether the sending server is authorized (via SPF) and whether the message is properly signed (via DKIM). Messages that fail both checks are rejected before reaching the recipient's inbox.

Lookalike Domain Spoofing

The attacker registers a domain that closely resembles yours -- yourdomam.com, yourdomain-inc.com, your-domain.com -- and sends email from the lookalike domain. The visual similarity tricks recipients who do not scrutinize the sender address.

Prevention: Certificate transparency monitoring identifies certificates issued for lookalike domains. CyberShield's CT module watches for new certificates that may indicate typosquatting or brand impersonation.

Display Name Spoofing

The attacker uses a completely different sending domain but sets the display name to match a trusted person. The email appears as "John Smith, CEO" in the recipient's inbox, but the actual email address is jsmith8847@freemail.com. Many email clients prominently display the name while hiding or minimizing the address.

Prevention: This technique does not spoof your domain, so DMARC does not block it directly. However, organizations with strong email authentication can implement policies that flag external emails mimicking internal display names. User awareness training complements technical controls here.

Compromised Account

The attacker gains access to an actual email account within your organization (through credential phishing, password spraying, or credential stuffing) and sends BEC emails from the legitimate account. Since the email genuinely originates from your infrastructure, it passes SPF, DKIM, and DMARC.

Prevention: Multi-factor authentication (MFA) on all email accounts is the primary defense. This is an internal control, but external security posture contributes: organizations with weak email authentication are more susceptible to the credential phishing that leads to account compromise.

Vendor Email Compromise

The attacker compromises a vendor's email account or domain and sends fraudulent invoices or payment instructions to the vendor's customers. Since the email comes from the vendor's actual infrastructure, the customer's email authentication checks pass.

Prevention: This highlights why vendor security posture matters. If your vendor lacks DMARC enforcement, their domain can be spoofed to target you. Assessing vendor email authentication as part of your third-party risk program reduces this exposure.

The Email Authentication Stack

Three protocols work together to authenticate email and prevent the domain spoofing that enables BEC.

SPF: Who Can Send

SPF declares which servers are authorized to send email for your domain. Published as a DNS TXT record, it lists IP addresses and includes for authorized services.

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:amazonses.com -all"

The -all at the end is critical. It tells receiving servers to reject email from any server not listed in the SPF record. Using ~all (soft fail) instead of -all merely suggests rejection -- most receiving servers treat soft fail as a suggestion rather than a requirement. For a complete walkthrough of SPF syntax and common pitfalls, see our SPF record configuration guide.

Common BEC-relevant SPF issues:

• No SPF record at all (any server can claim to be you)
• SPF with ~all or +all (weak or no enforcement)
• Exceeding the 10 DNS lookup limit (SPF evaluates to error, equivalent to no protection)

DKIM: Message Integrity

DKIM adds a cryptographic signature to outgoing messages. The sending server signs designated headers and the message body with a private key. The corresponding public key is published in DNS. Receiving servers verify the signature to confirm the message was not altered and originated from a server holding the private key.

selector._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgk..."

DKIM provides two guarantees relevant to BEC prevention:

1. The message was sent by someone holding the domain's private key (authenticity)
2. The message was not modified after signing (integrity)

Common BEC-relevant DKIM issues:

• DKIM not enabled on some sending services (those messages cannot be authenticated)
• Weak key sizes (RSA-1024 should be upgraded to RSA-2048 or Ed25519)
• Key rotation not practiced (long-lived keys increase compromise risk)

DMARC: Policy and Alignment

DMARC connects SPF and DKIM to the visible "From" header and defines what happens to messages that fail authentication.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com"

The critical elements for BEC prevention:

Policy (p=): Must be quarantine or reject to actually prevent spoofed messages from reaching recipients. p=none only reports -- it does not protect.

Subdomain policy (sp=): Should match the main policy. Without sp=reject, attackers can spoof billing.yourdomain.com or finance.yourdomain.com even if the main domain is protected.

Alignment (adkim=, aspf=): Strict alignment (s) requires exact domain match. Relaxed alignment (r, the default) allows subdomains to align with the parent domain. Strict alignment provides stronger protection but requires more careful configuration.

Reporting (rua=): Essential for visibility. DMARC aggregate reports show you who is sending email using your domain, whether those messages pass or fail authentication, and what policies are being applied.

Beyond SPF/DKIM/DMARC

Additional protocols strengthen email security beyond the core authentication stack.

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS tells sending servers that email to your domain must be delivered over TLS-encrypted connections. Without MTA-STS, an attacker performing a man-in-the-middle attack on an SMTP connection can strip TLS encryption and intercept email in transit.

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260310"

The MTA-STS policy is hosted as a text file at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

TLS-RPT (TLS Reporting)

TLS-RPT provides reporting on TLS delivery failures, helping you identify when email to your domain is failing TLS negotiation.

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

BIMI (Brand Indicators for Message Identification)

BIMI displays your organization's logo next to authenticated emails in supported email clients. While not a security control per se, BIMI makes it visually obvious when an email is properly authenticated, helping recipients distinguish legitimate messages from spoofed ones. BIMI requires DMARC at p=quarantine or p=reject as a prerequisite.

Measuring Your BEC Resilience

CyberShield's email authentication module evaluates every layer of your email security stack, providing a direct measurement of your BEC resilience.

SPF evaluation checks record validity, enforcement mode (-all vs ~all), lookup count relative to the 10-lookup limit, and whether all known sending services are included.

DKIM verification confirms that DKIM selectors are published and that public keys are valid. While CyberShield cannot verify signing on actual messages (that requires sending a test email), the presence of properly configured DKIM records indicates operational DKIM signing.

DMARC assessment evaluates policy strength (none/quarantine/reject), subdomain policy, alignment mode, percentage coverage, and reporting configuration. DMARC at p=none is flagged because it provides monitoring but zero protection against spoofing.

MTA-STS and TLS-RPT presence is checked to evaluate whether inbound email delivery is protected against downgrade attacks.

Each finding in the email category directly correlates with a specific BEC attack vector. Fixing email authentication findings does not just improve your security score -- it removes the technical foundations that enable the most costly form of email-based attack.

Implementation Roadmap

For organizations that have not yet implemented email authentication, or have partial implementations:

Week 1: Audit all services that send email using your domain. Include marketing platforms, CRM, helpdesk, transactional email, HR systems, and IT notifications. Publish or update your SPF record to include all authorized senders with -all.

Week 2: Enable DKIM signing on all identified email-sending services. Publish DKIM public key records in DNS. Verify signing by checking outbound message headers.

Week 3: Publish DMARC at p=none with reporting. Begin collecting aggregate reports to identify any legitimate senders you missed.

Week 4-6: Analyze DMARC reports. Fix any legitimate senders failing alignment. Address SPF lookup count if it exceeds 10.

Week 6-8: Move DMARC to p=quarantine at 25%, incrementally increasing to 100%. Monitor for delivery issues.

Week 8-10: Move DMARC to p=reject. Add sp=reject for subdomain protection. Deploy MTA-STS.

Ongoing: Monitor DMARC reports for changes. Run CyberShield scans to verify authentication remains properly configured. Review email authentication when onboarding new services. Consider BIMI deployment for brand visibility.

The technical controls described here do not eliminate all BEC risk -- compromised accounts and display name spoofing require additional defenses. But they eliminate the most damaging vector: direct domain spoofing, where an attacker sends email that is indistinguishable from your legitimate communications. With DMARC at enforcement, that specific attack becomes impossible. As AI-powered phishing makes spoofed emails even more convincing, these authentication controls become the most durable line of defense.