What should a supervisor ask before relying on email evidence?¶

title: What should a supervisor ask before relying on email evidence? subtitle: The supervisor needs to test the proposed conclusion, the preservation and the missing links—not become an email engineer. slug: what-should-a-supervisor-ask-before-relying-on-email-evidence series: email-evidence section: practical-tools card_type: manager_tool pathway_order: 44 section_order: 3 status: draft public_safe: true video_ready: true word_count: 538 estimated_read_time_seconds: 223 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - manager questions - supervision - decision making - attribution sources: - title: 'Microsoft Learn: Email entity page in Defender for Office 365' url: https://learn.microsoft.com/en-us/defender-office-365/mdo-email-entity-page - title: 'Microsoft Learn: Email analysis in investigations' url: https://learn.microsoft.com/en-us/defender-office-365/email-analysis-investigations - title: 'Microsoft Learn: Respond to a compromised email account' url: https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account - title: 'NCSC: Phishing attacks — defending your organisation' url: https://www.ncsc.gov.uk/guidance/phishing

What should a supervisor ask before relying on email evidence?¶

The supervisor needs to test the proposed conclusion, the preservation and the missing links—not become an email engineer.

Script¶

A supervisor doesn’t need to understand every email-header field before making a sound decision.

They do need to know what conclusion the team is asking them to rely on.

Start with the proposition.

Is the evidence being used to show that the message existed, that it was delivered, that an account sent it, that a device was involved or that a person wrote it?

Those are different propositions.

Then ask what has actually been preserved.

Is there a native original in the mailbox?

Do you have the full header and attachments?

Or is the conclusion being drawn from a screenshot, forward or copied extract?

A weak source may still support a limited conclusion, but that limitation needs to be visible.

Next, ask where the key record came from.

Was it created by the recipient’s provider, the claimed sender’s provider, a security platform, the sender’s own software or somebody summarising the result?

A label such as “sender IP”, “authenticated” or “opened” may hide a narrower technical event.

Ask what the field really represents.

Then test the attribution chain.

Does the From address merely display the identity?

Did authentication show an aligned domain route?

Did provider records link the message to an account?

Did account records identify a session or application?

Was that session linked to a device?

What links the device or account to the person?

If the team has skipped one of those steps, make the gap explicit.

Ask about realistic alternatives.

Could the address have been spoofed?

Could the genuine account have been compromised?

Was the mailbox shared or delegated?

Could an automated platform or workflow have generated the message?

Could the IP address belong to a mail server, VPN, mobile gateway or shared network?

Could a screenshot or forwarded copy have lost or changed information?

Alternative explanations shouldn’t be listed for decoration.

The team should say which ones have been tested and what evidence supports or challenges them.

Then ask about time.

Are the timestamps from the sender’s message, the receiving server, message trace, mailbox delivery or account login?

Were timezones normalised?

Do the records describe creation, submission, delivery, access or some other event?

Ask what records may still disappear.

Does the provider hold short-lived message trace, audit, sign-in, device or campaign data?

Has a preservation request been made through the correct route?

If immediate risk exists, has the account, payment or device been protected?

Finally, ask whether the proposed action is proportionate to the remaining uncertainty.

A low-risk enquiry may justify further preservation and checks.

A major intervention based on email attribution should normally require a clearer chain and stronger corroboration.

The common supervisory mistake is to ask:

“Are you sure?”

That invites a yes or no answer.

Better questions expose the reasoning.

“What does this record show directly?”

“What inference are we adding?”

“What is the weakest link?”

“What else could produce the same result?”

“What evidence outside the email supports the conclusion?”

A good supervisor doesn’t block action by demanding technical perfection.

They make sure the action matches the strength of the evidence.

The email may be a strong line of enquiry, a reliable account record or compelling evidence when properly corroborated.

The supervisor’s job is to know which of those it is.

Ask what the evidence shows directly, which inference is being added and what realistic alternative could produce the same record.

Manager questions¶

• [ ] What exact proposition are we relying on: message, delivery, account, session, device, person or location?
• [ ] Do we have the native original, full header and attachments?
• [ ] Which trusted system created the key record or label?
• [ ] What does that record show directly?
• [ ] What inference are we adding?
• [ ] Has the message been linked to a provider account, tenant, campaign, session or application?
• [ ] What links that account or session to a device or person?
• [ ] Could spoofing, compromise, shared access, delegation or automation explain it?
• [ ] Could the IP address represent a mail server, VPN, mobile gateway or shared network?
• [ ] Which timestamp and timezone are being used, and what event does it record?
• [ ] What independent evidence supports or challenges the conclusion?
• [ ] Which provider records may still disappear?
• [ ] Has immediate financial, account or device risk been addressed?
• [ ] Is the proposed action proportionate to the remaining uncertainty?

Related questions¶

• What corroboration should I look for?
• Can an email identify the person who wrote it?
• Does successful DKIM prove the named sender wrote it?
• Does an IP address in the header identify the sender’s location?

Source notes¶

• Microsoft Learn: Email entity page in Defender for Office 365
• Microsoft Learn: Email analysis in investigations
• Microsoft Learn: Respond to a compromised email account
• NCSC: Phishing attacks — defending your organisation