Important notice for Office 365 email customers who have configured connectors


Note: This post, originally published in March, got accidentally re-published on 8/23/16 when updating step 5 below. We are leaving it published as a reminder to our customers as the time for this change is now closer.

If you’re an Exchange Online or Exchange Online Protection (EOP) subscriber and you have configured connectors, this post contains important information that might impact your organization. To make sure that your mail flow isn’t interrupted, we strongly recommend that you read this post and take any necessary action at your earliest convenience.

The change will impact you if one of the following scenarios apply to your organization:

  • Your organization needs to send NDR (non-delivery report) messages to a recipient on the Internet and needs to relay them through Office 365.
  • Your organization needs to send messages from your own email server (on-premises environment) from domains that your organization has not entered in Office 365 (see Add Domains in Office 365). For example, your organization Contoso needs to send email as the domain fabrikam.com, which doesn’t belong to your organization.
  • There is a forwarding rule configured on your on-premises server, and messages need to relay through Office 365. For example, contoso.com is your organization’s domain, a user in your organization’s on-premises server, kate@contoso.com, has enabled forwarding. All her messages go to kate@tailspintoys.com. If john@fabrikam.com sends a message to kate@contoso.com, the message gets automatically forwarded to kate@tailspintoys.com. From Office 365’s point of view, the message is sent from john@fabrikam.com to kate@tailspintoys.com. Because Kate’s mail is being forwarded, neither the sender domain nor the recipient domain belongs to your organization.
Beginning February 1, 2017, Office 365 will no longer by default support relaying messages for the scenarios described above. And your MTA will get a rejection with the following detailed messages: “451 4.4.4 Relay Access Denied, unrecognized sender domain. ATTR36”. 
If your organization needs those scenarios to continue to work, you need to make sure that the following are all true:
  • You have created a connector in Office 365 that instructs the service to use certificate to authenticate emails coming from your organization’s own email server (on-premises environment).
  • Your own email server (on-premises environment) is configured to use the certificate to send email to Office 365.
  • This certificate is CA signed and its certificate name (CN) or subject alternative name (SAN) contains a domain that you have entered in Office 365.

To do so, use the following instructions.

Create or Edit a certificate-based connector in Office 365

For Office 365 to relay messages to internet that match with the scenarios listed above, you need to follow the below steps.

1. Sign in to Office 365 admin center, and go to Admin > Exchange.

image

2. Go to mail flow > connectors, and do one of the following:

If there are no connectors, choose ’+’ (Add) to create a connector.

image

If a connector already exists, select the connector, and choose Edit to modify it.

image

3. On the Select your mail flow scenario page, choose From: Your organization’s email server and To: Office 365. This creates a connector that indicates that your on-premises server is the sending source for your messages.

image

4. Enter connector name and other information, and then choose Next.

5. On the New connector or Edit connector page, choose the first option to use a TLS certificate to identify the sender source of your organization’s messages. The domain name in the option should match with the CN name or SAN in the certificate that you’re using and this domain must be a domain that belongs to your organization and you need to have added the domain to Office 365. For example, contoso.com belongs to your organization, and it’s part of CN name or SAN name in the certificate that your organization uses to communicate with Office 365. If the domain in cert contains multiple domains (such as mail1.contoso.com, mail2.contoso.com), It is recommended that domain in the connector UI to be *.contoso.com.

image

Configure your on-premises environment

Use the following steps to prepare your on-premises servers to relay messages through Office 365:

  1. If your organization uses Exchange server for its on-premises server, you need to configure your server to send messages over TLS. To do this, follow Set up your email server to relay mail to the Internet via Office 365, which is part 2.2 of “Set up connectors to route mail between Office 365 and your own email servers.” If you have already used Hybrid Configuration Wizard, then continue to use it, but ensure to use a certificate that matches the criteria outlined in step 5 of the previous section.
  2. Install a certificate in your on-premises environment. For details, follow “Step 6: Configure an SSL certificate” of Configure mail flow and client access.

For more details 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.

Carolyn Liu

Comments (5)

  1. This will enhance security. No question about it. But as forwarding is still widely used, this might force customers to implement centralized transport using an on-premises SMTP gateway.

  2. Joe says:

    What happens to the option to verify only by IP address?

  3. Aman Saxena says:

    Nice approach for enhancing the security…

  4. N says:

    In your example above, is kate@tailspintoys.com an Office365 recipient (since the first name’s the same)

  5. JG says:

    Will we loose the option for SMTP relay to be allowed by IP? I have several customers with devices and services that need to relay messages that do not support TLS.