Important notice for Office 365 email customers who have configured connectors

INTRODUCTION
Starting on February 1, 2017, by default, Microsoft Office 365 will no longer support relaying email messages in the following scenarios:

  • Your organization has to send non-delivery reports (NDRs) from the on-premises environment to a recipient on the Internet, and it has to relay the messages through Office 365. For example, somebody sends an email message to john@contoso.com, a user who used to exist in your organization's on-premises environment. This causes an NDR to be sent to the original sender.
  • Your organization has to send messages from the email server in your on-premises environment from domains that your organization hasn't added to Office 365. For example, your organization (Contoso.com) sends email as the fabrikam.com domain, which doesn’t belong to your organization.
  • A forwarding rule is configured on your on-premises server and messages are relayed through Office 365.

    For example, Contoso.com is your organization’s domain. A user on your organization’s on-premises server, kate@contoso.com, enables forwarding for all her messages to kate@tailspintoys.com. When john@fabrikam.com sends a message to kate@contoso.com, the message is automatically forwarded to kate@tailspintoys.com.

    From the point of view of Office 365, the message is sent fromjohn@fabrikam.comtokate@tailspintoys.com. Because Kate’s mail is forwarded, neither the sender domain nor the recipient domain belongs to your organization.
Additionally, your message transfer agent (MTA) will receive a rejection with the following message:
451 4.4.4 Relay Access Denied, unrecognized sender domain. ATTR36

If any of these scenarios apply to you, follow the steps in the "Resolution" section before February 1, 2017 to prevent mail flow from being interrupted. 
RESOLUTION
If your organization needs any of the scenarios that are described earlier to continue to work after February 1, 2017, all the following conditions must be true:

  • You create a connector in Office 365 that instructs the service to use a certificate to authenticate messages that come from your organization’s on-premises email server.
  • Your on-premises email server is configured to use this certificate to send mail to Office 365.
  • The certificate is signed by a certification authority (CA), and its Subject name or Subject Alternative Name (SAN) contains a domain that you added to Office 365. This domain name is also specified in the connector that's used to identify and accept messages from your on-premises environment to Office 365. For more information, see Step 1, sub-step 5.
To satisfy these conditions, use the following steps.

Step 1: Create or edit a certificate-based connector in Office 365

To set up a connector for Office 365 to relay messages to the Internet in the scenarios that are listed in the "Introduction" section, follow these steps:

  1. Sign in to the Office 365 portal (https://portal.office.com), click Admin, and then open the Exchange admin center. For more information, see Exchange admin center in Exchange Online.
  2. Click mail flow, click connectors, and then do one of the following:

    • If there are no connectors, click (Add) to create a connector.
    • If a connector already exists, select it, and then click (Edit).
  3. On the Select your mail flow scenario page, select Your organization’s email server in the From box, and then select Office 365 in the To box.

    Note This creates a connector that indicates that your on-premises server is the sending source for your messages.

    Screen shot of the Select your mail flow scenario page, showing the From and To options
  4. Enter the connector name and other information, and then click Next.
  5. On the New connector or Edit connector page, select the first option to use a Transport Layer Security (TLS) certificate to identify the sender source of your organization’s messages. The domain name in the option should match the CN name or SAN in the certificate that you're using. This domain must be a domain that belongs to your organization and you need to have added it to Office 365. For more information, see Add Domains in Office 365.

    For example, Contoso.com belongs to your organization, and it’s part of the CN name or SAN name in the certificate that your organization uses to communicate together with Office 365. If the domain in the certificate contains multiple domains (such as mail1.contoso.com, mail2.contoso.com), it's recommended that the domain in the connector user interface be *.contoso.com.

    Screen shot of the option to use a TLS certificate to identify the sender source of your organization's messages

Step 2: Configure your on-premises environment

To prepare the on-premises servers to relay messages through Office 365, follow these steps:

  1. If your organization uses Exchange Server for its on-premises server, configure the server to send messages over TLS. To do this, see Set up your email server to relay mail to the Internet via Office 365. (This is Part 2.2 of Set up connectors to route mail between Office 365 and your own email servers.)

    Note If you've already used Hybrid Configuration Wizard, continue to use it. However, make sure that you use a certificate that matches the criteria that's outlined in Step 1, sub-step 5.
  2. Install a certificate in your on-premises environment. To do this, see “Step 6: Configure an SSL certificate” in Configure mail flow and client access.
MORE INFORMATION
For more information about how to relay messages through Office 365, see the Setting up mail flow where some mailboxes are in Office 365 and some mailboxes are on your organization’s mail servers section of Mail flow best practices for Exchange Online and Office 365.

Still need help? Go to the Office 365 Community website or the Exchange TechNet Forums.
Properties

Article ID: 3169958 - Last Review: 09/19/2016 18:39:00 - Revision: 12.0

Microsoft Exchange Online

  • o365 hybrid kbgraphxlink KB3169958
Feedback