This article is contributed. See the original author and article here.
Microsoft Support is excited to continue the blog series that will demystify how Microsoft 365 email protection works. In this fifth and final part of the series, we will cover the different overrides, why you may need them, and why it isn’t a good idea to keep them permanently.
Email security is a critical aspect of modern business operations, and Microsoft 365 provides a robust set of tools to keep your communications safe. But what should you do when legitimate emails are blocked? This is where submissions and overrides come into play. As we have covered in part 2 of this series, Submissions help you learn more about why email was junked or quarantined and allow you to notify Microsoft if the filters got it wrong. (It happens.) Overrides are special settings that allow certain emails to bypass the usual security filters, ensuring important communications reach their destination.
A closer look at email overrides
Overrides are not one-size-fits-all; they come in different forms to suit various needs. Use Explorer email summary flyout and email entity pages to learn more about why a message was delivered to a certain location, and if overrides played a role in delivery. Note, since messages can have multiple allow or block overrides as identified in the column Override source, the override that ultimately allowed or blocked the message is identified in Primary override source in Explorer.
Learn more: Understanding overrides within the email entity page in Microsoft Defender for Office 365, Understanding detection technology within the email entity page in Microsoft Defender for Office 365
- Tenant Allow Block List (TABL): Ideal for creating temporary and safe exceptions. Based on your submission, Microsoft will analyze the exact part of the email deemed malicious (sender, domain, URL, file hash, spoof, or impersonation). TABL is the preferred choice for maintaining security: “Allows” eventually expire, and until they do, the system learns from your submissions to allow emails with similar elements. Both easy for you to manage, and useful for service filter adjustments. A win-win!
Note: spoof overrides do not expire. Learn more here: Allow or block email using the Tenant Allow/Block List
- Exchange Mail Flow Rules (Exchange Transport Rules or ETRs): ETRs provide the most flexibility but come with increased risk. They should be used sparingly and thoughtfully. Safer ETR overrides use conditions for email authentication checks passing before allowing anything (see an example). The Analysis tab of the email entity page in Explorer will help you verify which ETR acted on a message, and the anti-spam message headers will include SFV:SKN if an ETR override is detected.
Figure 1: “Allowed by organization policy: Exchange transport rule” override source on the Email Entity page in Microsoft Defender XDR
- Outlook Safe Senders (User Overrides): Users can mark their own trusted senders in Outlook, affecting only their individual mailbox. The screenshot below demonstrates the detailed information from the email entity page in Microsoft Defender XDR, and the anti-spam message headers will include SFV:SFE if a user override is detected.
Figure 2: “Allowed by user policy: Sender address list” override source on the Email Entity page in Microsoft Defender XDR
Certain user allows “win” over tenant configurations and provide the end-users the ability to manage their own exceptions, so make sure to review the “User and tenant settings conflict” section to learn what to expect at Order and precedence of email protection.
Tip: List all overrides for a user or all users in your organization using the PowerShell cmdlet. For full syntax and examples, see Get-MailboxJunkEmailConfiguration.
- IP Allow List (Connection Filtering): This allows emails from specified IP addresses to bypass filters as part of connection filtering. One risk here is if an IP you believe is trusted becomes compromised, the entire email filtering stack except Secure by default is bypassed. Another risk is adding IP overrides for shared IP addresses or ranges. If bad actors use the same sender infrastructure for malicious purposes, you will allow bad messages along with good ones. In short: exercise caution, review regularly, keep IP allows to a minimum. The anti-spam message headers will include IPV:CAL if an IP override is detected, and the Explorer email entity page will look like this:
Figure 3: “Allowed by organization policy: Connection policy” override source on the Email Entity page in Microsoft Defender XDR
- Anti-Phishing Policy Overrides: Aimed at combating domain, user and mailbox impersonation phishing threats, these overrides will target false positives with UIMP, DIMP, GIMP verdicts only. They are relatively safer as the rest of the protection scans take place, but it’s still a good idea to make sure from time to time any trusted senders and domains are still necessary, as they never expire.
Tip: You can also use Tenant Allow/Block List for impersonation overrides, just note that the allow entry isn’t created in the Tenant Allow/Block List. Instead, the domain or sender is added to the Trusted senders and domains section in the anti-phishing policy that detected the message and it does not expire.
Example
The company CEO, John Smith (johnsmith@contoso.com) is a prime target for impersonation attacks, so your SecOps team adds his address to trusted users to protect in the anti-phishing policy. However, the CEO sometimes sends email to his team from his personal account (johnsmith@outlook.com). After the service flags this correctly as user impersonation, you add the CEO’s personal address to trusted senders, for his emails to get through to recipient inboxes. (Of course, after you educate the CEO about the risks tied to this practice, you remove this entry.)
Figure 4: Add trusted senders part of the anti-phishing policy in Microsoft Defender XDR
- Anti-Spam Policy Overrides: used to override spam, bulk, spoofing and low-confidence phishing verdicts (SPM, HSPM, PHISH, SPOOF and BULK), anti-spam policy senders and/or domains allows also override the anti-phishing stack, and they do not expire. Overly broad (domain) allows are particularly risky and known to be a leading cause for letting bad email into your inboxes. Best practice, review your policies periodically and trim/clear these lists. The Analysis tab of the email entity page in Explorer will help you verify if a policy that acted on a message, and the anti-spam message headers will include SFV:SKA if a policy override is detected.
Tip: You can also export an extended report (message trace) for the email in question. The AGENTINFO event in the resulting csv file contains the CustomData field with additional details, such as the GUID of the policy that acted on the message. For example:
S:PCFA=SUM|tact=5|di=SQ|tactcat=SPM|hctfp=191b78dc-9221-4a2c-b51c-208a186e931a;
SQ means the message was routed to Spam Quarantine, and hctfp stands for Hosted Content Filter Policy. Find the policy name by running the cmdlet Get-HostedContentFilteringPolicy in Exchange Online PowerShell.
- While most of this article is about allow overrides, you can use Anti-Spam policies to block email, as well. For example, filter messages containing geographies and languages you would not expect to be working with. Learn how to configure spam filter policies.
Secure by Default
Microsoft 365 Secure by Default stance ensures that the system starts with the highest security settings. Notably, verdicts for malware (MALW) and high-confidence phishing (HPHISH) cannot be overridden by ETRs if the MX record points to Office 365. This policy is in place to protect users from the most severe threats automatically.
Why would I ever override Secure by Default?
There are specific instances where an override may be necessary. It is highly recommended to configure the Advanced delivery policy to handle these uses cases securely.
- Phishing Simulations: To test their defenses, organizations might run controlled phishing simulations. To ensure these tests reach inboxes when they’re sent over email, overrides are essential.
- SecOps Mailboxes: Security teams sometimes need to examine malicious emails for analysis and learning. Access to such emails requires an override to allow them through.
What if the MX record for my domain does not point to Exchange Online Protection?
Secure by default applies only when the MX record for your domain points to Microsoft 365 (contoso-com.mail.protection.outlook.com). If the MX record points to another service or device, it’s possible to override high-confidence phishing verdicts using an Exchange mail flow rule to bypass spam filtering (malware verdicts cannot be overridden). But although it’s technically possible, consider the benefits of defense-in-depth of your filtering solution paired with Microsoft Defender for Office 365. Use Enhanced Filtering for Connectors to skip the last known IP address(es) of your service, and to infer the email authentication information from the original sender IP. In addition, if your filtering solution supports ARC, configure to trust the ARC sealer in Microsoft Defender XDR settings. These configurations will allow you to keep the extra layer of Microsoft protection even when using third party protections.
Learn more about Getting started with defense in-depth configuration for email security, Secure by default in Office 365, Manage mail flow using a third-party cloud service with Exchange Online and Configure trusted ARC sealers.
Messages I send land in spam folders for external recipients. Can I override outbound spam filtering?
No. However, you can take steps to authenticate outbound email to improve deliverability.
Use overrides wisely
While overrides are useful tools, they must be implemented wisely. Incorrect usage can inadvertently open your company to threats. It’s essential to take the following precautions:
- Only allow emails from verified and trustworthy sources. And even when you trust the source, consider that it may become compromised, and you would inadvertently allow unwanted phishing or spam.
- Use Advanced Hunting in Microsoft Defender XDR to help you discover top overrides sources and remove the unnecessary ones.
- Regularly review your overrides to ensure they remain relevant and secure.
- Never put domains that you own onto the Allow and blocklists. If you own Contoso, do not add contoso.com to your allow lists.
- Never put common domains, such as microsoft.com and office.com, onto the Allow and blocklists.
We hope that by understanding and applying email overrides correctly, you can ensure your organization’s email is both secure and functional, allowing the right messages to get through while keeping the bad ones out.
Do you have questions or feedback about Microsoft Defender for Office 365? Engage with the community and Microsoft experts in the Defender for Office 365 forum.
Click here to view additional posts in this series.
Important resources:
Allow or block email using the Tenant Allow/Block List
Order and precedence of email protection
Understanding overrides within the email entity page in Microsoft Defender for Office 365
Understanding detection technology within the email entity page in Microsoft Defender for Office 365
About Threat Explorer and Real-time detections in Microsoft Defender for Office 365
Getting started with defense in-depth configuration for email security
Review and remove unnecessary allow list entries with Advanced Hunting in Microsoft Defender for Office 365
Create safe sender lists
Create blocked sender lists
Configure the advanced delivery policy for third-party phishing simulations and email delivery to SecOps mailboxes
Secure by default in Office 365
Manage mail flow using a third-party cloud service with Exchange Online
Configure trusted ARC sealers
Configure spam filter policies
Configure anti-phishing policies in Microsoft Defender for Office 365
Get-MailboxJunkEmailConfiguration
Authenticate Outbound Email to Improve Deliverability
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments