Skip to content
EML-035 Email Evidence

What should I ask an email provider to preserve?

title: What should I ask an email provider to preserve? subtitle: Describe the account, message, period and evidence types clearly enough for the provider to identify the relevant records. slug: what-should-i-ask-an-email-provider-to-preserve series: email-evidence section: provider-and-account-records card_type: question_card pathway_order: 30 section_order: 2 status: draft public_safe: true video_ready: true word_count: 582 estimated_read_time_seconds: 241 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - preservation request - provider records - message trace - audit logs sources: - title: 'Microsoft Learn: Trace an email message in Exchange Online' url: https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/trace-an-email-message - title: 'Microsoft Learn: Graph-based message trace API onboarding guide' url: https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/graph-api-message-trace - title: 'Microsoft Learn: Search the audit log for mailbox activities' url: https://learn.microsoft.com/en-us/purview/audit-log-search-for-mailbox-activities - title: 'Microsoft Learn: Audit log activities' url: https://learn.microsoft.com/en-us/purview/audit-log-activities - title: 'Google Workspace Admin Help: Troubleshoot message delivery with Email Log Search' url: https://support.google.com/a/answer/7513679?hl=en-GB

What should I ask an email provider to preserve?

Describe the account, message, period and evidence types clearly enough for the provider to identify the relevant records.

Script

If provider records may matter, act early.

The useful question isn’t simply:

“Can you preserve everything about this email address?”

That may be too vague to locate the event, too broad to be proportionate, or too narrow to protect the records you actually need.

Start by identifying the account and message as precisely as possible.

Provide the full email address or account identifier.

Give the complete Message-ID, including the angle brackets where present.

Include the sender and recipient addresses, exact date and time, timezone, subject and any provider-specific network, campaign or transaction identifier.

Where the time is uncertain, explain the range rather than inventing precision.

Then identify the categories of records that may answer the question.

For the message itself, that may include:

the message content and attachments;

the original header and MIME structure;

Sent, Draft, Deleted, Junk or archive copies;

message-trace or email-log-search records;

delivery, rejection, redirection and quarantine events;

internal message identifiers;

security verdicts;

and records linking the message to a tenant, campaign, API process or authenticated user.

For the account, consider:

sign-in and session records;

source IP addresses and available ports;

device, browser, application and operating-system information;

authentication methods and multi-factor events;

password, recovery and security-setting changes;

registered or trusted devices;

delegated access;

connected applications and tokens;

mailbox and forwarding rules;

and account alerts or compromise indicators.

The right list depends on the issue.

If the question is whether the message was delivered, you may not need the whole account history.

If the account holder denies sending it, preservation should usually cover the sending event, sign-ins, sessions, relevant devices, mailbox actions and evidence of compromise.

If the message came from a shared mailbox or platform, preserve delegate, tenant, campaign, workflow and API records rather than assuming one named account acted alone.

State the relevant time period.

Include enough time before and after the email to capture sign-in, draft, sending, deletion, rule creation and follow-up activity.

A window of only a few seconds around the final delivery time may miss the account access that matters.

Also identify the timezone used in your request.

Provider records may be stored or displayed in UTC even when the user interface shows local time.

Ask the provider to preserve existing records.

Don’t ask it to create conclusions it may not be able to support.

For example, “Preserve records identifying the person who sent the email” assumes the system recorded a person.

A better request identifies the records:

“Preserve account, session, device, authentication, mailbox-audit and message-trace records associated with this message and account during this period.”

The lawful, contractual or organisational route will depend on the jurisdiction, provider, organisation and case type.

Follow the correct process and seek specialist or legal support where necessary.

The content of a preservation request should still be technically clear, whatever route is used.

Record what was sent, when, to whom and which identifiers were included.

If the provider replies that a record type isn’t held, ask whether a related record exists under another name or system.

Message trace, mailbox audit, security events and sign-in logs are often separate datasets with different retention and access arrangements.

The common mistake is to preserve the email content but not the account activity.

The opposite mistake is to request an entire lifetime of unrelated account data without explaining the investigative need.

Target the message, account and period.

Protect the records that may disappear.

And write the request so that the provider can search its systems without having to guess which event you mean.

Key takeaway

Preservation should be targeted but broad enough to protect the message, account activity and provider identifiers needed to test attribution and compromise.

Source notes

Keep moving

Where this question leads

These links explain why the next page may matter, rather than presenting an undifferentiated list.