Recovering Missing or Deleted Items in an Exchange Online Mailbox (M365 Business Premium)

Overview:
In Microsoft 365 Business Premium (Exchange Online), data protection features are in place to help recover emails or other mailbox items that have been accidentally deleted or gone missing. When an item is deleted, it passes through stages before being permanently removed. By default, deleted items are retained for 14 days (configurable up to 30 days by an administrator). During this period, both end users and administrators have multiple methods to restore deleted emails, contacts, calendar events, and tasks. This guide outlines all recovery methods for both users and admins, assuming the necessary data protection settings (like retention policies or single item recovery) are already enabled.

Deletion Stages in Exchange Online

Understanding how Exchange Online handles deletions will inform the recovery process:

Deleted Items Folder (Soft Delete): When a user deletes an email or other item (without using Shift+Delete), it moves to the Deleted Items folder[1]. The item stays here until the user manually deletes it from this folder or an automatic policy empties the folder (often after 30 days)[2].
Recoverable Items (Soft Delete Stage 2): If an item is removed from Deleted Items (either by manual deletion or “Empty Deleted Items” cleanup) or if the user hard-deletes it (Shift+Delete), the item is moved to the Recoverable Items store (a hidden folder)[1]. Users cannot see this folder directly in their folder list, but they can access its contents via the “Recover Deleted Items” feature in Outlook or Outlook Web App.
Retention Period: Items remain in the Recoverable Items folder for a default of 14 days, but administrators can extend this to a maximum of 30 days for each mailbox. This is often referred to as the deleted item retention period. Exchange Online’s single item recovery feature is enabled by default, ensuring that even “permanently” deleted items are kept for this duration[1].
Purge (Hard Delete): Once the retention period expires (e.g., after 14 or 30 days), the items are moved to the Purges subfolder of Recoverable Items and become inaccessible to the user[1]. At this stage, the content is typically recoverable only by an administrator (and only if it’s still within any hold/retention policy). After this, the data is permanently deleted from Exchange Online (unless a longer-term hold or backup exists).

With this in mind, we’ll explore recovery options available to end users and administrators.

Recovery by End Users (Self-Service Recovery)

End users can often recover deleted mailbox items on their own, using Outlook (desktop or web). This includes recovering deleted emails, calendar appointments, contacts, and tasks, provided the recovery is attempted within the retention window and the item hasn’t been permanently purged. Below are the methods:

1. Restore from the Deleted Items Folder (User)

When you first delete an item, it moves to your Deleted Items folder:

Check the Deleted Items folder: Open your mailbox in Outlook or Outlook on the Web (OWA) and navigate to the Deleted Items folder[2]. This is the first place to look for accidentally deleted emails, contacts, calendar events, or tasks.
- Items in Deleted Items can simply be dragged back to another folder (e.g., Inbox) or restored via right-click > Move > select folder[2]. For example, if you see the email you need, you can move it back to the Inbox. If a deleted contact or calendar event is present, you can drag it back to the Contacts or Calendar folder respectively.
- Tip: The Deleted Items folder retains content until it’s manually cleared or automatically emptied by policy. In many Office 365 setups, items may remain here for 30 days before being auto-removed[2]. So, if your item was deleted recently, it should be here.
Recover the item from Deleted Items: Select the item(s) you want to recover, then either:
- Right-click and choose Move > Other Folder to move it back to your desired location (such as Inbox or original folder)[2].
- Or, in Outlook desktop, you can also use the Move or Restore button on the ribbon to put the item back.
- The item will reappear in the folder you choose, effectively “undeleting” it.
Verify restoration: Go to the target folder (Inbox, Contacts, Calendar, etc.) and ensure the item is present. It should now be accessible as it was before deletion.

If the item is found and restored at this stage, you’re done. If you emptied your Deleted Items folder or cannot find the item there, proceed to the next method.

2. Recover from the Recoverable Items (Hidden) Folder (User)

If an item was hard-deleted or removed from Deleted Items, end users can attempt recovery from the Recoverable Items folder using the Recover Deleted Items feature:

Access the “Recover Deleted Items” tool:
- In Outlook on the Web (browser): Go to the Deleted Items folder. At the top (above the message list), you should see a link or option that says “Recover items deleted from this folder”[2]. Click this link.
- In Outlook Desktop (classic): Select your Deleted Items folder. On the ribbon, under the Folder tab, click Recover Deleted Items from Server[2]. (In newer Outlook versions, you might find a Recover Deleted Items button directly on the toolbar when Deleted Items is selected.)
View recoverable items: A window will open listing items that are in the Recoverable Items folder and still within the retention period. This can include emails, calendar events, contacts, and tasks that were permanently deleted[2]. All items are shown with a generic icon (usually an envelope icon, even for contacts or calendar entries)[2].
- Tip: Because all item types look similar here, you may need to identify items by their subject or other columns. For instance, contacts will display the contact’s name in the “Subject” field and have an empty “From” field (since contacts aren’t sent by someone)[2]. Calendar items or tasks might show your name in the “From” column (because you’re the owner/creator)[2]. You can click on column headers to sort or search within this list to find what you need.
Select items to recover: Click to highlight the email or other item you want to restore. You can select multiple items by holding Ctrl (for individual picks) or Shift (for a range). In OWA, there may be checkboxes next to each item for selection[2].
Recover the selected items: In the recovery window, click the Recover (or Restore)** button (sometimes represented by an icon of an email with an arrow). In Outlook desktop, this might be a button labeled “Restore Selected Items”[2]; in OWA, clicking Restore will do the same.
- What happens next: The recovered item(s) will be moved back into your mailbox. Recovered emails and other items from this interface are typically restored to your Deleted Items folder by default[2]. This is by design: you can then go into Deleted Items and move them to any folder you like. (It prevents confusion of plopping items directly back into original folders, especially if those folders didn’t exist anymore.)
Confirm and move items: Navigate again to your Deleted Items folder in Outlook. You should see the items you just recovered now listed there (they usually appear as unread). From here, move the items to their proper location:
- For an email, move it to Inbox or any mail folder.
- For a contact, you can drag it into your Contacts folder.
- For a calendar appointment, drag it to the Calendar or right-click > Move to Calendar.
- For a task, move it into your Tasks folder.
  The item will then be fully restored to its original type-specific location.
Troubleshooting: If you do not see the item you need in the Recover Deleted Items window, it might mean the retention period has passed or the item is truly gone. By default, items are only available here for 14 days unless your admin extended it[1]. In some setups it could be up to 30 days. If the item is older than that, end users cannot recover it themselves[1]. In such cases, you should contact your administrator for further help – administrators may still retrieve the item if it was preserved by other means (see Admin Recovery below).

Summary of User Recovery: A user should always first check Deleted Items, then use Recover Deleted Items in Outlook/OWA. These two steps cover the majority of accidental deletions. The user interface handles all common item types (mail, calendar, contacts, tasks) in a similar way. Remember that anything beyond the retention window (e.g., >30 days) or content that was never saved (e.g., unsaved drafts) cannot be recovered by the user and would require admin assistance or may be unrecoverable.

Recovery by Administrators (Advanced Recovery)

Administrators have more powerful tools at their disposal to help recover missing or deleted information from user mailboxes. Admins can recover items that users can’t (such as items beyond the user’s 14/30-day window or items from mailboxes that are no longer active). Below are the methods for administrators:

1. Recover Deleted Items via Exchange Admin Center (EAC)

Microsoft 365 administrators can use the Exchange Admin Center to retrieve deleted items from a user’s mailbox without needing to access the user’s Outlook. This is useful if the user is unable to recover the item or if the admin needs to recover data from many mailboxes.

Steps (EAC Admin Recovery):

Open the Exchange Admin Center: Log in to the Microsoft 365 Admin Center with an admin account. Navigate to the Exchange Admin Center (EAC). In the new Microsoft 365 Admin portal, you can find this under Admin centers > Exchange.
Locate the user’s mailbox: In EAC, go to Recipients > Mailboxes. You will see a list of all mailboxes. Click on the mailbox of the user who lost the data. This opens the properties or a details pane for that mailbox.
Select “Recover deleted items”: In the mailbox properties, find the option for recovery. In the new EAC, there is often an “Others” section or a context menu (•••). Click that and then click “Recover deleted items”[1]. (In older versions of EAC, this might appear as a link or button directly labeled “Recover deleted items.”)
- The EAC will load a tool that is very similar to what the user sees in Outlook’s recover interface. It may show the most recent 50 recoverable items by default[1], along with search or filter options.
Find the items to recover: Use the interface to locate the missing item(s). You can filter by date range, item type (mail, calendar, etc.), or search by keywords (subject, sender) to narrow down the list[1]. This helps when there are many deleted items. All items that are still within the retention period (and thus in the user’s Recoverable Items folder) should be visible here.
Recover the item(s): Select the desired item(s) from the list, then click the Recover button (sometimes shown as a refresh or arrow icon). Confirm the recovery if prompted. The Exchange Admin Center will restore those items back to the user’s mailbox.
- Where do they go? Just like when a user does it, the recovered items through EAC will be returned to the user’s Deleted Items folder (this is the default behavior)[2]. The user (or admin) can then move them to the appropriate folder afterward.
Notify the user: It’s good practice to inform the user that the items have been recovered. The user should check their Deleted Items folder for the restored data[2] and move it back to the desired location.

Note: To use the EAC recovery feature, the admin account needs the proper permissions. By default, global admins have this. If an admin cannot see the “Recover deleted items” option, they may need the Mailbox Import-Export role added to their account’s role group[1] (this role is required for mailbox recoverable item searches).

2. Recover via PowerShell (for Admins)

For more advanced scenarios or bulk recoveries, admins can use Exchange Online PowerShell. Microsoft provides two key cmdlets for deleted item recovery: Get-RecoverableItems (to search for recoverable deleted items) and Restore-RecoverableItems (to restore them)[3][3]. This method is useful if you want to script the recovery, search with complex criteria, or recover items from multiple mailboxes at once.

Steps (PowerShell Admin Recovery):

