Update advanced-delivery-policy-configure.md

nithinnara · web-flow · commit 1a56e3e362dd · 2024-07-15T13:55:18.000+05:30
Clarifying this part as customers assume complex routing as MX-&gt;3rd party-&gt; EOP and assume advance delivery is not supported. Where as what we really mean here is the case where MX-&gt;EOP-&gt;3rd party/ onpremise -&gt; EOP.
diff --git a/defender-office-365/advanced-delivery-policy-configure.md b/defender-office-365/advanced-delivery-policy-configure.md
@@ -128,7 +128,7 @@ There must be a match on at least one **Domain** and one **Sending IP**, but no
 If your MX record doesn't point to Microsoft 365, the IP address in the `Authentication-results` header must match the IP address in the advanced delivery policy. If the IP addresses don't match, you might need to configure [Enhanced Filtering for Connectors](/Exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors) so the correct IP address is detected.
 
 > [!NOTE]
-> Enhanced Filtering for Connectors doesn't work for third-party phishing simulations in complex email routing scenarios (for example, email from the internet is routed to Microsoft 365, then to an on-premises environment or third-party security service, and then back to Microsoft 365). EOP 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 third-party sending infrastructure to the third-party phishing simulation. Doing so effectively bypasses spam filtering for any internet sender who impersonates the domain that's specified in the third-party phishing simulation.
+> Enhanced Filtering for Connectors doesn't work for third-party phishing simulations in email routing scenarios which involve emails coming to Exchange online twice (for example, email from the internet is routed to Microsoft 365, then to an on-premises environment or third-party security service, and then back to Microsoft 365). EOP 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 third-party sending infrastructure to the third-party phishing simulation. Doing so effectively bypasses spam filtering for any internet sender who impersonates the domain that's specified in the third-party phishing simulation. Note that email routing scenario where MX points to 3rd party and then routed to exchange online is still supported if enhanced filtering for connectors is setup.
 >
 > Currently, the advanced delivery policy for third-party 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:
 >

Original file line number	Diff line number	Diff line change
`@@ -128,7 +128,7 @@ There must be a match on at least one Domain and one Sending IP, but no`
`128`	`128`	If your MX record doesn't point to Microsoft 365, the IP address in the `Authentication-results` header must match the IP address in the advanced delivery policy. If the IP addresses don't match, you might need to configure [Enhanced Filtering for Connectors](/Exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors) so the correct IP address is detected.
`129`	`129`
`130`	`130`	`> [!NOTE]`
`131`		-> Enhanced Filtering for Connectors doesn't work for third-party phishing simulations in complex email routing scenarios (for example, email from the internet is routed to Microsoft 365, then to an on-premises environment or third-party security service, and then back to Microsoft 365). EOP 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 third-party sending infrastructure to the third-party phishing simulation. Doing so effectively bypasses spam filtering for any internet sender who impersonates the domain that's specified in the third-party phishing simulation.
	`131`	+> Enhanced Filtering for Connectors doesn't work for third-party phishing simulations in email routing scenarios which involve emails coming to Exchange online twice (for example, email from the internet is routed to Microsoft 365, then to an on-premises environment or third-party security service, and then back to Microsoft 365). EOP 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 third-party sending infrastructure to the third-party phishing simulation. Doing so effectively bypasses spam filtering for any internet sender who impersonates the domain that's specified in the third-party phishing simulation. Note that email routing scenario where MX points to 3rd party and then routed to exchange online is still supported if enhanced filtering for connectors is setup.
`132`	`132`	`>`
`133`	`133`	> Currently, the advanced delivery policy for third-party 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:
`134`	`134`	`>`