Microsoft Defender for Office 365
Email and collaborationAdvanced Delivery Policy Configure
In brief
The documentation now states that Advanced Delivery applies only when simulation messages traverse the transport pipeline. Direct Injection messages bypass the pipeline and are not covered by the policy.
What Defender admins need to know
Administrators should consider message routing when evaluating Advanced Delivery coverage for phishing simulations.
Summaries are generated from the documentation change itself.
Documentation change
View on Microsoft LearnThe comparison below shows only the changed extract. Use the full-page view for complete context.
Microsoft 365 can't identify the true IP address of the message source. Don't try to work around this limitation by adding the IP addresses of the on-premises or non-Microsoft sending infrastructure to the non-Microsoft phishing simulation. Doing so effectively bypasses spam filtering for any internet sender who impersonates the domain specified in the non-Microsoft phishing simulation.
Advanced Delivery policy for non-Microsoft phishing simulations requires the message to traverse the transport pipeline. Direct Injection emails bypass transport, so Advanced Delivery policy does not apply to them.
Currently, the advanced delivery policy for non-Microsoft phishing simulations doesn't support simulations within the same organization (
DIR:INT), especially when email is routed through an Exchange Server gateway before Microsoft 365 in Hybrid mail flow. To work around this issue, you have the following options:
- Create a dedicated Receive connector that doesn't authenticate the phishing simulation messages as internal.
- Configure the phishing simulation to bypass the Exchange Server infrastructure and route mail directly to your Microsoft 365 MX record (for example,
contoso-com.mail.protection.outlook.com).
In addition to non-Microsoft phishing simulations and SecOps mailboxes that the advanced delivery policy can help you with, there are other scenarios where you might need to bypass filtering for messages:
- Non-Microsoft filters: If your domain's MX record doesn't point to Office 365 (messages are routed somewhere else first), secure by default isn't available. If you'd like to add protection, you need to enable Enhanced Filtering for Connectors (also known as skip listing). For more information, see Manage mail flow using a non-Microsoft cloud service with Exchange Online. If you don't want Enhanced Filtering for Connectors, use mail flow rules
(also known as transport(transport rules) to bypass Microsoft filtering for messages that the non-Microsoft filtering service already evaluated. For more information, see Use mail flow rules to set the SCL in messages. - False positives under review: You might want to temporarily allow good messages incorrectly identified as bad (false positives) that you reported via admin submissions to Microsoft, and those messages are sill being analyzed. As with all overrides, we highly recommended that these allowances are temporary.
PowerShell procedures for SecOps mailboxes in the advanced delivery policy
@@ -142,6 +142,8 @@ If your MX record doesn't point to Microsoft 365, the IP address in the `Authent > > Microsoft 365 can't identify the true IP address of the message source. Don't try to work around this limitation by adding the IP addresses of the on-premises or non-Microsoft sending infrastructure to the non-Microsoft phishing simulation. Doing so effectively bypasses spam filtering for any internet sender who impersonates the domain specified in the non-Microsoft phishing simulation. >+> - Advanced Delivery policy for non-Microsoft phishing simulations requires the message to traverse the transport pipeline. Direct Injection emails bypass transport, so Advanced Delivery policy does not apply to them.+> > - Currently, the advanced delivery policy for non-Microsoft phishing simulations doesn't support simulations within the same organization (`DIR:INT`), especially when email is routed through an Exchange Server gateway before Microsoft 365 in Hybrid mail flow. To work around this issue, you have the following options: > - Create a dedicated [Receive connector](/exchange/mail-flow/connectors/receive-connectors#receive-connector-authentication-mechanisms) that doesn't authenticate the phishing simulation messages as internal. > - Configure the phishing simulation to bypass the Exchange Server infrastructure and route mail directly to your Microsoft 365 MX record (for example, `contoso-com.mail.protection.outlook.com`).@@ -236,7 +238,7 @@ Back on the **Phishing simulation** tab, the non-Microsoft phishing simulation e In addition to non-Microsoft phishing simulations and SecOps mailboxes that the advanced delivery policy can help you with, there are other scenarios where you might need to bypass filtering for messages: -- **Non-Microsoft filters**: If your domain's MX record _doesn't_ point to Office 365 (messages are routed somewhere else first), [secure by default](secure-by-default.md) _isn't available_. If you'd like to add protection, you need to enable Enhanced Filtering for Connectors (also known as _skip listing_). For more information, see [Manage mail flow using a non-Microsoft cloud service with Exchange Online](/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud). If you don't want Enhanced Filtering for Connectors, use mail flow rules (also known as transport rules) to bypass Microsoft filtering for messages that the non-Microsoft filtering service already evaluated. For more information, see [Use mail flow rules to set the SCL in messages](/exchange/security-and-compliance/mail-flow-rules/use-rules-to-set-scl).+- **Non-Microsoft filters**: If your domain's MX record _doesn't_ point to Office 365 (messages are routed somewhere else first), [secure by default](secure-by-default.md) _isn't available_. If you'd like to add protection, you need to enable Enhanced Filtering for Connectors (also known as _skip listing_). For more information, see [Manage mail flow using a non-Microsoft cloud service with Exchange Online](/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud). If you don't want Enhanced Filtering for Connectors, use mail flow rules (transport rules) to bypass Microsoft filtering for messages that the non-Microsoft filtering service already evaluated. For more information, see [Use mail flow rules to set the SCL in messages](/exchange/security-and-compliance/mail-flow-rules/use-rules-to-set-scl). - **False positives under review**: You might want to _temporarily_ allow good messages incorrectly identified as bad (false positives) that you reported via [admin submissions](submissions-admin.md) to Microsoft, and those messages are sill being analyzed. As with all overrides, we _**highly recommended**_ that these allowances are temporary. ## PowerShell procedures for SecOps mailboxes in the advanced delivery policy