Connect to Exchange Online via PowerShell: Launch a PowerShell session and connect to Exchange Online. Use the following steps (requires the Exchange Online PowerShell module or Azure Cloud Shell):

   Connect-ExchangeOnline -UserPrincipalName admin@yourtenant.com

Search for recoverable items: Use Get-RecoverableItems to identify the items you want to restore. At minimum, you provide the identity of the mailbox. You can also filter by item type, dates, or keywords. For example:

   # Search a mailbox for all recoverable emails with a certain subject keyword
   Get-RecoverableItems -Identity user@contoso.com -FilterItemType IPM.Note -SubjectContains "Project X"

This command will list all deleted email messages (IPM.Note is the message class for emails) in that user’s Recoverable Items, whose subject contains “Project X”[3]. You can adjust parameters:

FilterItemType can target other item types (e.g., IPM.Appointment for calendar items, IPM.Contact for contacts, IPM.Task for tasks). If omitted, all item types are returned.
SubjectContains, SenderContains, RecipientContains can filter by those fields.
FilterStartTime and FilterEndTime can narrow by deletion timeframe[3].

Review the output to ensure the desired item(s) are found. The output will show item identifiers needed for restoration.

Restore the deleted items: Once you’ve identified items (or if you want to restore everything you found with a given filter), use Restore-RecoverableItems. For example, to restore all items that match the previous search:

   Restore-RecoverableItems -Identity user@contoso.com -SubjectContains "Project X"

This will take all recoverable items in user@contoso.com’s mailbox with “Project X” in the subject and restore them[3]. You can use the same filters as before or specify particular ItemIDs (if you want to restore specific individual items). If not specifying filters, be cautious: running Restore-RecoverableItems without any filter will attempt to restore all deleted items available for that mailbox.

Target Folder: By default, restored items go to the user’s Deleted Items folder (just like the EAC method)[2]. PowerShell’s restore cmdlet doesn’t let you choose another folder as the destination.

Verify the restoration: After running the cmdlet, you can optionally run Get-RecoverableItems again to ensure those items no longer appear (they should be gone once restored), or simply check the user’s mailbox. The user’s Deleted Items folder should now contain the recovered messages or items. You can communicate to the user that the items have been recovered and they will find them in Deleted Items.

PowerShell gives fine-grained control and is especially useful for bulk operations or automation (for example, recovering a particular email for many mailboxes at once, or scheduling regular checks). It requires some expertise, but it’s a robust method when UI tools are insufficient.

3. eDiscovery Content Search (Compliance Center)

If an item is beyond the standard retention period (e.g., older than 30 days and thus not visible in the Recoverable Items folder) but you have configured additional data protection (like a retention policy or Litigation Hold** [3]**), the content might still be recoverable through eDiscovery. Also, if you need to recover a large set of data (for example, all emails from last year for a mailbox), the eDiscovery Content Search is a powerful approach. Microsoft Purview’s Compliance portal allows admins (with eDiscovery permissions) to search and export data from mailboxes.

Steps (Admin eDiscovery Recovery):

