DMARC Analyzer

TL;DR

• Business Email Compromise (BEC) is the FBI IC3 reports' highest-loss email-crime category with USD 2.9 billion in reported U.S. losses in 2023 alone and cumulative losses exceeding USD 55 billion across 2013-2024 globally.
• BEC is targeted, low-volume, high-value social engineering aimed at financial fraud — distinct from commodity phishing in that it often carries no malicious URL, no malware attachment, and originates from a technically legitimate sender.
• The six canonical BEC variants are CEO fraud (executive impersonation), invoice fraud (vendor wire redirection), payroll diversion (HR redirect), gift-card scam (low-value high-volume), M&A confidentiality fraud, and Vendor Email Compromise (VEC) — each variant uses different attacker mechanics and requires different defensive layers.
• DMARC at p=reject stops exactly ONE BEC variant: direct domain spoofing of the victim organisation (attacker forges From: ceo@victim.example). DMARC does NOT stop lookalike-domain BEC, display-name BEC, compromised-account BEC, VEC, or out-of-band BEC.
• The BEC kill chain has five stages: reconnaissance, weaponisation, delivery, exploitation, and payout — defenders can disrupt the chain at every stage with layered controls.
• Defense-in-depth pairs DMARC enforcement with display-name verification policies, lookalike-domain monitoring, phishing-resistant MFA, finance-team out-of-band payment verification, vendor banking-change controls, and ongoing employee training — no single layer is sufficient.
• The single most effective non-technical control is a written out-of-band verification policy for wire-instruction changes ("call back on a known number, never the number in the email") — this stops every variant DMARC cannot stop.
• Vendor Email Compromise (VEC) is the hardest BEC variant to detect because the attacker uses a real vendor mailbox; every email-authentication signal is clean and the conversation thread is genuine. Defense lives OUTSIDE the email-authentication stack.
• The FBI Financial Fraud Kill Chain (FFKC) can recover wired funds if reported within 24-72 hours — the 2023 IC3 annual report cites a 73% recovery rate when reported within 24 hours, dropping to 23% beyond 72 hours. File at ic3.gov immediately.
• BEC reports are typically a LOWER BOUND because only U.S. victims report to IC3, an estimated 15-20% of victims report at all, and reputational concerns suppress reporting at large enterprises — the true global cost is likely 5-10x higher than published figures.

1. What Business Email Compromise (BEC) means

Business Email Compromise (BEC) is a class of social-engineering email fraud in which an attacker impersonates a trusted party — typically an executive, vendor, HR officer, or finance counterpart — to trick an employee with wire-transfer authority, payroll access, or confidential-information access into moving money or sensitive data to the attacker. The FBI Internet Crime Complaint Center (IC3) introduced BEC as a distinct reporting category in 2013 and has consistently ranked it as the highest-loss email-crime category by reported losses ever since.

BEC differs from commodity phishing in four operationally significant ways. First, BEC is targeted: the attacker has researched the victim organisation, identified the wire-transfer counterparty roles (CFO, controller, accounts payable clerk), and tailored the message to a specific named recipient. Second, BEC is low-volume: a typical BEC campaign sends one to ten carefully crafted messages, not the millions of commodity phishing emails sent in spray-and-pray credential harvesting. Third, BEC is high-value: single wires of USD 10000 to USD 50 million have been reported; the 2023 IC3 annual report identifies a median per-incident loss in the USD 25000-50000 range with multiple outliers above USD 10 million. Fourth, BEC often carries no malicious payload: no URL to scan, no attachment to detonate in a sandbox, no executable signature for an EDR to detect — the attack lives entirely in the social-engineering content of the message.

BEC maps onto MITRE ATT&CK techniques T1566.003 Spearphishing via Service (the commodity-webmail- From: variants), T1078 Valid Accounts (compromised-account variants including VEC), T1534 Internal Spearphishing (post-compromise lateral BEC where the attacker uses a captured mailbox to target other employees in the same organisation), and T1114.003 Email Forwarding Rule (the persistence mechanism attackers establish inside compromised mailboxes to maintain covert access). Naming the techniques aligns BEC discussions with broader threat-modelling vocabularies used by SOC, detection engineering, and incident-response teams.

The financial impact of BEC is concentrated in finance, treasury, accounts payable, payroll, HR, and executive-assistant roles. The IT-security team is typically involved only AFTER the wire has been sent — discovery usually comes from the legitimate vendor calling about a missed payment, or the receiving bank flagging the wire as anomalous, days or weeks after the loss. This delayed-discovery pattern is exactly why the Financial Fraud Kill Chain (FFKC, covered in §8) emphasises immediate reporting within the first 24-72 hours.

2. The six canonical BEC variants

The FBI IC3 and the academic literature recognise six canonical BEC variants. Each variant uses a different attacker mechanic, targets a different employee role, and requires a different defensive layer. The breakdown below mirrors the variant taxonomy used by the FBI public-service announcement series and the Verizon Data Breach Investigations Report (DBIR) annual edition.

2.1 CEO fraud (executive impersonation)

Variant: Attacker impersonates the CEO, CFO, or another C-suite executive of the victim organisation and sends an urgent message to a finance employee directing an immediate wire transfer or gift-card purchase.

Attacker workflow: The attacker enumerates the executive team via LinkedIn, company About pages, SEC filings (for U.S. public companies), and press releases. They identify the finance employee with wire-transfer authority via LinkedIn job titles (controller, treasury analyst, CFO assistant). They craft a message in the executive's authentic voice — often copying the executive's actual email signature from a previously-leaked or publicly-archived message — and send it with high-urgency, low-detail framing: "I need this wire processed before market close — I am in a meeting and cannot take calls — confidential M&A activity — please process and acknowledge". The From: header is either (a) a direct spoof of the executive's real address (blocked by DMARC p=reject), (b) a lookalike domain registration like ceo@vvictim.example or ceo@victim-corp.example, or (c) a commodity-webmail address (Gmail, Yahoo, Outlook) with the display name set to "CEO Name" so the email client UI renders the executive's name prominently.

DMARC role: DMARC at p=reject blocks variant (a) — direct From: spoofing of victim.example. DMARC has zero effect on variants (b) lookalike domain and (c) display-name spoofing from commodity webmail.

Defense: Pair DMARC with a written out-of-band verification policy for any wire request from an executive ("call back on the executive's known mobile number from the corporate directory, never the number in the email"), a Secure Email Gateway (SEG) policy that flags commodity-webmail From: addresses where the display name matches a known executive's name (Microsoft Defender Anti- Impersonation, Proofpoint TAP Imposter, Mimecast Brand Exploit Protect), and a segregation-of-duties control where no single employee can authorise a wire above a threshold (typically USD 10000 to USD 50000 depending on organisation size).

2.2 Invoice fraud (vendor wire redirection)

Variant: Attacker impersonates a real vendor to redirect a legitimate, recurring payment to attacker-controlled bank accounts. This is the highest-DOLLAR BEC variant by reported losses.

Attacker workflow: The attacker identifies an active vendor relationship via public sources (case studies, supplier directories, invoice archives accidentally indexed by search engines) or, more commonly, via prior compromise of a small vendor's mailbox (the VEC variant below). They wait for an active invoice exchange — typically monitoring the compromised mailbox for weeks or months to learn payment cadence, typical invoice amounts, and the accounts-payable contact at the customer. At the exact moment a large invoice is due, they intercept the legitimate invoice email (or inject a parallel "bank account update" message into the existing thread) instructing the accounts- payable team to update wire instructions to a new bank account. The first wire is typically processed without challenge because the message comes from the real vendor address (in the VEC variant) or from a convincingly-lookalike domain, the conversation context is recent and genuine, and the requested account-number change is the only anomaly.

DMARC role: DMARC at the VICTIM's domain does not affect invoice fraud at all — the From: header points at the vendor, not the victim. DMARC at the VENDOR's domain blocks only the direct- spoof variant; lookalike-domain attacks bypass vendor DMARC entirely, and VEC bypasses vendor DMARC because the attacker uses a real vendor mailbox.

Defense: Bank-account-change out-of- band verification on a phone number from the original contract or supplier-master record (never the number in the email), supplier-master-data tight-change controls (any banking change requires a separate "supplier banking update" form and dual authorisation in the ERP), automated detection of new bank-account numbers in the accounts-payable workflow (any first-time-use account number is held for verification), and supplier-onboarding due diligence to assess vendor mailbox security posture.

2.3 Payroll diversion (HR redirect)

Variant: Attacker impersonates an employee and sends a message to HR or payroll requesting the next paycheck be redirected to a new bank account (typically a prepaid debit card or a money-mule bank account).

Attacker workflow: The attacker enumerates employees via LinkedIn and the company website. They identify the HR or payroll contact address (often listed publicly as careers@ or payroll@). They craft a brief, casual message from a lookalike or commodity-webmail From: address bearing the targeted employee's display name: "Hi, I changed banks recently — can you please update my direct deposit to the attached routing and account numbers? I need this in place for the next payroll cycle. Thanks!". The new account number is the attacker's. The employee discovers the fraud only when the expected paycheck does not arrive — typically on payday or shortly after, by which point at least one full pay cycle's funds have already been moved.

DMARC role: Same as CEO fraud — DMARC blocks direct spoofs of the victim domain but not lookalike or display-name variants.

Defense: Self-service-only direct- deposit changes (employee must log into the HRIS with their authenticated identity and SSO, never request a change via email), a mandatory waiting period (typically 5 business days) before a new direct-deposit account is activated, and SMS or voice notification to the employee's verified phone number when any direct-deposit change is submitted (so a compromised employee sees the notification immediately).

2.4 Gift-card scam (low-value, high-volume)

Variant: Attacker impersonates an executive and asks the targeted employee to purchase gift cards "for a client gift" or "for an employee appreciation event", then share the gift-card redemption codes back to the attacker.

Attacker workflow: The attacker enumerates the executive team and any executive assistant or office manager who would plausibly be asked to handle gift cards. They send a low-key message from a lookalike or commodity-webmail address: "Hi, are you at your desk? I need a favour — can you grab some Amazon gift cards for a client? I will reimburse. Need them in the next hour. Please share the codes by email — keep this confidential until I announce it to the team." Each gift card is typically USD 100-500; the attacker requests 10-50 cards per incident, yielding USD 1000-25000 per successful gift-card BEC. The codes are immediately laundered via gift-card resale marketplaces.

DMARC role: Same as CEO fraud.

Defense: A written policy that NO executive will EVER ask an employee to purchase gift cards via email — annual security awareness training reinforces this — and a low gift-card- purchase reimbursement threshold that requires pre-approval through the standard expense workflow (not via email).

2.5 M&A confidentiality fraud

Variant: Attacker impersonates a senior executive and uses an "active M&A transaction" cover story to extract confidential information (NDAs, financial statements, customer lists, source code) or to direct a large wire to a fictitious escrow account.

Attacker workflow: The attacker leverages public M&A rumours (press, analyst reports, SEC 8-K filings) to time the attack to a period when a real or rumoured M&A transaction is plausible. They send a tightly framed message citing the rumoured target ("I am sure you have seen the press around the Acme acquisition — I need to move USD 2.5 million to the escrow account this afternoon — please keep this confidential, only the audit committee knows") and emphasise confidentiality so the targeted employee will not ask peers to verify. The wire goes to attacker-controlled bank accounts.

DMARC role: Same as CEO fraud.

Defense: A written policy that NO M&A transaction will EVER bypass the dual- signatory wire authorisation control — even if confidentiality is asserted. An out-of-band verification call from finance to general counsel (or the audit-committee chair) before any wire citing M&A activity is released. Awareness training for executives and their assistants that real M&A processes go through external counsel and escrow agents, not through ad-hoc internal wires.

2.6 Vendor Email Compromise (VEC)

Variant: Attacker compromises a real mailbox at one of the victim organisation's vendors — typically a small or mid-market supplier with weak credential hygiene — then uses that authenticated mailbox to send fraud messages to the victim from a domain the victim organisation already trusts. VEC is the hardest BEC variant to detect because every email-authentication signal is clean.

Attacker workflow: The attacker compromises the vendor mailbox via (1) credential phishing of the vendor employee (the entry point for the BEC variant — note the recursion: BEC enables BEC), (2) password reuse from a third-party breach (the vendor employee re-used a password from LinkedIn, Adobe, or another previously-breached service), (3) password-spray against the vendor's Microsoft 365 or Google Workspace tenant (a high- volume credential-stuffing attack on the vendor's cloud mailbox), or (4) phishing the vendor employee's multi-factor-authentication token via a reverse-proxy phishing kit (Evilginx2, Modlishka, EvilProxy). Once inside, they establish persistence via a mail-flow forwarding rule (T1114.003 — forwards all mail to an attacker-controlled mailbox), then SILENTLY READ THE MAILBOX FOR WEEKS OR MONTHS to learn the vendor's customer base, payment cadence, typical invoice amounts, and the accounts-payable contact at each customer. At the precise moment a large invoice is due to a high-value customer, they intervene — either by editing the legitimate invoice email's banking-instructions section before it goes out (replace-in-flight pattern), by injecting a "bank account update" message into the existing thread, or by responding to the customer's legitimate payment-confirmation question with different wire instructions.

DMARC role: DMARC at the victim domain is irrelevant — the From: header points at the vendor. DMARC at the vendor domain PASSES cleanly because the attacker is using a real vendor mailbox; SPF passes (sending IP is the legitimate vendor SMTP), DKIM passes (signature is real), and DMARC alignment passes.

Defense: VEC defense lives OUTSIDE the email-authentication stack. Bank-account-change out-of-band verification on a phone number from the contract (never the email), supplier-master-data tight-change controls, dual-authorisation for any vendor banking change, supplier-onboarding due diligence including security questionnaires that assess MFA enforcement, automated detection of new bank-account numbers in the accounts-payable workflow, vendor mailbox compromise monitoring (look for the attacker mail-forwarding-rule signature T1114.003), and cyber-insurance riders that explicitly cover social-engineering fraud (many policies exclude VEC under "voluntary parting with funds" clauses — confirm coverage with your broker).

3. The BEC kill chain (5 stages)

BEC unfolds across a five-stage kill chain that mirrors the Lockheed Martin cyber kill chain structure and the MITRE ATT&CK tactic progression. Defenders disrupt the chain at every stage; the further left in the chain the disruption occurs, the less remediation work is needed.

3.1 Stage 1 — Reconnaissance

The attacker enumerates the victim organisation's executive team, finance and HR contacts, vendor relationships, and active business deals via public sources: LinkedIn profiles (executive names, titles, reporting structures, finance-team names), company About pages (executive bios with email addresses), SEC filings 10-K and 8-K (CFO name, treasury team, M&A activity), press releases (deal announcements, executive transitions, vendor partnerships), customer case studies (vendor names and integration depth), and data-broker services (ZoomInfo, Lusha, Apollo.io) that aggregate employee email addresses and direct-dial phone numbers.

Disruption: Restrict the public footprint of finance and treasury team members. Many large enterprises remove finance-team direct email addresses from press releases and case studies, route all external finance correspondence through a department alias (accounts-payable@, treasury@) backed by a shared mailbox with a strict triage workflow, and instruct finance employees to keep LinkedIn job titles generic ("Finance" rather than "Wire Transfer Authoriser, Treasury").

3.2 Stage 2 — Weaponisation

The attacker selects the BEC variant (CEO fraud, invoice fraud, payroll, gift card, M&A, VEC) based on the reconnaissance data. They register a lookalike domain (Stage 2 of variants (a)/(b)/(c) above), compromise a vendor mailbox (VEC variant — Stage 2 here overlaps with credential phishing of the vendor employee), or create a commodity-webmail address with the targeted executive's display name (display-name variant). They craft the message content in the targeted party's authentic voice, often using ChatGPT or similar LLM tools to polish the language to match the targeted party's writing style. They prepare the receiving bank account — typically a mule account at a foreign bank or a prepaid card — and the laundering workflow (subsequent transfers through 3-5 layered accounts within 24-48 hours of receipt).

