Skip to content
EML-039 Email Evidence

Who may hold relevant email records?

title: Who may hold relevant email records? subtitle: The message, mailbox, sending service and identity provider may each hold a different part of the answer. slug: who-may-hold-relevant-email-records series: email-evidence section: provider-and-account-records card_type: question_card pathway_order: 29 section_order: 1 status: draft public_safe: true video_ready: true word_count: 638 estimated_read_time_seconds: 264 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - provider records - data holders - message trace - account attribution 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: Search the audit log' url: https://learn.microsoft.com/en-us/purview/audit-search - title: 'Google Workspace Admin Help: Troubleshoot message delivery with Email Log Search' url: https://support.google.com/a/answer/7513679?hl=en-GB - title: 'Microsoft Learn: Sign-in log activity details' url: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-in-log-activity-details

Who may hold relevant email records?

The message, mailbox, sending service and identity provider may each hold a different part of the answer.

Script

You’ve preserved the email and identified the questions you need to answer.

The next step is working out who may hold the records.

That isn’t always the same organisation whose name appears in the From address.

An email can pass through several services before it reaches the recipient. The sender may use a personal mailbox, an employer’s system, a webmail provider, a customer-management platform, a security gateway or a mailing service.

Each organisation may hold a different part of the story.

Start with the recipient’s system.

The recipient’s mailbox may hold the best preserved copy of the message, the conversation, replies, attachments and folder context.

The recipient’s email provider or organisational administrator may hold message-trace records showing when the message entered the service, whether it was rejected, deferred, filtered, redirected, quarantined or delivered.

Security systems may separately hold malware verdicts, URL analysis, attachment hashes, spam classifications and details of any protective rewriting.

Then identify the system that handed the message to the recipient’s provider.

The trusted Received chain may point to a webmail provider, corporate gateway, hosting company, mailing platform or cloud service.

That organisation may be able to link the handover to a customer account, tenant, campaign, API credential or internal message identifier.

But the outbound server address alone may serve thousands or millions of customers.

You need the provider-specific identifiers, exact time, recipient and complete Message-ID to find the right event.

The claimed sender’s mailbox provider may hold another layer.

Depending on the service and the records available, that may include the sent message, drafts, account sign-ins, sessions, device information, security alerts, mailbox rules, forwarding settings, delegated access and connected applications.

For an organisational account, the employer or system administrator may hold more detailed audit information than the user can see.

The identity provider may be separate from the email service.

A business might use Microsoft Entra ID, Google identity services or another single-sign-on provider to control access to the mailbox.

That identity system may record sign-in attempts, authentication methods, session identifiers, registered devices and security-policy results.

A customer-management or mailing platform may hold records that the mailbox provider doesn’t.

It may know which user selected the template, which campaign was sent, which customer record triggered it, which API key submitted it and whether the message was automatic.

A domain registrar or DNS provider may help identify who controlled a domain or configured email authentication, but it won’t normally hold the content or user session that sent a particular message.

A network provider may hold records about an IP address used to access an account, but only if the email or identity provider first supplies a relevant address and accurate time.

The device itself may hold drafts, cached messages, attachments, browser sessions, tokens, notifications and local mail-client data.

And another recipient may hold a better copy if the first recipient deleted, forwarded or altered theirs.

So don’t begin with one broad request sent to the most visible company.

Map the roles.

Who received the message?

Who delivered it?

Who hosted the claimed sender’s account?

Who authenticated the user?

Was a third-party platform involved?

Which organisation controlled the domain?

Which device or network may hold the final link?

Then match the request to the question.

If you need to prove delivery, message trace may be the right source.

If you need to identify the sending account, the sending provider or platform matters.

If you need to test compromise, sign-in and audit records matter.

If you need to identify the person, you will usually need to combine provider, device and contextual evidence.

The common mistake is to treat “the email provider” as one data holder with every record.

Modern email is usually a chain of services.

A careful investigator follows the message through that chain and asks each organisation only for the part it is likely to hold.

Key takeaway

Map the email journey before sending requests. The organisation that delivered the message may not be the organisation that knows which account, device or user triggered it.

Source notes

Keep moving

Where this question leads

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