Begin with the identity, not the incident label
Business email compromise describes a harmful business scenario, not one unique email authentication result. A deceptive request might come from an impersonating domain, a compromised supplier mailbox, an abused internal account or an unauthorized application using legitimate sending infrastructure. The investigation must establish which identity was presented, which system authenticated it and which business authority the recipient believed it represented. Without that separation, a team can repair the wrong control while the underlying risk remains.
The IC3 cloud-based email advisory, dated April 6, 2020, describes how compromised cloud email accounts can support BEC and recommends independent verification and account protections. It is background guidance, not evidence of a current incident. Microsoft's compromised-account guidance likewise describes mailbox abuse and investigation in Microsoft 365. Neither source establishes that any account discussed in a hypothetical exercise has actually been compromised.
Preserve the request and pause the business action
The first operational question is what the message asks someone to do: change payment details, release information, approve access, alter a supplier record or take another consequential action. Record the action in neutral language. Pause execution through the organization's established process when the request is suspicious. Avoid turning the investigation itself into an unauthorized payment, account change or disclosure. An analyst can document the request without following it.
Preserve the original message and relevant business record in an approved restricted location. A screenshot can show presentation but cannot substitute for complete message evidence. A forwarded copy may change the context and add headers; label it accordingly. Keep a chronology with time zones and identify who collected each item. For a shared summary, remove unnecessary personal data while retaining the distinctions needed to compare identities. Do not circulate credentials, access tokens or complete sensitive correspondence as routine troubleshooting material.
Construct an identity stack
List the visible display name, parsed From address, Reply-To address, envelope sender, DKIM signing domain, receiver authentication result and alleged business role. Add the mailbox or application account only if authorized investigation evidence identifies it. These are separate rows, not interchangeable labels for “the sender.” The domain that authenticated a message may differ from the person whose authority the recipient inferred.
RFC 9989 makes the boundary explicit: DMARC uses domain alignment and does not authenticate entities other than domains or analyze content. A successful aligned result therefore cannot certify an invoice, a new bank detail or an executive's approval. Conversely, a failed result does not establish account takeover. An investigation should avoid jumping from a protocol result to a conclusion about who controlled a person’s account.
Establish the trust boundary for each observation
Determine which receiver produced the authentication result and whether the record was obtained through that receiver's trusted interface or logs. RFC 8601 addresses trust in Authentication-Results assertions. A sender can include misleading-looking text, so the presence of a field is not enough. Document the basis for treating an assertion as local and trusted. If that basis is absent, mark the result unverified rather than repeating it as fact.
Application logs and account audit records answer different questions. A sending log may show a successful submission without proving the human intended it. A mailbox audit may show a rule change without proving that the rule was malicious. Combine observations by time, account and message identifiers where authorized, preserving uncertainty when the linkage is weak. Avoid treating a single unusual location or isolated error as conclusive evidence of compromise.
Compare mechanisms before selecting controls
Use an identity-and-control matrix. For exact-domain impersonation without aligned authentication, examine domain policy and the sending path. For display-name or lookalike-domain abuse, examine presentation, recognition and independent business verification. For suspected account compromise, examine account access and unauthorized actions. For an abused application, inspect its authorization and message-construction boundaries. More than one mechanism can occur in the same case.
Microsoft's guidance lists potential symptoms such as suspicious inbox rules, forwarding and missing or deleted messages. These are investigation leads, not automatic verdicts. Its remediation sequence includes disabling an affected account, revoking access and reviewing authentication devices, consented applications, roles and forwarders. Those are consequential administrative actions for an authorized responder. This article does not instruct an assistant to perform them, grant permissions or collect credentials; it identifies the appropriate response domain once evidence supports the hypothesis.
The operational comparison worksheet
Create one row per hypothesis. Include the asserted identity, supporting observation, source of that observation, conflicting evidence, affected control, proposed next authorized check and the person responsible. Add a confidence label with a plain-language explanation. “Trusted receiver reports aligned DKIM for the supplier domain” is narrower and more useful than “supplier confirmed safe.” “Recipient remembers the display name” is not equivalent to an authenticated supplier address.
Add a separate business-verification row. Identify a contact channel established before the suspicious request, the exact change that needs confirmation, the authorized verifier and the recorded outcome. The response should confirm or reject the requested business action, not merely that the contact recognizes the sender name. Do not use telephone numbers, links or alternative addresses supplied only in the questionable message as independent verification. This proposed worksheet is not an executed incident response record.
Fictional diagnosis: an invoice-change request
A fictional manufacturer receives a request to change a supplier's payment destination. The display name matches the account manager, and trusted receiver evidence shows aligned authentication for the supplier's real domain. The recipient assumes this rules out BEC. The security team instead records a narrower conclusion: the message used an authenticated supplier-domain path. Whether the supplier account, an integration or an authorized person initiated the change remains unknown.
Using a previously recorded supplier contact, the business owner would verify the specific proposed change. An authorized supplier responder would investigate their own account and application evidence. If the supplier denies the request, that denial supports stopping the change but does not by itself identify how the email was sent. The case stays open until account or service evidence resolves the mechanism. This entire example is fictional; no payment detail, supplier account or real correspondence was obtained.
Close each uncertainty with the right evidence
A sound conclusion states what was observed, what mechanism is supported, what remains uncertain and which control was changed through authorization. Do not label every message from the affected domain malicious, claim that a DNS edit contains an account takeover, or declare remediation complete merely because later mail authenticates. Business-process verification, account containment and mail authentication each answer different questions.
The catalogue requires a redacted identity-and-control comparison built from trusted message evidence. That evidence remains open. This draft provides a method and fictional case, not trusted original message material. Independent specialist review, current source applicability, production route checks, visual accessibility and owner release are also open. Publication should wait for an authorized evidence package that demonstrates the comparison without exposing sensitive account data or implying that unperformed response actions occurred.