Notice of O365 change for DLP Cloud Service for Email in Reflecting mode
search cancel

Notice of O365 change for DLP Cloud Service for Email in Reflecting mode

book

Article ID: 275421

calendar_today

Updated On:

Products

Data Loss Prevention

Issue/Introduction

Notice of Change for DLP Cloud Service for Email  Reflect Mode Customers

Microsoft is changing the behavior of its inbound connector. Details about the change are at Updated Requirements for SMTP Relay through Exchange Online - Microsoft Community Hub.

This change only impacts Broadcom customers using Configuring Microsoft 365 to use Microsoft 365 for Email Delivery (Reflecting mode) (broadcom.com). Due to these changes, emails sent with a null sender will be rejected when delivered back to Office365. To avoid any issues, Broadcom is working on a set of instructions you can use to address this coming change. DLP Cloud Service for Email Reflecting mode customers will be required to make some configuration changes based on these instructions.

 

Update (January 2024): DLP Support and Engineering have confirmed a new requirement from Microsoft in relation to this advisory. Further guidance on necessary changes to the Inbound Connector are given in this article. Updates will also be made to online help for Reflecting mode (link above) and to the Product Advisory for this topic.

 

Environment

DLP 15.8 - Current

DLP Cloud Service for Email in Reflecting mode

Cause

As per their published notice, this is due to a change in Microsoft that will no longer allow null senders:

Updated Requirements for SMTP Relay through Exchange Online - Microsoft Community Hub

 

Current Requirements

Currently, to relay email through Exchange Online, two conditions must be true:

  1. Any of the following is an accepted domain of your organization:
    1. SMTP certificate domain on the SMTP connection; or
    2. SMTP envelope sender domain in the MAIL FROM command (P1 sender domain); or
    3. SMTP header sender domain, as shown in email clients (P2 sender domain).
  2. The sending host’s IP address or the certificate domain on the SMTP connection matches your tenant’s Inbound Connector of OnPremises type.

New Requirements

On November 1, 2023, we removed the matching condition for the SMTP P2 sender domain (1c above). With this condition removed; relaying email through Exchange Online will require the following:

  1. Any of the following is an accepted domain of your organization:
    1. SMTP certificate domain on the SMTP connection; or
    2. SMTP envelope sender domain in the MAIL FROM command (P1 sender domain).
  2. The sending host’s IP address or certificate domain on the SMTP connection matches your organization’s Inbound Connector of OnPremises type.

After November 1, 2023, if either of the above conditions are not met, the relay attempt from your on-premises environment to Exchange Online will be rejected.

This change may affect your organization’s email routing or delivery. Possible scenarios that are affected by this change include, but may not be limited to:

  1. Your organization hosts email on-premises, and you need to relay non-delivery reports (NDRs) generated by your on-premises system through Exchange Online. In this scenario, the NDRs often have null as the SMTP envelope sender (P1 sender), but the SMTP header sender domain (P2 sender domain) is your organization’s accepted domain in Microsoft 365.
  2. Your organization uses an application hosted on-premises to send email and the SMTP envelope sender domain (P1 sender domain) is not an accepted domain in Exchange Online.
  3. You use a third-party cloud service to relay messages by creating an Inbound Connector of OnPremises type. For example, when you use a cloud service platform to relay emails through Exchange Online, the SMTP envelope sender domain (P1 sender domain) will be the 3rd party service’s domain (perhaps for bounce tracking), but the SMTP header domain (P2 sender domain) is your organization’s accepted domain in Microsoft 365.

Resolution

To ensure traffic for your O365 Reflecting mode Cloud Detector is not impacted, take the following steps to add a Broadcom-owned subdomain to Office 365.

  1. From the Microsoft 365 admin center, go to Settings > Domains > Add domain.

  2. Type the domain name provided by your Broadcom Support team in the Domain name field. The domain name should contain the first 13 characters of the detector ID plus the domain ds.dlp.protect.broadcom.com. 

    Example: Your detectorID looks like something like: 12345678-abcd-efgh-ijkl-12345678abcd

    Your domain will be the first 13 characters, so per the above example, 12345678-abcd. Now you add the Broadcom domain (.ds.dlp.protect.broadcom.com), so it looks like:

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

  3. Click Use this domain.

  4. On the Verify you own your domain page, click Add a TXT record to the domain’s DNS record.

  5. On the Add a record to verify ownership page, copy the TXT name, the TXT value, and the TTL. Provide these values to your Broadcom Support team. The Broadcom team will make the required changes in the backend.  You can exit the setup and complete it later. The progress you have made so far will not be lost. 

  6. The Broadcom team will let you know when the changes are complete. This may take up to a day. 

  7. After you receive notification from your Broadcom Support team, go to the Add a record to verify ownership page and select the Verify.

  8. Please keep Exchange at Exchange Online Protection unchecked.

  9. Go to How do you want to connect your domain? 

  10. Click More options and Skip and do this later.

  11. Click Done.

  12. Go to the Domains page. The domain should now show a No services selected status. This status means that the domain was correctly added and the setup process is complete.

 

Update (January 2024): After making the changes above, follow these next steps to update the existing Inbound Connector in O365, for your DLP Cloud Service:

  1. Find your DLP Inbound Connector in O365.

  2. In the flyout configuration window, click on "Edit sent email identity".

  3. 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 (as per "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, which was 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:

      1234567a-b123.ds.dlp.protect.broadcom.com

  4. 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 Microsoft reference:

Scenario Integrate Microsoft 365 or Office 365 with an email add-on service | Microsoft Learn

Additional Information

This updated requirement came directly from Microsoft, and DLP documentation is being updated to reflect this new instruction.

If you have any questions or require assistance, contact Technical Support: Contact Support - Support Portal - Broadcom support portal.

Powered by Wolken Software