You get 30 days to investigate an email incident. Most breach investigations begin after that window has already closed.
The search reaches 30 days back at most, and it opens filtered to yesterday and today. Should an incident surface in week six, whatever this tool held has already aged out. Knowing that in advance changes how you investigate and, more importantly, what you export while the evidence is still there to export.
- 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
Of every distinction on this page, this is the one that matters. Real-time detections shows you malicious email detections as they were at the moment of delivery, and nothing beyond that. Threat Explorer shows every email detection at delivery plus what happened afterwards, and post-delivery activity is precisely what an investigation needs once the message has already landed in an inbox.
Which one you have depends on your plan
Plan 1 of Defender for Office 365 gives you Real-time detections. Threat Explorer requires Plan 2. Businesses routinely discover which of the two they hold in the middle of an incident, and there is no worse moment to learn what your license actually covers.
A 30 day search window
Searches reach back a maximum of 30 days, with the filter defaulting to yesterday and today. That default catches people out mid investigation, because a query returning nothing might simply be pointed at the wrong two days rather than proving the message never existed at all.
Views that differ between the two tools
Both products give you Malware, Phish and Content malware. All email, Campaigns and URL clicks belong to Threat Explorer alone. URL clicks is the view most frequently reached for after a phishing incident, and it happens to be one of the ones Plan 1 does not include.
Export limits that shape your method
The details area table exports up to 200,000 filtered or unfiltered results to CSV, and top targeted users exports up to 3,000 users along with their corresponding attempts. Both figures are generous. Both are also hard ceilings, which starts to matter once a campaign gets large.
Saved queries and richer filtering
Beyond Real-time detections, Threat Explorer brings additional property filtering options, the ability to save a query, and a wider set of actions. Saved queries matter more than they sound. They are what separates an investigation method living inside one analyst head from one the entire team can run the same way every time.
What is not in there at all
Two categories are absent: end-user spam notifications and system generated messages. The documentation notes both become available where a mail flow rule exists to override the behavior. This matters because searching for something that was never indexed in the first place returns a confident answer that happens to be wrong.
Campaign view for the bigger picture
The Campaigns view exists only in Threat Explorer and groups related messages together instead of listing them one by one. Faced with a coordinated attack on your organization, that is the difference between investigating forty separate messages and understanding a single campaign that happened to deliver forty times.
Thirty days is the entire window available to you, and the view opens showing two of them.
Each of those facts causes genuine trouble during an investigation, and neither requires a licensing change to solve. Process handles both.
- Searching reaches thirty days back and stops. Incidents get discovered late as a matter of course, particularly anything involving stolen credentials or a compromise that burned slowly, and by the time somebody goes looking the email evidence may already sit outside the window entirely.
- The filter opens on yesterday and today. Run a query without adjusting that range, find nothing, and what you have established is that the message did not arrive during the last forty eight hours. That was not the question. Under pressure it is a very easy mistake to make.
- On the process side, the answer is to export early instead of searching late. The details area table will send up to 200,000 filtered or unfiltered results to CSV, so the first action during any live incident should be pulling the relevant data out before the window slides past it.
- Architecturally, the answer is to route the data somewhere that keeps it longer. Where email telemetry matters past thirty days, and it usually does for anyone facing a HIPAA breach investigation or a state breach notification timeline, that means feeding it into a SIEM whose retention period was chosen against your investigation requirements rather than inherited from a tool default.
Four things that make email investigation reliable.
The thirty day window gets designed around rather than wished away
Thirty days back is as far as the search reaches, full stop. Incidents found late routinely need data sitting outside that boundary. Two responses work: export early during any live incident, and move the telemetry somewhere with longer retention wherever the requirement justifies what that costs.
We build saved queries rather than documenting steps
Queries can be saved here, and a saved query is a far better artifact than a written procedure ever was. It runs identically for everybody, it does not quietly drift over time, and it eliminates the date range mistake structurally rather than by telling people to be careful.
We check the license before we design the method
Under Plan 1, Real-time detections shows you detections at the moment of delivery and nothing else. Threat Explorer under Plan 2 adds post-delivery activity, the all email, campaigns and URL clicks views, saved queries and a broader set of actions. Designing an investigation method that depends on URL clicks for a tenant holding Plan 1 wastes the time of everybody involved.
We state what the tool cannot see
Neither end-user spam notifications nor system generated messages appear in Threat Explorer unless a mail flow rule overrides that behavior. An analyst unaware of it can search, find nothing, and conclude the message never existed. That outcome is worse than not having searched at all.
Four phases across roughly three to four weeks.
- 01Week 1
Establish what you have and what it can see
We establish which plan you are licensed for and therefore which tool you actually have, whether the URL clicks and campaigns views exist for you at all, and what your current retention position looks like for email telemetry once the thirty day window closes.
- License 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
Queries get saved for the investigations you genuinely run: a suspicious sender, a message somebody reported, a user who clicked something, a campaign aimed at one department. Saved rather than remembered, so that the method outlives whoever worked it out.
- Saved queries built for common investigations
- Date range discipline built into each
- An export procedure written with the 200,000 result limit accounted for
- Top targeted users export understood at 3,000 users
- 03Week 3
Rehearse against a real scenario
Either a tabletop or a live-fire exercise built on a genuinely reported message, walked end to end by the people who will actually do this work. That exercise is where the default two day filter, the missing view or the licensing gap comes to light, and it costs you nothing when it happens there.
- 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
Any investigation needing to reach past thirty days requires the telemetry to live somewhere other than here. That is a SIEM decision carrying a cost, and it deserves to be taken deliberately rather than discovered halfway through an incident that turns out to need sixty days of 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?
This is the opening question after any reported phishing attempt, and the answer sets the size of everything that follows. The tool answers it directly, and the campaigns view collapses forty individual messages into one coordinated attack you can reason about as a single thing.
Did anybody actually click the link?
Since URL clicks lives in Threat Explorer and has no equivalent in Real-time detections, this is the most common way a Plan 1 tenant runs into what its license does not cover. Whether or not somebody clicked reshapes the entire incident response around it.
A regulated firm evidencing an incident response
An examiner, a HIPAA investigator or a state regulator will ask four things: what arrived, who received it, what was done about it and when. Exported evidence produced by a defined investigation method answers all four far better than a narrative somebody reconstructed afterwards, and the 200,000 result ceiling is generous enough to cover almost any single incident.
A business responding to a vendor compromise
Once a supplier is breached, the question becomes what they sent you and on which dates. That is a sender-based search across the window, and the answer decides whether you are running a monitoring exercise or an actual incident. Fall outside the thirty day window and the whole thing turns into guesswork.
A provider checking who was targeted
Exporting top targeted users gives you up to 3,000 of them with their corresponding attempts, which converts a vague impression that leadership receives more phishing into a list carrying actual numbers. That list is usually what justifies putting stronger controls around one specific group.
An organization building a security operations function
Most incidents start in email, which makes email investigation the right place for a new security function to build its first repeatable method. Saved queries, a runbook somebody has rehearsed and a known export procedure make a far better starting point than a broader capability nobody has ever practiced.
How US organizations investigate email incidents.
| Feature | Method built and rehearsed | Tool available, used ad hoc | Tool unfamiliar |
|---|---|---|---|
License 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
Malware view
- Real-time detections, Plan 1
- Yes
- Threat Explorer, Plan 2
- Yes
Capability
Phish view
- Real-time detections, Plan 1
- Yes
- Threat Explorer, Plan 2
- Yes
Capability
Content malware view
- Real-time detections, Plan 1
- Yes
- Threat Explorer, Plan 2
- Yes
Capability
All email view
- Real-time detections, Plan 1
- No
- Threat Explorer, Plan 2
- Yes
Capability
Campaigns view
- Real-time detections, Plan 1
- No
- Threat Explorer, Plan 2
- Yes
Capability
URL clicks view
- Real-time detections, Plan 1
- No
- Threat Explorer, Plan 2
- Yes
Capability
Detections shown
- Real-time detections, Plan 1
- At time of delivery only
- Threat Explorer, Plan 2
- Delivery plus post-delivery activities
Capability
Saved queries
- Real-time detections, Plan 1
- No
- Threat Explorer, Plan 2
- Yes
Capability
Property filtering
- Real-time detections, Plan 1
- Fewer options
- Threat Explorer, Plan 2
- More options
Capability
Available actions
- Real-time detections, Plan 1
- Fewer
- Threat Explorer, Plan 2
- More
Five steps, and it is the rehearsal that uncovers the gaps.
- 1
Confirm the license and available views
Plan 1 delivers Real-time detections, carrying the malware, phish and content malware views and showing detections as at the time of delivery. Plan 2 delivers Threat Explorer, adding the all email, campaigns and URL clicks views, post-delivery activity, saved queries and a wider set of actions. In a mixed estate this has to be established group by group.
- 2
Build saved queries for the investigations you run
Cover the cases you meet: a reported phishing message, a sender that looks wrong, a user who may have clicked, a campaign aimed at one department. Each saved, so it runs identically whoever opens it and the date range comes out correct by construction rather than because somebody remembered to change it.
- 3
Define the export procedure
The procedure states what gets exported during a live incident and in which order, all before the thirty day window slides past the period that matters. Both ceilings belong in that document rather than in memory alone: 200,000 results from a details area export, 3,000 users from top targeted users.
- 4
Rehearse with the people who will do it
Take a genuinely reported message and walk it end to end with the actual team, against a clock. That exercise is where the default two day filter, a view you turn out not to have, or a licensing gap makes itself known. Finding it there costs an afternoon. Finding it later costs an incident.
- 5
Decide the retention question deliberately
Wherever investigations genuinely have to reach past thirty days, the telemetry needs to be going somewhere that keeps it longer, and that is a SIEM decision carrying a real cost. Taking it in advance is considerably better than arriving at it halfway through an incident.
What organizations 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 license 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 the tool, widen the range to the full thirty days, and put a clock on answering a single question.
The question being who else received a particular message. However long that takes 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
Microsoft Defender for Office 365 Services
Anti-phishing, Safe Links and Safe Attachments done right
Learn moreKQL Threat Hunting Enablement
Advanced hunting and KQL enablement for US security teams: permission
Learn moreMicrosoft 365 Anti-Phishing Policy Configuration
Anti-phishing policy reviews for US organizations: policy inventory
Learn moreMicrosoft Defender XDR Services
One incident queue across endpoint, email and identity
Learn moreCyber Incident Response
Cyber incident response for US businesses. 24/7 on-call IR engineers
Learn moreMicrosoft Sentinel
Cloud-native SIEM and threat intelligence
Learn more