A fraud-response team needs a short account of who the message claimed to be, what the receiving system actually verified and which business action remains unsafe. A long header dump alone does not answer those questions. Preserve technical originals, then create a decision-oriented summary with confidence and unknowns.
Keep four identities separate
Record the visible author address, Reply-To, envelope identity and DKIM signing domains where present. Add the apparent person or organization represented by display text as a separate claim. A legitimate-looking display name can coexist with a different domain. DMARC examines domain alignment, not whether the named executive approved the message. RFC 9989.
Do not substitute a source IP for the responsible person or customer. Shared services, forwarding and gateways complicate the route. Treat infrastructure ownership as a lead requiring correlation with service records and authorized investigation, not a ready-made accusation.
Label each evidence layer
The original export is the captured artifact. Receiver results are statements from a specific authentication service. Business verification is a separate confirmation through the organization's authorized workflow. Attribution is an investigative conclusion that may remain unresolved. Put those layers in separate fields so a fraud analyst does not mistake one for another.
RFC 8601 describes the trust boundary for Authentication-Results. A field copied from an untrusted source cannot become authoritative merely by being included in the incident package. RFC 8601. Preserve questionable fields as evidence of what was present, but label them untrusted and request the receiver's corroborating record.
Build the handoff record
Include a case identifier, collection owner, receiver-observed time when available, original hash, sharing-copy hash, observed identities, business request, known impact and immediate next action. State whether a payment was requested, initiated or confirmed sent; do not infer loss from the wording of an email. Keep unnecessary personal or financial details out of a broadly shared summary.
For financial requests, a known-contact check belongs with the payment owner. The FBI recommends verifying account and payment changes independently through a known channel. FBI guidance. Authentication findings should inform that response without becoming financial authorization.
Review a complete hypothetical handoff
Case DEMO-FRAUD-01 is a written example, not a captured incident. Stipulate the display name Example Accounts and visible From billing@brand-payments.test. Reply-To, envelope sender and DKIM signing domains are not supplied. A copied header claims a pass for brand.test, but its trusted receiver origin is unknown; authentication and actor attribution remain unresolved.
Original file, collection timestamp, original hash, redacted-copy hash and transformation log are all unavailable in this example. Do not fabricate any of those values. In a real case the authorized collector retains the original and records exactly what a recipient-specific derivative changes, then computes each file’s actual digest. A digest identifies bytes, not the human sender.
Assume the business request is a payment change. Whether money was initiated or sent is unknown, and known-contact verification is not completed. The proposed finance owner preserves the verification hold; the proposed mail owner obtains trusted receiver evidence; the incident lead approves any specific sharing. These are unaccepted role assignments for teaching, not executed callbacks, redactions or reports.
Close the handoff with an explicit decision request: preserve a payment hold, investigate an account, verify a supplier instruction or await a named piece of evidence. That keeps the technical team from inadvertently deciding a financial action and keeps the fraud team from assuming every unanswered technical question blocks immediate containment.