Go to Microsoft Purview Compliance Center: Visit the compliance portal (https://compliance.microsoft.com) and sign in with an account that has eDiscovery permissions (e.g., Compliance Administrator or eDiscovery Manager roles).
Initiate a Content Search: In the Compliance Center, navigate to Content Search (under the eDiscovery section). Create a new search case or use an existing case if one is set up. Then set up a New Search:
- Name the search (e.g., “Recover John Doe Emails March 2021”).
- Add Conditions/Locations: Specify the location to search – in this case, select Exchange mailboxes and pick the specific user’s mailbox (or multiple mailboxes if needed).
- Set the query for items you want to find. You can filter by keywords, dates, subject, sender/recipient, etc., or even search for all items if you’re attempting a broad recovery. For example, you might search for emails from a certain date range that were lost.
Run the search: Start the search and wait for it to complete. Once done, you can preview the results in the portal to verify that the missing/deleted item is found. The search is powerful – it can find items that were permanently deleted by the user but retained for compliance. For instance, if a retention policy holds items for 10 years, an email deleted by the user 6 months ago (and long gone from Recoverable Items) would still show up in this search[4].
Export the results: If the needed item is found (or you want all results), use the Export option. When exporting:
- Choose to export Exchange content as PST file (this is the usual format for mailbox data export).
- The system will prepare the export; you might have to download an eDiscovery Export Tool and use an export key provided in the portal to download the PST to your local machine[4]. Follow the prompts – the portal provides these details.
Retrieve data from the PST: Once you have the PST file (Outlook Data File) downloaded, open it with Outlook (by going to File > Open > Open Outlook Data File in Outlook desktop). You’ll then see an additional mailbox/folder set in Outlook corresponding to the exported data. Navigate inside it to find the specific emails or items.
- You can now copy the needed item back to the user’s mailbox: for example, drag the email from the PST into the user’s Inbox (if you have the mailbox open) or save the item and forward it to the user. If you exported items from only one mailbox and you have access to that mailbox in Outlook, you could also import the PST back into their mailbox directly (with caution to avoid duplicates).
- Another method: instead of you doing this, you could give the PST to the user to review. But usually, the admin or an IT specialist would extract the needed item and restore it to the mailbox.
Completion: Given that eDiscovery is a more involved process, you’d likely communicate with the user throughout. After restoring the item, let the user know it has been recovered and where (e.g., restored to their Inbox or sent to them separately).

Note: Content Search requires that the content still exists in the backend (Recoverable Items or Purges or held by a retention policy). If an item was permanently deleted and no hold or retention preserved it, eDiscovery will not find it after the retention period. Also, eDiscovery in Business Premium is available (Content Search is generally included), but features like Litigation Hold or Advanced eDiscovery might require higher licenses. In our scenario, we assume the organization enabled all appropriate data protection (like retention policies) to allow such recovery.

Using eDiscovery is a powerful way for admins to handle “long-term” recovery and is often the only recourse for items that were deleted long ago or when needing to retrieve data from an inactive mailbox.

4. Restoring a Deleted Mailbox (Entire User Mailbox Recovery)

The above methods focus on recovering items within a mailbox. However, what if an entire mailbox was deleted? This can happen if a user account was deleted or their license was removed. In Microsoft 365, when you delete a user, their Exchange Online mailbox is soft-deleted but recoverable for a limited time.

Key point: When a user is removed, the mailbox is retained for 30 days by default (this is separate from item-level retention). Within that 30-day window, an admin can restore the user account and thereby restore the mailbox. After 30 days, the mailbox is permanently deleted (unless it was put on Litigation Hold or converted to an inactive mailbox beforehand, which for Business Premium is not applicable without an upgraded license).

Steps to restore a deleted mailbox/user:

Restore the user account: Go to the Microsoft 365 Admin Center > Users > Deleted Users. Find the user who was deleted. Microsoft 365 will list users here for 30 days after deletion.
- Select the user and choose Restore. You will be prompted to set a new password for the account and (optionally) send sign-in details. Complete the restore process****. This action essentially undeletes the account in Azure AD and reconnects the original mailbox.
Reassign licenses: After restoration, ensure the user has the Exchange Online (Business Premium) license assigned (the admin center usually gives an option to reassign the old licenses during restore). The mailbox needs an active license to be accessible. Once restored and licensed, the mailbox will reappear in the Active users list and in Exchange Admin Center as an active mailbox.
Verify mailbox content: The mailbox should be exactly as it was at the moment the user was deleted, since it was preserved in soft-delete state. Verify by accessing the mailbox (e.g., via Outlook Web or restoring login to the user). All emails, folders, and other items should be intact. This includes any deleted items that were within retention, etc., as of deletion time. All content is retained during the 30-day soft delete window.
Communicate to user or adjust data as needed: If this was a mistake and the user needed to be restored, they can now simply continue using their mailbox. If the goal was to recover some data from a departed user, at this point an admin can access the mailbox to retrieve specific information (or alternatively, you could convert this mailbox to a shared mailbox if the user is not returning, etc., but that’s beyond scope).

If the 30-day window has passed and no holds were in place, the mailbox is permanently removed and cannot be recovered through native means. At that stage, only if a backup exists or if an inactive mailbox was created (requires advanced licensing) could data be retrieved. It’s crucial to act within that window if an entire mailbox (user) needs restoration.

Additional Notes on Calendar, Contacts, and Tasks Recovery

We touched on this above, but to clarify: emails, calendar items, contacts, and tasks are all treated similarly by Exchange Online’s deletion recovery system.

When a calendar appointment or meeting is deleted, it goes to Deleted Items (yes, even though it’s not an email, it appears in the Deleted Items folder)[2]. If you permanently delete it from there, it can be recovered from the Recoverable Items folder just like an email. The UI in Outlook makes it appear that only mail is listed, but in reality those appointments are there with a blank sender and the subject line (which is the event title). Once recovered, a calendar item can be dragged back to the Calendar interface to restore it.
When a contact is deleted, it also lands in Deleted Items (as a contact item). Users can open Deleted Items folder and find the contact (it will show the contact’s name). If it’s not there, recovering via the Recover Deleted Items tool will list the contact by name (with an envelope icon). After recovery, the contact will be in Deleted Items; from there, it can be dragged into the Contacts folder to restore it fully[2].
When a task is deleted, it behaves in the same way. The task will appear in Deleted Items (and can be restored or dragged back to the Tasks folder). If it was hard-deleted, the Recover Deleted Items tool will show it (again with an envelope icon). After recovering a task, you can drag it from Deleted Items to your Tasks folder.

In summary, all these item types (mail messages, events, contacts, tasks) utilize the same two-stage recycle system (Deleted Items -> Recoverable Items) and thus the recovery methods described for emails apply equally to them[2][2]. The key difference is recognizing them in the recovery interface, since they might not have obvious icons or sender/subject lines like an email. Sorting and carefully reviewing the recovered item list helps identify them.

Best Practices & Preventative Measures

To minimize data loss and simplify recovery in the future, consider the following best practices and protections in an Exchange Online (Business Premium) environment:

Extend Deleted Item Retention: Ensure that the mailbox retention for deleted items is set to the maximum if appropriate for your org. By default it’s 14 days, but admins can increase it to 30 days per mailbox. This gives users a larger window to discover and recover deletions on their own, and gives admins more time for recovery as well. In PowerShell, this is done with:

  Set-Mailbox -Identity user@contoso.com -RetainDeletedItemsFor 30

(30 is the max in days). This is especially important for Business Premium, which might not have unlimited archiving – you want to buy as much time as possible for recovery.

Enable Archive Mailboxes (if available): Microsoft 365 Business Premium now supports archive mailboxes (Online Archive) for users – this was historically an Exchange Plan 2 feature, but Microsoft has made archive available for Business plans as well in recent updates. If not already enabled, admins should enable the Archive Mailbox for each user via EAC or PowerShell. An archive mailbox provides extra storage and can automatically archive old emails (with policies). While it’s not directly a recovery feature, it reduces the likelihood of users deleting stuff just to free up space. Archived mail is still searchable and can be brought back to the main mailbox if needed.
Use Retention Policies for Compliance: If your organization needs to keep data for longer (for legal or compliance reasons), configure a Microsoft Purview retention policy on mailboxes. For example, you might have a policy “retain all emails for 7 years.” Even on Business Premium, you can create such retention policies (this is a compliance feature available across enterprise plans). With a retention policy, even if a user deletes an item, Exchange will keep a copy in a hidden Recoverable Items subfolder (called the “Preservation Hold” library) for the duration of the policy[4]. This effectively means an admin could recover items long past 30 days via eDiscovery as we showed. Important: Retention policies are different from Litigation Hold, but they serve a similar purpose in preserving data. Make sure to communicate and plan retention policies carefully, since they can also mean mailboxes retain a lot of data invisibly.
Litigation Hold / In-Place Hold: Business Premium does not include Litigation Hold capability (that’s an Exchange Plan 2 / E3 feature). If long-term hold of all mailbox content is required (for legal reasons), consider upgrading the specific user to an Exchange Online Plan 2 or an E3 license which supports Litigation Hold. Litigation Hold would preserve everything indefinitely (or until hold is removed), making recovery straightforward but it’s a heavier compliance measure. In our scenario “all appropriate protection methods” likely means retention is used since Litigation Hold isn’t available on Business Premium by default.
Educate and communicate with users: A significant part of data protection is making sure users know how to recover their own items and encouraging good habits:
- Teach users to check Deleted Items first when they miss something.
- Inform them that if they delete something with Shift+Delete (hard delete), it bypasses Deleted Items but can still be recovered for a period of time with some extra steps[1].
- Encourage users to report missing important emails sooner rather than later, so admins can assist if needed before time runs out.
- If users manage their mailbox via mobile or Mac Mail, etc., ensure they know how deletions work (some clients might immediately hard-delete items). The Outlook web and Windows client both fully support the recovery features as described.
Implement a Backup Solution (if needed): Microsoft’s retention and recovery features are usually sufficient for most scenarios. However, some organizations opt for a third-party Office 365 backup service that periodically backs up Exchange Online mailboxes. This can protect against catastrophic scenarios or extended delays (e.g., noticing a deletion after a year). While this may be beyond “built-in” methods, it’s worth noting that 3rd-party backups can allow recovery even after Microsoft’s own retention is expired. This is an extra safety net, especially in Business Premium environments where advanced holds aren’t available.
Monitor mailbox activities: Admins can use audit logs or eDiscovery to monitor unusual deletion activity (for instance, if a user or attacker deletes a large number of items). Early detection can prompt immediate recovery actions. Also, consider enabling alerts for when mailboxes are deleted or retention policies are changed.

By following these best practices, you ensure that “appropriate protection methods” are truly in place and that both users and administrators can collaborate to recover information if something is missing or deleted.

Conclusion:
In an M365 Business Premium environment, recovering missing or deleted mailbox information is very feasible thanks to built-in Exchange Online features. Users have self-service options for recent deletions, and admins have powerful tools for deeper recovery tasks. The keys to success are understanding the time limits (14/30 days by default, longer if retention policies apply) and acting methodically to retrieve the data. With the detailed processes outlined above, both users and admins can confidently restore emails, calendar events, contacts, or tasks that were thought to be lost.

[3]: Litigation Hold: An advanced mailbox hold feature (not available in Business Premium by default) that preserves all mailbox content indefinitely. If a mailbox were on Litigation Hold, even after 30 days post-deletion, the data would be retained. In such a case, recovery would be done via eDiscovery as well, since the content is held beyond the normal retention. Business Premium tenants may need an upgrade for this, so retention policies are the alternative.

References: The information above was compiled from Microsoft documentation and community content, including Microsoft Learn guides on recovering deleted mailbox items[3][3], Microsoft Support articles on Outlook item recovery[2][2], and Exchange Online blog and community posts detailing retention and recovery behaviors[1][4]. Each specific detail is backed by these sources to ensure accuracy.

References

[1] Restore Hard-Deleted Emails in Exchange Online

[2] Recover and restore deleted items in Outlook – Microsoft Support

[3] Recover deleted messages in a user’s mailbox in Exchange Online

[4] Recoverable items in Exchange online. – Microsoft Community

PowerShell script for analyzing Exchange Online email headers

Source =

https://github.com/directorcia/Office365/blob/master/email-header-report.ps1

Overview

The Email Header Report Tool is a PowerShell script that analyzes email headers to identify potential spam, phishing, and security concerns in messages processed by Exchange Online and Microsoft 365. This tool provides security administrators and email analysts with a comprehensive report of authentication results, spam filtering decisions, and other security-related information embedded in email headers.

Features

- Authentication Analysis: Evaluates SPF, DKIM, and DMARC authentication results

- Spam Filter Analysis: Examines SCL (Spam Confidence Level) and other spam indicators

- Defender for Office 365 Analysis: Analyzes Safe Links and Safe Attachments processing results

- Transport Rule Detection: Identifies if mail flow rules were applied to the message

- Risk Assessment: Provides an overall verdict with color-coded risk indicators

- Recommendations: Suggests appropriate actions based on analysis results

Requirements

- PowerShell 5.0 or higher

- Access to email headers from Exchange Online/Microsoft 365 environment

- Windows with support for color console output (for optimal viewing experience)

Usage

.\email-header-report.ps1 -HeaderFilePath "C:\path\to\email_header.txt"

Parameters

Parameter	Type	Required	Description
HeaderFilePath	String	Yes	Path to the text file containing the raw email header

How to Extract Email Headers

From Outlook Desktop

1. Open the email message
2. Click File > Properties
3. The headers appear in the “Internet headers” box
4. Select all and copy to a text file

From Outlook Web App (OWA)

1. Open the email message
2. Click the three dots (⋯) in the top-right corner
3. Select “View message details” or “View > Message details”
4. Copy the headers to a text file

From Microsoft 365 Security Portal

1. Navigate to the message in quarantine or Explorer view
2. Select the message and view details
3. Find and copy the headers to a text file

Understanding the Report

The report is divided into several sections:

Authentication Analysis

Shows the results of email authentication protocols:

- SPF (Sender Policy Framework): Verifies if the sending server is authorized to send email for the domain

- DKIM (DomainKeys Identified Mail): Validates the digital signature attached to the message

- DMARC (Domain-based Message Authentication, Reporting, and Conformance): Evaluates alignment between the sender’s domain and the authenticated domain

- CompAuth: Microsoft’s composite authentication result

Spam Filtering Analysis

Details how Exchange Online Protection and Microsoft 365 evaluated the message:

- SCL (Spam Confidence Level): Score from -1 to 9 indicating spam probability

- BCL (Bulk Complaint Level): Score from 0 to 9 for bulk email

- Forefront Anti-Spam Report: Detailed anti-spam processing information

- Delivery Destination: Where the message was delivered (Inbox, Junk, Quarantine, etc.)

Safe Attachments Analysis

Shows results from Defender for Office 365 attachment scanning:

- CLEAN: No malicious content detected

- BLOCK: Malicious content detected and blocked

- REPLACE: Malicious attachment replaced with a placeholder

- DYNAMICDELIVERY: Attachment analysis performed with temporary placeholder

Safe Links Analysis

Shows results from Defender for Office 365 URL scanning:

- CLEAN: No malicious URLs detected

- BLOCK: Malicious URLs detected and rewritten/blocked

- PENDING: Analysis in progress

- NOT SCANNED: URLs were not evaluated

General Message Analysis

Provides additional information about the message:

- Originating IP: Source IP address of the sender

- Message ID: Unique identifier for the message

- Return-Path vs From: Compares the envelope sender with the display sender

Analysis Summary

Provides an overall verdict based on all factors:

- HIGH RISK / SPAM DETECTED: Strong indicators of being spam or malicious

- POTENTIAL RISK / LIKELY SPAM: Several characteristics of spam or unwanted mail

- LIKELY LEGITIMATE: Message appears to be legitimate based on key checks

- MIXED RESULTS / CAUTION ADVISED: Some checks passed, others raised concerns

Interpreting Key Values

SCL (Spam Confidence Level)

Value	Meaning	Typical Action
-1	Trusted sender	Bypasses spam filtering
0-1	Not spam	Delivered to inbox
2-4	Low spam probability	Usually delivered to inbox
5-6	Spam	Usually delivered to junk folder
7-9	High confidence spam	Quarantined or rejected

Authentication Results

Result	Meaning
Pass	Authentication successful
Fail	Authentication failed
SoftFail	Weak failure (typically for SPF)
Neutral	No policy assertion
None	No policy found
PermError	Permanent error in policy
TempError	Temporary error during lookup

Examples

Legitimate Message Example

AUTHENTICATION ANALYSIS
-----------------------
  [SPF] PASS
  [DKIM] PASS
  [DMARC] PASS
  [Composite Auth (CompAuth)] PASS

EXCHANGE ONLINE SPAM FILTERING ANALYSIS
--------------------------------------
  [SCL (Spam Confidence Level)] 0 - Not spam (message determined to be clean by EOP content filter).
  
MESSAGE VERDICT:
──────────────────────────────────────────────────
  ✅ LIKELY LEGITIMATE
     This message appears to be legitimate based on key checks.

Spam Message Example

AUTHENTICATION ANALYSIS
-----------------------
  [SPF] FAIL
  [DKIM] FAIL
  [DMARC] FAIL
  [Composite Auth (CompAuth)] FAIL

EXCHANGE ONLINE SPAM FILTERING ANALYSIS
--------------------------------------
  [SCL (Spam Confidence Level)] 9 - Definite spam (highest confidence, typically quarantined or rejected).
  
MESSAGE VERDICT:
──────────────────────────────────────────────────
   HIGH RISK / SPAM DETECTED
     This message shows strong indicators of being spam or malicious.

Troubleshooting

Script Errors

- Ensure you’re using PowerShell 5.0 or higher

- Verify the header file exists and is readable

- Check that the header file contains valid email headers

Missing Information

Some headers might not be present depending on:

- Email routing path

- Microsoft 365 subscription level

- Security features enabled in your tenant

- Age of the message (older messages might use different headers)

False Positives/Negatives

- The tool analyzes only what’s present in the headers

- It doesn’t re-evaluate the message content

- Discrepancies may occur if policies changed after message delivery

Advanced Usage

Piping Output

You can redirect the output to a file:

.\email-header-report.ps1 -HeaderFilePath "C:\path\to\header.txt" > "report.txt"

Incorporating into Other Scripts

The script can be called from other PowerShell scripts or functions:

& "C:\path\to\email-header-report.ps1" -HeaderFilePath $headerPath

References

- Microsoft 365 Security Documentation

- Exchange Online Protection (EOP)

- Anti-spam message headers in Microsoft 365

- Spam confidence levels (SCL)

- Bulk Complaint Level (BCL) values

- How Microsoft 365 uses SPF

- How Microsoft 365 uses DKIM

- How Microsoft 365 uses DMARC

- RFC 5322 (Internet Message Format)

- RFC 7208 (SPF)

- RFC 6376 (DKIM)

- RFC 7489 (DMARC)

License

This script is provided as-is with no warranties. Use at your own risk.

Analyzing Exchange Online Email Headers for Junk/Quarantine Reasons

Understanding the information in an email header can reveal why a message was marked as junk (spam) or placed in quarantine by Exchange Online. Email headers in Exchange Online contain specialized “X-” fields that record spam filtering results and policy actions, allowing administrators to decipher which policies were applied and what the outcome was[2]. Below, we explain key header fields, how to interpret them, and a step-by-step guide to analyse an email header to determine why a message ended up in Junk or Quarantine. We also discuss tools and best practices for using header information in troubleshooting.

Key Header Fields and What They Mean

Exchange Online (part of Microsoft 365) adds several anti-spam and policy-related fields to message headers. The most important ones for diagnosing junk/quarantine issues are listed below:

X-Forefront-Antispam-Report – Contains detailed spam filtering diagnostics. This single header includes many field:value pairs (separated by semicolons) about how the message was processed[2]. Key sub-fields include:
- SCL (Spam Confidence Level) – A numeric score from -1 to 9 indicating spam likelihood[4]. Higher values mean the message is more likely spam. For example, SCL 5 or above typically means the message was flagged as spam, whereas SCL -1 means the sender was whitelisted (skipped spam filtering)[1][4].
- SFV (Spam Filter Verdict) – A code summarising what the spam filter decided to do. For example: SFV:NSPM means “not spam” (message is clean)[2]; SFV:SPM means the filter classified it as spam[2]; SFV:SKQ means the message was quarantined and later released to the mailbox[2][2]; SFV:SKS means it was flagged as spam by a mail flow rule before normal filtering[2][2]. Many other codes exist (e.g. SFE for Safe Sender, SKB for blocked sender) which indicate if users’ safe/block lists or admin allow/block policies affected the mail[2]. (See Table 1 below for a summary of common SFV values.)
- CIP (Connecting IP) – The IP address of the sending server[2]. This can indicate if the sender is on a blocked IP list or allowed list. For instance, IPV:CAL in the header means the IP was on the admin’s IP Allow List (skipping spam filtering)[2], whereas IPV:NLI means the IP had no negative listing (not on known blocklists)[1][2].
- CAT (Category) – Indicates which protection policy category was triggered[2]. Examples: CAT:SPM for spam, CAT:PHSH for phishing, CAT:HPHISH for high-confidence phishing, CAT:BULK for bulk mail, etc.[2]. This helps identify what type of threat (spam, phishing, malware, etc.) the system associated with the message. If multiple filters flag the email, multiple categories might appear here (though only the highest priority policy ultimately determines the action)[2].
- Other fields – There are many other fields in X-Forefront-Antispam-Report (such as DIR for direction, CTRY for country of origin, PTR for reverse DNS, LANG for message language, etc.) which provide context[2][2]. These can sometimes help (e.g. a foreign language or unusual country source might slightly affect spam scoring), but the SCL, SFV, CAT, and IPV are usually most directly relevant to junk/quarantine decisions.
X-Microsoft-Antispam – Provides additional spam filtering info, notably about bulk mail and phishing confidence[2][4]. It commonly includes:
- BCL (Bulk Complaint Level) – A score from 0 to 9 indicating how likely the message is bulk mail that recipients might consider unwanted “gray mail.” Higher BCL means more people have complained about similar messages. For example, BCL 0 means not bulk, 3 means a bulk sender with few complaints, and 9 means a bulk sender with a high complaint rate[4]. Administrators set a threshold (default around 7) above which Exchange Online will treat the mail as spam. If a message’s BCL exceeds your tenant’s bulk mail threshold, it can be sent to junk.
- PCL (Phish Confidence Level) – A 0 to 9 score for how likely the email is a phishing attempt[4]. Lower is better; e.g. PCL 2–3 is neutral (likely not a phish), while PCL 4–8 suggests suspicious elements (possible phishing)[4]. A very high PCL might indicate the phishing filters strongly suspect the message.
- Additional info – The X-Microsoft-Antispam header may contain internal identifiers or flags related to spam filtering. Often, however, admins focus on BCL and any mentions of specific filter flags here. (Note: There is also X-Microsoft-Antispam-Message-Info, which is an encoded string of data used by Microsoft – not human-readable – and X-CustomSpam headers added if an Advanced Spam Filter (ASF) rule was triggered[2].)
Authentication-Results – Shows the results of email authentication checks: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication Reporting & Conformance)[2]. For example, it might contain entries like spf=pass or spf=fail, dkim=pass, dmarc=pass/fail for the sending domain[7]. Failed or missing authentication can increase spam score. For instance, if SPF or DKIM fails, and especially if DMARC policy is reject/quarantine, Exchange Online is more likely to mark the message as spam or quarantine it. Authentication-Results also may include a compauth=pass/fail (composite authentication) which is Microsoft’s overall assessment of authentication (considering SPF, DKIM, and ARC)[7].
X-MS-Exchange-Organization-SCL and X-MS-Exchange-Organization-PCL – These might appear as separate headers (especially in Outlook.com/Office365 consumer or internal routing) showing the numeric SCL and PCL values in plain form[4]. For example, you might see X-MS-Exchange-Organization-SCL: 5 indicating the spam confidence level is 5 (borderline spam)[7]. These values correspond to the ones in the composite X-Forefront header.
X-Microsoft-Antispam-Mailbox-Delivery – This header is added when the message reaches the mailbox and informs how it was finally delivered. It indicates if user-level filtering or mailbox rules moved the message to Junk. Key fields within this header include:
- dest: – The destination folder: usually I for Inbox or J for Junk[4]. If you see dest:J, it confirms the message landed in the Junk folder.
- ucf: – User Controlled Filtering. A value of 1 here can mean the user’s own Safe Senders/Blocked Senders or client-side rules had an effect. For instance, ucf:1 might show the user had a block rule or sender on blocked list, contributing to Junk delivery.
- jmr: – Junk Mail Rule verdict (Outlook’s client-side heuristic spam filter). jmr:1 would indicate the Outlook client (or OWA) junk filter algorithm believed the message was spam. In modern Exchange Online scenarios this is often 0 (since server-side filtering usually dominates).
- auth: – If authentication influenced mailbox delivery. For example, auth:1 could indicate the message passed authentication checks; auth:0 might hint authentication was not satisfied.
- OFR: / RF: – These codes (e.g. OFR:SpamFilterAuthJ or RF:JunkEmail) are internal codes for which spam/filter rule caused the message to go to Junk. They are not well-documented publicly, but they can hint at the reason (such as Outlook’s filtering vs. Exchange Online policy)[7].

