Treat payment authority as a separate question
A supplier's email can be correctly authenticated and still contain an unauthorized payment-change request. A compromised mailbox or application may use the supplier's legitimate sending infrastructure, while an impersonator may use a different domain with a familiar display name. The immediate business question is whether the requested change is authorized, not whether the message contains the word pass. Keep the financial decision separate from the technical investigation so neither substitutes for the other.
RFC 9989 limits DMARC to domain authentication relationships and explicitly excludes content analysis and authentication of entities other than domains. It cannot approve a bank-account change or establish the intentions of a supplier's employee. A passing result is useful evidence about domain use, but it is not a payment instruction that the organization must follow. This manuscript proposes a defensive process; no payment, account update or external contact was performed.
Preserve the request without executing it
Place the requested change on hold through the existing purchasing or finance process. Record what the message asks to change, which supplier record it affects, when the change is supposed to take effect and who received it. Avoid copying full financial details into a broadly accessible incident ticket. An approved restricted record can preserve the original while the working summary describes the change using a reference identifier and the minimum necessary context.
Retain the original message and its provenance. A forwarded copy or screenshot can help show how the request appeared, but it is not interchangeable with the original message or receiver logs. Record the collection time and time zone. If someone has already acted, escalate through the organization's established financial incident procedure rather than assuming the change can be silently reversed. This article does not authorize transfers, recalls or communications with a bank.
Establish which identity was used
Compare the actual From domain with the supplier domain in the trusted vendor record. Keep the display name, Reply-To address, envelope identity and DKIM signing domain separate. A different-domain message can authenticate for its own domain while misleading the reader about affiliation. An exact supplier-domain message with aligned authentication can still originate through an abused account or service. Do not select the compromise hypothesis solely because the request is unusual.
Use trusted receiver evidence when interpreting authentication. RFC 8601 explains why Authentication-Results fields require a trust boundary. A sender-supplied line, screenshot or forwarded header excerpt may not establish the relevant receiver's evaluation. Record which receiver produced the result and which aligned path was observed. When evidence is incomplete, say so instead of forcing a pass-or-fail conclusion into the finance decision.
Verify through an established independent route
The IC3 cloud-email BEC advisory, published April 6, 2020, recommends independent verification of suspicious business requests. Use a supplier contact route that was established before the questionable request, such as the organization's existing verified vendor record. A new telephone number, alternative email address or verification link supplied only in that message is not an independent source. The cited advisory supports this general principle, not a current incident claim.
Ask the authorized business verifier to confirm the specific proposed change through the established process. Confirming that a person recognizes the sender name is weaker than confirming that the change itself was requested and approved. Where policy requires separate approvers, preserve that separation. Do not let urgency in the message replace the organization's approval requirements. The technical analyst can supply identity evidence but should not silently become the financial approver.
Coordinate the technical investigation carefully
If evidence points toward supplier account abuse, communicate through an approved verified contact and share only the relevant redacted evidence after authorization. The supplier's authorized responder owns investigation of their systems. The receiving organization should not assert that it has proved a supplier takeover merely because a message authenticated and the supplier denied the payment request. An integration, delegated sender or other mechanism may require investigation.
Microsoft's compromised-account guidance lists suspicious inbox rules, forwarding and missing messages among possible indicators, and describes account response for Microsoft 365. It is a reference for an authorized supplier responder in that environment, not permission to inspect another organization's accounts. No account access, session revocation, rule deletion or credential collection is part of this manuscript's work.
A payment-change evidence worksheet
Build a worksheet with four linked sections. The request section records the supplier reference, change type, requested date and business owner. The identity section records actual domains, trusted authentication observations and the evidence source. The verification section records the independently established contact route, authorized verifier, precise question and response. The decision section records approval or rejection, required approvers, permitted implementation path and any unresolved investigation.
Keep financial account identifiers out of general-purpose copies. Use consistent placeholders where comparison matters, and store the complete original only in an approved restricted location. Add a column distinguishing observed facts from hypotheses. “Supplier-domain aligned DKIM observed at our receiver” is a fact only if the evidence supports it; “supplier employee approved the change” requires separate business confirmation. The worksheet should never promote the former into the latter automatically.
Fictional diagnosis: a familiar supplier thread
A fictional facilities team receives a request in an established supplier conversation asking to change future payment details. The message uses the supplier's real domain and hypothetically passes DMARC at the receiver. The recipient assumes the existing thread and authentication result make the change safe. A second reviewer instead pauses the update and checks the approved supplier record for the established verification route.
In the exercise, the supplier contact denies authorizing the change. That response supports rejecting the request under the business process, but the mechanism remains unresolved until authorized technical evidence is available. The investigation would preserve the message and share a minimal approved summary rather than forwarding full payment details widely. This is a fictional scenario, not a real denial, compromise finding, verification call or prevented loss. It illustrates why business verification and domain authentication answer different questions.
Close the financial and technical tracks separately
Record the disposition of the requested change even if the technical investigation continues. Conversely, do not declare the business issue resolved merely because an account was secured: someone may already have modified a supplier record or acted on the request. Reconcile the actual business record with the authorized decision and document who verified the outcome. Any such action requires the organization's normal authority; none has been performed here.
The catalogue requires a redacted abuse scenario with identity evidence, control boundary and independent business verification. That original evidence remains open. The proposed worksheet and fictional exercise do not satisfy it. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. A publishable version needs an authorized evidence package that demonstrates the verification process without exposing financial identifiers or making unsupported allegations about a supplier.