Important notice for Office 365 email customers who have configured connectors


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 of all her messages 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. 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 a certificate to authenticate emails coming from your organization’s on-premises email server.
  • Your on-premises email server is configured to use the certificate to send email to Office 365.
  • The certificate is CA-signed and its Subject name or Subject Alternative Name (SAN) contains a domain that you have entered in Office 365, and this domain name is also specified in your connector that used  to identify/accept emails from your on-premises environment to Office 365. See more details below.

Use the following instructions to do so.

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. The domain you use needs to 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.

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 (11)
  1. Trying to understand what scenarios will stop working here.

    Does this mean that inbound connectors that currently use an IP address instead of a certificate will no longer work?

  2. Jos Lieben says:

    No, it means that inboud connectors that currently receive mail for domains that you don't own yourself, in your Office 365 tenant, will stop receiving (and forwarding) mail to those external domains.

  3. Carolyn Liu says:

    No, Inbound connectors that currently use IP will continue to work. Only if any of the 3 scenarios listed in the beginning of above that apply to your organization, then you need to create cert based connector to make them work.

  4. Azure-Amjad says:

    From my understanding, this is applying to Hybrid Implementations, is my assumption correct?

  5. Carolyn Liu says:

    @Azure-Amajad,
    No, this is not just applying to Hybrid. It applies to all customers who need to relay emails via Office 365 from their on-premises environment to internet/other customers

  6. @Carolyn Liu

    We have an organization that’s a subdomain of our primary domain, for example we are contoso.com, they are subdomain.contoso.com. We have configured their domain in O365 and have them setup as an accepted domain in Exchange of type "internal relay".

    We receive messages on their behalf, perform message hygiene and then pass the email to their server server1.subdomain.contoso.com. The emails are typically to lists, so server1 expands the email and sends it to each expanded recipient. This would be very similar
    to your forwarding scenario above.

    Server1 is also using O365 as a smarthost with an IP based connector. Would we need to use certificate authentication?

    Thanks!

  7. Carolyn Liu says:

    @Douglas Plumley
    Not sure I fully understand the scenario. 1. Are contoso.com and subdomain.contoso.com two different tenants? If so, a. How does contoso.com receive emails on behalf of subdomain.contoso.com? b. When server1. subdomain.contoso.com expand the email, what is
    the sender? contoso.com? If so, then yes, they do need to create a cert based connector using subdomain.contoso.com.

  8. @Carolyn Liu

    In this example contoso.com is a domain in an O365 tenant, subdomain.contoso.com is also a domain in the same O365 tenant but the tenant is configured as an internal relay for subdomain.contoso.com. Any messages to @subdomain.contoso.com recipients that cannot
    be delivered within O365 will be relayed to server1.subdomain.contoso.com which is authoritative for subdomain.contoso.com.

    The sender can be anyone including @contoso.com, O365 would just be used as the ingress/egress points for subdomain.contoso.com so we can provide inbound message hygiene and authenticated email relaying.

    The way I read the document we would need a certificate on server1.subdomain.contoso.com.

  9. Carolyn Liu (MSFT) says:

    @Douglas Plumley
    If I understand correctly, you are asking whether a mail sent from your organization in Office 365 to your on-premises requires a certificate. The scenarios in the blog only apply to messages sent FROM on-premises environment and relayed THROUGH Office 365
    to recipients that are not belong to your organization. It does not apply to mails sent from your organization in Office 365 (subdomain.contoso.com) to your on-premises environment (server1.subdomain.contoso.com). That is a different scenario and no change
    in that direction. For that direction, Office 365 supports all scenarios: plain SMTP, TLS (via self-signed certificate or CA signed certificate).

  10. Steve says:

    What about the following scenario:

    We have contacts in Exchange that have external smtp addresses. These contacts are in internal DLs that are available to users externally. When an external user sends an e-mail to the DL the mail will be sent to the external contacts part of that internal DL. Will those stop working?

  11. Daniel Andersson says:

    In an Hybrid solution between Office 365 and On-prem Exchange.
    You can today use one domain in the certificate and add the other domains in Set-HybridConfiguration.
    Is it possible after this change?
    Set-HybridConfiguration –Domains “secondcompany.com” “thirdcompany”, “autod:company.com”

Comments are closed.