Table 1: Common Spam Filter Verdict (SFV) Codes in Headers

SFV Code
Meaning and Action

NSPM
Not Spam – The message passed filtering as non-spam[2]. It was delivered to Inbox (unless something else moved it).

SPM
Spam – The content was flagged as spam by EOP’s content filter[2]. Typically, such messages get SCL 5-9 and go to Junk or Quarantine based on policy.

SKB
Spam (blocked sender) – The message was marked spam because the sender/domain is in a block list (tenant block list in anti-spam policy)[2]. Action is usually Junk or Quarantine per policy.

SFE
Allowed (Safe sender) – Filtering was Skipped because the sender is in a Safe Senders list (user or tenant)[2]. The message is delivered normally.

SKA
Allowed (Admin allow) – Spam filter Skipped because sender/domain is in an allowed list in the anti-spam policy[2]. Delivered to Inbox.

SKN
Non-spam (Bypass) – Message was pre-marked safe (SCL -1) by a rule or previous verdict, so spam filtering was bypassed[2]. Delivered to Inbox.

SKQ
Quarantined – The message was initially quarantined by EOP (e.g. high confidence spam), then later Released from quarantine to the recipient[2][2]. (If you see SKQ, the copy you are inspecting was delivered after a manual release.)

SKS
Spam (via rule) – Marked as spam before normal filtering, e.g. by a mail flow rule that set SCL to spam[2][2]. Treated as spam (Junk).

BLK
Blocked – Filtering skipped because recipient blocked the sender (user’s blocked senders list)[2]. The message was dropped (not delivered to inbox).

SRV:BULK
Bulk mail – The message was identified as bulk mail by EOP and exceeded the bulk threshold, so it was marked spam (usually SCL 6)[2].

