Errors for emails with null senders in the DLP Cloud Service for Email
search cancel

Errors for emails with null senders in the DLP Cloud Service for Email

book

Article ID: 278810

calendar_today

Updated On: 03-21-2024

Products

Data Loss Prevention Core Package

Issue/Introduction

Most of your emails are being delivered successfully, but some messages are queueing in O365, and they appear to be rejected by DLP Cloud Service. The errors may vary, but will likely include the following errors:

  • 421 4.3.0 Fatal: Processing error. Closing connection.
  • 451 4.4.4 Mail received as unauthenticated, incoming to a recipient domain configured in a hosted tenant which has no mail-enabled subscriptions. ATTR5
  • 451 4.4.62 Mail sent to the wrong Office 365 region. ATTR35. For more information please go to https://go.microsoft.com/fwlink/?linkid=865268 
  • 550 5.7.64 TenantAttribution; Relay Access Denied

 

Again, the above errors are only happening for a small subset of emails being sent - the majority of messages are being delivered without any errors. If queued emails in O365 are for messages with "null senders", such as OOOs, auto-forwarded messages or NDRs, then DLP Customers will need to make the below, additional change to their O365 configuration.

Environment

DLP Cloud Service for Email - customers in "O365 Reflecting mode" only

Cause

The "Inbound Connector" for DLP in your O365 Tenant needs to be set so that the "subject name on the certificate" for the DLP Detector matches the "accepted domain" for our service.

 

Resolution

Broadcom has issued updates for this issue on several channels back in October 2023 for customers to take in advance of this Microsoft update.

Recently, however, DLP Engineering has also confirmed that a new Microsoft requirement - the DLP Inbound Connector as configured in O365 must be configured with a subject name that matches an accepted domain in O365.

Therefore, you need to modify the entry for "By verifying that the subject name on the certificate that the sending server uses to authenticate with Microsoft 365 matches this domain name."

 

Login to O365 and edit your existing Inbound Connector for DLP. Complete instructions on doing both of these steps are here:

Configuring Microsoft 365 to use Microsoft 365 for Email Delivery (Reflecting mode) (broadcom.com)

 

1) Verify that you have already added the DLP Detector domain as an "accepted domain" in your O365 Tenant. This change was part of our original Advisory last October.

Note Microsoft's limit for "accepted domains" is 48 characters, so you need to modify this to a shorter version of the FQDN of your Cloud Detector. Starting from the FDQN matching the "Server > Detector Detail" page in the Enforce Server administration console:

1234567a-abcd-efgh-ijkl-12345678abcd.ds.dlp.protect.broadcom.com

Take the first 13 characters of the detector ID plus the domain ds.dlp.protect.broadcom.com. 

Example: Your detectorID has this format:

12345678-abcd-efgh-ijkl-12345678abcd

Per the above example, take the first 13 characters of the DetectorID (12345678-abcd) and add the Broadcom domain (.ds.dlp.protect.broadcom.com). The resulting example:

12345678-abcd.ds.dlp.protect.broadcom.com

 

2) Next, go to the settings in Mailflow > Connectors, and open the one for your DLP Inbound Connector.

  • In the flyout configuration window, click on "Edit sent email identity".
  • In the configuration, you need to modify the entry for "By verifying that the subject name on the certificate that the sending server uses to authenticate with Microsoft 365 matches this domain name."
  • Previously, our instructions were to enter the FULL DETECTOR FQDN of your Cloud Detector (matching the one shown in your "Server > Detector Detail" page in the Enforce Server administration console). This needs to be changed to match the above new "short" domain for the Detector, added in the steps above as an "accepted domain" in O365 for your account.
  • Per the example above, this field should now have an entry like this:
12345678-abcd.ds.dlp.protect.broadcom.com
  • Click Save and verify the change has been applied. 

 

The above change should not have any negative impacts on current mailflow. It will, however, allow any queued emails with "null sender" values to be delivered successfully.

 

Additional Information

For more complete information on these changes, with details on the exact steps to take, please review the following topics:

Microsoft requirements for 3rd party vendors integrating with O365 / M365 needed to follow directions given in this update:

 

 

 
Powered by Wolken Software