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:

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 you will need to make the below, additional change to your 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

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)

  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 product Advisory - Required Configuration Change for DLP Cloud Service for Email Reflecting Mode.
  2. 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
    1. 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
    2. 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
  3. Next, go to the settings in Mailflow > Connectors, and open the one for your DLP Inbound Connector.
    1. In the flyout configuration window, click on "Edit sent email identity".
    2. 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."
    3. 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.
    4. Per the example above, this field should now have an entry like this:

      12345678-abcd.ds.dlp.protect.broadcom.com
    5. 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, review the following topics:

Powered by Wolken Software