Note: These header values reflect what policies were applied. For instance, seeing SFV:SKB (spam due to blocked sender) tells us an anti-spam policy’s block list was applied[2]. Seeing SRV:BULK shows the bulk mail filter policy classified it as spam[2]. In this way, the header lets us infer which filtering mechanism or policy list influenced the decision (content vs. safe/blocked sender lists vs. bulk filter, etc.).

Interpreting Headers to Identify Applied Policies

Yes – it is possible to decipher the header to track policies applied and their results. By examining the fields above, you can determine why Exchange Online took a certain action:

Spam Filtering Policies: The combination of SCL and SFV (and sometimes CAT) reveals the spam filter’s verdict. For example, SCL 9 with SFV:SPM and CAT:HPHISH would indicate the message was judged as high confidence phishing by the anti-phishing policy, likely causing it to be quarantined (since by default high phish is quarantined)[2][2]. If you see SFV:SRV:BULK, it means the bulk mail filter policy (part of anti-spam) marked it as spam[2]. A SFV:SKB result indicates an organization’s Blocked Senders policy blocked it[2]. In each case, the header’s codes map to a specific policy action:
- Content-based Spam Filtering: indicated by SFV:SPM (spam) vs NSPM (not spam) and the SCL rating[2][2].
- High confidence spam/phish: indicated by very high SCL (usually 9) and possibly category tags like HSPM or HPHISH[2].
- Blocked/Allowed Sender Policies: indicated by SFV:SKB (blocked sender/domain) or SFV:SKA/SFE (allowed sender/domain)[2][2].
- Bulk mail threshold: indicated by SRV:BULK and a BCL value in X-Microsoft-Antispam header[2][4].
- Mail Flow (Transport) Rules: If an admin-created rule set an action, its effect may appear in headers. For example, a rule that sets spam confidence will show an SCL in the header (often along with SFV:SKS if it set SCL 5+)[2]. Some mail flow rules add custom headers or comments; if present, those are visible too. (E.g., a rule could stamp “X-Company-Rule: AutoEncrypted=Yes” or similar – these would be visible if configured, though not default.)
Authentication Policies: The Authentication-Results header indicates whether SPF, DKIM, and DMARC checks passed. Exchange Online’s spam policy heavily favors authenticated email. If, for instance, SPF and DKIM both failed and DMARC policy was “quarantine/reject,” EOP will likely treat the mail as untrustworthy (often raising the SCL to spam). A header showing spf=fail or dmarc=fail aligns with DMARC enforcement policies being applied. For example, if DMARC says to quarantine and the message fails DMARC, it may go to Quarantine – the header will show DMARC fail, and the SFV might be SPM (spam) as a result. Conversely, compauth=pass with SPF/DKIM pass suggests authentication wasn’t the issue[7], so the spam verdict must have come from content or other filters.
Anti-Phishing Policies: Exchange Online’s Defender for Office 365 provides anti-phishing protection (impersonation protection, etc.). If those policies trigger, the header may show CAT:HPHISH, CAT:PHSH, CAT:UIMP (user impersonation) or similar categories[2]. There is also a field SFTY (safety) that, when present with values like 9.20 or 9.19, indicates user or domain impersonation was detected by anti-phishing policies[2]. These would correspond to actions like delivering to Junk with a safety tip or even quarantine if configured. For example, SFTY:9.20 combined with a high SCL implies an anti-phishing policy saw user impersonation and likely caused the message to be treated as phish[2].
Malware/Safe Attachments Policies: Malware detection usually results in outright rejection or quarantine before delivery. If an email was quarantined due to malware, you typically wouldn’t see normal headers in the user’s mailbox (since it never got delivered). However, if you retrieve the header from the quarantine portal or an admin tool, you might see CAT:MALW (malware) or references to the Safe Attachments scanner (ATP) in the X-Forefront-Antispam-Report (CAT:SAP for Safe Attachments policy)[2]. Additionally, an X-Exchange-Organization-AV stamp might indicate malware scan results. These are less commonly examined via header by end-users (since such messages are in quarantine, not in the Junk folder).

In summary, each header field provides clues about which filter or policy acted on the message. By piecing together SCL/SFV (spam filter outcome), CAT (category of threat), authentication results, and other flags, you can often trace the decision path. For example, “Header shows CAT:BULK, BCL:8, SCL:6, SFV:SPM” – this tells us the Bulk mail policy identified it as spam (bulk complaint level high), resulting in spam verdict and Junk delivery. Or “Header shows SPF fail and SFV:SPM” – suggests the message failed authentication and was marked spam by policy (possibly due to failing an anti-spoof or DMARC policy).

Important: The headers do not usually name a custom policy by name (e.g., “Contoso Spam Policy”), but they show the effect. For exact policy names or rule names that triggered, an admin would use the Message Trace or Explorer (discussed below). However, for most purposes the header’s codes are enough to deduce the cause (content, sender reputation, authentication failure, etc.) behind the Junk/Quarantine decision.

Step-by-Step Guide: How to Analyze an Email Header in Exchange Online

Follow these steps to examine an email’s header and determine why it went to Junk or Quarantine:

1. Retrieve the Full Message Header:
In Outlook on the web or Outlook client, view the message options to get the internet headers. For example, in Outlook desktop: open the email, go to File > Properties > Internet Headers. In OWA: open the email, click “⋯” (More actions) > View message details. Copy the entire header text.

2. Use a Header Analyzer Tool (Optional):
To make the header more readable, you can use Microsoft’s Message Header Analyzer tool[2]. Microsoft provides an online analyzer (in the Microsoft 365 Defender portal, or via tools like Outlook Message Header Analyzer). Paste the header text into the analyzer – it will format the header into a table and highlight key values (like the SPF/DKIM results and SCL). This is recommended for convenience[2], but you can also read it manually.

**3. Check *Authentication-Results***:
Early in the header, find the *Authentication-Results* line. Examine whether SPF, DKIM, and DMARC passed or failed[7].

If you see “spf=fail” or “dkim=fail”, that indicates the sender’s domain failed authentication – a red flag for spam/phishing. A DMARC fail (especially with p=quarantine/reject) is even more likely to result in spam or rejection.
If all are “pass”, then you know the decision to junk the email was not due to standard authentication failure (it passed the identity checks).

**4. Locate *X-Forefront-Antispam-Report***:
This header might be long. It usually starts with X-Forefront-Antispam-Report:. Look inside it for key fields:

SCL: Note the number after SCL:[2]. This is the Spam Confidence Level. Use the value to gauge spam likelihood (-1 means trusted, 0-1 not spam, 5+ likely spam[4]). For instance, SCL 5 or 6 means it was probably sent to Junk, 9 often means quarantined (if high confidence spam/phish).
SFV: Find the SFV: code[2][2]. Use Table 1 (and the definitions above) to interpret the verdict. Key outcomes: NSPM (not spam, should go to Inbox), SPM (spam content), SK codes (indicate skipped or pre-marked by safelist/block or rules), BLK (blocked by user). This tells you why the filter classified it as it did. For example, SFV:BLK means a user blocked the sender[2]; SFV:SKB means your tenant block list caught it[2]; SFV:SPM means it simply looked like spam to the filter[2].
CAT (Category): If present, see what category tag is there (SPM, PHSH, BULK, etc.)[2]. This shows the type of filter/policy. E.g. CAT:PHSH would hint a phishing policy trigger.
Other values: Check for IP reputation indicators like IPV:. If it’s IPV:CAL (IP allowed) or IPV:NLI (not on blocklists)[2], that tells you the sending IP wasn’t blacklisted in connection filtering[1]. If neither CAL nor NLI is present, the IP might have a poor reputation (which can contribute to spam scoring). Also note PTR (reverse DNS) and CTRY (country) if relevant, though these are just informational.

**5. Examine *X-Microsoft-Antispam*** (and related):
Look at X-Microsoft-Antispam and potentially X-MS-Exchange-Organization-SCL/PCL lines if they exist:

Note the BCL value in X-Microsoft-Antispam (e.g., BCL:8). If BCL is high (above ~7) it means Microsoft considered it bulk mail with many complaints[4]. This often causes the mail to go to junk if your spam policy is set to mark bulk mail as spam (which is default). A low BCL (0-3) means bulk mail but low complaints[4].
If present, note the PCL (Phish Confidence Level) header or value. A higher PCL (like 4-8) suggests the content resembled phishing[4], which may have contributed to a higher SCL.
Check for X-Microsoft-Antispam-Mailbox-Delivery header and find dest:. If it says dest:J, that confirms the message ended in Junk folder[4]. This header also shows if user’s Safe Senders/Blocked Senders had any effect (ucf: field) or if Outlook’s client filter (jmr) was involved. For example, ucf:1 means the user explicitly blocked the sender or domain in their mailbox settings, which would send even a benign email to Junk. On the other hand, ucf:0; jmr:0; auth:1; dest:J (as in a sample above) means the system (server) decided on Junk despite no user rule, likely due to server spam verdict[7].

6. Identify the Trigger:
With the above information, deduce which policy or mechanism “tipped the scales.” For instance:

If authentication failed (Step 3) and you see a spam verdict, then the lack of proper auth might be the key reason (especially if SFV=SPM with no other obvious cause, or SFV has an “Auth” related code like OFR:SpamFilterAuthJ in mailbox delivery[7]).
If SFV indicates a safelist/blocked list, then a user or admin safe/blocked sender policy applied. E.g., SFV:SKA or SFE means it bypassed spam filtering due to safelist[2], whereas SKB means a block list caught it[2].
If BCL is high and SRV:BULK is present, then the Bulk mail filter policy marked it as spam due to being bulk mail[2].
If CAT or SFTY indicates phishing (or SCL = 9 with PCL high), it’s likely an anti-phishing policy triggered (like impersonation protection).
If none of these stand out except a moderately high SCL (e.g. 5 or 6) and SFV:SPM, it might just be the general content filter (Spam Filter Policy) that decided the email content looked spammy (common for typical junk mail). Microsoft’s filters consider many things (keywords, links, sender reputation, etc.) to assign SCL.

