Auto-Forwarded emails from O365 are rejected by Symantec Email Security.Cloud and Data Loss Prevention
Article ID: 277297
Updated On:
Products
Issue/Introduction
Email Security.Cloud (ESS)
Auto-Forwarded emails from Office 365 are rejected by Symantec Email Security.Cloud with the error " you are trying to use me as a relay ":
Reason: [{LED=453-you are trying to use me [server-X.tower-X.messagelabs.com] as a relay, but I have not been configured to let you [X.X.X.X, mailX.outbound.protection.outlook.com] do this. Please visit https://knowledge.broadcom.com/external/article?legacyId=TECH246726 for more details.
Data Loss Prevention (DLP)
If these auto-forwarded emails are routed to DLP first, then you may encounter this error " Domain not authorized ":
Reason: [{LED=550 5.7.1 Domain not authorized};{MSG=};{FQDN=X.dlp.protect.broadcom.com};{IP=X.X.X.X};{LRT=12/4/2023 8:38:48 PM}]. OutboundProxyTargetIP: X.X.X.X. OutboundProxyTargetHostName: X.dlp.protect.broadcom.com
Cause
If auto-forwarding is configured in O365 and Microsoft distrusts the inbound email, then Microsoft sends the forwarded email from its Relay Pool (which is currently configured as 40.95.0.0/16). The said IP range isn't included in the Microsoft's SPF records. With this scenario, Email Security.cloud does not recognize the sending IP address as a trusted source as configured in the customer's domain. Microsoft's distrust of the inbound email from the SPF check (performed by Microsoft) failing; it is failing because the IP address Microsoft uses for the SPF check belongs to Email Security.cloud and not to the original sender.
According to Microsoft, the P1 From or also known as Envelope sending address is not getting rewritten by SRS in O365 once auto-forwarded emails get routed to the Relay pool IP range. When these auto-forwarded emails get delivered to DLP with the original external sender address, DLP will reject them with the error " Domain not Authorized". Same thing happens if these emails get routed to ESS with the original external address, ESS will reject them with the error " you are trying to use me as a relay ".
On the other hand, if these emails get routed through O365 regular IP ranges, then that should trigger SRS to re-write the P1 address to one of your provisioned domains. This will allow DLP or ESS to accept these auto-forwarded emails.
Resolution
To resolve this issue:
Configure Enhanced Filtering for Connectors "Enhanced Filtering for Connectors in Exchange Online" in Microsoft 365 Defender (https://security.microsoft.com/skiplisting). Simply select "Automatically detect and skip the last IP address" and click "Save". This instructs Microsoft Exchange Online to use the original sending IP address for the SPF check instead of the Symantec Email Security.cloud IP addresses. If SPF passes, then the email is trusted by Microsoft, and is auto-forwarded via an IP address that is published in Microsoft's IP ranges. Also, SRS will re-write the envelope sender address to one of your provisioned domains, making it acceptable to Email Security.Cloud and Data Loss Prevention.
Note: If the external sender domain lacks an SPF record or fails the SPF check, then auto-forwarded emails will be sent from the Relay pool with the original external sender domain. In this scenario you may need to forward these emails directly to the internet as forwarding them to DLP/ESS will be dropped due to the sender domain not being provisioned.
Additional Information
Microsoft articles referenced in this article:
1- Sender Rewriting Scheme (SRS) in Microsoft 365
2- Relay pool
Feedback
