Important notice for Office 365 email customers who have configured connectors

If you are an Exchange Online or Exchange Online Protection (EOP) customer 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 before the deadline (July 5th, 2017).

If your organization has a hybrid deployment (on-premises plus Office 365), you often need to relay emails to the Internet via Office 365—i.e. emails from your on-premises environment (mailboxes, applications, scanners, fax machines, etc.) that are sent to Internet recipients will be routed to Office 365 first, then sent out.


Figure: Email relayed from your on-premises email servers to the Internet via Office 365

For this relay to work, your organization needs to follow these steps:

  1. Create one or more connectors in Office 365 to authenticate emails coming from your on-premises mail servers, using either the sending IP address or a certificate.
  2. Configure your on-premises servers to relay via Office 365.
  3. Configure your setup so that:

a) The sender domain belongs to your organization (i.e. you have registered your domain with Office 365). For more information, see Add Domains in Office 365.


b) Your on-premises email server is configured to use a certificate to send email to Office 365, and the CN (Common-Name) or SAN (Subject Alternate Name) in the certificate contains a domain name you have registered with Office 365 and you have created a certificate based connector in Office 365 with that domain.

If neither step 3a nor 3b is true, Office 365 will NOT be able to know deterministically whether the email sent from your on-premises environment belongs to your organization. Therefore, it is important that organizations with hybrid deployments ensure that they fulfill either step 3a or 3b. This protects your organization, your domain, and your IP reputation.

Beginning July 5, 2017 (changed from Feb. 1, 2017), Office 365 will no longer support relaying emails if a hybrid customer has not configured either step 3a or 3b (see detail above). Such emails will get rejected with the following error message: “550 5.7.64 Relay Access Denied ATTR36. For more details please refer to″ 

Additionally, if your organization needs the following scenarios to continue to work (and most hybrid organizations do), you need to ensure that you follow step 3b.

  • Your organization needs to send NDR (Non-Delivery Report) or bounce messages to a recipient on the Internet and needs to relay them through Office 365.
  • You need to send emails on behalf of domains that do not belong to your organization.
  • Your on-premises users have forwarding rules configured, and messages need to be relayed through Office 365. For example:
    • is your organization’s domain.
    • A user in your organization’s on-premises server,, has enabled forwarding of all her messages to
    • If sends a message to, the message gets automatically forwarded to From Office 365’s point of view, the message is sent from to
    • Because Kate’s mail is being forwarded, neither the sender domain nor the recipient domain belongs to your organization.


Figure: When step 3b is followed, a forwarded email from will be allowed to be relayed via Office 365

For more details, see the step-by-step instructions below.

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.


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

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


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


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.


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 the CN name or SAN in the certificate you are using to send email and this domain must be a domain you have registered with Office 365 (see Add Domains in Office 365).

For example:

  • The certificate you plan to use has CN or SAN as In that case, you can enter in the dialog below and register in Office 365 (see Add Domains in Office 365)
  • The certificate you plan to use has CN or SAN as <hostname> or In that case, you could enter * in the dialog below, and register in Office 365 (see Add Domains in Office 365)

Note: Existing hybrid customers that used the Hybrid Configuration Wizard to configure their connectors SHOULD check their existing connector and ensure that it is using * instead of or <hostname>, since or <hostname> may not be a registered domains with Office 365.


Register your domain with Office 365

You can follow the steps to register your domain here - Add Domains in Office 365.

Go to Setup > Domains in the O365 Admin Center to see the list of domains registered:


Prepare your on-premises email 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:

    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, they are 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 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?


  7. Carolyn Liu says:

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

  8. @Carolyn Liu

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

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

    The way I read the document we would need a certificate on

  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 ( to your on-premises environment ( 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 “” “thirdcompany”, “”

Comments are closed.

Skip to main content