What if the sender’s account was compromised?¶
title: What if the sender’s account was compromised? subtitle: A message may genuinely come from the real account without having been sent by the account holder. slug: what-if-the-senders-account-was-compromised series: email-evidence section: sender-and-account-attribution card_type: question_card pathway_order: 10 section_order: 4 status: draft public_safe: true video_ready: true word_count: 528 estimated_read_time_seconds: 218 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - account compromise - mailbox audit - session - alternative explanation sources: - title: 'Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts' url: https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts - title: 'Microsoft Learn: Respond to a compromised email account in Microsoft 365' url: https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account - title: 'Microsoft Learn: Audit log activities' url: https://learn.microsoft.com/en-us/purview/audit-log-activities - 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: 'Google Workspace Admin Help: Troubleshoot message delivery with Email Log Search' url: https://support.google.com/a/answer/7513679?hl=en-GB
What if the sender’s account was compromised?¶
A message may genuinely come from the real account without having been sent by the account holder.
Script¶
A message can pass authentication, appear in the real account’s Sent Items and travel through the genuine provider.
The account holder may still deny sending it.
One realistic explanation is account compromise.
That doesn’t mean every denial should be accepted. It means the possibility has to be tested rather than ignored.
If somebody gains access to an email account, they may send messages using the genuine address and provider. SPF, DKIM and DMARC may all pass because the message followed an authorised route.
The header may prove that the real service sent the email.
It may not prove which person controlled the session.
Treat the account as a separate scene.
Preserve the message, but also preserve the account activity around it.
Look for sign-ins, session identifiers, IP addresses, device details, multi-factor events, security alerts, password or recovery changes, connected applications, OAuth grants, forwarding rules, inbox rules and delegated access.
Check Sent Items, Drafts, Deleted Items, Junk and archive folders.
An intruder may delete sent messages, create rules to hide replies, forward mail externally, register another authentication method or use an existing session token without a fresh password login.
Provider audit records may help show who accessed particular messages or which session performed an action. Message trace may confirm how the email moved through the service. Those records may be held separately from the mailbox itself.
Act promptly.
Account and provider logs may be retained for limited periods or depend on the organisation’s subscription and settings. Preserve or request them before routine retention removes them.
If compromise appears active, containment matters.
The account may need to be secured, sessions revoked, credentials reset, malicious rules removed and affected parties warned.
Don’t delay necessary protection simply to preserve an untouched account.
Record what was done, when and by whom. Where possible, preserve the available logs and settings before or alongside the containment action.
Then test the compromise explanation.
Was there an unusual sign-in or session?
Was the location, device, application or IP address unfamiliar?
Were other suspicious messages sent?
Were mailbox rules added?
Did the account holder report credential theft or a phishing event?
Did the activity begin before the disputed email?
Is there evidence that the account holder was using the same session normally?
Absence of an obvious alert doesn’t prove the account was secure. Existing sessions, trusted devices, shared credentials and poorly logged access can complicate the picture.
Equally, an unusual foreign IP address doesn’t prove compromise. VPNs, mobile routing, travel and provider infrastructure can affect location results.
The common mistake is:
“The email passed authentication, so the account holder must have sent it.”
Authentication normally addresses domains and sending systems, not the identity of the person operating the account.
The other mistake is:
“The account holder says they were hacked, so the email can’t be attributed.”
A compromise claim needs evidence too.
Keep the conclusions separate.
The real account may have sent the message.
A particular session may have controlled the account.
A device may be linked to that session.
The person behind the activity still needs to be established.
A compromised account is an alternative explanation to investigate, not a magic answer that proves or disproves authorship.
Key takeaway
A genuine account and successful authentication can prove the route used by the message while leaving the human sender unresolved.
Related questions¶
- Can an email identify the person who wrote it?
- Does the From address identify the sender?
- Should I preserve the mailbox as well as the individual message?
- What if the email address was spoofed?
Source notes¶
- Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts
- Microsoft Learn: Respond to a compromised email account in Microsoft 365
- Microsoft Learn: Audit log activities
- Microsoft Learn: Trace an email message in Exchange Online
- Google Workspace Admin Help: Troubleshoot message delivery with Email Log Search