7. Consult Message Trace (if needed):
The header analysis usually tells the story. However, for further confirmation, an Exchange Message Trace or the Microsoft 365 Defender “Threat Explorer” can be used by an admin. These tools can show the exact policies and actions applied to the message (e.g., “Anti-spam policy ‘Default’ applied, action: Moved to Junk”, or “High Phish detected, action: Quarantined”). Message Trace isn’t a header, but it’s a complementary step if header info is unclear. (For example, if you saw a header with SCL 5 but aren’t sure why, the trace might say “Spoof intelligence: Phish” or similar reason.)

8. Verify Quarantine Scenarios:
If the email was quarantined (never reached the mailbox), you typically won’t have the header in your inbox. Admins can view the header via the quarantine portal by previewing the message details. The analysis approach is similar: check the same fields there. Often quarantine happens for higher-severity threats: e.g., malware (virus), high confidence phishing, or admin policies set to quarantine certain spam. In such cases, the header’s SFV might not be visible (since it didn’t go through to the mailbox), but the admin portal will directly state the malware or phish policy that acted. For Junk vs Quarantine: by default, Exchange Online will send most spam to Junk, but “High confidence spam” or certain phish gets quarantined. So an SCL of 9 with PHISH category likely equals quarantine. Understanding this default behavior helps interpret the header’s implications.

9. Summarize the Findings:
After parsing the header, you should be able to answer: Why was this email marked spam? Perhaps the SPF failed and the domain had no reputation (so it got SCL 5), or the sender was on a blocklist, or the content was suspicious. Document the specific indicators from the header:

e.g., “The header shows SCL:6 and SFV:SPM, meaning Exchange Online’s spam filter flagged the content as spam[2]. Additionally, PCL:5 in the X-Microsoft-Antispam header suggests it had phishing-like content. Therefore, the email was sent to Junk by the spam/phishing content filter.”
Or “SFV:SKB is present, which indicates our tenant’s Blocked Senders policy blocked the email[2]. The sender’s address or domain must be in the block list, causing the message to be routed to Junk.”
Or “Authentication-Results show SPF failure, and the header has CAT:SPOOF – this suggests the anti-spoofing policy kicked in and spam-filtered the message (possible DMARC/anti-spoof enforcement).”
If multiple factors appear (e.g., bulk mail that also failed SPF), note all contributing factors.

By carefully stepping through these checks, you can decipher the header and pinpoint the reason for the spam/junk verdict or quarantine.

Tools and Methods for Header Analysis

Microsoft provides several tools to help interpret message headers and track policy actions:

Microsoft 365 Message Header Analyzer: As mentioned, this tool can parse raw headers into a readable format[2]. It’s available through the Microsoft 365 Defender portal (Security Center) under Threat Analysis tools, or via standalone web tools. It will highlight fields like SCL, spam verdict, and authentication results, saving time. Using it can directly answer questions like “was this marked as spam and why” without manually decoding every acronym.
Exchange Admin Center – Message Trace: The Exchange Message Trace utility allows administrators to trace an email’s journey. A message trace for the email in question will show events and policies, e.g., “Delivered to Junk Folder” or “Quarantined by policy”, along with any transport rule actions. While not as detailed as headers in terms of spam score, it can list which Anti-Spam policy (content filter policy) applied and what action it took. Message Trace also shows if a mail flow rule was triggered.
Threat Explorer (Microsoft Defender for Office 365): If your organization has Defender for Office 365 (Plan 2 or E5), the Threat Explorer (or real-time detections) tool can be very insightful[3]. It can show why a message was categorized as it was (e.g., it might explicitly say “Phish confidence high” or “User impersonation detected”). Threat Explorer surfaces the same info contained in headers but in a user-friendly way, and is great for investigating phishing/spam incidents[3]. It even allows viewing the headers and some content of the message in a secure way.
PowerShell (Get-MessageTrace / Get-QuarantineMessage): For advanced admins, PowerShell cmdlets can retrieve trace details or quarantine info, which might include some header fields or policy names.
Third-Party Header Analyzers: Tools like MXToolbox’s header analyzer or other online parsers can also decode routing and spam headers. They might not understand every Microsoft-specific field, but they will list them out clearly and flag obvious issues (like a large time gap in a Received chain, or a fail in SPF).

Note: Standard email clients (Outlook) don’t interpret these headers for you – they simply act on them (e.g., if SCL>=5, Outlook will put it in Junk automatically). So, the above tools are needed for humans to decode the headers.

Common Reasons Emails Go to Junk/Quarantine (Shown by Headers)

By reviewing many such headers, administrators find recurring causes for legitimate emails being misclassified. Some common reasons (and how they appear in headers) include:

Failed Authentication: A legitimate sender’s email fails SPF or DKIM (e.g., due to misconfigured DNS records or sending on behalf of another domain). The header shows spf=fail or dkim=fail, and often the spam filter reacts with SFV:SPM or CAT:SPOOF. For example, if an email from [email protected] comes through an unexpected server, SPF might fail and Exchange Online thinks it could be a spoof. Ensuring SPF/DKIM are set up correctly for all sending services will prevent this.
IP or Domain Reputation Issues: Even if authentication passes, the sender’s IP or domain may have a poor reputation. In the header, you might see no IPV:NLI (meaning the IP could be on a watchlist) and a high SCL. Or the BCL could be high, indicating many recipients marked messages from that sender as spam in the past[4]. Also, X-Forefront-Antispam-Report sometimes has an SFS field (Spam Filter Score) internally reflecting rules matched. Solution: The sender might need to improve their sending practices, or you may add them to a safe senders list if you trust them.
Bulk (Graymail) Filtering: The email might be a newsletter or bulk notification that isn’t strictly malicious but is considered unwelcome. Headers will show a high BCL and SRV:BULK with SCL around 6[2]. By default, Exchange Online will send bulk mail above the threshold to Junk. Solution: If this bulk sender is desired, the admin can raise the bulk threshold or add that sender to the allowed list; individual users can also add to Safe Senders (which would give future messages SCL -1, bypassing spam filter[1]).
Content Triggers (Spam Keywords/Patterns): The email content might contain phrases or styles that the spam filter flags (e.g., too many marketing phrases, suspicious links, formatting resembling phishing). This results in SFV:SPM with a moderate SCL (5-7) and no special safe/blocked indicators. Essentially, the filter’s AI said “this looks spammy.” Solution: If you control the sending content, avoid spam-like features; if you’re the recipient admin and it’s false positive, you might loosen the spam filter aggression slightly or create a rule to trust that sender/content.
Phishing Detection: If an email tries to impersonate your organization or a VIP, the anti-phishing policies might catch it. The header could show SFTY:9.20 (user impersonation) or CAT:UIP (user impersonation) and an SCL of 8 or 9[2]. It will almost certainly go to Junk or quarantine. Example: an attacker impersonates your CEO’s name – Defender for O365 flags it. Solution: Ensure anti-phishing policies are tuned (so they don’t false-positive on legitimate emails) and educate users. If it’s a false positive (e.g., a vendor coincidentally has the same name as your CEO), you might need to adjust allowed sender lists in the anti-phish policy.
User/Administrator Filtering Rules: Sometimes the cause is outside of EOP’s automatic filters. A user might have accidentally added the sender to their Blocked Senders list, which forces even genuine emails to Junk. In the header, SFV:BLK will appear in such a case[2]. Alternatively, an admin might have created a mail flow rule that flags certain content and sets SCL to 9 or redirects to quarantine. In these cases, the header can still reveal it: a mail flow rule can add an identifiable header or you might see SFV:SKS (spam via rule)[2]. Solution: Check user’s Outlook junk settings and admin transport rules if a particular pattern of false positive keeps occurring.
Spoofing and Safety Tips: Exchange Online has anti-spoof measures. If an external email claims to be from your domain or a similar domain, it might get flagged (CAT:SPOOF or an SFV:SPM with compauth=fail). Additionally, first-contact safety tips (SFTY:9.25) don’t directly junk a message, but indicate the system’s caution[2]. Such headers show the protective features at work.

By recognizing these patterns in the headers, administrators can address the root cause (whether that’s fixing the sender’s SPF record, or updating a safe sender list, or modifying a rule, etc.).

Using Headers for Troubleshooting and Improvement

Email headers are invaluable for troubleshooting delivery issues. An administrator can use them to answer: “Was my email blocked by a policy? Or was it something about the content?” Here are some best practices and tips:

Always start with header analysis for spam issues: When a user says “Email from X is going to Junk,” grab the header from that junk email. The header provides a transparent view of Exchange Online’s verdicts[2]. This is often quicker than guessing which policy might be responsible.
Correlate header info with policy settings: For example, if the header shows BCL 7 and got marked as spam, check your tenant’s Anti-Spam policy Bulk mail threshold. If your threshold is 5, that explains it – maybe you’ll decide to bump it higher if too many wanted newsletters are going to Junk. If the header shows SFV:SKB (blocked sender by organization)[2], you know to check the tenant block sender list in your spam policy settings.
Authentication issues: If you see the sender failing SPF or DMARC, you might reach out to that sender to inform them, or as a temporary measure add them to the allow list if you trust them (to bypass spam filtering until they fix their SPF). But be cautious – only bypass if you are confident it’s a false alarm and not a genuine threat.
False Positives vs. False Negatives: Headers help with both. For a false positive (good email marked spam), the header tells you why, so you can adjust filters or add an exception. For a false negative (spam delivered to Inbox), a header might show a low SCL and SFV:NSPM – meaning the system thought it was fine. In such cases, you might tighten policies or add specific block rules. (For instance, if phishing got through with PCL 3 and SCL 1, maybe enable stricter anti-phishing measures.)
Improving filtering: Over time, track headers of spam that got through and legit mail that was junked. You may spot patterns – e.g., many false positives have a particular link or triggering content: you could adjust the allowed domains or train users to use the “Not Junk” button which sends feedback to Microsoft. Microsoft’s filtering AI does adapt to feedback and to widespread trends, but tenant-level tweaks are sometimes needed.
User education: Encourage users to use the “Mark as not junk” option for legitimate emails in Junk. This action in Outlook not only moves the mail but also can inform the system (especially if you have the user submission feature enabled)[6]. The header of a user-reported message can then be reviewed by Microsoft to adjust tuning. On the flip side, remind users not to indiscriminately trust emails just because they passed SPF – show them how to read the warnings (Exchange will sometimes include a warning in the message if it suspects phishing, via a safety tip banner).
Limitations of header analysis: While headers are powerful, be aware of their limits. Encrypted emails (e.g., using end-to-end encryption) might not have full scanning results if they weren’t scanned. Also, some advanced threats might only be identified by attachment sandboxing or time-of-click URL detonation (these results might not reflect in the header at delivery time – e.g., an email could be delivered, then later a Safe Attachments scan finds malware and quarantines it after delivery, which wouldn’t retroactively change the original header). For those scenarios, you rely on the Defender portal alerts rather than header. Additionally, as noted, headers won’t name custom policies; they just show outcomes. If you have multiple spam policies (say different ones per domain), the header won’t tell you which one applied – you infer it based on the recipient or you check message trace.
Document and reference: When solving a spam issue, it’s helpful to copy the header fields into your helpdesk notes. That way, if a similar issue arises, you can compare. For example, “Last month, company X’s emails were getting SCL 5 due to SPF fail – we added them to allowed senders as a workaround.” This builds organisational knowledge on filtering quirks.
Keep learning and updating policies: Microsoft’s filters evolve (they release updates frequently), so what was once delivered might suddenly start going to Junk if new spam rules catch something in the content (as was likely the case in a Spiceworks forum example where Office 365 started blocking previously accepted emails[5]). Thus, ongoing monitoring of headers and updating of allow/block lists, spam policy thresholds, etc., is part of email administration. Use headers to verify if a change in Microsoft’s filtering is affecting you, and then adjust accordingly or contact Microsoft support with evidence if needed.

