What account-access records may exist?¶
An email account can leave evidence across several different record systems.
A single “login history” view is rarely the whole picture.
The useful question is which record set can answer the part of account activity you are trying to establish?
Different records answer different questions¶
| Record area | Examples | What it can help explain |
|---|---|---|
| Authentication | successful/failed sign-ins, MFA, challenges | how access was accepted or refused |
| Sessions / tokens | session IDs, refresh activity, expiry, revocation | how access continued after the original login |
| Mailbox activity | message access, sending, deletion, rules, delegate actions | what happened inside the mailbox |
| Account control | password, recovery, MFA-method or device changes | whether practical control of the account changed |
| Applications / API | connected apps, consent, application IDs | whether software acted through the mailbox |
| Message trace | submission and delivery events | how a particular message moved through the service |
The names and exact fields vary by provider, but the evidence questions remain broadly the same.
A send event may sit several steps away from the login¶
Imagine this simplified sequence:
S-4812 is created.The message at 13:42 may not have a fresh password event beside it.
The useful link may be the continuing session or application authority.
What can login history show? explains the authentication layer in more detail.
Preserve identifiers that let the records join together¶
Where the service provides them, useful joining fields may include:
- account or tenant ID;
- session or token ID;
- application/client ID;
- device ID;
- Message-ID;
- provider network/message ID;
- source address;
- exact timestamp and time zone; and
- correlation or request ID.
One field rarely does all the work. The value comes from connecting the records.
Absence from one log is not the same as absence of activity¶
A relevant event may:
- sit in a different dataset;
- use an existing session;
- be caused by a delegate or connected application;
- fall outside the enabled audit scope; or
- be outside the retained period.
So establish what the provider was capable of recording at the relevant time before treating a missing event as meaningful.
How access was granted, how authority persisted, which mailbox action followed and which technical route linked the events.
Who physically or remotely controlled the device, session or application responsible for the activity.
The practical point is: map the account evidence by function, then join authentication, continuing authority and mailbox activity into one timeline.