Disruption: Lookalike-domain monitoring services (DomainTools, ZeroFox, DigitalShadows, BrandShield) detect new domain registrations that match victim brand patterns within 24-48 hours of registration; most attackers register and weaponise within the same 1-week window. Vendor mailbox compromise monitoring (T1114.003 forwarding-rule detection on the vendor's Microsoft 365 or Google Workspace tenant) detects the VEC weaponisation stage. CAA records on the victim apex with DNSSEC prevent attacker certificate issuance on lookalike subdomains.

3.3 Stage 3 — Delivery

The attacker sends the weaponised message to the targeted employee. The message arrives at the victim mailbox through the standard SMTP path; if the From: header is a direct spoof, DMARC at p=reject causes the receiving MTA to reject the message at SMTP time (the kill-chain disruption DMARC actually provides). If the From: header is a lookalike domain or a commodity-webmail address with a display-name forgery, DMARC has no effect and the message lands in the inbox unless a Secure Email Gateway (SEG) anti-impersonation policy flags it.

Disruption: DMARC at p=reject on the victim apex (disrupts direct-spoof delivery — 1 of 6 BEC variants), SEG anti-impersonation policies (disrupts display-name forgery and high-confidence lookalike matches), inbound message banner warnings ("This sender appears to be an external party impersonating an internal executive" — Microsoft 365 Defender, Google Workspace Advanced Phishing Protection), and Microsoft First Contact safety tip ("You don't often get email from this sender — Learn why this is important").

3.4 Stage 4 — Exploitation

The targeted employee reads the message and decides whether to comply. This is the socio-technical decision point at which most real-world BEC losses occur. The attacker has engineered the message to maximise compliance: authority pressure (the requester is the boss or a trusted vendor), urgency (the request is time-critical), confidentiality (do not consult peers), and plausibility (the request fits an ongoing business context the employee already knows about). The employee initiates the wire, updates the bank account number in the ERP, or forwards the requested confidential information.

Disruption: The single most effective non-technical control is a written out-of-band verification policy for wire-instruction changes ("call back on a known number, never the number in the email"). Segregation of duties: no single employee can authorise a wire above a threshold (typically USD 10000-50000); the wire requires a second approver on a different machine. Dual-control on supplier-master banking-data changes: the AP clerk submits the change, a treasury manager approves on a separate authenticated session. Mandatory waiting period (typically 5 business days) for any new direct-deposit or vendor banking change. Ongoing security awareness training that includes BEC simulation exercises.

3.5 Stage 5 — Payout

The wire arrives at the receiving bank account. The attacker has minutes-to-hours to disperse the funds before the originating bank or the FBI Financial Fraud Kill Chain can freeze them. Typical laundering patterns: immediate transfer to a second-tier mule account at a foreign bank, subsequent transfer to a third-tier account in a jurisdiction with weak banking cooperation, conversion to cryptocurrency via a non-KYC exchange, withdrawal at an ATM via a money mule in person.

Disruption: Immediate reporting to the FBI Financial Fraud Kill Chain via ic3.gov and the FBI 24-hour Cyber Watch desk (recovery rate 73% within 24 hours, 23% beyond 72 hours per the 2023 IC3 annual report). Immediate SWIFT recall request with the originating bank. Preserve email headers, ERP audit logs, and any malicious mail-flow rules the attacker established. Notify the cyber-insurance carrier. Consider issuing a breach notification if confidential information (employee SSNs, M&A data) was also exposed.

4. How DMARC defends against BEC

DMARC at p=reject with full SPF and DKIM alignment stops the single most direct BEC delivery technique: forging the From: header to read ceo@victim.example or accounts-payable@victim.example. The defence chain operates at SMTP delivery time:

1. The attacker connects to the receiver MTA and issues MAIL FROM and RCPT TO with a forged envelope, then DATA containing a message whose From: header reads ceo@victim.example.
2. The receiver MTA performs SPF lookup against the connecting IP and the envelope-MAIL-FROM domain. If the connecting IP is not in the victim's SPF record (which it will not be because the attacker is not on victim infrastructure), SPF returns fail.
3. The receiver MTA performs DKIM signature verification. Either the attacker did not include a DKIM signature (DKIM = none) or included one signed with their own key against a different d= (the alignment check will catch this in step 4).
4. The receiver MTA performs DMARC alignment: does the SPF passing domain align with the From: header domain (victim.example)? Does the DKIM d= align with the From: header domain? Both fail because the attacker is not victim infrastructure.
5. The receiver MTA reads the DMARC policy from _dmarc.victim.example. If p=reject, it issues a 550 5.7.1 SMTP rejection at end-of-DATA; the attacker connection is closed with no message delivered. The message never reaches the recipient inbox.

This is the SINGLE point in the BEC kill chain where DMARC provides direct defensive value: a hard SMTP rejection of the direct-spoof delivery attempt. The defence is binary — either the From: header exactly matches the victim apex (and DMARC blocks) or it does not (and DMARC does nothing). For receivers that publish public DMARC failure reports (rua= aggregate stream), the victim operator sees the attacker delivery attempt in the rua= report as a failing message from a sending IP they did not authorise — useful threat intelligence documented in help_dmarc_attacker_bypass.php §10.

Empirical data: per the DMARC.org annual deployment reports, organisations that move from p=none to p=reject typically see a 40-60% drop in successful direct-domain-impersonation BEC delivery attempts within 30 days. The drop is not 100% because attackers immediately pivot to lookalike domains, display-name forgery, and VEC variants — the focus of §5 below.

Reaching p=reject requires the full phased rollout documented in help_dmarc_policy_rollout.php (Week 0 publish at p=none, Week 4-6 transition to p=quarantine with pct=10 ramping to pct=100, Week 12+ p=reject). Operators stuck at p=none for years have ZERO direct-spoof BEC protection; the rua= aggregate stream gives visibility but no enforcement.

5. The DMARC gap (variants DMARC cannot block)

DMARC is necessary but radically insufficient against BEC. Five of the six canonical BEC variants pivot around DMARC entirely. Treating DMARC as "BEC defense" is the single most expensive mental- model error in email security — it produces organisations that publish p=reject, declare victory, and continue losing millions to lookalike and VEC variants.

5.1 Lookalike-domain BEC

The attacker registers a domain that visually resembles the victim or vendor — typosquats (vvictim.example, victirn.example), cousin domains (victim-corp.example, victim-pay.example), TLD swaps (victim.co vs victim.com), or IDN homographs using Cyrillic, Greek, or Latin Extended characters that visually mimic ASCII Latin letters. The attacker publishes their OWN DMARC, SPF, and DKIM on the lookalike. Every authentication check passes cleanly for the attacker domain. DMARC at the victim apex has zero opinion on the attacker domain.

Defense: Brand-monitoring services that proactively register confusable lookalikes and IDN punycode variants, SEG anti-impersonation policies that flag emails from domains with a high edit-distance-to-known-brand match, employee training that emphasises checking the full From: address (not just the display name), and email client UI that renders the full email address by default (some webmail clients hide it by default — a known UX-security tradeoff).

5.2 Display-name BEC

The attacker uses a commodity-webmail address (ceo.victim@gmail.com or confidential.payments@outlook.com) with the display name set to a real executive's name ("Victim CEO Name <ceo.victim@gmail.com>"). DMARC passes cleanly for gmail.com or outlook.com. Most email client UIs render the display name prominently and the address subtly, so a hurried executive assistant reads "Victim CEO Name" and complies without scrutinising the address.

Defense: SEG anti-impersonation policies that build a directory of internal display names and flag any external message whose display name matches an internal employee name (Microsoft Defender Anti-Impersonation, Proofpoint TAP Imposter, Mimecast Impersonation Protect), inbound message banners that render external senders distinctly ("[EXTERNAL]" subject prefix or a visual warning band — covered as External Email Banner / EEB), and BIMI logos on legitimate internal mail (so the absence of the expected logo on a display-name forgery is a visible signal to the recipient).

5.3 Compromised-account BEC

The attacker has stolen or phished the credentials of a real employee at the victim organisation. They log into the employee mailbox via OWA, Gmail, or IMAP and send BEC messages from the real address — every authentication check passes because the attacker IS legitimate from the email-authentication perspective. The message originates from victim.example infrastructure, signed by victim DKIM, with SPF passing for victim's outbound MTA.

Defense: Phishing-resistant MFA on all employee mailboxes (FIDO2 / WebAuthn / passkeys — NOT SMS or TOTP which are bypassable via reverse-proxy phishing kits like Evilginx2), conditional access policies that restrict mailbox login to managed devices or specific geographic regions, anomalous-login detection (Microsoft Defender Identity Protection, Google Workspace Login Audit), session-token revocation on any anomaly, mail-flow-rule monitoring (alert on any new forwarding rule created in any user mailbox, with security-team review before allowing persistence — T1114.003 disruption), and outbound- mail anomaly detection that flags BEC patterns even from legitimate authenticated employee mailboxes (Abnormal Security, Tessian, Avanan).

5.4 Vendor Email Compromise (VEC)

Same defense pattern as 5.3 but for the vendor organisation rather than the victim. The victim cannot directly enforce phishing-resistant MFA on every vendor; supplier-onboarding due diligence must therefore include vendor-MFA-attestation questionnaires, and operational controls (out-of- band verification on bank-account changes, supplier-master-data tight-change controls) must assume vendor mailbox compromise as a baseline threat.

5.5 Out-of-band BEC

Increasingly, attackers pivot to SMS smishing, voice vishing (often using AI voice cloning of executive voices), Microsoft Teams chat messages, Slack DMs, and WhatsApp messages — channels that bypass email entirely and therefore bypass DMARC, SPF, DKIM, and the SEG completely. The Teams / Slack variants are particularly insidious because Microsoft Teams Federation accepts inbound chat messages from any tenant by default; an attacker can spin up a free Microsoft 365 tenant under a domain similar to the victim's and initiate a chat conversation that appears to be from a real colleague.

Defense: Restrict Microsoft Teams Federation to a whitelist of explicitly-trusted partner tenants (the Teams equivalent of the ARC-trusted-sealer pattern), apply the same out-of-band verification policy regardless of the communication channel ("call back on a known number" works for SMS, Teams, Slack, and WhatsApp just as well as for email), employee training that includes voice and Teams BEC simulations, and AI-voice-cloning awareness ("a voice that sounds like the CEO is not proof of identity").

6. The full BEC defense-in-depth control stack

BEC defense is a defense-in-depth problem; no single layer is sufficient. The layered control stack below is ordered from outer perimeter (least organisation-specific work) to inner (most organisation-specific work). Each layer disrupts a different subset of the six canonical BEC variants.

Layer 1 — Email authentication (DMARC, SPF, DKIM, BIMI)

• DMARC at p=reject on the victim apex AND on every parked / non-sending domain via sp=reject — blocks the direct-spoof variant. Pair with the rollout playbook in help_dmarc_policy_rollout.php.
• SPF tight: only authorised outbound IPs, no +all, regular review for third-party include: drift via help_spf_lookup_limit.php.
• DKIM with 2048-bit keys minimum, rotated every 6-12 months, separate selectors per sending service via help_dkim_key_rotation.php.
• BIMI with VMC where commercially justified — provides a visible legitimacy-signal in compatible inboxes that attackers cannot replicate via help_bimi_explained.php.
• MTA-STS + TLS-RPT — not directly BEC-related but closes the transport-security gap an attacker could exploit via active-on- path attacks during message delivery.

Layer 2 — Secure Email Gateway (SEG) anti-impersonation

• Display-name impersonation policies — build an internal directory of executive and finance-team display names, flag any inbound message from an external domain whose display name matches a directory entry (Microsoft Defender Anti-Impersonation, Proofpoint TAP Imposter, Mimecast Impersonation Protect, Barracuda Sentinel).
• Lookalike-domain detection — SEG edit-distance and Punycode-decoded lookalike-domain checks against a brand-tracked list.
• First-contact safety tips — inline UI warnings on emails from senders the recipient has not previously corresponded with (Microsoft 365 Defender, Google Workspace Advanced Phishing Protection).
• External-sender banners — visible "[EXTERNAL]" subject prefix or a colour-coded banner at the top of every external message so the recipient sees the external-origin signal at every glance.
• Outbound BEC anomaly detection — third-party tools (Abnormal Security, Tessian, Avanan) that profile every employee's outbound mail patterns and flag deviations consistent with compromised-account BEC.

Layer 3 — Identity hardening

• Phishing-resistant MFA — FIDO2 / WebAuthn / passkeys on every employee mailbox. NOT SMS, NOT TOTP, NOT push-confirmation MFA — all three are bypassable via reverse-proxy phishing kits like Evilginx2, Modlishka, and EvilProxy.
• Conditional access policies — restrict mailbox login to managed devices or specific geographic regions; block legacy authentication protocols (IMAP, POP3, basic SMTP) that bypass MFA entirely.
• Anomalous-login detection and session- token revocation — Microsoft Defender Identity Protection, Google Workspace Login Audit, Okta IdentityThreat Protection.
• Mail-flow-rule monitoring — alert on any new forwarding rule created in any user mailbox, with security-team review before allowing persistence (disrupts T1114.003).

Layer 4 — Finance-team payment-process controls

• Out-of-band verification for wire- instruction changes — written policy that any change to a vendor bank account, an employee direct-deposit account, or a wire beneficiary must be verified by phone callback on a known number from the original contract or HRIS record (never the number in the email). This is the single most effective non-technical BEC control.
• Segregation of duties on wires — no single employee can authorise a wire above a threshold (typically USD 10000-50000); the wire requires a second approver on a different machine in a different role.
• Dual-authorisation on supplier-master banking-data changes — the AP clerk submits the change, a treasury manager approves on a separate authenticated session.
• Mandatory waiting period on any new direct-deposit or vendor banking change — typically 5 business days from change submission to first payment to the new account.
• Anomaly detection on new beneficiary accounts — automated ERP / AP workflow rules that hold any first-time-use bank account for separate verification before the first wire releases.

Layer 5 — Vendor and supplier controls

• Supplier-onboarding security questionnaires that assess MFA enforcement, mail-flow-rule monitoring, and cyber-insurance coverage at the vendor.
• Cyber-insurance riders that explicitly cover social-engineering fraud (many baseline policies exclude VEC under "voluntary parting with funds" — confirm coverage with your broker).
• Vendor-relationship change procedures — annual review of vendor banking instructions with the vendor's verified finance contact (not via email).
• Contractual obligations on vendor cybersecurity baseline in master service agreements (MSAs) — particularly for high-value or critical vendors.

Layer 6 — Continuous training and BEC simulation

• Annual security-awareness training that includes BEC-specific examples (CEO fraud, invoice fraud, payroll diversion, gift-card scam, M&A fraud, VEC) and the recommended out-of-band verification policy.
• BEC simulation campaigns — quarterly phishing-simulation exercises that include BEC variants, not just commodity- phishing variants. Track click-through and report rates by department; identify employees and departments that need targeted retraining.
• Executive and EA-specific training — because CEO fraud disproportionately targets executive assistants and the executive's finance counterparts.
• Tabletop exercises with the finance, security, and legal teams that walk through a hypothetical BEC incident from delivery through FBI FFKC engagement, cyber- insurance notification, and breach disclosure.

7. Red-flag indicators every employee must recognise

Annual security training should include the following red-flag indicators. Each indicator is actionable: if present, the employee must invoke the out-of-band verification policy before proceeding.

• Urgency framing — "I need this before market close", "process today", "the deadline is in 30 minutes". Real executives and real vendors give the finance team time to verify; BEC attackers are betting on urgency bypassing verification.
• Confidentiality framing — "do not discuss with anyone", "keep this between us", "the audit committee does not know yet". Real wire requests for legitimate M&A activity go through external counsel and escrow agents; the finance team is NOT asked to keep wires confidential from peers.
• Authority pressure — "as your boss I am directing you to do this", "I need you to handle this for me personally". Real executives respect the finance team's process controls; BEC attackers bet on authority bypassing controls.
• Channel anomalies — the message arrives via a channel the requester does not normally use (the CFO never emails the AP clerk directly — the request normally goes through the treasury manager).
• Inconsistent reply-to — the From: header reads one address but the reply goes to a different domain (a common attacker technique to capture the response without being detected by simple SEG checks).
• New bank account number — any vendor or employee requesting a payment to a new bank account number, especially at a foreign bank or a prepaid card.
• Address mismatch on close inspection — the From: address looks like the executive's but is a lookalike (vvictim.example vs victim.example, victim.co vs victim.com, Cyrillic а vs Latin a).
• Display name does not match address — the display name is the executive but the address is a free webmail provider.
• Unusual writing patterns — the message tone or grammar is subtly different from the requester's usual style. (LLM-polished BEC has reduced this signal but it remains detectable on close reading.)
• Out-of-hours timing — the message arrives outside the requester's normal business hours (early morning, late evening, weekend) when verification calls are harder to place.

The single most effective response to any of these indicators is: pause, pick up the phone, call back on a known number from the corporate directory or the original contract — never the number in the email.

8. Incident response for suspected BEC

The FBI Financial Fraud Kill Chain (FFKC) can recover wired funds if reported within 24-72 hours of the wire. The recovery rate is heavily time-dependent. The 2023 IC3 annual report cites a 73% recovery rate when reported within 24 hours and 23% beyond 72 hours. The incident-response procedure below activates the FFKC and the parallel internal-recovery steps.

8.1 Step 1 — Confirm the loss (5 minutes)

The first task is to confirm that money has left the originating bank account. Check the ERP, the bank portal, and the wire-system queue. Distinguish between (a) a wire that has not yet been released, which can be cancelled immediately, (b) a wire that has been released but not yet settled at the receiving bank, which the FFKC can intercept, and (c) a wire that has settled, where the FFKC and SWIFT recall are the remaining options.

8.2 Step 2 — Immediate bank engagement (15 minutes)

Call the originating bank's fraud line. Most commercial banks have a dedicated wire-fraud line available 24/7. Request: (1) immediate wire cancellation or SWIFT recall (Message Type MT 192 Request for Cancellation), (2) freeze on any additional wires from the affected account pending investigation, and (3) bank-internal escalation to their financial-crimes unit. Keep the call notes — bank reference numbers will be needed for the FBI filing.

8.3 Step 3 — File IC3 complaint (within 24 hours)

Submit a complaint at ic3.gov including (1) date and time of wire, (2) amount and currency, (3) originating bank name, account number, and routing number, (4) beneficiary bank name, account number, and routing or SWIFT reference, (5) the email evidence including raw message headers and any associated attachments, (6) the attacker's email address(es) and any domain(s) used. Include "BEC" in the complaint type. If the loss exceeds USD 50000 (the FFKC direct-engagement threshold), call the FBI 24-hour Cyber Watch desk directly: +1-855-292-3937.

8.4 Step 4 — Preserve evidence (24-48 hours)

• Raw email headers from the triggering BEC message (Microsoft 365 Compliance Center export, Google Vault export — full Internet headers, not just the rendered display).
• ERP audit logs covering the wire creation, approval, and release events.
• Mailbox audit logs covering any login from anomalous IP addresses around the BEC time window.
• Mail-flow rule audit — snapshot every mail-flow rule on every executive and finance-team mailbox; preserve any forwarding rule found (T1114.003 evidence).
• SEG quarantine logs for any related messages that the SEG flagged before the BEC delivery.
• Telephone logs if any voice verification was attempted (BEC attackers occasionally route through phone-spoofing services to confirm the request).

8.5 Step 5 — Notify the cyber-insurance carrier (within 72 hours)

Most cyber-insurance policies require notification within 72 hours of incident discovery. Notify the carrier or broker in writing with the IC3 reference number, bank reference numbers, and preserved evidence inventory. Confirm coverage scope under the social-engineering-fraud rider (if present) or the funds-transfer-fraud rider. Be aware: many baseline cyber policies exclude BEC under "voluntary parting with funds" — the rider must be explicitly endorsed.

8.6 Step 6 — Lateral investigation (1-2 weeks)

Investigate the full scope of compromise: was the BEC delivered via a compromised account (5.3), requiring credential reset and session-token revocation across the organisation? Was a vendor mailbox compromised (5.4), requiring notification to other affected customers of the same vendor? Did the attacker establish mail-flow-rule persistence (T1114.003), requiring audit of every user mailbox for forwarding rules created in the incident window? Did the attacker exfiltrate confidential information (M&A data, employee SSNs, customer PII), triggering breach-notification obligations under SEC, GDPR, HIPAA, state laws?

8.7 Step 7 — Lessons-learned and control hardening

Run a formal post-incident review with finance, security, legal, and executive leadership. Identify which defense-in-depth layers failed (DMARC, SEG anti-impersonation, identity, payment process, vendor controls, training) and prioritise remediation. Update the BEC playbook based on the actual incident's attack pattern. Re-baseline quarterly BEC simulation campaigns to include the variant that succeeded against the organisation.

9. BEC cost & impact statistics

The following figures are drawn from the FBI Internet Crime Complaint Center (IC3) annual reports and the Verizon Data Breach Investigations Report (DBIR). All figures are reported losses; actual losses are estimated to be 5-10x higher after accounting for under-reporting.

9.1 Annual reported U.S. BEC losses (FBI IC3)

9.2 Per-incident loss distribution

The Verizon DBIR consistently identifies BEC as the most expensive single-incident phishing class with:

• Median loss per incident: USD 25000-50000
• 75th percentile: USD 75000-150000
• 95th percentile: USD 500000-1000000
• 99th percentile: USD 5-10 million
• Reported outlier maximum: USD 37 million (Toyota Boshoku, 2019)

9.3 BEC vs ransomware: the executive-sponsorship comparison

The 2023 IC3 annual report identifies BEC losses at USD 2.95 billion vs ransomware losses at USD 59.6 million. BEC is roughly 50x larger by reported losses despite ransomware dominating cybersecurity media coverage. The implication for security-leadership sponsorship: BEC controls deliver substantially more risk-reduction per dollar invested than ransomware controls for most organisations.

Caveats: (1) ransomware losses are systematically under-reported even more severely than BEC because of brand-damage concerns; (2) BEC IC3 figures only cover reported U.S. losses; (3) ransomware losses often include indirect costs (downtime, recovery, breach notification) that the IC3 figure does not capture; (4) the ratio varies by industry and organisation size. Treat the 50x figure as a headline order-of-magnitude comparison, not a direct apples-to-apples cost analysis.

9.4 FBI FFKC recovery rates by reporting time

The takeaway: incident response speed is the single biggest determinant of recovery success after a BEC loss. Internal IR playbooks should target activation of the FFKC within 4 hours of the loss, and IC3 filing within 24 hours.

10. BEC + DMARC enforcement strategy decision matrix

The following matrix maps the six canonical BEC variants to the defensive layers that disrupt each. Use this to identify gaps in your defense-in-depth posture.

The cells marked with Yes in bold identify the single most-load-bearing control for that variant. Note the pattern: payment-process out-of-band verification is load-bearing for the majority of variants — including the variants DMARC does NOT block — making it the single highest-leverage non-technical BEC control.

Note also that DMARC blocks one variant outright (CEO fraud direct spoof) and partially blocks two others (payroll, gift card, M&A) when the attacker chose the direct-spoof variant rather than a lookalike. The reason DMARC matters even when it is not load-bearing is that it FORCES attackers off the cheapest variant (direct spoof) and onto more expensive variants (lookalike domain registration, VEC, compromised account) that the other layers detect more reliably.

11. FAQ

What is Business Email Compromise (BEC) in simple terms?

Business Email Compromise (BEC) is a class of social-engineering email fraud in which an attacker impersonates a trusted party — typically an executive, vendor, or HR officer — to trick an employee with wire-transfer authority or payroll access into moving money or sensitive data to the attacker. Unlike commodity phishing, BEC is targeted (the attacker has researched the victim organisation), low-volume (one carefully crafted message rather than a campaign), and high-value (single wires of USD 10000 to USD 50 million have been reported). The FBI Internet Crime Complaint Center (IC3) consistently ranks BEC as the highest-loss email-crime category by reported losses, with cumulative U.S. losses exceeding USD 55 billion across 2013-2024 according to the FBI public-service announcement series. BEC techniques map onto MITRE ATT&CK T1566.003 (Spearphishing via Service), T1078 (Valid Accounts), and T1534 (Internal Spearphishing) depending on the variant.

Does DMARC stop BEC attacks?

DMARC at p=reject with full SPF and DKIM alignment stops exactly ONE BEC variant: direct domain spoofing of the victim organisation, where the attacker forges the From: header to read ceo@victim.example. DMARC at p=reject causes receivers to reject those messages at SMTP time so they never reach the recipient inbox. DMARC does NOT stop the other five BEC variants: lookalike- domain BEC (attacker registers ceo@victim-corp.example or vvictim.example and sends from that attacker-controlled domain with valid DMARC for the attacker domain), display-name BEC (From: cheap- webmail@gmail.com with display name "CEO Name", DMARC passes for gmail.com), compromised-account BEC (attacker logs into a real employee mailbox via stolen credentials and sends authenticated DMARC- passing mail from inside the organisation), Vendor Email Compromise (VEC, attacker compromises a real vendor mailbox and sends genuine DMARC-passing invoice-redirect requests from the vendor), and SMS / voice / Teams-chat BEC (out-of-band channels that bypass email entirely). DMARC is necessary but insufficient; the BEC defense-in-depth stack pairs DMARC with display-name policies, lookalike-domain monitoring, phishing- resistant MFA, finance-team payment-process controls, and vendor-relationship change- confirmation procedures.

What is the difference between BEC and phishing?

Phishing is the broad category: any deceptive message designed to extract credentials, credit-card numbers, or other information from a victim. Phishing campaigns are typically high-volume (thousands or millions of messages), low-cost-per-target, and aimed at credential or data theft. BEC is a SUBSET of phishing — specifically the targeted, low-volume, social-engineering variant aimed at financial fraud: the attacker wants the victim to authorise a wire transfer, redirect a vendor payment, divert payroll, or release confidential M&A information. BEC is sometimes called "spear phishing for money" or "Type 5 phishing" in the FBI taxonomy. The Verizon Data Breach Investigations Report (DBIR) annual edition consistently identifies BEC as the most expensive phishing variant per incident even though the volume is much lower than commodity phishing. From a defense perspective, commodity phishing is blocked at scale by Secure Email Gateways (SEGs) using reputation and URL-rewrite; BEC requires socio-technical defense (employee training + payment-process controls) because the messages often contain no malicious URL, no malware attachment, and originate from a technically legitimate sender.

What is CEO fraud and how does it differ from generic BEC?

CEO fraud (also called "executive impersonation" or "whaling-driven BEC") is the highest-volume BEC variant: an attacker impersonates the CEO, CFO, or another C-suite executive of the victim organisation and sends an urgent message to a finance employee directing an immediate wire transfer. Typical patterns include "I need this wire processed before market close — I am in a meeting and cannot take calls", "Confidential M&A activity — do not discuss with anyone — please prepare a wire to the attached account", and "Can you process a personal favour for me — gift cards for a client gift — I will reimburse". CEO fraud relies on (1) authority pressure (the attacker is the boss), (2) urgency (no time to verify), and (3) confidentiality (no time to consult). The FBI IC3 reports identify CEO fraud as the single highest-loss BEC variant by reported median loss per incident. Defense pairs DMARC (to block the direct-spoof variant at p=reject) with display-name verification policies, payment-process out-of-band verification ("call back on a known number, never the number in the email"), and segregation-of- duties controls (no single employee can authorise a wire above a threshold).

What is invoice fraud and how does DMARC interact with it?

Invoice fraud (also called "vendor-redirect fraud" or "wire-redirect fraud") is the highest-DOLLAR BEC variant by reported losses: an attacker impersonates a real vendor to redirect a legitimate, recurring payment to attacker-controlled bank accounts. The attacker usually compromises the vendor mailbox first (or registers a lookalike domain), waits for an active invoice exchange, then sends a "bank account update" message instructing the accounts-payable team to update wire instructions. The first wire is typically processed without challenge because the message comes from the real vendor address (in the Vendor Email Compromise variant) or from a convincingly-lookalike domain (in the lookalike variant), the conversation context is recent and genuine, and the requested account-number change is the only anomaly. DMARC blocks invoice fraud only when the attacker uses a direct-spoof variant (forging the vendor From: address) — vanishingly rare at scale because vendors with DMARC at p=reject force the attacker to a lookalike. When the variant is lookalike (vendor-corp.example vs vendor.example) or VEC (attacker logged into the real vendor mailbox), DMARC for the victim or vendor domain does NOT block the message; defense is bank-account-change out-of-band verification ("call the vendor on the phone number from the contract, not the email"), supplier-master-data tight-change controls, and dual-authorisation for any vendor banking change.

What is Vendor Email Compromise (VEC) and why is it so hard to detect?

Vendor Email Compromise (VEC) is the BEC variant where the attacker compromises a real mailbox at one of the victim organisations vendors — typically a small or mid-market supplier with weak credential hygiene — then uses that authenticated mailbox to send fraud messages to the victim from a domain the victim organisation already trusts. VEC is exceptionally hard to detect because (1) the From: domain is the real vendor (DMARC, SPF, DKIM all pass cleanly), (2) the conversation thread is genuine (the attacker reads the existing mailbox history), (3) the language matches the vendors past correspondence (the attacker uses the existing thread), (4) attachments and signature blocks are real, and (5) any reply goes to the attacker, who maintains mailbox access. The attacker typically waits weeks or months inside the vendor mailbox to learn the payment cadence, then intervenes at exactly the moment a large invoice is due. Defense layers must therefore live OUTSIDE the email-authentication stack: bank-account-change out-of-band verification on a phone number from a contract (not the email), supplier-onboarding due diligence including security questionnaires, vendor mailbox compromise monitoring (look for the attacker mail-forwarding-rule signature T1114.003), and cyber-insurance riders that explicitly cover social-engineering fraud (many policies exclude VEC under "voluntary parting with funds" clauses).

What is the Financial Fraud Kill Chain and how should I report a BEC incident?

The Financial Fraud Kill Chain (FFKC) is the FBI-operated process for emergency recovery of funds wired in BEC and other financial-fraud incidents. The kill chain works because most wires settle through correspondent-banking relationships that introduce a 24-72 hour window between the originating-bank debit and the receiving-bank credit; within that window the FBI can coordinate with the originating bank, correspondent banks, and the receiving foreign bank to freeze the funds before they are dispersed to layered mule accounts. To activate the FFKC: (1) immediately file a complaint at ic3.gov including the wire details (date, amount, originating bank, beneficiary bank, account number, SWIFT or ACH reference), (2) call the FBI 24-hour Cyber Watch desk if the loss exceeds USD 50000 (the FFKC threshold for FBI direct engagement), (3) notify the originating bank immediately requesting a SWIFT recall, (4) preserve all email evidence including raw headers and Microsoft Compliance Center / Google Vault audit logs, (5) preserve any malicious-mail-flow rules the attacker may have established under T1114.003, (6) file the IC3 complaint within 72 hours of the wire (the recovery rate drops sharply outside this window — the 2023 IC3 annual report cites a 73% recovery rate when reported within 24 hours, dropping to 23% beyond 72 hours), and (7) notify your cyber-insurance carrier. The FFKC is U.S.-centric; outside the U.S. the equivalent process is country-specific (Action Fraud in the UK, BKA in Germany, AFP ReportCyber in Australia).

How much does BEC actually cost organisations every year?

According to the FBI Internet Crime Complaint Center (IC3) annual reports, U.S. organisations alone reported BEC losses of USD 2.9 billion in 2023, USD 2.7 billion in 2022, USD 2.4 billion in 2021, USD 1.8 billion in 2020, USD 1.7 billion in 2019, and USD 1.3 billion in 2018 — a growth rate of roughly 15-20% year over year. Cumulative reported U.S. losses from 2013 (when IC3 began tracking BEC as a distinct category) through 2024 exceed USD 55 billion. The IC3 figures are LOWER BOUNDS because (1) only U.S. victims report to IC3, (2) only a fraction of victims report at all (estimated 15-20% based on Verizon DBIR methodology), and (3) reputational concerns suppress reporting at large enterprises. The Verizon DBIR consistently identifies BEC as the most expensive single- incident phishing class with median per- incident loss in the USD 25000-50000 range and outliers exceeding USD 50 million (the highest reported single BEC incident is the 2019 Toyota Boshoku case at USD 37 million). For executive sponsorship the headline figure is: BEC is roughly an order of magnitude more expensive per organisation per year than ransomware on a reported-loss basis, despite ransomware dominating cybersecurity media coverage.

12. Related guides

• How attackers bypass weak DMARC — the broader attacker-perspective catalogue covering 22 concrete bypass techniques across 4 classes. BEC is referenced in §7.1 (compromised legitimate accounts / Valid Accounts T1078). Pair this BEC page (the finance / treasury / fraud-team audience) with the attacker-bypass page (the blue-team / red-team / security-engineer audience).
• DKIM-Signature header anatomy — the BEC-FORENSIC-EVIDENCE-PER-MESSAGE- CRYPTOGRAPHIC-BINDING-LAYER companion to this BEC playbook. Where THIS page documents the SIX BEC variants (CEO fraud, invoice fraud, attorney impersonation, payroll diversion, gift- card scam, M&A fraud) and the organisational incident-response workflow the finance / treasury / fraud team follows once a BEC incident is reported, the DKIM-Signatures-explained spoke documents the FOUR PER-MESSAGE FORENSIC- EVIDENCE DIMENSIONS the BEC investigator extracts from the raw DKIM-Signature header of the offending message to attribute its true cryptographic-signing origin: (i) d= signing-domain attribution — the d= tag identifies the domain that cryptographically signed the message, which is the SINGLE MOST IMPORTANT BEC-forensic data point — a CEO-fraud message that produces dkim=pass with d=attacker-controlled.example (rather than the impersonated victim's d=) is the immediate cryptographic evidence that the message did NOT originate from the victim's signing infrastructure, even though the From: header was rewritten to appear so; (ii) s= selector publication trace — the s= selector sublabel identifies WHICH publication record under <s>._domainkey.<d> the BEC investigator queries to retrieve the public key the offending message was signed with, providing the cryptographic chain-of-custody back to the attacker's DNS publication infrastructure that the FBI Financial Fraud Kill Chain playbook references as Stage 3 evidence collection; (iii) h= signed-header-list scope — the h=From:Date:Subject:To:… tag enumerates which message headers the signature cryptographically commits to, letting the BEC investigator identify which header fields are guaranteed-original (per the signing engagement) vs which fields the attacker could rewrite in transit without invalidating the signature — critical forensic detail for invoice-fraud variants where wire-instructions in the body need to be verified against the signed body-hash; (iv) t= signature-timestamp + x= expiry chronology — the optional t= and x= tags give the BEC investigator a per-message chronological timestamp the signing infrastructure attests to, which is cross-referenced against email server logs and bank wire timestamps in the Stage 4 chronological-reconstruction phase of the FBI Financial Fraud Kill Chain incident-response workflow. Read the DKIM-Signatures-explained spoke WITH this BEC playbook when conducting a BEC-incident forensic investigation: the DKIM-Signature header on the offending message is the PRIMARY cryptographic-binding artifact the investigation parses to attribute the message to its true origin, and the per-tag byte-shape reference is the canonical operator-facing companion to any concrete BEC forensic-evidence- collection exercise.
• DKIM alignment with DMARC — the BEC-DEFENSE-DKIM-IDENTIFIER-ALIGNMENT- LAYER companion documenting the DKIM-side identifier-alignment computation (RFC 7489 §3.1.1, adkim=r vs adkim=s, the Public Suffix List organizational-domain extraction algorithm, the multiple-signature "any aligns wins" rule, the M365 onmicrosoft.com gotcha, the Workspace gappssmtp.com gotcha, the SPF-vs-DKIM asymmetry under forwarding, subdomain semantics edge cases) whose correct publisher-side deployment is the SINGLE most important technical defense against the direct-domain-spoofing BEC variants documented on THIS page. Where THIS page catalogues the SIX BEC variants (CEO fraud, invoice fraud, payroll diversion, attorney impersonation, data-theft variant, vendor-email-compromise — VEC) along with their financial-fraud outcomes and human- factor exploitation techniques, the DKIM- alignment-with-DMARC spoke is the TECHNICAL-CONTROL-LAYER companion documenting the precise byte-level d=-aligned signature contract that — when the publisher has deployed DKIM alignment correctly under p=reject — eliminates the direct-domain-spoofing class of BEC entirely at the receiver's DMARC filter, BEFORE the BEC content ever reaches a finance team member's inbox. The four-axis BEC-VARIANT-VS- DKIM-ALIGNMENT-DEFENSE comparison exposes the structurally-distinct DEFENSE-LAYER roles: (i) direct-domain CEO-fraud variants (attacker forges the From: as ceo@yourcompany.com) are eliminated entirely by a correctly-deployed DKIM-aligned p=reject — the attacker cannot produce a DKIM signature with the publisher's d= private key, so the message fails DKIM alignment at the receiver and is 5xx-refused at the MX- published host before reaching the recipient mailbox; (ii) direct-domain invoice- fraud variants (attacker forges the From: as billing@vendor.com) are eliminated by a correctly-deployed DKIM- aligned p=reject on the VENDOR's domain — note this requires the VENDOR (not the customer being defrauded) to publish DKIM-aligned p=reject; the DKIM-alignment-with-DMARC spoke documents how to verify-and-pressure-vendors on their DMARC posture as part of a vendor-management program; (iii) lookalike-domain BEC variants (attacker registers yourcornpany.com with rn-vs-m substitution and uses it as the From: domain) are NOT defended by DKIM alignment on the legitimate domain — the attacker's lookalike domain has its own DKIM keys and signs its own messages successfully; only mailbox-provider lookalike-domain warning systems (Gmail confusable-domain notice, Microsoft 365 Safe Sender heuristics) defend against this BEC variant; (iv) compromised-account BEC variants (attacker has stolen credentials for a legitimate ceo@yourcompany.com mailbox and sends from there) are NOT defended by DKIM alignment at all — the legitimate sending infrastructure signs the BEC content with the legitimate d= and the message passes DMARC alignment; only compromised-account-detection systems (anomalous-IP login alerts, MFA enforcement, impossible-travel signals) defend against this BEC variant; the DKIM-alignment-with- DMARC spoke documents the alignment-layer defense scope precisely so a BEC response plan can identify which variants need which controls. Read the DKIM-alignment-with-DMARC spoke when authoring the BEC-defense technical-control inventory: it documents WHICH BEC variants are eliminated by publisher-side DKIM-aligned p=reject, WHICH require receiver-side lookalike-detection, and WHICH require account-compromise-detection controls.
• DKIM for Microsoft 365 — the BEC-DEFENSE-M365-TENANT-DKIM- SELECTOR1-SELECTOR2-PUBLICATION-AS- PREREQUISITE-FOR-MEANINGFUL-DKIM- IDENTIFIER-ALIGNMENT-VERDICT companion reference. Where THIS page documents the six canonical BEC variants (CEO fraud, invoice fraud, attorney impersonation, vendor email compromise, data-theft pretexting, payroll-redirect) and the publisher-side DKIM-aligned p=reject DMARC enforcement that is THE PRIMARY TECHNICAL CONTROL eliminating direct-domain-spoofing BEC variants, the DKIM-for-Microsoft-365 spoke documents the M365-tenant-specific DKIM enablement that is the LOAD-BEARING DKIM-half publisher-side prerequisite for that defense. The CONNECTION is that the DKIM-half of the DKIM-aligned- p=reject BEC-defense depends on the M365 tenant publishing the selector1._domainkey + selector2._domainkey CNAME chains AND enabling the DKIM toggle in the Defender portal — without M365-tenant DKIM enablement, outbound Exchange Online mail is signed ONLY by the onmicrosoft.com-domain default key whose d=<tenant>.onmicrosoft.com does NOT align with the From:<your-domain> header field — producing dkim=pass aligned=false aggregate-report rows that fail the DMARC alignment check. For a finance/legal/payroll team hosted on M365 (the typical BEC target profile), the BEC-defense posture REQUIRES the M365-tenant-specific DKIM enablement documented on the DKIM-for-Microsoft-365 spoke as the DKIM-half publisher-side prerequisite for any meaningful p=reject + DKIM-aligned DMARC verdict that rejects direct- domain-spoofing BEC attempts at receiver-side. Read the spoke as the FIRST step in the BEC-defense deployment checklist for any M365- hosted organisation — the spoke's CNAME publication mechanics, Defender- portal enable toggle, and dual-selector rotation discipline are the load-bearing prerequisites for every downstream DMARC-aligned BEC defense documented on THIS page.
• Email spoofing — the protocol-level technique deep dive on the seven-mechanism spoofing surface area BEC attackers most frequently weaponise against the visible From: header. Where this BEC page covers the financial-fraud outcome and the six BEC variants, the email-spoofing page covers the technique mechanics in detail: direct- domain spoofing (RFC 5322 From: forgery), display-name spoofing (Reply-To / Display-Name mismatch attacks), lookalike-domain attacks (Punycode / IDN homographs / typo-squatting), Reply-To injection, envelope-MAIL-FROM forgery, and the Received-chain anomalies an analyst sees when investigating a suspected BEC delivery attempt. Pair this BEC page (the outcome / financial-loss view) with the spoofing page (the protocol-level technique view) for the complete attack-mechanic-to-outcome chain.
• Reverse DNS / PTR records for mail servers — the INCIDENT-RESPONSE-FORENSIC-LOOKUP companion documenting the IN-ADDR.ARPA / IP6.ARPA reverse-zone PTR record reference whose FCrDNS (Forward-Confirmed reverse DNS) verification is the FIRST-TRIAGE step every BEC incident-response runbook performs on the suspected attacker-IP captured from the suspicious message's Received-chain. Where THIS page documents the BEC financial-fraud outcome and the six BEC variants (CEO fraud, invoice fraud, payroll diversion, attorney impersonation, data-theft variant, vendor-email-compromise — VEC), the reverse- DNS-PTR spoke is the INCIDENT-RESPONSE FORENSIC-LOOKUP companion documenting how an analyst extracts the suspected attacker- IP from the Received-chain header and runs the canonical PTR/FCrDNS query to characterise the attacker's infrastructure. The four-axis BEC-INCIDENT-RESPONSE-VS- FCrDNS-FORENSIC comparison exposes the structurally-distinct INCIDENT-RESPONSE roles: (i) extract the Received: from <HELO-name> ([<connecting-IP>]) from the suspicious BEC message's Received-chain — every BEC analyst starts here; the connecting-IP is the IP-IDENTITY-LAYER artefact the FCrDNS lookup verifies; (ii) run the PTR lookup against the connecting-IP (dig -x <ip> or nslookup <ip>) — the response either returns the attacker-claimed HELO-name (FCrDNS-aligned, suggesting a compromised-legitimate-account BEC variant — Valid Accounts T1078 per MITRE ATT&CK), returns a generic ISP/hosting-provider PTR (FCrDNS-misaligned, suggesting a spoofed-source BEC variant), or returns NXDOMAIN (no-PTR-published, suggesting attacker-controlled infrastructure on a zone the attacker cannot author PTR records on); (iii) cross-reference the FCrDNS posture against the message's DKIM-d= and SPF-envelope-domain for incident-classification — the BEC variant taxonomy (compromised vs spoofed vs lookalike) is partially identifiable from the FCrDNS-vs-message-identity-layer cross-tabulation; (iv) BEC forensic timeline reconstruction relies on FCrDNS data from third-party threat- intelligence feeds (Censys, Shodan, VirusTotal Passive DNS) for historical attacker-IP-to-PTR association — the attacker may have rotated IPs but the PTR-record history at threat-intel providers retains the forensic record analysts need for the incident-response report. Read the reverse-DNS-PTR spoke when authoring the BEC incident-response runbook: this page documents the BEC threat-landscape and financial-impact, the PTR spoke documents the IP-identity-layer forensic-lookup primitive every BEC investigator runs as one of the FIRST triage steps.
• DMARC myths and misconceptions debunked — corrects the "DMARC stops BEC" myth and 17 other common mental-model errors with RFC 7489 evidence and receiver behaviour. Pair with this BEC page for the full picture: myths corrects what defenders mistakenly believe DMARC blocks; this page documents the BEC threat landscape DMARC is one layer of defense within.
• DMARC policy rollout playbook — the phased rollout that takes a domain from Week 0 p=none to Week 12+ p=reject. Reaching p=reject is the prerequisite for blocking the single BEC variant DMARC addresses (direct- domain spoofing); domains stuck at p=none for years have zero direct-spoof BEC protection.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the BEC-DIRECT-DOMAIN-SPOOFING-DEFENSE-IS- GATED-ON-TERMINAL-DMARC-POLICY-MODE-STATE companion to this Business Email Compromise threat-landscape reference. Where THIS page documents the six canonical BEC variants (CEO fraud / invoice fraud / payroll diversion / gift-card scam / M&A fraud / VEC) and the single BEC variant DMARC addresses (direct-domain spoofing), the DMARC-policy-modes spoke documents the UPSTREAM three-state DMARC-enforcement policy-mode ladder whose terminal-state choice at the publisher's apex DMARC TXT record is the LOAD-BEARING UPSTREAM PRECONDITION every per-receiver per-message BEC-direct-domain-spoofing-defense outcome THIS page documents structurally depends on. The PER-DMARC-POLICY-MODE-VS-BEC-DEFENSE- EFFICACY cross-reference establishes FOUR structurally-distinct per-policy-mode-to- BEC-defense-outcome coupling dimensions: (i) p=none as canonical ZERO-BEC-DIRECT-DOMAIN-SPOOFING-DEFENSE policy-mode state at every receiver — under p=none publication, the receiver-side per-message DMARC evaluation returns policy_evaluated/disposition= none for every BEC-direct-domain- spoofing attempt against the publisher's From-domain; the BEC-direct-domain-spoofing message is delivered to the recipient's inbox with the impersonated From-domain intact — ZERO BEC-defense efficacy; the DMARC-policy-modes spoke documents p=none as the OBSERVATION-ONLY policy-mode whose publication produces ZERO per-message BEC-direct-domain-spoofing- defense efficacy at every receiver — the canonical defect class operators must advance OUT OF before any BEC-direct-domain- spoofing-defense outcome materialises; (ii) p=quarantine; pct=10 through pct=100 as PARTIAL- COVERAGE-RAMP BEC-defense efficacy with the per-percentage-coverage-vs-defense-efficacy linear relationship — under p=quarantine; pct=10, the receiver-side per-message DMARC evaluation returns policy_evaluated/disposition= quarantine for 10% of BEC-direct- domain-spoofing attempts (the remaining 90% evaluate to policy_evaluated/disposition =none per RFC 7489 §6.6.4 pct= semantics) — producing 10% BEC-defense efficacy; the per-percentage-coverage rate scales linearly through the ramp until pct=100 produces 100%-coverage per-receiver BEC-direct-domain-spoofing- attempt diversion to Junk / Spam / Quarantine; the DMARC-policy-modes spoke documents the pct=-tag per-percentage-coverage semantics whose per-percentage-coverage rate is the canonical BEC-defense-efficacy scaling dimension during the policy-mode ramp; (iii) p=reject; pct=100 as CANONICAL TERMINAL-STATE 100%-COVERAGE BEC-DIRECT-DOMAIN-SPOOFING-DEFENSE policy- mode state — under p=reject; pct=100, the receiver-side per-message DMARC evaluation returns policy_evaluated/disposition=reject for 100% of BEC-direct-domain-spoofing attempts at every receiver implementing DMARC-aligned receiver-side enforcement; the BEC-direct-domain-spoofing message is rejected at SMTP-time with 5xx receiver- side rejection — the canonical TERMINAL- STATE BEC-defense posture this page's BEC- defense-in-depth-stack documents as the load-bearing first-layer defense; the DMARC-policy-modes spoke documents p=reject; pct=100 as the canonical TERMINAL-STATE author-domain enforcement-posture whose publication is the load-bearing upstream BEC-direct-domain- spoofing-defense prerequisite; (iv) sp= subdomain-policy-mode tag-value as load-bearing per-subdomain- emitting-mail BEC-defense coordination prerequisite — BEC attackers targeting publisher's subdomains (e.g., billing.<publisher>, finance.<publisher>, ceo.<publisher>) bypass an apex-only p=reject posture when the publisher publishes sp=none at the apex — the per-subdomain enforcement posture inherits from sp= rather than p= per RFC 7489 §6.3; publishers with p=reject; sp=none are VULNERABLE to per-subdomain BEC-direct-domain- spoofing attempts at every legitimate-but- non-mail-emitting subdomain in the publisher's DNS zone — a canonical BEC-defense defect class; the DMARC-policy-modes spoke documents the sp= subdomain-policy-mode coordination tag-value semantics whose per- subdomain enforcement posture is the load- bearing per-subdomain BEC-defense coordination prerequisite. Read THIS Business Email Compromise threat-landscape reference WITH the DMARC-policy-modes spoke when the per- publisher BEC-direct-domain-spoofing-defense posture audit step arrives: the BEC page documents the SIX BEC VARIANTS + the SINGLE BEC VARIANT DMARC ADDRESSES, the DMARC- policy-modes spoke documents the THREE-STATE AUTHOR-DOMAIN ENFORCEMENT-POLICY-MODE LADDER whose terminal-state choice at the publisher's apex DMARC TXT record is the upstream precondition every per-receiver per-message BEC-direct-domain-spoofing-defense outcome structurally depends on.
• DMARC for transactional email — covers ESP / transactional-mail authentication setup; BEC is referenced as the threat justifying DMARC enforcement on the organisation's transactional sender domains.
• DMARC for Microsoft 365 — the M365 deployment guide. Includes Defender Anti-Impersonation, mail-flow-rule monitoring (T1114.003 disruption), and Conditional Access policy hardening for the compromised-account BEC variant.
• DMARC for Google Workspace — the Workspace deployment guide. Includes Advanced Phishing Protection settings, login audit monitoring, and Google Vault evidence preservation for BEC incident response.
• SPF for Google Workspace — the WORKSPACE-BEC-EXACT-DOMAIN-SPOOFING-PREREQUISITE authoring companion to this BEC threat- model reference. Where THIS page documents the BEC THREAT LANDSCAPE (the seven canonical BEC variants — CEO fraud, vendor-invoice fraud, payroll-redirect, attorney impersonation, W-2 / data theft, gift-card fraud, account-compromise BEC — and the cumulative FBI IC3 $50B+ 2013-2022 financial-loss data that quantifies the threat), the SPF-for-Workspace spoke is the Workspace-tenant-SPECIFIC SPF- AUTHORING reference that determines whether the Workspace tenant's DMARC posture can block the single BEC variant DMARC addresses: EXACT-DOMAIN SPOOFING (the attacker forges the From: header to claim the protected organisational domain). DMARC can ONLY block exact-domain spoofing when the receiver evaluates the DMARC record as p=reject AND the attacker's mail FAILS both SPF-alignment and DKIM-alignment evaluation — and the SPF-alignment evaluation depends entirely on the Workspace tenant's SPF record AUTHORING choices documented in the spoke: the load-bearing include:_spf.google.com baseline coverage envelope (without which Workspace-tenant legitimate mail produces SPF=fail and forces the Workspace operator to publish ?all or stay at p=none indefinitely — both of which leave direct-domain BEC fully exploitable), the secondary-SaaS-sender include population completeness (every missing third-party sender token produces a legitimate-but- SPF=fail row that pressures the operator toward weakening the SPF or DMARC record), the on-prem-hybrid co-existence explicit-IP enumeration completeness, and the ~all-vs--all qualifier choice that determines whether the SPF anti-spoofing guarantee is enforced or merely advisory. Read the SPF-for- Workspace spoke when the BEC threat-model case is being made for a Workspace-tenant organisation — the spoke is the authoritative per-platform SPF-AUTHORING PREREQUISITE reference that determines whether the Workspace tenant can ever reach the p=reject DMARC posture that closes the EXACT-DOMAIN-SPOOFING BEC attack surface this page documents.
• DMARC for SaaS senders — the multi-tenant SaaS sender deployment guide. Relevant to invoice-fraud / VEC because ESP / SaaS-sender compromise is a recurring attack vector against vendor mail flows.
• DMARC for cPanel & shared hosting (SMB BEC-defender procedure) — the SMB-DEFENDER OPERATIONAL PROCEDURE for the BEC threat model this page documents. Where this page is the THREAT- MODEL reference for the seven canonical BEC attack patterns (CEO fraud, invoice fraud, attorney impersonation, vendor email compromise, payroll diversion, gift card scam, data-theft variant), the cPanel deployment guide is the SMB-specific defender procedure for the small-and-mid- size-business attack surface BEC attackers disproportionately target. The commercially-honest reality of the SMB cohort is that shared-hosting cPanel domains (Bluehost, HostGator, SiteGround, A2 Hosting, GoDaddy cPanel, Namecheap Stellar Plus, Hostinger, InMotion, DreamHost cPanel) are SYSTEMATICALLY less protected against direct-spoof BEC than their enterprise M365 / Workspace counterparts: (i) cPanel does NOT auto-generate a DMARC record at account creation (it auto-generates only SPF + DKIM-default selector), so the typical SMB domain on shared hosting ships with NO DMARC published — leaving the apex From: wide open to exact-domain spoofing of the CEO/CFO/legal/HR mailbox, (ii) SMB operators frequently lack DNS-edit access (registrar-managed DNS routed through the host's branded interface) or the operational headcount to monitor the rua/ruf aggregate-report feedback loop that the cPanel guide documents, (iii) shared outbound IPs mean a single tenant's compromised account on the same Exim signer can spoof the apex From: of every other tenant via the default._domainkey shared signer key — the canonical cross-tenant-on-same-signer attack vector distinct from the per-tenant signer isolation of M365 / Workspace, (iv) SMB attackers (BEC ring operators) explicitly target shared-hosting cPanel SMB domains as the lowest-cost-to-attack cohort — attack-economic asymmetry well-documented in the FBI IC3 BEC reporting. The cPanel guide documents the SMB-realistic defender procedure that closes these gaps: publishing _dmarc.<domain> at p=none via the cPanel Zone Editor (or the upstream registrar's equivalent), the seven-step ramp through p=quarantine to p=reject, the SMB-realistic rua/ruf monitoring procedure (DMARC Analyzer's free tier, or a managed service for sub-$1k annual budgets), the provider-managed SPF include verification, and the WHM-administrator-only DKIM rotation procedure for the default selector when a cross-tenant compromise is suspected. Pair this page (the BEC threat model and the seven attack-pattern taxonomy) with the cPanel guide (the SMB-realistic defender operational procedure on the shared-hosting attack surface this threat model disproportionately exploits) when advising SMB clients on BEC defence.
• DMARC for shared hosting — the BUSINESS-EMAIL-COMPROMISE-FROM- SHARED-HOSTING-TENANT-ACCOUNT-TAKEOVER- VIA-CPANEL-PASSWORD-COMPROMISE-WITH- CROSS-TENANT-LATERAL-MOVEMENT-AND- NEIGHBOR-DOMAIN-IMPERSONATION companion to the cPanel-specific guide above. Where the cPanel guide above is the cPanel-SHARED-HOSTING-SUBSET defender procedure, the shared-hosting spoke is the FULL-CONTROL-PANEL-SURFACE companion documenting the structurally-distinct BEC threat model that applies to ALL FOUR major shared-hosting control panels (cPanel, Plesk, DirectAdmin, ISPConfig) as a cohort, framing the attack economics from the SHARED-INFRASTRUCTURE perspective: (i) Plesk-tenant account takeover via Plesk admin password reuse — Plesk's "Customer" / "Reseller" / "Service Plan" access hierarchy means a single compromised Plesk customer credential unlocks send capability for ALL hosted domains under that customer's subscription, producing a higher-impact BEC lateral-movement radius than cPanel's per-account isolation; (ii) DirectAdmin-tenant cross- user spoofing via shared Exim signer — DirectAdmin's default Exim configuration uses a single server-wide DKIM signer just like cPanel's default._domainkey pattern, producing the same cross-tenant- on-same-signer attack surface where one compromised tenant's outbound mail can spoof the apex From: of any neighbor domain hosted on the same DirectAdmin server; (iii) ISPConfig-tenant cross-server-DKIM exposure via Mailman / Roundcube / Squirrelmail web mail client — ISPConfig's bundled web mail clients expose the per-tenant IMAP/SMTP credentials to credential- harvesting phishing kits targeting ISPConfig-branded login pages, producing a higher-yield credential- capture rate than cPanel's branded Webmail login; (iv) cross-control-panel neighbor-domain impersonation via registrar-managed DNS — SMB tenants on ALL four shared-hosting platforms typically route DNS through the upstream registrar's web-UI rather than the control panel's Zone Editor, producing a credential-attack surface DISTINCT from the control-panel admin UI — registrar password compromise unlocks the ability to publish a permissive SPF / blank DMARC record on any tenant's domain, opening EXACT- DOMAIN-SPOOFING BEC without requiring control-panel access. The shared-hosting spoke documents the FOUR-CONTROL-PANEL comparative defender procedure: the per-platform DMARC publication wizard (cPanel Zone Editor, Plesk DNS Settings, DirectAdmin DNS Management, ISPConfig DNS Records → TXT), the per-platform DKIM rotation cookbook on cross-tenant- compromise suspicion, the per-platform rua/ruf aggregate-report ingestion pipeline (DMARC Analyzer free tier accommodates all four), the per-platform WHM/admin-only DKIM key rotation bulk-operation procedures for incident response, and the per-platform attack- surface differential audit operators use to determine BEC-defender investment priority across mixed-control-panel fleets. Pair this page (the BEC threat model and seven attack-pattern taxonomy) with the shared-hosting spoke (the FOUR-CONTROL-PANEL defender procedure for the full shared-infrastructure attack surface) when advising SMB clients whose domain inventory spans multiple control panels — the spoke is the cPanel-guide's structural superset for the persona that owns a heterogeneous shared-hosting estate.
• DKIM replay attacks — the orthogonal threat class against DKIM signatures that BEC attackers occasionally weaponise to amplify lookalike-domain campaigns; pair for the complete authentication-layer attack picture.
• Phishing protection — the broader phishing-defense playbook covering the technique side of the threat continuum. BEC is the finance-loss outcome class; phishing is the technique class that enables it. Pair this BEC page (the outcome / financial-loss audience) with the phishing-protection page (the defender / control-design audience) for the full attack-and-defense picture across recon, lure-design, credential harvesting, MFA-bypass tooling, post- compromise mail-flow tampering, and the layered controls (email authentication + SEG + URL rewriting + attachment sandboxing + identity-side MFA-resistant authentication + user training) that close each phase.
• MTA-STS vs DANE for SMTP — the BEC-DEFENSE-TRANSPORT-LAYER- ENFORCEMENT-CHOICE companion to this BEC playbook. Where THIS page documents the six BEC variants (CEO fraud, invoice fraud, attorney impersonation, payroll diversion, data-theft variant, vendor- email-compromise / VEC) and the layered organisational incident-response workflow, the MTA-STS-vs-DANE spoke is the TRANSPORT-LAYER-ENFORCEMENT-CHOICE decision-tree companion documenting the head-to-head DNSSEC-anchored-DANE vs HTTPS-PKI-anchored-MTA-STS technology decision whose answer determines which transport-layer enforcement technology (or both) the BEC-defending organisation deploys to defend against the BEC- variants whose ATTACK INFRASTRUCTURE exploits the SMTP transport hop. Four BEC-VARIANT-VS-TRANSPORT-LAYER-DEFENSE cross-correlation dimensions the spoke documents: (i) vendor-email- compromise (VEC) MX-substitution defense — sophisticated VEC attackers positioned at network or DNS choke points can inject forged MX records pointing at attacker-controlled phishing relay infrastructure to intercept vendor-to-customer mail and substitute fraudulent wire-transfer instructions; the spoke documents how DANE-TLSA records (when supported by both sender and receiver) STRUCTURALLY ELIMINATE the MX-substitution variant by requiring the forged MX to ALSO publish a DNSSEC-signed TLSA record matching the attacker's certificate — an attacker who can substitute the MX record cannot simultaneously substitute the DNSSEC-signed TLSA record without compromising the DNSSEC ZSK/KSK chain; (ii) invoice-fraud STARTTLS- stripping defense — invoice- fraud variants in which the attacker positioned at the network layer strips the 250 STARTTLS capability advertisement to force plaintext SMTP for in-transit message modification (substituting attacker bank-account-number bytes in the body before delivery) are STRUCTURALLY ELIMINATED by both DANE-TLSA-publishing and MTA-STS-enforce-publishing receivers because sender MTAs implementing either technology REFUSE to fall back to plaintext when a TLSA record exists or the MTA-STS policy forbids it — the spoke documents the per-technology coverage matrix that determines which BEC-defending organisations need DANE, MTA-STS, or both to close the specific STARTTLS- stripping invoice-fraud vector for their per-organisation receiver population; (iii) per-counterparty transport-security-readiness assessment for high-value-vendor BEC-protection program — the spoke documents the per-counterparty assessment methodology that the BEC-defending organisation uses to inventory which high-value-vendor counterparties are themselves DANE-publishing or MTA-STS- publishing, informing the BEC-defense program's per-counterparty risk-tier classification (counterparties with no transport-security publication get elevated risk-tier classification because the SMTP transport hop is attacker-modifiable); (iv) DNSSEC-readiness assessment for the BEC-defending organisation's own transport-security publication — the spoke documents the per-domain DNSSEC-readiness assessment that determines whether the BEC-defending organisation can deploy DANE (DNSSEC- signed zones required) vs needs to adopt MTA-STS (no DNSSEC dependency) as the transport-security technology for their OWN outbound mail-stream's protection against the VEC and invoice-fraud variants that exploit the BEC-defending organisation's own transport hop. Pair this BEC playbook with the MTA-STS-vs-DANE spoke when scoping the transport-layer-defense component of the BEC-defense program — the spoke is the canonical decision- reference whose answer determines which transport-layer enforcement technology closes the MX-substitution and STARTTLS-stripping attack vectors that the VEC and invoice-fraud BEC variants exploit at the SMTP transport hop.
• DMARC for Hybrid Exchange (on-prem + M365) — the BEC-HYBRID-TOPOLOGY-DUAL-RECEIVE- PATH-DEFENSE-VS-COMPROMISED-LEGITIMATE- ACCOUNT-AND-VENDOR-EMAIL-COMPROMISE-AT- EITHER-RECEIVE-PATH companion reference. Where THIS page covers the BEC financial- fraud outcome and the six BEC variants (CEO fraud, invoice fraud, payroll diversion, attorney impersonation, data-theft variant, vendor-email- compromise / VEC) plus the layered BEC-defense control stack (anti- impersonation rules, finance-process verification, dual-control disbursement, SEG anti-BEC modules), the DMARC-for- Hybrid-Exchange spoke documents the canonical TOPOLOGY-LEVEL BEC-attack- surface that hybrid Exchange + EOP coexistence produces and that BEC-defense controls MUST coordinate across: (i) Hybrid topology creates TWO receive paths — EOP-inbound MX (contoso-com.mail.protection.outlook.com) AND on-prem-inbound MX (mail.contoso.com) — both carrying authenticated mail to the organisation's protected domain; a BEC-defense posture tightened ONLY at the EOP-inbound path leaves the on-prem- inbound path open to attacker-injected BEC pattern mail; (ii) Compromised- legitimate-account BEC (T1078 Valid Accounts) on a hybrid mailbox produces BEC pattern mail egressing via either the EOP-outbound connector OR the on-prem Edge Transport role — the finance-team / treasury BEC-defense protocol must verify mail through BOTH egress paths (the suspect's mailbox might be on the cloud half OR the on-prem half of the hybrid topology); (iii) Vendor Email Compromise (VEC) sender on a partner organisation's hybrid topology shows up in the receiver's RUA with TWO source_ip rows — partner-EOP- outbound IP AND partner-on-prem-Edge IP — both flagged for finance- team verification when the VEC partner is on hybrid; (iv) Hybrid- Exchange topology's transport-rule coexistence model can MASK BEC-pattern mail at the cross-boundary forwarding point — a transport rule that rewrites attacker-injected Reply-To or modifies the envelope-MAIL-FROM at the hybrid coexistence boundary can hide a BEC-pattern message from receiver-side DMARC enforcement. Read the DMARC-for- Hybrid-Exchange spoke alongside this BEC defense reference when the protected organisation OR a VEC-vendor partner is on a hybrid Exchange topology — the dual-receive-path and dual-egress-path BEC-attack-surface produced by hybrid coexistence requires coordinated BEC defense across BOTH paths, not just the EOP path.
• Email authentication ecosystem (SPF, DKIM, DMARC, ARC, BIMI) — the cluster-intro pillar above the per- standard pillars. Read first if SPF, DKIM, DMARC, ARC, and BIMI are not already familiar; this BEC page assumes the reader understands the email-authentication vocabulary.
• BIMI Verified Mark Certificates (VMC / CMC) — the supply-chain trust-anchor reference for the brand-identity binding that raises the bar for BEC attackers. Where THIS page documents the six BEC variants (CEO fraud, invoice fraud, payroll diversion, gift-card scam, M&A fraud, Vendor Email Compromise) and the financial-loss outcomes (FBI IC3 BEC losses USD 2.9B in 2023 alone), the BIMI certificates spoke documents an upstream trust-anchor control that BEC attackers structurally CANNOT forge: the Verified Mark Certificate (VMC) is issued ONLY by qualified CAs (DigiCert, Entrust) after verifying corporate-identity binding with a relevant IP office (USPTO, EUIPO, UKIPO, JPO) trademark registration, making BIMI a meaningful supply-chain defense layer for VEC attacks where the attacker controls a lookalike or compromised vendor domain. A BEC attacker impersonating a vendor cannot mint a VMC for the vendor's brand without breaking the CA's trademark verification, so the recipient mailbox does not render the recognised brand logo for the attacker-sent message — a signal alert finance / treasury staff can train on as part of BEC-prevention awareness programs. Read this when designing the BRAND-VERIFICATION layer of an anti-BEC control suite: BIMI VMC is one of the few email-layer controls that the verifying CA actively gatekeeps against criminal supply-chain abuse, and it integrates with DMARC enforcement documented on this page (BIMI logos render only after the message passes DMARC at quarantine or reject).
• BIMI SVG Tiny Portable / Secure profile requirements — the BIMI logo-file format reference for the recognisable-brand-visual signal that BEC attackers cannot reproduce in the recipient mailbox. Where the BIMI certificates spoke above covers the certificate-side supply-chain trust-anchor, the BIMI SVG-requirements spoke covers the FILE-format constraints that ensure the recognised brand logo renders consistently across every BIMI-honoring mailbox provider. The format is SVG Tiny 1.2 Portable / Secure (SVG-T-P/S): no scripts, no external references, no animation, no JavaScript event handlers, fixed viewBox square aspect (1:1), file size capped at 32 KB post-optimisation, and a per-element whitelist that excludes <script> / <foreignObject> / external-href <use> references. The format constraint matters for BEC defense because the recognised brand logo is a TRAINABLE VISUAL SIGNAL for finance / treasury staff: when a purchase-order request arrives "from Vendor X" but the recipient mailbox does NOT render Vendor X's familiar logo (because the lookalike or compromised domain cannot present a matching VMC + SVG pair), that absence is a trainable BEC red-flag indicator. Read this when building staff-training materials for BEC prevention: brand-visual-absence training relies on consistent cross-provider rendering, which the SVG-T-P/S constraints enforce structurally.
• Email security glossary — defines BEC, CEO fraud, invoice fraud, VEC, smishing, vishing, whaling, spear phishing, and ~70 other threat-vocabulary terms with cross-references into this page and the attacker-bypass page.
• DMARC Analyzer dashboard — ingests DMARC aggregate (RUA) and forensic (RUF) reports via includes/DmarcParser.php and includes/ForensicReportParser.php, rendering the per-sender / per-IP / per-day breakdown that surfaces direct-spoof BEC delivery attempts at p=reject.
• SPF mechanisms explained — the ATTACKER-SIDE-SPF-MECHANISM-MISUSE- AND-DEFENDER-CATALOGUE companion to this BEC defensive reference. Where THIS page documents the BEC threat surface (CEO impersonation, vendor-payment redirection, wire-fraud, gift-card scams, payroll diversion, W-2 phishing) and the DMARC- anchored defensive playbook, the SPF- mechanisms-explained spoke is the PER- MECHANISM BYTE-GRAMMAR REFERENCE documenting the eight RFC 7208 §5 primitives whose per-mechanism MISUSE is the canonical BEC-attacker-side exploit surface. The ATTACKER-SIDE- SPF-MECHANISM-MISUSE-CATALOGUE cross- reference establishes FIVE structurally- distinct per-mechanism BEC-relevant misuse-or-discipline patterns: (i) over-permissive +all qualifier on the protected domain's SPF record — the SPF-mechanisms spoke documents how publishing +all (Pass — all IPs authorised) creates an UNCONDITIONAL SPF-pass that lets ANY attacker-controlled IP origin the protected domain's SPF leg, bypassing the SPF half of the DMARC evaluation entirely; canonical BEC attackers fingerprint targets for +all presence and prioritise those domains for direct-domain-spoofing BEC campaigns; (ii) cousin- domain attacker publishes their own permissive SPF — when the attacker registers a typosquat (acrne.com for acme.com) the cousin- domain's SPF record authorises the attacker's outbound IPs, producing a legitimate spf=pass verdict at the receiver for the cousin-domain BEC message — the SPF-mechanisms spoke documents how ip4: literal- IP mechanisms on the cousin-domain sidestep the protected-domain's DMARC evaluation entirely because the cousin is a DIFFERENT organisational domain; (iii) deprecated ptr: mechanism on legacy protected-domain SPF records — the SPF-mechanisms spoke documents the RFC 7208 §5.5 deprecation; protected-domain legacy SPF records carrying ptr: produce permerror bursts in the RUA stream that mask the actual BEC-attempt-detection signal a defender relies on; (iv) compromised- vendor supply-chain attack via the vendor's include: cascade — the SPF-mechanisms spoke documents the include: cross-domain dependency mechanism; attackers who compromise a vendor's outbound mail infrastructure (a shared ESP relay tenant, a compromised marketing-automation platform account) can authorise their own attacker- controlled IPs through the vendor's SPF record, which the protected domain has authorised via include: — the result is BEC messages from the attacker's IPs producing spf=pass aligned=false rows in the protected domain's RUA stream; (v) defender-side discipline of pairing p=reject with -all — the SPF-mechanisms spoke documents the canonical guidance to PAIR a fully- enforced DMARC posture (p=reject) with the strict -all terminating qualifier for full BEC-blocking commitment; publishing p=reject with ~all is the most common defender-side mistake the SPF-mechanisms spoke catalogues — it leaves receivers authorised to soft-fail rather than hard-fail the BEC delivery attempt. Pair this page (the BEC defensive playbook reference) with the SPF- mechanisms spoke (the per-mechanism byte-grammar attacker-misuse and defender-discipline catalogue) when authoring a BEC-hardening posture review — the spoke documents the per- mechanism exploit surface every BEC- prevention review must close.
• SPF qualifiers explained — the BEC-DEFENSE-VIA-HARDFAIL-SPF- QUALIFIER-AS-RECEIVER-AUTHORISED- SMTP-REJECTION-OPERATIONAL-LEVER companion reference. Where THIS page documents the BEC threat surface (CEO impersonation, vendor-payment redirection, wire-fraud, gift-card scams, payroll diversion, W-2 phishing) and the DMARC-anchored defensive playbook (p=reject + DKIM-PRIMARY alignment + homograph-domain registration + executive-team trained reporting), the SPF-qualifiers spoke documents the FOUR QUALIFIER PREFIXES (+ Pass / - Fail / ~ SoftFail / ? Neutral) whose VALUE- CHOICE on the all mechanism is the OPERATIONAL LEVER the BEC-defense playbook tunes. An attacker mounting a direct-domain BEC spoof against a protected domain published with ~all wins inbox delivery at most receivers (Gmail, Microsoft 365, Yahoo) when DMARC is still at p=none during the enforcement-ramp window, because the SoftFail signal is conventionally treated as monitoring-mode and receivers do not act on it at SMTP time. The -all qualifier gives receivers explicit AUTHORITY TO REJECT at the SMTP layer per RFC 7208 §4.7 — even before DMARC evaluation runs against the alignment disjunction — closing the inbox-delivery window the BEC attacker exploits during the DMARC-rollout monitoring period before p=reject is active. Read the qualifier spoke alongside this page when authoring the BEC-defense operational playbook — the ~all → -all tightening is the SPF-layer hardening step the BEC- defense posture requires to deny attackers the softfail-bypass operating below the DMARC layer.
• DMARC forensic reports (RUF) — the BEC-INCIDENT-RESPONSE-PER-MESSAGE- AFRF-ENVELOPE-EVIDENCE-STREAM companion to this BEC-defense reference. Where THIS page catalogues the SIX BEC variants (CEO fraud, invoice fraud, payroll diversion, attorney impersonation, data-theft variant, vendor- email-compromise) with their financial-fraud outcomes and the technical-control inventory defending against each variant, the DMARC forensic-reports (RUF) spoke documents the per-message EVIDENCE STREAM that surfaces the OFFENDING BEC message's complete bytes the SIRT (Security Incident Response Team) triage workflow needs for forensic reconstruction, criminal-prosecution evidence preservation, and Financial Fraud Kill Chain activation. The RUF stream is load-bearing during BEC incident response for three distinct evidence-gathering purposes: (i) FORENSIC RECONSTRUCTION of the attacker's exact From: / Reply-To: / Return-Path: header forgery pattern — the AFRF envelope's embedded message/rfc822 part preserves the BYTES of the forged headers EXACTLY as the receiver's filter saw them, eliminating any ambiguity about whether the attacker used From: "CEO Name" <ceo@yourcornpany.com> (rn-vs-m lookalike), From: "CEO Name" <ceo@yourcompany-corp.com> (suffix-extension lookalike), From: "CEO Name" <attacker@gmail.com> (free-mailbox display-name impersonation), or a compromised-account variant signed by the legitimate d=yourcompany.com DKIM key — each variant triggers a STRUCTURALLY DIFFERENT incident-response response plan (vendor-lookalike-domain UDRP filing vs domain-takedown coordination vs free-mailbox provider abuse-report vs compromised-account forensics + credential rotation); (ii) CRIMINAL-PROSECUTION EVIDENCE PRESERVATION under 18 U.S.C. §1343 (wire fraud) — the RUF envelope is admissible as evidence under Federal Rules of Evidence Rule 902(13)-(14) (electronically-generated records authenticated by hash / certification), and FBI IC3 investigators / federal prosecutors REQUIRE the offending message's complete bytes (not just metadata) to charge wire fraud — the RUF stream is often the ONLY preserved copy of the offending bytes after a finance team member has already deleted the message from their inbox; (iii) FINANCIAL FRAUD KILL CHAIN ACTIVATION at recipient-bank level — the RUF envelope's Source-IP header attributes the BEC traffic to a specific IP-routing origin that the SIRT can correlate with threat-intelligence indicators (known BEC infrastructure, residential-proxy IP cohorts, compromised-mailbox-provider IP ranges) accelerating the 72-hour Financial Fraud Kill Chain window during which recipient-bank clawback is operationally achievable. Read the DMARC forensic-reports spoke when authoring the BEC incident- response playbook — the ruf=mailto:dmarc-forensic@… tag publication, the fo=1 failure-reporting-options posture (emit on ANY mechanism failure, surfacing the maximum evidence-volume for BEC reconstruction), the still-active forensic receivers (Yahoo / AOL / Mail.ru — Microsoft and Gmail DEPRECATED RUF emission years ago, which means BEC messages delivered to M365 / Gmail recipients do NOT generate RUF and the SIRT must rely on RUF from Yahoo / AOL recipients to reconstruct the offending bytes), and the GDPR Art 28 processor- agreement scrutiny governing operator-side ingestion of RUF envelopes containing third-party PII in the embedded message/rfc822 part — load-bearing for SIRTs handling BEC incidents involving European recipient mailboxes.
• DMARC monitoring & reporting analysis — the BEC-DETECTION-AS-MONITORING-DASHBOARD- CONTROL-LAYER companion to this BEC-defense reference. Where THIS page catalogues the six FBI IC3 BEC variants (CEO fraud, invoice fraud, payroll diversion, attorney impersonation, data-theft, vendor-email- compromise) with their financial-fraud outcomes and the publisher-side technical controls (DMARC at p=reject, SPF hardfail, DKIM alignment) that structurally defeat each variant, the DMARC-monitoring spoke documents the OPERATIONAL-DETECTION layer that converts the aggregate-report data the protection controls produce into BEC-attack-in-progress signals during the 72-hour Financial Fraud Kill Chain window when recipient-bank clawback is still operationally achievable. The BEC-DETECTION-AS-MONITORING-DASHBOARD- CONTROL-LAYER cross-reference establishes FOUR structurally-distinct BEC-variant-to- monitoring-KPI-signal-mapping dimensions: (i) volume-based-compromise-signal- KPI-as-VEC-and-vendor-email-compromise- sender-cohort-detection dimension — the monitoring page's "volume-based compromise signals" KPI tracks the per- source-IP per-day-bucket volume baseline for every legitimate sender cohort; a sudden volume spike at a previously-low- volume tenant or vendor sender cohort is the canonical signal of a vendor- email-compromise (VEC) BEC variant in progress — the attacker has gained control of a legitimate vendor sender and is using it to dispatch invoice- fraud messages at scale before the vendor notices; the monitoring page's volume-spike alert thresholds (10x daily baseline = Sev-1 alert, 3x weekly baseline = Sev-2) directly support the VEC-BEC-variant detection THIS page's threat catalogue documents the financial- outcome severity of; (ii) sender- inventory-drift-KPI-as-shadow-IT-and- compromised-shadow-mailbox-detection-for- CEO-fraud-and-payroll-diversion dimension — the monitoring page's "sender-inventory drift" KPI tracks new per-source-IP cohorts appearing in the aggregate-report stream that the publisher does NOT have a documented sending-system record for; the appearance of a previously- unmonitored sender IP claiming to send as the protected domain is the canonical signal of a CEO-fraud or payroll-diversion BEC variant exploiting a shadow-IT or compromised-shadow-mailbox channel; the monitoring page's inventory-drift alert routing (auto-correlate to threat- intelligence indicators: known BEC infrastructure / residential-proxy IP cohorts / compromised-mailbox-provider IP ranges) is directly load-bearing for the CEO-fraud and payroll-diversion BEC variants THIS page documents the impersonation-technique catalogue of; (iii) reporter-coverage-KPI-as- receiver-cohort-blind-spot-detection-for- invoice-fraud-and-attorney-impersonation dimension — the monitoring page's "reporter coverage" KPI tracks which receiver-side reporters are emitting aggregate reports for the publisher's per-recipient sending streams; gaps in reporter coverage (a major receiver-side reporter cohort that previously emitted aggregate reports has stopped) are the canonical signal of a receiver-side blind spot the attacker can exploit for invoice-fraud or attorney-impersonation BEC variants targeted at recipients on the now-blind receiver cohort; the monitoring page's per-receiver-cohort coverage-quality alerting is directly load-bearing for the BEC-recipient- selection patterns THIS page catalogues; (iv) per-source-IP-enforcement- disposition-rate-KPI-as-data-theft- variant-and-direct-domain-spoofing-attempt- detection-confirmation dimension — the monitoring page's "policy-mode enforcement disposition rate" KPI tracks the receiver-side reject / quarantine / none disposition per-source-IP; spikes in receiver-side reject disposition counts at unauthorised per-source-IP cohorts confirm the BEC-attempt-blocked event the publisher's p=reject control structurally defeats (per the THIS page's defense catalogue); the monitoring page's per-IP reject-rate alert routing converts the publisher-side defense into a per- attempt operational-detection signal that the SIRT correlates with the RUF forensic evidence stream (above) for the complete BEC-attempt-detection-and-investigation loop. Read this monitoring spoke alongside THIS BEC-defense reference when authoring the SOC dashboard that converts the DMARC aggregate-report stream into BEC-attempt-detection alerts during the 72-hour Financial Fraud Kill Chain recipient-bank-clawback window.
• DMARC deployment checklist — the BEC-PREVENTION-AS-DEPLOYMENT- CHECKLIST-OUTCOME canonical companion. Where THIS page documents the FBI IC3 Business Email Compromise threat model (the eight canonical BEC sub-types — vendor-invoice-redirect / CEO-fraud / attorney-impersonation / data-theft / payroll-diversion / W-2-scam / real- estate-wire-fraud / gift-card-fraud — the per-sub-type loss-distribution statistics from the IC3 annual Internet Crime Report, the impersonation- technique taxonomy including display- name spoofing and lookalike-domain registration), the deployment-checklist spoke documents the CANONICAL POSITIVE- CONTROL whose successful end-to-end execution IS the BEC-prevention primary control: a publisher that has reached p=reject with full SPF alignment and DKIM-aligned signing on every legitimate send path STRUCTURALLY-DEFEATS direct-domain BEC impersonation at receiver-side regardless of social-engineering sophistication, because receivers REJECT the spoofed-From: message at SMTP-data-acceptance time before the targeted recipient ever sees the message in any folder. The deployment- checklist spoke's staged-rollout runbook IS the playbook every CISO / SOC / fraud-prevention org executes once the BEC threat-impact (per- incident loss in the $50K-$5M range per IC3) is established as the motivating force; the BEC-threat spoke this page documents is the cost-impact justification feeding the deployment-checklist spoke's operational-priority queue. The 100%- DMARC-enforcement plateau the deployment-checklist runbook achieves eliminates the direct-domain impersonation sub-class of BEC; the eight BEC sub-types this page enumerates REDUCE to the three SUB-TYPES that operate AROUND DMARC enforcement (lookalike-domain registration, display-name spoofing without From:-domain-spoofing, compromised- legitimate-mailbox abuse). Read THIS BEC-threat page WITH the deployment- checklist spoke when building a budget-justification for DMARC deployment to executive stakeholders; the deployment-checklist runbook is the OUTPUT artefact whose execution cadence the BEC-threat business-case funds.
• DKIM troubleshooting — the BEC-INCIDENT-RESPONSE-PER-MESSAGE- DKIM-VERDICT-SYMPTOM-DRIVEN-FORENSIC- ATTRIBUTION-PLAYBOOK companion to this BEC-threat playbook. Where THIS page catalogues the SIX BEC variants (CEO fraud, invoice fraud, attorney impersonation, payroll diversion, gift- card scam, vendor email compromise) and the organisational SIRT incident- response workflow the finance / legal / FBI-IC3-liaison team executes once a BEC incident is reported, the DKIM- troubleshooting spoke is the PER-MESSAGE FORENSIC-ATTRIBUTION-PLAYBOOK companion documenting the operator-facing symptom-to-action diagnostic sequence run AGAINST the per-message Authentication-Results stamp in the AFRF-embedded message/rfc822 headers of the offending BEC message. Concretely, the spoke documents FOUR BEC-variant-specific DKIM-verdict-attribution dimensions: (i) direct-domain-spoofing CEO fraud dkim=pass with unaligned d=attacker-controlled.example verdict symptom — when the attacker cryptographically signs the CEO-fraud message with their own attacker-controlled domain's DKIM key, the troubleshooting page's identify-which-key-the-signer-used-at- message-sign-time step matches the d=-tag literal against the victim's publisher org-domain set and names the unaligned-d= signing-identity as the cryptographic chain-of-custody evidence the SIRT investigator forwards to the FBI IC3 complaint; (ii) invoice-fraud cousin-domain-impersonation dkim=pass with cousin- domain d= verdict symptom — when the attacker registers a lookalike cousin domain (e.g. microsft.com vs microsoft.com, rn vs m) and publishes a DKIM key under the cousin domain, the troubleshooting page's compare-the- returned-record-bytes-against-what-the- receiver-fetched step pins the cousin- domain DKIM publication as the cryptographic source-of-truth the SIRT investigator references when triggering the registrar takedown request; (iii) vendor email compromise (VEC) dkim=pass with LEGITIMATE vendor d=<vendor-domain> verdict symptom from compromised- legitimate-account — when the attacker has taken over a legitimate vendor mailbox and emits invoice- rerouting mail through the vendor's own signing infrastructure, the troubleshooting page's identify-which- signer-key-the-per-message-b=-tag- was-generated-against step confirms the message DOES match the vendor's published DKIM key — which is the critical NEGATIVE-EVIDENCE the SIRT investigator uses to escalate from "lookalike-domain attack" to "compromised vendor mailbox" with attendant Stage 3 vendor-side incident- response coordination per the FBI Financial Fraud Kill Chain playbook; (iv) attorney-impersonation BEC dkim=permerror NXDOMAIN verdict symptom from attacker-side selector-publication- deletion after the campaign closes — when the attacker publishes a DKIM key for the duration of a time-limited attorney-impersonation campaign and then deletes the <selector>._domainkey.<d-domain> TXT record after the wire-settlement window closes, the troubleshooting page's canonical dig TXT symptom-to-action walk from multiple geographic resolvers retrieves the NXDOMAIN response and pins the attacker-side selector-deletion evidence the SIRT investigator preserves for civil clawback proceedings under 18 U.S.C. §1343. Read the DKIM-troubleshooting symptom- driven playbook AFTER consulting THIS BEC playbook to attribute every BEC- message DKIM verdict in the AFRF forensic evidence stream to the specific BEC-variant-attack-pattern responsible — the spoke is the AUTHORITATIVE per-message diagnostic primitive the SIRT forensic-evidence- collection workflow this page coordinates depends on.
• Email deliverability — the BEC-CAMPAIGN-AS-PER-PUBLISHER-PER- DOMAIN-REPUTATION-DEGRADATION-VECTOR companion to this Business-Email- Compromise defence reference. Where THIS page documents the per-publisher per-domain BEC variant catalogue (CEO fraud / vendor invoice fraud / payroll diversion / account takeover / data theft / lookalike-domain / display-name spoofing / thread hijacking) + the per-variant cryptographic-and-protocol- layer defence playbook (DMARC p=reject enforcement + per-selector DKIM-key- custody discipline + per-publisher SPF authority-list publication + per- domain BIMI VMC display-eligibility + per-domain MTA-STS / TLS-RPT transport- layer hardening + SIRT forensic- evidence-collection workflow), the email-deliverability spoke is the per- publisher per-domain BUSINESS-OUTCOME reference whose per-publisher per- domain reputation-model verdict IS the downstream-consumer of per-publisher BEC-campaign-driven reputation- degradation events at four per-BEC- variant-to-per-publisher-deliverability- impact coupling dimensions: (i) per-publisher per-domain BEC-campaign- successful-spoofing-event as load-bearing receiver-side reputation-model degradation trigger — every per-publisher per-domain BEC variant the per-message defence playbook on THIS page is engineered to prevent (CEO-fraud lookalike-From + vendor- invoice-fraud cousin-domain + display- name spoofing + thread-hijacking Reply-To manipulation) registers as per-publisher per-domain authentication-posture-degradation evidence at the receiver-side reputation-model verdict the email- deliverability framework's Section 2 (authentication-verdict) and Section 4 (reputation-model verdict) document as the load-bearing per-publisher per- domain reputation-degradation trigger; (ii) per-publisher per-domain DMARC-aligned-pass-rate-degradation- from-BEC-campaign as load-bearing per- domain inbox-placement-vs-spam-folder- rate input — every successful per-publisher per-domain BEC spoofing event lowers the per-publisher per- domain DMARC-aligned-pass-rate the per-receiver reputation model consumes as load-bearing per-message per-receiver-side inbox-placement-vs- spam-folder-rate routing input — the per-publisher per-domain BEC defence playbook THIS page coordinates IS the load-bearing per-publisher per-domain DMARC-aligned-pass-rate-floor- protection input feeding the email- deliverability framework's Section 6 (engagement metrics) and Section 10 (inbox-placement-rate measurement); (iii) per-publisher per-domain BEC-as-DMARC-aligned-pass-rate-floor- breach as load-bearing per-domain Bulk-Sender-Requirements 2024 compliance-gate-failure trigger — the Gmail/Yahoo Feb 2024 Bulk Sender Requirements threshold mandates per- publisher per-domain DMARC-aligned- pass-rate floors; BEC-campaign-driven DMARC-aligned-pass-rate-floor-breach events the per-message defence playbook THIS page coordinates is engineered to prevent IS the load- bearing per-publisher per-domain Bulk-Sender-Requirements compliance- gate-failure trigger the email- deliverability framework's Section 13 (Bulk Sender Requirements deliverability floor) cross-references; (iv) per-publisher per-domain BEC-incident- recovery as load-bearing per-domain reputation-model-recalibration trajectory feeding deliverability uplift — per-publisher per- domain BEC-incident-recovery (immediate DMARC p=reject enforcement + compromised per-selector DKIM-key- retirement + per-domain authentication- posture-hardening) IS the load-bearing per-publisher per-domain reputation- model-recalibration trajectory the per-receiver reputation model registers as authentication-posture-improvement evidence; the per-publisher per-domain deliverability uplift the email- deliverability framework's Section 4 (reputation-model verdict) and Section 10 (inbox-placement-rate measurement) document IS the downstream-consumer of per-publisher per-domain BEC-incident- recovery-driven authentication-posture- hardening events. Read the email- deliverability spoke ALONGSIDE this Business-Email-Compromise defence reference whenever a per-publisher per- domain BEC-campaign-to-per-receiver- deliverability-impact attribution question emerges — THIS page gives the per-publisher per-domain per-BEC- variant defence playbook, the email- deliverability spoke gives the per- publisher per-domain inbox-placement BUSINESS-OUTCOME framework that per-publisher BEC defence ultimately protects at the receiver-side reputation-model verdict boundary.
• DMARC reporting pipeline (RUA / RUF ingestion, parsing, delivery) — the canonical detection-and-forensics infrastructure-path reference documenting how the five-stage receiver-to-operator pipeline materialises the per-source-IP per-day per-disposition evidence stream every per-publisher BEC defence playbook THIS page coordinates structurally depends on: (1) receiver- side aggregate-XML generation cadence (Gmail 24-hour UTC-aligned batch, Microsoft 365 hourly rolling window, Yahoo / Mail.ru 24-hour UTC-aligned batch) where every direct-spoof BEC attempt against the publisher's domain produces one policy_evaluated.dkim=fail + policy_evaluated.spf=fail + disposition=quarantine or =reject row (the canonical BEC-direct-spoof signature p=reject publication produces), (2) publisher-side rua= mailbox addressing, (3) IMAP / Microsoft-Graph ingestion (imap_fetch.php / ImapFetcher / GraphFetcher polling + attachment unwrap), (4) DmarcParser XML-to-row decomposition minting dmarc_records rows whose per-source-IP attribution surfaces attacker-infrastructure IPs (bulletproof- hosting CIDRs, residential-proxy clusters, commodity-webmail egress pools) that the SIRT can cross-reference with Threat-Intelligence feeds, and (5) dashboard delivery surfacing the per-source-IP per-disposition evidence BEC-defenders consume for the four canonical attack-in-progress signals (volume-based spike per attacker IP block, sender-inventory drift via new unknown source_ip × From:-domain combinations, geographic-cohort shift in per-source-IP-cohort attribution, and reporter-coverage gaps where new receivers begin emitting rua against the publisher's domain). Read the reporting-pipeline spoke ALONGSIDE this Business-Email-Compromise defence reference when the SIRT or the DMARC-defender asks "where does the evidence I need to detect the BEC campaign in progress actually live and how do I ingest it" — the answer is FIVE-LAYERED: THIS page documents the BEC variant catalogue + defence playbook, the reporting-pipeline spoke documents the five-stage receiver-to- operator infrastructure path that delivers the per-source-IP per-day per-disposition evidence stream the BEC defence playbook is operationally gated on.
• TLS-RPT report format (RFC 8460 §4 JSON-aggregate schema) — the PER-RECEIVER-PER- PUBLISHER-PER-DAY-RFC-8460-§4- TLS-RPT-JSON-AGGREGATE-REPORT- FORMAT-AS-LOAD-BEARING- TRANSPORT-LAYER-OBSERVABILITY- STREAM-FOR-BEC-DEFENSE-IN- DEPTH-FRAMEWORK companion to this BEC defense-in-depth reference. Where THIS page documents the 22-technique BEC attack-TTP catalogue + the defense-in-depth-control-stack consuming per-receiver per-day per-disposition aggregate evidence, the tls_rpt_report_ format spoke documents the structurally-parallel per- receiver per-publisher per-day RFC 8460 §4 JSON-aggregate TLS- RPT report-format byte-schema (the policies[].policy.policy- type enum, the summary.total-successful- session-count / summary.total-failure- session-count fields, the failure-details[].result- type per-failure-class catalogue, the sending-mta-ip + receiving-mx-hostname per-hop attribution fields) whose per-receiver-emitted transport-layer observability IS the canonical load-bearing TLS-handshake-and-transport- confidentiality observability stream the BEC defense-in- depth-control-stack consumes to diagnose BEC TTPs that exploit transport-layer weaknesses. FOUR structurally- distinct PER-TRANSPORT-LAYER- FAILURE-CLASS-VS-BEC-ATTACK- TTP-COUPLING-DIMENSIONS the tls_rpt_report_format spoke operationally documents the BEC defense playbook consumes: (i) per-receiver per- publisher per-day certificate-host- mismatch / certificate-not- trusted / certificate-expired failure-details[].result- type rows AS LOAD- BEARING-DETECTION-PRIMITIVE- FOR-TLS-MITM-DOWNGRADE-BEC- ATTACK-TTP-CLASS — attacker-controlled TLS-MITM downgrade attempts (an attacker injecting a forged certificate on the SMTP egress path) surface as per-receiver per- publisher per-day TLS-RPT failure-details rows with result-type certificate-host- mismatch or certificate-not- trusted; the BEC defense playbook consumes these rows as the canonical detection- primitive for the TLS-downgrade- plus-attacker-issuance BEC attack-TTP class; (ii) per-receiver per- publisher per-day sts-policy-invalid / sts-policy-fetch- error failure-details[].result- type rows AS LOAD- BEARING-DETECTION-PRIMITIVE- FOR-MTA-STS-POLICY-TAMPERING- BEC-ATTACK-TTP-CLASS — attacker-controlled mta-sts.<d-domain> policy-file tampering attempts (an attacker controlling the per-publisher DNS authority OR the HTTPS-fetch authority to inject a forged policy) surface as per-receiver per-publisher per-day TLS-RPT failure-details rows with result-type sts-policy-invalid or sts-policy-fetch- error; the BEC defense playbook consumes these rows as the canonical detection- primitive for the MTA-STS- policy-tampering BEC attack- TTP class; (iii) per- receiver per-publisher per-day tlsa-invalid / dnssec-invalid failure-details[].result- type rows AS LOAD- BEARING-DETECTION-PRIMITIVE- FOR-DANE-TLSA-RECORD-TAMPERING- BEC-ATTACK-TTP-CLASS — attacker-controlled DANE-EE TLSA-record tampering attempts (an attacker bypassing the DNSSEC chain-of-trust OR injecting a forged TLSA record) surface as per- receiver per-publisher per-day TLS-RPT failure-details rows with result-type tlsa-invalid or dnssec-invalid; the BEC defense playbook consumes these rows as the canonical detection-primitive for the DANE-TLSA-record- tampering BEC attack-TTP class; (iv) per-receiver per- publisher per-day summary.total-failure- session-count baseline- shift AS LOAD-BEARING-EARLY- WARNING-PRIMITIVE-FOR-PER- PUBLISHER-PER-EGRESS-PATH-TLS- ENFORCEMENT-DEGRADATION-BEC- ATTACK-TTP-CLASS — a sudden per-publisher per- receiver per-day TLS-RPT summary.total-failure- session-count baseline- shift (e.g., a +50% baseline- shift over a 24-to-72-hour window) signals per-egress- path TLS-enforcement degradation the BEC defense playbook consumes as the canonical early-warning primitive for the per- publisher per-egress-path TLS- attack-surface compromise BEC TTP class. Read the tls_rpt_ report_format spoke ALONGSIDE this BEC defense-in-depth reference whenever the BEC defense operator scopes a per- publisher per-receiver per- day transport-layer observability-analysis plan — the RFC-8460-§4-JSON- aggregate-report byte-schema THIS comparison spoke documents IS the canonical load-bearing transport-layer observability stream every per- publisher per-egress-path TLS- enforcement BEC-attack-TTP- detection outcome the BEC defense-in-depth-control-stack operationally depends on.
• Email Header Analyzer — paste any suspicious email's headers and see the per-message SPF, DKIM, DMARC, and alignment results; surfaces display-name forgery and lookalike-domain From: addresses.
• Domain Security Checker — live DNS lookups for SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, CAA, and DNSSEC via includes/DnsChecker.php; verify your own DMARC posture before relying on it for BEC defense.
• FBI Internet Crime Complaint Center (IC3) — the canonical BEC reporting and statistics source; file BEC incidents here within 24 hours of loss to activate the Financial Fraud Kill Chain.
• Verizon Data Breach Investigations Report (DBIR) — annual industry-cross-cutting incident report; the canonical secondary source for BEC incidence and per-incident-cost statistics.
• MITRE ATT&CK T1566.003 — Spearphishing via Service — the commodity-webmail-From: BEC variant catalogued in the ATT&CK matrix.
• MITRE ATT&CK T1078 — Valid Accounts — the compromised-account BEC variant (including VEC) catalogued in the ATT&CK matrix.
• MITRE ATT&CK T1534 — Internal Spearphishing — the post-compromise lateral BEC variant catalogued in the ATT&CK matrix.
• MITRE ATT&CK T1114.003 — Email Forwarding Rule — the persistence mechanism BEC attackers establish inside compromised mailboxes to maintain covert access.
• DKIM canonicalization — the canonicalization-mode spoke documents the per-publisher per-domain RFC 6376 §3.4 c=-tag choice between c=simple/simple (byte-exact header + body) and c=relaxed/relaxed (case-folded + whitespace-collapsed) whose per-message DKIM body-hash stability across legitimate intermediary whitespace normalisation, MIME re-encoding, and signature-preserving relays is the LOAD-BEARING upstream determinant of the per-message DKIM- verify-pass verdict that is the per-message cryptographic anti-spoofing proof defeating the canonical BEC direct- spoof variant THIS page catalogues. Four BEC-defense-vs-canonicalization-mode axes the canonicalization spoke documents: (i) per-publisher per-domain c=relaxed/relaxed canonicalization-mode adoption is the per-message DKIM-aligned-pass-rate-floor prerequisite enabling the DMARC p=reject terminal-state enforcement that blocks the direct-spoof BEC variant at the receiver-side 5xx-SMTP rejection boundary — c=simple/simple canonicalization produces brittle per-message DKIM body-hash stability under legitimate intermediary whitespace normalisation, collapsing the per-publisher per-domain DKIM-aligned-pass- rate floor below the safe p=quarantine → p=reject ramp-advancement threshold and leaving the direct-spoof BEC variant unblocked at the receiver-side DMARC evaluator; (ii) per-publisher per-domain canonicalization-mode consistency across heterogeneous outbound signing-MTA cohorts (on-prem Exchange + Exchange Online + transactional ESP cohorts) is the operator- discipline-floor whose divergence produces dkim=fail-but-cryptographically- legitimate evidence indistinguishable from BEC-attacker spoofing at the per-receiver per-publisher per-day aggregate-report row level — heterogeneous canonicalization-mode deployment populates the per-publisher per-domain dmarc=fail row stream with false-positive evidence that mismeasures the per-publisher per-domain BEC-attack- surface at p=reject-readiness- decision time; (iii) per-publisher per-domain canonicalization-mode publication regression introduces per-receiver dkim=permerror verdicts that under p=reject terminal-state enforcement propagate to 550 SMTP-time rejection identically to BEC-attacker direct-spoof rejection — a per-publisher per-domain canonicalization- mode publication divergence (e.g. signing MTA emits c=relaxed/relaxed but body-canonicalization re-computation diverges due to MIME-encoding regression) converts cryptographically-legitimate publisher-signed mail into bounce-evidence indistinguishable from the BEC direct- spoof variant THIS page catalogues at the defense-in-depth message-authentication boundary; (iv) per-publisher per-domain canonicalization-mode stability under the per-message DKIM-Signature re-signing required by ARC-rescue (RFC 8617) intermediary chains is the LOAD-BEARING upstream determinant of the per-message DKIM-aligned-pass verdict that defeats the lateral BEC variant (MITRE ATT&CK T1534) traversing legitimate-account-compromised outbound- forwarding chains — ARC- rescue intermediary chains re-canonicalize the per-message body under their own c=-tag choice; divergence between the originating-publisher canonicalization mode and the ARC-sealer canonicalization mode produces per-receiver per-day per-publisher arc=fail + dkim=fail evidence on legitimate intra-org lateral BEC-detection scenarios. Read THIS page when reasoning about per-publisher per- domain BEC defense-in-depth architecture; read the canonicalization spoke when AUDITING the per-publisher per-domain c=-tag canonicalization-mode choice whose per-message DKIM body-hash stability is the LOAD-BEARING upstream determinant of the per-message DKIM- verify-pass verdict that is the per- message cryptographic anti-spoofing proof defeating the canonical BEC direct-spoof variant THIS page catalogues at the receiver-side DMARC-evaluator-and-SMTP- rejection boundary.
• DKIM cryptography basics (RSA-2048 / Ed25519 / SHA-256) — the PER-PUBLISHER-PER-SELECTOR- CRYPTOGRAPHIC-PRIMITIVE-AS-LOAD-BEARING- ANTI-SPOOF-PROOF companion to this BEC playbook. Where THIS page documents the SIX BEC variants (CEO fraud, invoice fraud, attorney impersonation, payroll diversion, gift-card scam, M&A fraud) and the organisational incident-response workflow the finance / treasury / fraud team follows once a BEC incident is reported, the DKIM-cryptography-basics spoke documents the UPSTREAM per- publisher per-selector cryptographic- primitive publication discipline (RFC 6376 §3.3 rsa-sha256 / ed25519- sha256 algorithm catalogue, the per- selector 2048-bit RSA modulus floor, the per-publisher key-rotation cadence, the per-selector public-key TXT record v=DKIM1; k=rsa; p=<BASE64-key> byte-shape) whose per-publisher per- selector cryptographic primitive publication is the LOAD-BEARING anti- spoof cryptographic proof every BEC direct-spoof variant catalogued on THIS page must structurally defeat to land at the victim's inbox under the impersonated executive / vendor / lawyer / payroll / gift-card-procurement / M&A- counsel From-header identity. The BEC- DEFENSE-VS-DKIM-CRYPTOGRAPHY cross- reference establishes FOUR structurally- distinct cryptographic-anti-spoof-proof coupling dimensions: (i) BEC direct-spoof variant attempts to forge the victim's From: header without producing a per-message DKIM-Signature cryptographically valid under the victim's per-selector RSA-2048 / Ed25519 public key — the absence of a valid signature under d=victim-domain is the immediate cryptographic-anti-spoof-proof the receiver-side DKIM verifier returns dkim=fail on, gating downstream DMARC-aligned-DKIM-pass evaluation; the DKIM-cryptography-basics spoke documents the per-publisher per- selector cryptographic-primitive publication discipline whose absence at the attacker's controlled signing infrastructure produces this per-message anti-spoof failure verdict; (ii) BEC compromised-account variant produces a per-message DKIM-Signature cryptographically valid under the victim's compromised per-selector RSA- 2048 key — the cryptographic primitive passes, the impersonation succeeds at the message-authentication layer, and the incident-response priority is per- publisher per-selector key revocation — the DKIM- cryptography-basics spoke documents the per-publisher per-selector key-rotation cadence (RFC 6376 §3.6.1 key-rotation with DNS-propagation overlap window) the finance / treasury / fraud-team BEC incident-response workflow THIS page documents must execute on every per- selector key suspected to be compromised; (iii) per-publisher per-selector cryptographic-primitive publication algorithm choice (rsa-sha256 vs ed25519-sha256) and per-selector 2048-bit RSA modulus floor materially determines the cost of a per-publisher per-selector key-compromise attack feeding the BEC compromised-account variant — sub-1024-bit RSA moduli (legacy per-selector publication) are cryptographically broken in the 2024 threat model; 2048-bit RSA + ed25519 per-selector publication is the floor the per-publisher BEC-defense-in-depth framework THIS page documents requires; the DKIM-cryptography-basics spoke documents the per-publisher per-selector cryptographic-primitive selection discipline; (iv) BEC forensic- evidence-collection workflow at Stage 3 of the FBI Financial Fraud Kill Chain depends on per-message DKIM-Signature d= + s= attribution to the attacker's controlled per-selector public-key publication infrastructure — the per- message d=attacker-domain + s=attacker-selector trace is the cryptographic chain-of-custody from offending message back to the attacker's DNS publication infrastructure; the DKIM-cryptography-basics spoke documents the per-selector public-key TXT-record publication discipline whose per-attacker-controlled-publication is the load-bearing forensic-attribution primitive the BEC incident-response playbook THIS page documents extracts in Stage 3 evidence collection. Read this BEC playbook when EXECUTING the organisational incident-response workflow on an active BEC incident; read the DKIM-cryptography-basics spoke when UNDERSTANDING the upstream per- publisher per-selector cryptographic- primitive publication discipline whose per-message DKIM-verify-pass / fail verdict gates the per-receiver DMARC- aligned-DKIM-pass enforcement the BEC direct-spoof variant THIS page catalogues must structurally defeat.
• Email authentication glossary — the BEC-VARIANT-DEFENSE-VOCABULARY- RESOLVES-TO-CROSS-CLUSTER-EMAIL- AUTHENTICATION-TERMINOLOGY-HUB companion to this BEC-variant defense reference. Where THIS page documents the six FBI IC3 BEC variants (CEO fraud, invoice fraud, payroll diversion, attorney impersonation, data-theft, vendor-email- compromise) with their financial-fraud outcomes and the publisher-side technical controls (DMARC at p=reject, SPF hardfail, DKIM alignment) that structurally defeat each variant, the email-authentication-glossary spoke is the cross-cluster TERMINOLOGY-RESOLUTION reference whose per-term canonical definitions establish the shared vocabulary every BEC-variant defense discussion structurally depends on at FOUR per-term vocabulary-resolution dimensions: (i) per-term DMARC- enforcement vocabulary resolution — the DMARC-enforcement vocabulary (p=reject full enforcement, p=quarantine partial enforcement, p=none monitoring, sp= subdomain-policy, pct= percentage rollout, per-receiver disposition keyword set, per-publisher per-domain ramp-progression discipline) THIS page's BEC-variant defense catalogue references when describing the DMARC-p=reject-as-direct- spoof-defense mechanism is canonically defined in the glossary spoke; the per-publisher per-domain DMARC-enforcement-mode terminology vocabulary that drives every BEC-direct- spoof-defense discussion lives in the glossary's per-term enforcement- vocabulary entry-set; (ii) per- term DMARC-alignment vocabulary resolution — the DMARC-alignment vocabulary (organizational domain, aspf= s/relaxed mode, adkim= s/relaxed mode, RFC5322-From domain, From-header binding, SPF-aligned-pass, DKIM-aligned-pass) THIS page's BEC-variant defense catalogue references when describing how DMARC binds authentication-pass verdicts to the RFC5322-From header the BEC direct-spoof variant impersonates is canonically defined in the glossary spoke; the per-message From-header- binding-evaluation vocabulary that determines whether a per-message DMARC- aligned-pass verdict structurally defeats the per-BEC-variant direct-spoof attempt lives in the glossary's per-term alignment-vocabulary entry-set; (iii) per-term cousin-domain-attack- catalogue vocabulary resolution — the cousin-domain-attack vocabulary (cousin domain, look-alike domain, IDN homograph attack, display-name spoofing, From- header display-name vs From-header email- address divergence, per-publisher per- domain brand-protection registration coordination) THIS page's BEC-variant defense catalogue references when describing the BEC variants that bypass DMARC by registering look-alike domains is canonically defined in the glossary spoke; the per-attacker per-cousin- domain terminology vocabulary that drives every BEC-cousin-domain-defense discussion lives in the glossary's per- term cousin-domain-vocabulary entry-set; (iv) per-term BEC-defense- primitive vocabulary resolution — the BEC-defense-primitive vocabulary (Auth- Results header, per-receiver per-message verdict-emission, Authentication-Results chain, per-receiver per-source-IP per-day aggregate-report row, per-message Auth-Results header dkim= keyword set, spf= keyword set, dmarc= keyword set) THIS page's BEC-variant defense catalogue references when describing the per-receiver per-message verdict- emission infrastructure that produces the BEC-attempt-blocked event is canonically defined in the glossary spoke; the per-receiver per-message Auth-Results-header decode vocabulary that drives every operator-side per- BEC-variant-defense-effectiveness decision discussion lives in the glossary's per-term Auth-Results- vocabulary entry-set. Read the email- authentication-glossary spoke alongside this BEC-variant defense reference when authoring per-publisher per-domain BEC- defense runbooks and per-BEC-variant- triage documents that need the shared terminology hub.
• MTA-STS for Microsoft 365 Four per-M365-tenant BEC-vs-transport-layer-MITM precondition-coupling dimensions: (i) per-attacker STARTTLS-downgrade MITM as precondition for per-message Authentication-Results header manipulation — without MTA-STS enforce-mode, an active MITM between the sending MTA and the M365 EOP inbound MX can downgrade the STARTTLS handshake to plaintext, then inject or rewrite the Authentication-Results header so per-message DKIM=fail / SPF=fail / DMARC=fail verdicts at the upstream evaluator are not detected by the receiving M365 tenant's downstream filters, enabling a per-message direct-spoof BEC variant to slip past per-tenant inbound filtering; (ii) per-M365-tenant inbound MTA-STS enforce-mode as receive-side cryptographic-pinning analog to per-publisher DKIM-Signature header binding — where outbound DKIM-Signature publication binds the per-message header set to the per-publisher per-selector RSA-2048 private key, inbound MTA-STS enforce-mode binds the per-M365-tenant receive-side MX delivery to a per-publisher per-receiver-tenant TLS-handshake-cert-chain-validation discipline that closes the per-attacker BEC-attack-chain transport-leg precondition at the per-customer-domain inbound boundary; (iii) per-M365-tenant MTA-STS publication as Stage-1 BEC-precondition-closure within the FBI-IC3-tracked BEC-attack-chain catalogue — the IC3 BEC attack-chain enumerates seven canonical stages (recon → impersonation domain registration → DKIM-key-cryptanalysis → MITM STARTTLS-downgrade → per-message Authentication-Results header injection → per-payload wire-fraud invoice / pretexted W-2 / vendor-payment-redirect → exfiltration), and per-M365-tenant MTA-STS publication is the LOAD-BEARING Stage-4 precondition-closure that prevents the downstream Stage-5 authentication-evidence-tampering BEC attacker variant catalogued in this guide; (iv) per-M365-tenant inbound MTA-STS as defense-in-depth complement to per-M365-tenant DMARC=reject enforcement on the same custom domain — the per-M365-tenant DMARC=reject publication closes the per-message direct-spoof BEC variant at the application-layer From-header authentication boundary, BUT per-M365-tenant MTA-STS enforce-mode publication is required to close the per-attacker per-message transport-layer per-MX STARTTLS-downgrade MITM attack-surface that lets attackers tamper with the per-message Authentication-Results header set before EOP's DMARC evaluator consumes it — TWO ORTHOGONAL per-publisher per-domain hardening primitives the BEC-defense operator coordinates concurrently. Read the M365-MTA-STS spoke alongside this BEC reference when the operator is hardening an M365-hosted target organisation against per-attacker per-message transport-layer MITM preconditions, when planning concurrent per-M365-tenant DMARC=reject + MTA-STS enforce-mode publication rollouts, or when investigating per-message Authentication-Results header anomalies in BEC-attack-incident forensic triage that correlate with TLS-RPT-observed STARTTLS-downgrade attempts at the per-M365-tenant inbound MX.
• ARC (Authenticated Received Chain, RFC 8617) explained — the BEC-FORWARDED-CHAIN-AUTH-PRESERVATION- AND-COMPROMISED-MAILBOX-FORENSICS companion to this BEC reference. Where THIS page documents the per-BEC-variant attacker playbook (CEO fraud, invoice fraud, payroll diversion, gift-card scam, M&A fraud, VEC) and per-publisher per-M365-tenant defense-in-depth posture, the ARC-explained spoke is the FORWARDED-MAIL-CHAIN-AUTH- PRESERVATION REFERENCE BEC defenders consult when investigating per-incident forensic evidence on attacker-controlled forwarder chains. Three structurally- distinct BEC-vs-ARC coordination dimensions: (i) compromised-mailbox lateral movement BEC variants frequently re-emit attacker wire-fraud payloads through legitimate mailing lists or auto-forwarders the compromised account belongs to — the receiver-side ARC chain preserves the original-domain DKIM verdict (which still passes because the message ORIGINATED on the compromised domain) AND the per-hop ARC-Sealer identities, producing the forensic trail BEC incident responders use to reconstruct the per-hop relay topology; (ii) BEC attack variants that exploit hijacked-legitimate-sender semantics produce a structurally-distinct ARC-chain signature relative to direct-spoof BEC variants — the publisher's domain appears in BOTH the Original-Mail-From AFRF row AND the Reported-Domain row AND the ARC- chain Authentication-Results carries original-domain pass evidence, which is the canonical fingerprint of an account- compromise BEC variant the forensic- reports stream documents; (iii) per-message ARC-chain validation outcomes interact with per-publisher Trusted ARC Sealers configuration at receive-side filtering — BEC defenders coordinate the receive-side Trusted ARC Sealers list with the upstream publisher's per-domain ARC-Sealer publication decision so legitimate forwarded mail preserves DMARC-pass while attacker-forged ARC chains break at the first un-trusted sealer.
• RFC 7489 — DMARC — the canonical DMARC specification; defines the From-header authentication semantics that block the direct-spoof BEC variant.
• DANE TLSA explained (RFC 7672) — the PER-PUBLISHER-DANE-TLSA-AS-TRANSPORT- LAYER-BEC-DEFENSE-IN-DEPTH-CONTROL companion to this BEC defense-in-depth reference. Where THIS page documents the BEC defense- in-depth framework (the direct-spoof variant blocked by message-authentication DMARC enforcement, the look-alike-domain variant addressed by domain-monitoring + brand- protection, the compromised-mailbox variant addressed by MFA + behavior-monitoring, the thread-hijacking variant addressed by external-banner + content-inspection), the DANE-TLSA-explained spoke is the RFC 7672 per-publisher per-MX-host DNSSEC-anchored transport-confidentiality reference whose per-publisher per-MX-host TLSA-RR publication-discipline is the LOAD-BEARING transport-layer anti-MITM-downgrade-AND- lookalike-MX-host-suppression control- primitive complementing the BEC defense- in-depth framework at the transport-layer boundary. The PER-PUBLISHER-DANE-TLSA-VS- BEC-DEFENSE-IN-DEPTH cross-reference establishes FOUR structurally-distinct BEC-defense-DANE-TLSA-coupling dimensions: (i) per-publisher per-MX-host DANE-EE-TLSA-RR DNSSEC-anchored-trust certificate-pinning AS LOAD-BEARING anti- MITM-downgrade BEC-defense control- primitive — attacker MITM-downgrade attempts on the per-receiver-MTA-to-per- publisher-MX-host inbound SMTP handshake are deterministically suppressed by per- MX-host DANE-EE-TLSA-pinning — the per-publisher per-MX-host TLSA-RR DNSSEC-anchored cryptographic-trust-anchor prevents per-receiver-MTA acceptance of an attacker-supplied certificate during the inbound SMTP handshake, deterministically suppressing MITM-downgrade variants the BEC-defense framework would otherwise treat as a transport-layer compromise; the DANE- TLSA-explained spoke documents the per- publisher per-MX-host TLSA-RR DNSSEC- anchored cryptographic-trust-anchor discipline complementing the message- authentication-layer DMARC enforcement THIS page documents; (ii) per- publisher per-MX-host DANE-EE-TLSA-RR- REQUIRED MX-host-name-validation AS LOAD- BEARING lookalike-MX-host-suppression BEC- defense control-primitive — attacker- registered look-alike-MX-host names (typosquats, IDN-homoglyph, dash-insertion variants) cannot fraudulently terminate SMTP at a per-publisher-domain claim because the per-publisher per-MX-host TLSA-RR DNSSEC-anchored DNS-publication is the per-receiver-MTA's load-bearing per-MX-host-name validation primitive — the per-publisher per-MX-host TLSA-RR anchored at _25._tcp.<mx-host> DNSSEC-validated DNS-publication boundary prevents per-receiver-MTA acceptance of attacker-registered look-alike-MX-host names as legitimate per-publisher-domain SMTP termination points; the DANE-TLSA- explained spoke documents the per-MX-host- name-validation discipline complementing the look-alike-domain BEC variant defense THIS page documents; (iii) per- publisher per-MX-host DANE-EE-TLSA-RR + TLS-RPT JSON-aggregate per-day TLS- handshake-failure-class catalogue AS LOAD-BEARING per-publisher BEC-attacker- TTP-detection observability primitive — per-publisher per-day per-receiver TLS- RPT JSON-aggregate failure-class distribution shifts surface BEC-attacker TTP TLS-MITM-downgrade attempts as a canonical transport-layer attack-evidence stream — a per-publisher per-day per-receiver certificate-host- mismatch OR certificate-not- trusted OR tlsa-invalid OR dnssec-invalid failure- class spike in TLS-RPT JSON-aggregate is the canonical BEC-attacker transport- layer-TTP observability signature; the DANE-TLSA-explained spoke documents the per-MX-host TLSA-RR per-failure-class attribution discipline whose per-day observability stream IS the per-publisher BEC-defense-in-depth transport-layer- observability primitive THIS page documents the BEC defense framework depends on at the transport-layer boundary; (iv) per-publisher per- MX-host DANE-EE-TLSA-RR rollover-cadence operational-discipline AS LOAD-BEARING per-publisher BEC-defense operational- readiness primitive — per-publisher per- MX-host TLSA-RR rollover-cadence operational discipline coordinates with per-publisher BEC-defense-readiness pre- condition compliance — the per- publisher per-MX-host TLSA-RR rollover- cadence operational discipline (60-day overlap window for per-MX-host certificate rotation, per-receiver-MTA cache-window- bounded coordination, per-publisher operational-quality SLO commitment) IS the per-publisher BEC-defense operational- readiness pre-condition the per-publisher operations team commits to long-term; the DANE-TLSA-explained spoke documents the per-publisher per-MX-host TLSA-RR operational-discipline whose per-publisher BEC-defense-readiness pre-condition IS the load-bearing operational-discipline primitive THIS page documents the BEC defense framework depends on. Read the DANE-TLSA-explained spoke alongside this BEC defense-in-depth reference whenever the operator scopes a per-publisher BEC- defense-AND-transport-confidentiality coordination plan — the per-publisher per- MX-host DANE-EE-TLSA-RR DNSSEC-anchored certificate-pinning IS the canonical transport-layer anti-MITM-downgrade-AND- lookalike-MX-host-suppression BEC-defense control-primitive complementing the message-authentication-layer DMARC enforcement THIS page documents the BEC direct-spoof variant defense of.
• MTA-STS explained — the transport-layer SMTP-TLS-enforcement pillar — the load-bearing transport-layer anti-MITM-downgrade BEC-defense control- primitive complementing the message- authentication-layer DMARC enforcement THIS page documents. Where THIS page documents the BEC attack-class catalogue (CEO-impersonation / supplier-invoice- fraud / W-2-data-theft / wire-transfer- redirect) the application-layer DMARC + SPF + DKIM defense stack addresses, the MTA-STS pillar documents the per- publisher per-MX-host SMTP-TLS-policy publication discipline (RFC 8461) that constrains receiving MTAs to refuse STARTTLS-stripping and lookalike-MX-host delivery — closing the per-attacker per- message in-transit MITM-downgrade-AND- lookalike-MX-host attack surface that survives the application-layer authentication stack. Read the MTA-STS pillar alongside this BEC defense-in- depth reference whenever the operator scopes a per-publisher transport-layer- AND-message-authentication-layer coordinated BEC-defense plan — the per- publisher per-MX-host MTA-STS policy- file (mode=enforce + per-MX-host name + per-policy max_age) IS the canonical transport-layer BEC-defense primitive the per-publisher BEC-defense framework THIS page synthesises requires at the transport-confidentiality layer.
• Why SPF alone is insufficient — the per-publisher per-domain SPF-ONLY- PUBLISHER-AS-BEC-ATTACK-SURFACE companion to this Business Email Compromise defence- in-depth reference. Where THIS page documents the per-publisher per-domain BEC threat catalogue (per-attacker per-publisher per- domain CEO-impersonation, vendor-invoice- spoofing, wire-transfer-redirect, payroll- diversion, gift-card-fraud) and the per-publisher per-domain layered authentication- plus-process defence framework, the why-SPF- alone-is-insufficient spoke documents the per- publisher per-domain SPF-only-publication- discipline COVERAGE-GAP that creates the per-publisher per-domain BEC attack surface in the first place: a per-publisher per- domain operator publishing ONLY SPF (v=spf1 ... -all) without DKIM + DMARC leaves the per-publisher per-domain per-message coverage incomplete on four axes — (i) per-message SPF-pass survives only when the per-message envelope MAIL FROM is preserved end-to-end (per-message SPF-fail-after-Listserv-forwarding-and-MX- redirect breakage); (ii) per-non-existent- subdomain SPF publication coverage is absent (the per-publisher per-non-existent- subdomain impersonation-campaign attack surface BEC attackers exploit); (iii) per-message MAIL FROM envelope verdict has NO alignment-with-RFC-5322-From-header coverage (the per-message envelope-vs- header alignment-invisibility gap BEC attackers exploit); (iv) per-message message-integrity is unprotected (the per- message body-and-headers post-SPF-pass remain mutable, enabling per-message post-pass-content-modification BEC scenarios). Three per-BEC-defense per- publisher per-domain SPF-only-coverage-gap- as-attack-surface dimensions the why-SPF- alone-is-insufficient spoke documents the per-publisher per-domain BEC-defense operator MUST AUDIT at the per-publisher per-domain authentication-coverage- completeness tier: (i) per-publisher per-domain SPF-only-publication-discipline- as-BEC-impersonation-enabler at the per- publisher per-non-existent-subdomain coverage-gap tier — the per- publisher per-non-existent-subdomain impersonation campaigns the BEC threat catalogue THIS page documents EXPLOIT SUCCEED specifically because per-publisher per-non-existent-subdomain SPF publication coverage is ABSENT (the per-publisher per- non-existent-subdomain SPF-only operator publishes ONLY the per-organization-domain SPF TXT-RR and provides NO coverage for the per-non-existent-subdomain attacker spoof-source the BEC attacker chooses); the why-SPF-alone-is-insufficient spoke documents the per-publisher per-non- existent-subdomain coverage-gap mechanics the BEC-defense operator MUST close via the DMARC per-non-existent-subdomain np=reject publication discipline; (ii) per-publisher per-domain SPF-only-publication-discipline- as-BEC-vendor-invoice-spoofing-enabler at the per-publisher per-message MAIL-FROM- vs-From-header alignment-invisibility tier — the per-publisher per-domain vendor- invoice-spoofing campaigns the BEC threat catalogue THIS page documents EXPLOIT the per-publisher per-domain MAIL-FROM-vs- From-header alignment-invisibility gap (a per-publisher per-domain SPF-only operator publishing v=spf1 include:vendor.example -all cannot prevent per-message MAIL-FROM-set- to-attacker-controlled-domain-but-From- header-spoofed-to-vendor messages from reaching recipients with a per-message SPF-pass verdict); the why-SPF-alone-is- insufficient spoke documents the per- publisher per-message alignment- invisibility-gap mechanics the BEC- defense operator MUST close via the DMARC per-message aspf=strict publication discipline; (iii) per- publisher per-domain SPF-only-publication- discipline-as-BEC-wire-transfer-redirect- enabler at the per-message message- integrity-publication-discipline gap tier — the per-publisher per-domain wire- transfer-redirect campaigns the BEC threat catalogue THIS page documents EXPLOIT the per-message body-and-headers-post-SPF-pass message-integrity gap (a per-publisher per-domain SPF-only operator's per-message body and headers remain mutable post-SPF- evaluation, enabling per-message intermediary-MTA-or-mailbox-compromise wire-instructions-modification attacks); the why-SPF-alone-is-insufficient spoke documents the per-message message- integrity gap mechanics the BEC-defense operator MUST close via per-publisher per-selector DKIM-Signature header cryptographic-message-integrity publication discipline. Read the why- SPF-alone-is-insufficient spoke ALONGSIDE this BEC defence-in-depth reference whenever the per-publisher per- domain BEC-defense operator AUDITS the per-publisher per-domain SPF-only- coverage-gap-as-BEC-attack-surface rationale for the per-publisher per- domain SPF+DKIM+DMARC layered authentication adoption — the per-publisher per-domain BEC defence-in-depth framework THIS page synthesises is the per-publisher per-domain BEC-DEFENSE-FRAMEWORK primitive; the per- publisher per-domain why-SPF-alone-is- insufficient spoke is the per-publisher per- domain SPF-ONLY-COVERAGE-GAP-AS-BEC-ATTACK- SURFACE-MOTIVATING-RATIONALE primitive that closes the per-publisher per-domain "why SPF alone is insufficient against BEC" justification gap at the per-publisher per- domain layered-authentication-adoption documentation tier.
• DKIM failures explained — the per-recipient per-message DKIM-VERDICT-CATALOGUE companion documenting the seven canonical receiver-side Authentication-Results verdicts (dkim=none / neutral / pass / fail / policy / temperror / permerror) per RFC 6376 §3.9 + RFC 8601 §2.7.1 to this Business Email Compromise threat-model and defence-in-depth reference. Where THIS page documents the per-attacker per- target-domain BEC attack-vector catalogue (CEO-impersonation, vendor-invoice- spoofing, wire-transfer-redirect, payroll- diversion, gift-card-fraud) and the per- publisher per-domain layered authentication- plus-process defence framework, the DKIM-failures-explained spoke is the PER-MESSAGE-DKIM-VERDICT-FAIL-ATTRIBUTION- DIAGNOSTIC companion documenting the per-verdict receiver-side outcome catalogue that BEC-incident forensic-reconstruction relies on to attribute the per-message attack-vs-legitimate-mail signal. The BEC- defence operator AUDITING a suspected BEC incident retrieves the per-message Authentication-Results header and the DMARC aggregate-report <auth_results><dkim> block for the suspect message, then maps the per-message dkim= verdict to one of the seven canonical receiver-side outcomes the DKIM-failures- explained spoke catalogues to attribute the per-message BEC-attempt to its root cause class: (i) per-message dkim=none indicates the suspect message arrived without any DKIM signature — usually a per-publisher per-domain DKIM-never-deployed BEC-attack- surface gap; (ii) per-message dkim=fail indicates a DKIM-Signature header existed but cryptographically failed — typically a BEC-attacker-controlled spoofed signature attempt or a per-recipient downstream forwarder body-rewrite breaking a legitimate signature; (iii) per-message dkim=permerror indicates a malformed <selector>._domainkey.<d-tag> public-key TXT — sometimes a BEC-attacker publishing a malformed key on a look-alike domain to manufacture a "DKIM evaluation attempted" signal in the receiver's Authentication-Results header; (iv) per- message dkim=pass on a suspected BEC message indicates either a per-publisher per-domain DKIM-key- compromise or a per-publisher per-third- party-sender-re-signing-with-publisher- d-tag misconfiguration the BEC attacker exploited — the highest-severity BEC- incident root-cause class requiring immediate per-publisher per-selector key rotation. Read the DKIM-failures- explained spoke ALONGSIDE this BEC defence-in-depth reference when constructing the per-publisher per- domain BEC-incident forensic- reconstruction discipline — the spoke documents the per-message DKIM-verdict receiver-side outcome catalogue the BEC- defence operator MUST master to attribute every per-message BEC-attack-attempt to its correct DKIM-verdict-fail root-cause class.
• DMARC multi-domain strategy — the BEC-PORTFOLIO-WIDE-PER-DOMAIN- ENFORCEMENT-COVERAGE companion to this BEC defence playbook. Where THIS page enumerates the SIX BEC variants (CEO fraud, invoice fraud, attorney impersonation, payroll diversion, gift-card scam, M&A fraud) and the per-message investigation workflow the finance / treasury / fraud team follows once an individual BEC incident is reported, the multi-domain-strategy spoke documents the FOUR PER-PORTFOLIO-DOMAIN-CLASS ENFORCEMENT-COVERAGE DIMENSIONS the BEC- defender MUST close to deny the BEC-attacker per-organisational-perimeter unauthenticated- domain attack surface: (i) per-owned- active-sending-domain p=reject enforcement — every domain that emits commercial mail (the corporate domain, per-product brand domains, per-subsidiary domains acquired through M&A) MUST publish an aligned DMARC p=reject record so the BEC-attacker direct-domain-spoofing variant is denied at the receiver's DMARC engine; (ii) per-parked / per-non-sending owned-domain v=DMARC1; p=reject; sp=reject null-MX defensive publication — every domain the organisation owns but does NOT use for outbound mail (typo-variants, legacy domains, defensively-registered look-alike prefixes) MUST publish a reject-everything DMARC record and a null MX record so the BEC-attacker cannot use the dormant owned domain as a spoof source; (iii) per-look-alike unowned-domain registrar-watch + takedown workflow — the organisational-perimeter BEC-defence discipline includes a per-domain-monitoring registrar-watch service that surfaces newly-registered look-alike domains (.co vs .com, double-letter swaps, Unicode- homoglyph attacks) so the BEC-defender can initiate a UDRP / registrar-abuse takedown BEFORE the look-alike is weaponised in a per-target wire-transfer-fraud campaign; (iv) per-domain rua= aggregate- report ingestion under a single dashboard- per-organisation reporting umbrella — the per-owned-domain DMARC rua= publication MUST funnel every per-domain receiver-side aggregate report into a single BEC-defender dashboard so the per-message BEC-incident investigation workflow this page documents can be executed with the per-portfolio-domain authentication- verdict context available at the operator's fingertips. Read the multi-domain-strategy spoke ALONGSIDE this BEC playbook when designing the organisational-perimeter BEC- defence posture — the per-portfolio-domain enforcement-coverage catalogue is the canonical operator-facing companion to the per-message BEC-incident response workflow this page documents.
• DKIM selectors explained — the PER-PUBLISHER-PER-SELECTOR-DKIM- SELECTOR-PUBLICATION-AS-PUBLISHER-SIDE- CRYPTOGRAPHIC-IDENTITY-ANCHOR-COMPRESSING- BEC-ATTACK-SURFACE companion to THIS BEC playbook reference. Where THIS page documents the per-publisher per-domain BEC-attack-class catalogue (CEO impersonation, wire-fraud payment-redirection, vendor-invoice-redirect, attorney-impersonation, payroll-diversion, gift-card-extortion, W-2-data-theft) and the receiver-side and publisher-side BEC-defense control set (per-publisher per-domain DMARC p=reject enforcement, per- publisher per-domain SPF + DKIM + DMARC composite-publication, per-recipient inbox external-sender warning banners, per-recipient domain-similarity detection, per-organisation wire-transfer multi-channel verification protocol), the DKIM-selectors-explained spoke documents the per-publisher per-selector DKIM-selector publication discipline at FOUR per-selector-publication-vs-BEC-attack-class coupling dimensions: (i) per- publisher per-selector <selector>._domainkey.<d- domain> TXT-RR publication AS load- bearing publisher-side cryptographic identity-anchor compressing per-attacker BEC direct-spoof attack surface — per- attacker BEC direct-spoof variants (per- attacker per-message forged From: header claiming per-publisher organisational- domain identity without per-publisher per- selector DKIM-Signature header presence) are compressed by the per-publisher per-selector DKIM-Signature publication discipline THIS page documents the <selector>._domainkey.<d- domain> TXT-RR publication for; per- publisher per-domain DKIM-aligned-pass verdict production at the per-receiver per- message authentication boundary discriminates per-publisher legitimate-signed mail-stream from per-attacker direct-spoof BEC campaigns at the per-receiver per-message DMARC composite-verdict boundary; (ii) per- publisher per-selector key-rotation cadence floor AS BEC-defense publisher-side operational hygiene discipline compressing per-attacker key-compromise-window BEC- amplification surface — per- attacker per-publisher per-selector private- key compromise (per-publisher per-selector weak RSA key length, per-publisher per- selector private-key-custody breach, per- publisher per-selector stale-key-retention) opens per-attacker BEC-amplification window where per-attacker per-message cryptographic- signature forgery is feasible against per- publisher per-selector cryptographic identity; the per-publisher per-selector key-rotation cadence floor THIS page documents (RFC 6376 recommendation: at minimum quarterly rotation cadence) compresses the per- attacker key-compromise-window BEC- amplification surface at the per-publisher per-selector publication boundary; (iii) per-publisher per-domain multi- selector publication discipline AS per- publisher per-domain DKIM-signing-coverage- floor that compresses per-attacker BEC partial-coverage-bypass attack surface — per-attacker BEC campaigns exploit per- publisher per-domain DKIM-signing-coverage gaps (per-publisher per-third-party-SaaS- sender selector publication missing, per-publisher per-Workspace-tenant per- custom-domain dual-selector publication incomplete) where per-attacker per-message spoofing claiming the gap-sender mail-stream identity is undetectable at the per-receiver per-message DKIM-leg-evaluation boundary; the per-publisher per-domain multi-selector publication discipline THIS page documents (per-publisher per-stream selector segmentation, per-publisher per-third-party- SaaS-sender selector publication coordination, per-publisher per-Workspace-tenant per- custom-domain selector1._domainkey + selector2._domainkey dual- selector publication) compresses the per- attacker BEC partial-coverage-bypass attack surface at the per-publisher per-domain DKIM-signing-coverage-floor publication boundary; (iv) per-publisher per- selector DKIM publication AS per-publisher per-domain DMARC-aligned-pass evidence-stream input feeding BEC-defense receiver-side enforcement primitives — the per- receiver per-message BEC-defense enforcement consumes the per-publisher per-domain DMARC p=quarantine / p=reject verdict at the per- receiver per-message disposition-decision boundary; the per-publisher per-domain DMARC- aligned-pass verdict requires either per- message per-publisher per-selector DKIM- aligned-pass OR per-message per-publisher per-domain SPF-aligned-pass; the per-publisher per-selector DKIM-selector publication discipline THIS page documents IS the per- publisher per-selector input that produces the per-publisher per-domain DKIM-aligned- pass evidence stream feeding per-receiver per-message BEC-defense enforcement at the per-publisher per-domain composite- authentication-evidence boundary. Read THIS page when DESIGNING per-publisher per-domain BEC-defense posture; read the DKIM-selectors- explained spoke when UNDERSTANDING how the per-publisher per-selector DKIM-selector publication discipline IS the load-bearing publisher-side cryptographic identity-anchor compressing the per-attacker BEC direct- spoof and lookalike-domain attack surface THIS BEC playbook documents the receiver- side and publisher-side defense control set for.
• MTA-STS policy file byte-grammar — the load-bearing transport-layer anti- downgrade-AND-anti-MX-redirect BEC-defense control-primitive companion to this BEC defense-in-depth reference. Where THIS page documents the message-authentication-layer DMARC enforcement BEC-defense control primitive, the MTA-STS-policy-syntax spoke documents the per- publisher per-domain transport-layer policy-byte- grammar publication discipline whose mode: enforce + mx: policy-line publication is the canonical transport-layer defense against per-attacker MX-redirect-and- downgrade BEC variants. Four BEC-defense MTA- STS coupling dimensions matter: (i) per-attacker per-message MX-redirect-attack class — per- attacker DNS-cache-poisoning or per-attacker BGP- hijack producing per-receiving-MTA MX-lookup deflection to attacker-controlled SMTP relay is blocked by per-publisher MTA-STS mx: policy-line pattern-match enforcement at per- sending-MTA-side policy-fetch boundary; (ii) per-attacker per-message STARTTLS-downgrade- attack class — per-attacker active-MITM stripping STARTTLS extension from per-sending-MTA EHLO response is blocked by per-publisher MTA-STS mode: enforce + per-receiving-MTA- certificate-name-match validation at per-sending- MTA-side enforcement boundary; (iii) per- publisher per-domain composite BEC defense-in- depth layering — per-publisher SPF envelope- MAIL-FROM-layer + per-publisher DKIM application- layer + per-publisher DMARC composite-verdict- layer message-authentication enforcement COMPLEMENTED by per-publisher MTA-STS transport- layer anti-MITM enforcement form the composite per-publisher per-domain four-layer BEC defense control set; (iv) per-publisher per-domain DUAL BEC-attack-surface coverage — per-publisher DMARC enforcement closes the per-message direct- domain-spoof BEC variant, per-publisher MTA-STS enforcement closes the per-transport MX-redirect- and-downgrade BEC variant — together they form the composite per-publisher per-domain BEC- defense-in-depth publication portfolio every per-publisher per-domain BEC-defense deployment THIS page documents materially coordinates publication discipline against.
• DKIM DNS-TXT-RR byte-grammar publication
• DMARC identifier-alignment
• DMARC aggregate (RUA) reports
• DMARC troubleshooting — the PER-PUBLISHER-PER-DOMAIN-BEC-INVESTIGATION-AS-LOAD-BEARING-CONSUMER-OF-DMARC-TROUBLESHOOTING-DIAGNOSTIC-LADDER companion at four per-publisher per-domain BEC-investigation-vs-DMARC-troubleshooting-diagnostic-ladder coupling dimensions: (i) per-publisher per-domain BEC-investigation operationally consumes the DMARC-troubleshooting diagnostic-ladder when the per-publisher per-domain DMARC RUA aggregate-report stream THIS page documents the per-publisher per-domain BEC-defense-effectiveness-monitoring consumption-discipline of surfaces anomalous per-day per-receiver per-source-IP `policy_evaluated/dkim=fail` + `policy_evaluated/spf=fail` + `disposition=quarantine|reject` attribution rows — the per-publisher per-domain operator-side SIRT (Security Incident Response Team) workflow runs the DMARC-troubleshooting diagnostic-ladder symptom-to-publication-discipline-drift root-cause-attribution discipline against per-source-IP per-row evidence to classify the per-receiver per-day per-source-IP per-row attribution as legitimate-publisher-publication-drift (treat as ramp-readiness regression) vs per-attacker per-target-domain direct-domain-spoof BEC attack-attempt (treat as incident-response trigger); (ii) per-publisher per-domain BEC-investigation operationally consumes the DMARC-troubleshooting per-authentication-leg drift-classification taxonomy — the per-receiver per-day per-source-IP `dkim=fail` per-row class subdivides into per-publisher per-selector key-publication-discipline-drift (legitimate operator-side regression) vs per-attacker per-target-domain no-DKIM-Signature-present direct-domain-spoof (BEC attack-attempt) vs per-attacker per-cousin-domain DKIM-Signature-`d=`-tag-mismatch alignment-fail (BEC cousin-domain spoof) vs per-attacker per-mailing-list-cascade DKIM-resign-breakage (legitimate forwarder cascade NOT BEC attack); (iii) per-publisher per-domain BEC-investigation operationally consumes the DMARC-troubleshooting per-receiver per-publisher per-domain remediation-decision-tree — the per-publisher per-domain DMARC-troubleshooting spoke documents the per-publisher per-domain operator-side root-cause-attribution-to-remediation-action-mapping discipline whose per-publisher per-domain BEC-defense-stack publication-discipline-readiness-floor-preservation THIS page documents the per-publisher per-domain composite cross-layer per-attack-class defense-floor coordination posture of materially depends on for per-publisher per-domain BEC-defense ramp-readiness decision (deferring per-publisher per-domain `p=none → p=quarantine → p=reject` enforcement-mode progression when DMARC-troubleshooting diagnostic-ladder surfaces legitimate-publisher publication-discipline-drift root-cause vs progressing when per-publisher per-domain DMARC-troubleshooting confirms per-attacker per-target-domain direct-domain-spoof BEC attack-class attribution); (iv) per-publisher per-domain BEC-investigation operationally consumes the DMARC-troubleshooting `dkim=temperror` + `dkim=permerror` + `spf=temperror` + `spf=permerror` per-result-class verdict-attribution taxonomy — per-receiver per-day per-source-IP per-row `dkim=permerror` + `spf=permerror` attribution surfaces per-publisher per-domain DNS-publication-discipline-drift (per-publisher per-domain SPF 10-DNS-lookup-cap exceeded per RFC 7208 §4.6.4 / per-publisher per-selector DKIM TXT-RR malformed per RFC 6376 §3.6.1) that the per-publisher per-domain BEC-defense-stack THIS page documents the per-publisher per-domain composite cross-layer per-attack-class defense-floor coordination posture of catalogues against per-publisher per-domain operator-side per-attacker per-target-domain BEC-bypass via per-receiver per-day per-source-IP `policy_evaluated/disposition=none` disposition-softening cascade that the DMARC-troubleshooting spoke documents the per-publisher per-domain operator-side per-`permerror`-class-bypass mitigation-discipline of.
• SPF for Microsoft 365 — per-M365-tenant per-accepted- domain SPF authorisation publication- discipline IS the load-bearing per-tenant envelope-MAIL-FROM-layer first-leg BEC- defense control closing the per-attacker per-message direct-domain-spoof BEC variant via per-receiver envelope-MAIL- FROM-authorisation evaluation per RFC 7208 §4.6 — per-M365-tenant per- accepted-domain SPF-aligned-pass leg + per-tenant per-accepted-domain DKIM- aligned-pass leg compose the per-tenant per-accepted-domain DMARC composite- verdict whose p=quarantine / p=reject enforcement-mode publication closes the per-attacker per- message direct-domain-spoof BEC attack- surface THIS BEC playbook documents the per-publisher per-domain composite SPF + DKIM + DMARC + MTA-STS four-layer BEC defense-in-depth publication-floor coordination posture of at the per-M365- tenant per-accepted-domain composite envelope-MAIL-FROM-layer-authorisation- and-direct-domain-spoof-BEC-defense coordination boundary.
• SPF (Sender Policy Framework) primer
• CAA records explained — the PER-PUBLISHER-PER-DOMAIN-CAA-RR-CERTIFICATE-AUTHORITY-AUTHORIZATION-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING-PKI-LAYER-ANTI-CA-IMPERSONATION-PRIMITIVE-CLOSING-BEC-LOOKALIKE-DOMAIN-AND-COUSIN-DOMAIN-ATTACK-CLASS-VIA-CA-CERTIFICATE-MIS-ISSUANCE companion at four per-publisher per-domain CAA-RR-publication-discipline-vs-BEC-defense-stack coupling dimensions: (i) per-publisher per-domain CAA-RR 0 issue "<ca-domain>" property-tag publication-discipline per RFC 8659 §4.2 IS the load-bearing per-publisher per-domain PKI-layer anti-CA-impersonation primitive closing per-attacker per-target-domain rogue-CA cert-issuance attack-class against per-attacker per-lookalike-domain + per-attacker per-cousin-domain BEC infrastructure provisioning — CA enforcement of per-publisher per-domain CAA-RR allowlist per RFC 8659 §3 BLOCKS per-attacker per-lookalike/cousin-domain TLS-cert acquisition that BEC infrastructure-provisioning attack-class structurally depends on for HTTPS-served credential-harvesting and spear-phishing message-source infrastructure; (ii) per-publisher per-domain CAA-RR 0 iodef "mailto:<security-contact>" incident-objective-description-exchange-format publication-discipline per RFC 8659 §4.4 IS the per-publisher per-domain operator-side per-CA-mis-issuance-incident attribution-mailbox publication primitive whose per-publisher per-domain anti-BEC composite-defense-stack THIS page documents the per-publisher per-domain anti-BEC seven-protocol defense-in-depth-publication-floor coordination of consumes for per-publisher per-domain operator-side per-attacker per-CA-mis-issuance incident-attribution discipline; (iii) per-publisher per-domain CAA-RR per-CA-allowlist publication-discipline IS structurally parallel publication-discipline reference to per-publisher per-domain SPF + DKIM + DMARC + BIMI + MTA-STS + DANE + TLS-RPT seven-protocol composite anti-BEC defense-in-depth publication-discipline THIS page documents the per-publisher per-domain anti-BEC composite-defense-stack publication-discipline-floor coordination of — the CAA-RR per-CA-allowlist publication-discipline IS the EIGHTH protocol in the per-publisher per-domain composite anti-BEC defense-in-depth publication-discipline stack closing the per-attacker per-lookalike-domain + per-attacker per-cousin-domain PKI-layer cert-mis-issuance attack-class subset that the per-publisher per-domain seven-protocol defense-stack alone does not structurally address; (iv) per-publisher per-domain CAA-RR publication-discipline drift (missing CAA-RR at apex / overly-permissive `0 issue ";"` deny-all-but-self mis-publication / missing `iodef` incident-mailbox / CAA-RR DNSSEC-unsigned-zone exposing per-attacker per-zone CAA-RR DNS-cache-poisoning attack-class) directly opens per-publisher per-domain PKI-layer per-attacker per-target-domain rogue-CA cert-issuance attack-window structurally parallel to per-publisher per-domain SPF `+all` permissive-mis-publication + DMARC `p=none` permissive-publication drift the per-publisher per-domain anti-BEC composite-defense-stack THIS page documents the per-publisher per-domain anti-BEC composite-defense-in-depth publication-discipline of catalogues against — together the per-publisher per-domain anti-BEC seven-protocol composite-defense-stack THIS page documents the per-publisher per-domain anti-BEC composite-defense-in-depth publication-discipline-floor coordination of AND the per-publisher per-domain CAA-RR PKI-layer per-CA-allowlist publication-discipline compose the per-publisher per-domain composite eight-protocol cross-layer authentication-and-PKI publication-discipline-floor coordination boundary closing the per-attacker per-target-domain BEC composite attack-surface across SMTP-application-layer + PKI-layer publication-discipline-floor primitives.
• DMARC records explained
• MX records explained — the inbound-routing-integrity companion to this BEC defense guide. Where this page catalogues the per-publisher per-domain seven-protocol anti-BEC composite-defense-stack against direct-domain-spoof and lookalike-domain wire-fraud, the MX-records spoke documents the inbound routing layer those defenses presuppose: an attacker who can alter a domain's MX records (via registrar or DNS-hosting account takeover) silently re-routes inbound mail to attacker-controlled mail exchangers, enabling reply-chain interception and thread-hijacking BEC even when SPF / DKIM / DMARC are correctly published. Read the MX-records spoke when hardening the DNS-zone and registrar account-takeover attack-surface the BEC composite-defense-stack THIS page documents depends on.
• Forwarding issues with SPF — the SRS / ARC / mailing-list / .forward catalogue of forwarder-induced SPF failures. Legitimate forwarded mail that arrives with a broken SPF result is the noise BEC actors exploit: it normalises SPF-fail at the receiver and erodes the alignment confidence the BEC composite-defense-stack relies on — understanding which failures are benign forwarding artefacts is part of the triage.
• DKIM explained — BEC defense ultimately rests on DMARC enforcement, and DKIM is one of the two authentication legs that makes p=reject trustworthy: a forged direct-domain BEC message cannot produce a valid signature that aligns with the From-header domain. Read the DKIM primer to understand the cryptographic leg the enforcement this page recommends depends on.
• DKIM best practices (the deployment-rules catalogue) — the operational hardening companion to the DKIM primer: 2048-bit RSA keys, scheduled selector rotation, and removal of stale public-key records are the publisher-side hygiene rules that keep the p=reject DKIM leg durably trustworthy against the direct-domain spoofing BEC relies on. Read it to turn “DKIM is enabled” into “DKIM is correctly and durably enabled.”
• Microsoft SNDS + JMRP monitoring — outbound abuse from compromised accounts or infrastructure surfaces first as spam-trap hits and Junk-click complaints: Microsoft's SNDS filter verdicts and JMRP ARF stream are an early-warning channel for your own sending IPs.

13. Audit your BEC defense posture

DMARC Analyzer is the operator console for the email-authentication layer of the BEC defense stack. The dashboard ingests DMARC aggregate (RUA) and forensic (RUF) reports via includes/DmarcParser.php and includes/ForensicReportParser.php, surfacing direct-spoof BEC delivery attempts as failing messages from sending IPs you did not authorise. The Domain Security Checker runs live DNS lookups across SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, CAA, and DNSSEC through includes/DnsChecker.php so you can verify your own DMARC posture is at p=reject (the prerequisite for direct-spoof BEC blocking). The Email Header Analyzer at header_analyzer.php diagnoses individual suspicious messages including display- name forgery and lookalike-domain From: addresses. The email-authentication layer is necessary but NOT sufficient for BEC defense; pair these tools with the layered control stack in §6.

Sign up — Free plan Audit my BEC defense posture