Your email investigation window is 30 days. Most breach investigations start later than that.
Threat Explorer searches up to 30 days back, and defaults to yesterday and today. If an incident surfaces in week six, the evidence in this tool is already gone. Knowing that changes both how you investigate and what you export while you still can.
- 30 daysMaximum search period back
- 200,000Maximum results exportable to CSV
- 3,000Users exportable from top targeted users
- Plan 2Required for Threat Explorer itself
Eight things that decide whether an email investigation succeeds.
Post-delivery activity, not just delivery decisions
The distinction that matters most. Real-time detections shows malicious email detections at the time of delivery only. Threat Explorer shows all email detections at the time of delivery along with post-delivery activities, which is what an investigation needs after the message has already landed.
Which one you have depends on your plan
Real-time detections is available in Defender for Office 365 Plan 1. Threat Explorer is available in Plan 2. Organisations frequently discover the difference mid incident, which is the worst possible moment to find out what their licence includes.
A 30 day search window
The search period reaches up to 30 days ago, and the default filter is yesterday and today. That default catches people out during an investigation, because a query that returns nothing may simply be looking at the wrong two days rather than proving the message never existed.
Views that differ between the two tools
Malware, Phish and Content malware are available in both. All email, Campaigns and URL clicks are Threat Explorer only. URL clicks in particular is the view most often needed after a phishing incident, and it is the one Plan 1 does not have.
Export limits that shape your method
Up to 200,000 filtered or unfiltered results can be exported to CSV from the details area table, and up to 3,000 users can be exported from top targeted users with their corresponding attempts. Those are generous ceilings and they are ceilings, which matters for large campaigns.
Saved queries and richer filtering
Threat Explorer adds more property filtering options, including the ability to save queries, and more actions than Real-time detections. Saved queries are the difference between an investigation method that exists in somebody head and one the whole team can run consistently.
What is not in there at all
End user spam notifications and system generated messages are not available in Threat Explorer. Microsoft notes these types of messages are available if there is a mail flow rule to override. Searching for something that was never indexed produces a confident and wrong conclusion.
Campaign view for the bigger picture
Campaigns is a Threat Explorer view that groups related messages rather than showing them individually. For a coordinated attack against your organisation, that is the difference between investigating forty separate messages and understanding one campaign with forty deliveries.
Thirty days is the whole window, and the default view shows two of them.
Both facts cause real problems during investigations, and both are fixable with process rather than licensing.
- The search period reaches up to 30 days ago. Where an incident is discovered late, which is the normal case for anything involving credential theft or a slow-burning compromise, the email evidence may already be outside the window when somebody first goes looking.
- The default filter is yesterday and today. An analyst who queries without changing the date range and finds nothing has learned that the message did not arrive in the last two days, which is not what they were trying to establish. It is an easy mistake under pressure.
- The process answer is to export early rather than search late. Up to 200,000 filtered or unfiltered results can be exported to CSV from the details area table, so during any live incident the first action is to pull the relevant data out before the window moves past it.
- The architectural answer is to send the data somewhere with longer retention. Where email telemetry matters beyond 30 days, that means getting it into a SIEM with a retention period matched to your investigation requirements rather than to the tool default.
Four things that make email investigation reliable.
We design around the 30 day window rather than ignoring it
The search period reaches up to 30 days ago and no further. Incidents discovered late routinely need data outside it. The two responses are exporting early during any live incident, and moving telemetry somewhere with longer retention where the requirement justifies the cost.
We build saved queries rather than documenting steps
Threat Explorer supports saving queries, and a saved query is a considerably better artefact than a written procedure. It runs the same way for everybody, it does not drift, and it removes the date range mistake by construction rather than by instruction.
We check the licence before we design the method
Real-time detections in Plan 1 shows detections at time of delivery only. Threat Explorer in Plan 2 adds post-delivery activities, the all email, campaigns and URL clicks views, saved queries and more actions. Designing a method that needs URL clicks for a Plan 1 tenant wastes everybody time.
We state what the tool cannot see
End user spam notifications and system generated messages are not available in Threat Explorer unless a mail flow rule overrides them. An analyst who does not know that can search, find nothing, and conclude a message never existed. That is a worse outcome than not searching.
Four phases across roughly three to four weeks.
- 01Week 1
Establish what you have and what it can see
Which plan is licensed and therefore which tool is available, whether URL clicks and campaigns views exist, and what the current retention position is for email telemetry beyond the 30 day window.
- Licence position confirmed per user group
- Available views documented
- Email telemetry retention beyond 30 days established
- Gaps between capability and requirement identified
- 02Week 2
Build the investigation method
Saved queries for the investigations you actually run: a suspicious sender, a reported phishing message, a user who clicked, a campaign against a department. Saved rather than remembered, so the method survives the person who devised it.
- Saved queries built for common investigations
- Date range discipline built into each
- Export procedure defined with the 200,000 limit in mind
- Top targeted users export understood at 3,000 users
- 03Week 3
Rehearse against a real scenario
A tabletop or a live-fire exercise using a real reported message, walked through end to end by the people who will do it. This is where the default two day filter, the missing view or the licence gap surfaces, at no cost.
- Investigation walked through with the actual team
- Time to answer measured for a standard scenario
- Gaps found in method or tooling
- Runbook corrected against what actually happened
- 04Week 4
Close the retention gap and hand over
Where investigations need to reach beyond 30 days, the telemetry has to live somewhere else. That is a SIEM decision with a cost, and it should be made deliberately rather than discovered during an incident that needs 60 day data.
- Retention requirement stated and costed
- Ingestion into a SIEM designed where justified
- Runbook handed to the operational team
- Review point set against incident volume
Six investigations that live or die on this tool.
Who else received this phishing message?
The first question after any reported phish, and the one that determines the size of the response. Threat Explorer answers it directly, and the campaigns view turns forty individual messages into one coordinated attack you can reason about as a whole.
Did anybody actually click the link?
URL clicks is a Threat Explorer view and is not available in Real-time detections, which makes this the single most common reason a Plan 1 tenant discovers its licence limitation. Whether somebody clicked changes the entire shape of the incident response.
A regulated firm evidencing an incident response
Supervisors ask what arrived, who received it, what was done and when. Exported evidence from a defined investigation method answers that far better than a narrative reconstruction, and the 200,000 result export ceiling is generous enough for almost any single incident.
A business responding to a supplier compromise
When a supplier is breached, the question is what they sent you and when. That is a sender-based search across the window, and the answer determines whether this is a monitoring exercise or an incident. Being outside the 30 day window turns it into guesswork.
A provider checking who was targeted
Top targeted users exports up to 3,000 users with their corresponding attempts, which turns a vague sense that leadership gets more phishing into a list with numbers. That list is usually what justifies stronger controls for a specific group.
An organisation building a security operations function
Email is where most incidents begin, so email investigation is where a new function should build its first repeatable method. Saved queries, a rehearsed runbook and a known export procedure are a better starting point than a broader capability nobody has practised.
How UAE organisations investigate email incidents.
| Feature | Method built and rehearsed | Tool available, used ad hoc | Tool unfamiliar |
|---|---|---|---|
Licence position known in advance | Yes | Partly | No |
Saved queries exist | Yes | No | No |
Date range discipline | Built into method | Sometimes missed | Frequently missed |
Post-delivery activity visible | If Plan 2 | If Plan 2 | Unknown |
Export during live incident | Standard practice | Sometimes | No |
Retention beyond 30 days | Designed | None | None |
Investigation rehearsed | Yes | No | No |
Time to first answer | Minutes | Hours | Days |
Conclusions defensible | Yes | Usually | Uncertain |
Method survives staff change | Yes | No | Not applicable |
What each tool can actually show you.
| Capability | Real-time detections, Plan 1 | Threat Explorer, Plan 2 | |
|---|---|---|---|
| Malware view | Yes | Yes | |
| Phish view | Yes | Yes | |
| Content malware view | Yes | Yes | |
| All email view | No | Yes | |
| Campaigns view | No | Yes | |
| URL clicks view | No | Yes | |
| Detections shown | At time of delivery only | Delivery plus post-delivery activities | |
| Saved queries | No | Yes | |
| Property filtering | Fewer options | More options | |
| Available actions | Fewer | More |
Five steps, and the rehearsal is the one that finds the gaps.
- 1
Confirm the licence and available views
Plan 1 gives Real-time detections with malware, phish and content malware views showing detections at time of delivery. Plan 2 gives Threat Explorer, adding all email, campaigns and URL clicks, post-delivery activity, saved queries and more actions. Mixed estates need this per group.
- 2
Build saved queries for the investigations you run
A reported phishing message, a suspicious sender, a user who may have clicked, a campaign against a department. Saved so they run identically for everybody and the date range is correct by construction rather than by somebody remembering to change it.
- 3
Define the export procedure
What to export during a live incident, in what order, before the 30 day window moves past the relevant period. The 200,000 result ceiling for details area exports and the 3,000 user ceiling for top targeted users both belong in the procedure rather than in somebody memory.
- 4
Rehearse with the people who will do it
A real reported message walked end to end by the actual team, timed. This is where the default two day filter, an unavailable view, or a licence gap shows up, and where it costs an afternoon rather than an incident.
- 5
Decide the retention question deliberately
Where investigations genuinely need to reach beyond 30 days, the telemetry has to go somewhere with a longer retention period, which is a SIEM decision with a cost attached. Making that decision in advance is considerably better than discovering it mid incident.
What organisations ask about Threat Explorer.
Fifteen questions to answer before the next incident.
Capability
- Do we have Plan 1 or Plan 2?It determines which tool you get.
- Can we see URL clicks?Threat Explorer only.
- Can we see campaigns?Threat Explorer only.
- Can we see post-delivery activity?Threat Explorer only.
- Is the licence uniform across users?Mixed estates are common.
Method
- Do we have saved queries?Or does the method live in one head.
- Does everyone change the date range?Default is yesterday and today.
- Who runs an email investigation at 2am?Name them.
- Have we ever rehearsed one?Not during a real incident.
- How long does a standard search take us?Measure it.
Retention
- Do we need to look back beyond 30 days?Most investigations eventually do.
- Where does email telemetry go afterwards?If anywhere.
- Do we export during live incidents?Before the window moves.
- Do we know the 200,000 export limit?It matters for large campaigns.
- Are system generated messages in scope?They are not in Threat Explorer.
Open Threat Explorer, set the range to 30 days, and time how long it takes to answer one question.
Who else received a given message. That number is your current email incident response speed, and it is usually the first thing worth improving.
Related Services
Explore more solutions that work great with this service
Defender for Office 365
Plan 1 versus Plan 2, and the ten second way to tell which you have
KQL Threat Hunting
Hunting across Defender data, and turning it into detections
Quarantine Policies
Who can see, act on and release blocked mail
Tenant Allow/Block List
Manual overrides that do more than you expect
Anti-Phishing Policies
Impersonation protection, spoof handling and thresholds
Defender XDR
Eleven signal sources, one incident, and containment without a human
Incident Response
24/7 incident response and forensics in Dubai
Microsoft Defender
Advanced endpoint and email threat protection