Finally, if in doubt, leverage Microsoft resources: The Microsoft documentation on anti-spam headers provides reference for each field[2], and communities (Microsoft TechCommunity, forums) often have discussions decoding specific header codes. With practice, reading an Exchange Online header becomes second nature and is a reliable way to track the policies and filters at work on any given email.

Additional Resources

Microsoft Learn – Anti-spam message headers in Microsoft 365[2] – Official documentation listing all the X-Forefront-Antispam-Report and related header fields and their meanings (great for reference).
Nylas Guide – Deciphering spam headers for Office 365[1] – A practical tutorial on reading spam header values (with common codes like IPV, SCL, SFV explained in plain language).
Spam Resource Blog – Decoding hidden spam headers[4] – An article explaining SCL, PCL, BCL, and the X-Microsoft-Antispam-Mailbox-Delivery fields, with examples.
Practical 365 – Tracing Junk Mail in Exchange Online[3] – Discusses tools like message trace and Explorer for investigating spam/junk issues.
Microsoft Tech Community forums/Q&A – There are Q&A posts where Microsoft engineers or experts have explained specific header lines (for example, the meaning of OFR:SpamFilterAuthJ or other cryptic flags). These can be useful if you encounter an unfamiliar code in a header.
Exchange Online Protection Overview – For understanding the overall spam filtering and policy configuration that leads to these headers (Microsoft Docs on Anti-spam and Anti-phishing policy setup). Knowing what options admins have (like adjusting thresholds or actions) helps interpret why an email went to Junk versus Quarantine.

By leveraging the information in email headers and the resources above, administrators can confidently decipher why an email was classified as spam and take appropriate action – whether that’s adjusting a policy, informing the sender to fix their setup, or simply reassuring the user that the system is working as intended to filter threats. The header is essentially the “log file” of the email’s evaluation, and with the guidelines in this report, you can read that log to track the policies applied and their results. [2][1]

References

[1] Deciphering spam headers for Office365 recipients – Nylas

[2] Anti-spam message headers – Microsoft Defender for Office 365

[3] Using Advanced Message Tracking to identify Junk-Mail and Spoof …

[4] Microsoft: Decoding hidden spam-related headers

[5] email getting filtered as spam on 365 all of a sudden. Advice?

[6] (False Positives) How to handle legitimate emails getting blocked from …

[7] My emails are marked as SPAM in Outlook and Office365

Best practices for configuring anti-spam policy settings in Microsoft Exchange Online

Best Practice Anti-Spam Policy Settings for SMBs

For small and medium-sized businesses (SMBs), the goal is to strike a balance between strong protection and minimal disruption to legitimate communications. The following are recommended best practices:

1. Use Preset Security Policies (Standard or Strict)

Microsoft recommends starting with the built-in Standard or Strict preset security policies. These are optimised for most organisations and include anti-spam, anti-phishing, and anti-malware settings.

Standard: Balanced protection with fewer false positives.
Strict: Higher protection, suitable for high-risk users or domains.

You can assign these policies to all users or specific groups via the Microsoft Defender portal.

2. Custom Anti-Spam Policies

If you need more control, create custom anti-spam policies. These allow you to:

Adjust thresholds for spam, high-confidence spam, phishing, and bulk email.
Choose actions like:
- Move to Junk Email folder
- Quarantine
- Add X-headers
- Redirect to another mailbox

Custom policies override the default and can be prioritised as needed.

3. Outbound Spam Protection

Configure outbound spam policies to prevent compromised accounts from sending spam:

Set-HostedOutboundSpamFilterPolicy -Identity "Default" -NotifyOutboundSpam $true -OutboundSpamFilterAction Quarantine

This ensures that outbound spam is quarantined and alerts are generated.

4. Enable Advanced Threat Protection (ATP)

For SMBs using Microsoft 365 Business Premium or Defender for Office 365 Plan 2, enable:

Safe Links: Time-of-click protection for URLs.
Safe Attachments: Sandboxing for email attachments.
Anti-Phishing Policies: Impersonation protection and spoof intelligence.

These features significantly enhance protection against sophisticated threats.

5. Disable Legacy Protocols

Block POP, IMAP, and SMTP AUTH unless explicitly needed. These protocols don’t support modern authentication and are often exploited.

6. Monitor and Adjust

Use tools like Threat Explorer, Quarantine Reports, and User Submissions to monitor effectiveness and adjust policies accordingly.

️ How to Configure These Settings in the Microsoft 365 Admin Console

Step-by-Step via Microsoft Defender Portal:

Go to: https://security.microsoft.com
Navigate to:
Email & collaboration → Policies & rules → Threat policies
Anti-Spam Policies:
- Click Anti-spam policies
- Edit the Default policy or click + Create policy
- Configure actions for spam, high-confidence spam, phishing, and bulk email
Safe Links & Safe Attachments:
- Under Threat policies, configure Safe Links and Safe Attachments
- Apply policies to users, groups, or domains
Anti-Phishing:
- Enable impersonation protection
- Configure spoof intelligence and thresholds
Outbound Spam:
- Configure under Outbound spam filter policies
Monitoring:
- Use Reports and Explorer to review detections and user reports

For PowerShell users, the following script configures best practice spam settings:

Connect-ExchangeOnline
Set-HostedContentFilterPolicy -Identity "Default" ` 
-EnableSafetyTips $true ` 
-EnableEndUserSpamNotifications $true ` 
-EndUserSpamNotificationFrequency 1 ` 
-SpamAction Quarantine ` 
-HighConfidenceSpamAction Quarantine ` 
-PhishSpamAction Quarantine ` 
-HighConfidencePhishAction Quarantine ` 
-BulkSpamAction Quarantine ` 
-BulkThreshold 6 ` 
-QuarantineRetentionPeriod 30 ` 
-InlineSafetyTipsEnabled $true ` 
-EnableRegionBlockList $true ` 
-RegionBlockList @("CN","RU","KP","IR") ` 
-EnableLanguageBlockList $true ` 
-LanguageBlockList @("zh-cn","ru","ko","fa") ` 
-IncreaseScoreWithImageLinks Off ` 
-IncreaseScoreWithNumericIps Off ` 
-IncreaseScoreWithRedirectToOtherPort Off ` 
-IncreaseScoreWithBizOrInfoUrls Off ` 
-MarkAsSpamEmptyMessages On ` 
-MarkAsSpamJavaScriptInHtml On ` 
-MarkAsSpamFramesInHtml On ` 
-MarkAsSpamObjectTagsInHtml On ` 
-MarkAsSpamEmbedTagsInHtml On ` 
-MarkAsSpamFormTagsInHtml On ` 
-MarkAsSpamWebBugsInHtml On ` 
-MarkAsSpamSensitiveWordList On ` 
-MarkAsSpamSpfRecordHardFail On ` 
-MarkAsSpamFromAddressAuthFail On ` 
-MarkAsSpamBulkMail On ` 
-TestModeAction None

This script ensures all spam types are redirected to quarantine

Use AI to provide better spam protection and detection with exchange online

Let’s break down how AI enhances spam and phishing protection within Microsoft Exchange Online Protection (EOP) and Microsoft Defender for Office 365 (MDO), along with configuration examples.

How AI Powers Spam/Phishing Protection in Exchange Online

Instead of just relying on static rules (like blocking specific keywords or known bad IPs), AI (specifically Machine Learning models) introduces several powerful capabilities:

Advanced Pattern Recognition: AI models analyze vast amounts of global email data (billions of messages daily) from Microsoft’s network. They identify subtle and evolving patterns associated with spam, phishing, malware, and impersonation attempts that rule-based systems would miss. This includes:
- Linguistic Analysis: Understanding the nuances of language, tone, urgency cues, grammatical errors common in phishing, and topic shifts often used to bypass simple filters.
- Structural Analysis: Examining message headers, sending infrastructure reputation, URL structures, attachment types, and email formatting anomalies.
- Behavioural Analysis: Learning normal communication patterns for your organization and flagging deviations (e.g., a sudden email from the “CEO” asking for gift cards, which is out of character).
Adaptive Learning: Spammers constantly change tactics. AI models continuously learn and adapt to these new threats in near real-time, significantly reducing the window of vulnerability compared to waiting for manual rule updates. When new spam campaigns emerge, the models retrain based on newly classified samples.
Contextual Understanding: AI helps differentiate between legitimate and malicious use of similar content. For example, an “invoice” email from a known supplier vs. a generic “invoice” from an unknown sender with a suspicious link. AI considers sender reputation, recipient history, link destinations, etc.
Impersonation Detection (MDO): This is heavily AI-driven.
- User Impersonation: Mailbox Intelligence learns the frequent contacts and communication style of protected users (e.g., executives). It flags emails claiming to be from that user but originating externally or exhibiting unusual patterns.
- Domain Impersonation: AI detects attempts to use domains that look very similar to your own (e.g., yourc0mpany.com instead of yourcompany.com) or legitimate external domains (e.g., spoofing a well-known supplier).
Enhanced Heuristics & Reputation: AI refines the calculation of Spam Confidence Levels (SCL) and Bulk Complaint Levels (BCL) by incorporating more complex signals than just IP/domain blocklists. It considers the “neighborhood” of sending IPs, historical sending behavior, and feedback loops (user submissions, junk reports).
Zero-Hour Auto Purge (ZAP): Even if a malicious email initially bypasses filters and lands in an inbox, AI continues analyzing signals. If the message is later identified as spam or phishing (often through updated AI models or user reports), ZAP can automatically pull it from user mailboxes.

Specific Configuration Examples (Using the Microsoft 365 Defender Portal)

Most AI capabilities are inherently part of the features. You don’t toggle “AI On/Off,” but you configure the policies that leverage AI.

Prerequisites:

Access to the Microsoft 365 Defender portal (https://security.microsoft.com).
Appropriate permissions (e.g., Security Administrator, Global Administrator).
Note: Some advanced features (like Impersonation, Safe Links, Safe Attachments) require Microsoft Defender for Office 365 Plan 1 or Plan 2 licenses, beyond the basic EOP included with Exchange Online.

Example 1: Tuning Anti-Spam Inbound Policy (Leverages AI for SCL)

AI determines the SCL score based on numerous factors. You configure the actions based on those AI-determined scores.

Navigate to Email & collaboration > Policies & rules > Threat policies > Anti-spam.
Select the Anti-spam inbound policy (Default) or click Create policy > Inbound for a custom policy.
In the policy settings, locate the Bulk email threshold & spam properties section and click Edit actions.
Spam Confidence Level (SCL) Actions:
- Spam: Action: Move message to Junk Email folder (Recommended Default). SCL levels typically 5, 6.
- High confidence spam: Action: Quarantine message (Recommended). SCL levels typically 7, 8, 9. You could choose Redirect message to email address, Delete message, or Move message to Junk Email folder. Quarantine is generally safest.
- AI Impact: The determination of which message gets an SCL of 5 vs. 7 vs. 9 is heavily AI-driven based on content, sender, structure, etc.
Bulk Complaint Level (BCL) Threshold: Set a threshold (e.g., 6 or 7). Messages exceeding this BCL (often unwanted marketing mail) will take the specified action (e.g., Move message to Junk Email folder). AI helps differentiate bulk from true spam.
Zero-hour auto purge (ZAP): Ensure “Enable for spam messages” and “Enable for phishing messages” are turned On. This allows AI to retroactively remove messages.
Save the changes.

Example 2: Configuring Anti-Phishing Policy (Leverages AI for Impersonation & Spoofing)

Requires MDO licenses for advanced features.

Navigate to Email & collaboration > Policies & rules > Threat policies > Anti-phishing.
Click Create to make a new policy (recommended) or edit the Default policy.
Phishing threshold & protection:
- Enable spoof intelligence: Ensure this is On. AI helps identify and classify spoofing attempts (legitimate vs. malicious). You can review/override its findings later under “Spoof intelligence insight”.
- Impersonation Protection (Key AI Area):
  - Click Edit next to Users to protect. Click Manage sender(s) and add email addresses of key personnel (CEO, CFO, HR Managers, up to 350). AI (Mailbox Intelligence) learns their communication patterns.
  - Click Edit next to Domains to protect. Add your own company domains and consider adding custom domains that are visually similar or frequently targeted. AI flags emails spoofing these domains or using lookalike domains.
  - Enable Mailbox Intelligence: Ensure this is On. This activates the AI learning for the protected users’ contact graphs and communication patterns.
  - Enable intelligence for impersonation protection: Ensure this is On. Uses AI to improve detection based on learned senders/patterns.
- Actions: Configure actions for detected impersonation (User/Domain) and spoofing. Recommended actions often include Quarantine the message or Redirect message to administrator address and displaying safety tips.
Advanced phishing thresholds: Set the level (e.g., 2: Aggressive, 3: More aggressive, 4: Most aggressive). Higher levels use more sensitive AI/ML models but might increase false positives. Start with 1: Standard or 2: Aggressive and monitor.
Assign the policy to specific users, groups, or the entire domain.
Save the policy.

Example 3: Enabling Safe Links & Safe Attachments (Leverages AI for Analysis)

Requires MDO licenses. These features use sandboxing (detonation) and URL reputation checks, heavily augmented by AI analysis.

Safe Attachments:
- Navigate to Email & collaboration > Policies & rules > Threat policies > Safe Attachments.
- Click Create or edit an existing policy.
- Choose an action like Block (blocks email with detected malware) or Dynamic Delivery (delivers email body immediately, attaches placeholder until attachment scan completes – often preferred for user experience).
- Enable Redirect messages with detected attachments and specify an admin mailbox for review if desired.
- Apply the policy to users/groups/domains.
- AI Impact: AI models perform static analysis before detonation and analyze the behavior of the file during detonation in the sandbox to identify novel/zero-day malware.
Safe Links:
- Navigate to Email & collaboration > Policies & rules > Threat policies > Safe Links.
- Click Create or edit an existing policy.
- Ensure On: Safe Links checks a list of known, malicious links when users click links in email is selected under URL & click protection settings.
- Enable Apply Safe Links to email messages.
- Enable Apply real-time URL scanning for suspicious links and links that point to files. (This uses AI and other heuristics).
- Configure Wait for URL scanning to complete before delivering the message (more secure, slight delay) or leave it off (less secure, no delay).
- Choose actions for malicious URLs within Microsoft Teams and Office 365 Apps if applicable.
- Configure Do not rewrite the following URLs for any trusted internal/external sites that break due to rewriting (use sparingly).
- Apply the policy to users/groups/domains.
- AI Impact: AI powers the reputation lookups and real-time scanning analysis of URLs, identifying phishing sites, malware hosts, and command-and-control servers even if they aren’t on a static blocklist yet.

Key Takeaways:

AI is Integrated: You configure features like Anti-Spam, Anti-Phishing, Safe Links/Attachments, and AI works behind the scenes within those features.
MDO is Crucial: The most advanced AI-driven protections (impersonation, advanced phishing detection, Safe Links/Attachments) require Microsoft Defender for Office 365 licenses.
Configuration is Tuning: You adjust thresholds (SCL, BCL), enable specific protections (Impersonation), and define actions (Quarantine, Junk, Delete).
Monitor & Adapt: Regularly review quarantine, user submissions (use the Report Message Add-in!), and threat reports in the Defender portal to fine-tune policies and understand how AI is performing in your environment. Feedback helps the AI models learn.

By leveraging these AI-powered features and configuring them appropriately, you can significantly improve your organization’s defense against increasingly sophisticated spam and phishing attacks in Exchange Online.

New mailbox logging settings

CISA released a Microsoft Expanded Cloud Logs Implementation Playbook that I recommend Microsoft 365 administrators take a look at.

“This playbook provides an overview of the newly introduced logs in Microsoft Purview Audit (Standard), which enable organizations to conduct forensic and compliance investigations by accessing critical events, such as mail items accessed, mail items sent, and user searches in SharePoint Online and Exchange Online. In addition, the playbook also discusses significant events in other M365 services such as Teams. Lastly, administration/enabling actions and ingestion of these logs to Microsoft Sentinel and Splunk Security Information and Event Management (SIEM) systems are covered in detail.”

“Default enablement is defined at a license level. For example, Auditing (Standard or Premium) is enabled by default for E3/E5/G3/G5 licenses. Some licenses, such as M365 Business Basic, M365 Business Standard, M365 Business Premium, and trial license accounts do provide access to Audit but do not currently have auditing enabled by default. These licenses will have Audit enabled by default in the future. If you are leveraging one of these license types, the steps below can be utilized to ensure that all audit features are enabled.”

Thus, if you are using ANY Microsoft 365 license in my books you want to ensure all the logging available to you is enabled for all user, regardless of Microsoft does.

The playbook will take you what needs to be done. Most of it relates to:

Mailbox actions for user mailboxes and shared mailboxes

with the most important being around the MailItemsAccessed setting, but there are others.

The most important thing to remember is that most of these settings cannot be set in the web portal and can only be set using PowerShell commands like:

Set-Mailbox – @{Add=“SearchQueryInitiated”}

Apart from these settings the playbook has lots of additional handy information that will help with the security of your Microsoft 365 environment and this makes it a recommended read for all administrators.

Bulk senders insight in Exchange Online

If you navigate to

https://security.microsoft.com/senderinsights

you should see the above Bulk senders insight console. You can also get to this if you select an Exchange Online anti spam policy like so:

and scrolling down the dialog that appears on the right and selecting Edit spam threshold and properties as shown above.

and then scroll up to the top of the dialog as shown above.

You can read more about this capability here:

https://learn.microsoft.com/en-us/defender-office-365/anti-spam-bulk-senders-insight

You can adjust the sliders on the left and then select the Simulate button to report on the emails that would be caught by this new level before actually applying to the policy. The list below will also show those that have been caught so you know exactly which emails would be caught if this change was made to the BCL level in a spam policy setting.

This now a handy way to fine tune the BCL settings inside Exchange Online antispam policies.

Disable Linkedin integrations in Microsoft 365

The first place to disable Linkedin integration in Microsoft 365 is inside the Azure portal.

Navigate to Microsoft Entra ID, then select Users as shown above.

Select User settings on the left and set the Linkedin account connections to No.

Remember to Save your settings before existing this page.

Now navigate to the Exchange Online administration portal. Expand the Roles option on the left and then select Outlook Web Apps policies.

Typically, there will only be one OWA policy as shown above. If there are more, then you will need to repeat this process with each.

Select the policy name, here OwaMailboxPolicy-Default..

From the window that appears on the right select Manage features as shown above.

Ensure Linkedin contact sync is unselected as shown above.

Save your settings before you exit.