Share via

Using Office365 Connector - Mail Flow

  • Article

Essence of this article is when you would need to use a mail flow connector based on your requirement.

 

  • Take Mail Flow Connector as a medium/bridge to establish mail flow between Office365 Online and On-premise Exchange/Another Partner Organization and vice versa.
  • A condition + Connector = Mail Delivery.
  • Mail Flow Connector ues On-premise Exchange/Partner's OWA FQDN to estbalish mail flow between two organizations.  
  • Mail Flow Connector works only when a defined condition is met/matched. If not, it just doesn't work.
    • The condition could  be, for example, defining a transport rule that if recipient email is a member of a particular group then use the mail flow connector you created to send to another destination (your on-premise exchange sever or partner organization, etc)
    • You are essentially associating a condition, in  this case,  a transport rule with mail flow connector to deliver the emails to n fro.
    • A condition + Mail Flow Connector = Mail Delivery.
    • Mail Flow Connector alone doesn't do anything - again - Mail Flow Connector must be associated with a condition you desired/defined.  
    • The condition(s) could be manipulating/using transport rules, and associating it with the connector(s) you created to achieve desired results or meet your mail flow requirements.

**Scenarios

**

Currently we have 3 domains (in your case may be more or less), abc.com, xyz.com and 123.com (replace with your domains here).

Abc.com is a pure cloud domain – it means its users have no on-premise Active Directory login, no on-premise Exchange server mailboxes – it will use pure Office365 Cloud Identity, Exchange Online email, Skype for Business Online services, etc.

Abc.com’s MX record is pointing to Office365 Online. While xyz.com and 123’s pointing to on-premise Exchange servers.

However, at the same time xyz.com and 123.com domains and their users are on-premise users – users login to on-premise Active Directory, are on on-premise Exchange servers and most notably we are planning to migrate on-premise Exchange users to the Office365 Exchange Online at a later date.

Added and verified abc.com, xyz.com and 123.com domains in the Office365 Portal. Assigned E3/E1/ licenses to abc.com users.

Email delivery issue surfaced.

I tried to send and receive email to and from as following directions:

Email sent from user@abc.com to user@xyz.com and user@123.com  - FAILED. 

"Delivery has failed" and "550 5.1.10 RESOLVER.ADR.RecipNotFound" NDR

 

** **

Root Cause

** **

The root cause of the problem is that Office365 Exchange Online thought/assumed that user@xyz.com and user@123.com are Exchange Online mailbox users because xyz.com and 123.com domains are registered, verified and accepted domains in Office365 environment.

And by default all registered, verified domains in Office365 are “Authoritative” – which means Office365 Exchange Online will handle and is responsible for delivering any email sent and received from abc.com including xyz.com and 123.com.

 

And CURRENTLY Office365 has no idea of xyz.com and 123.com mailboxes are not hosted in Office365 but in on-premise Exchange environment.

 

That’s why email sent from user@abc.com to user@xyz.com and user@123.com failed. So, we have to make changes in Office365 to ensure that it knows users of xyz.com and 123.com mailboxes are hosted in the On-premise Exchange (or/and any other mail servers) environment.

 

Solutions

 

There are two aspects we have to configure in order for user@abc.com to be able to successfully send email to user@xyz.com  and user@123.com

 

  1. Configure/change xyz.com and 123.com domains to Internal Relay from current Authoritative

  2. To create a Connector, so that email sent from user@abc.com (Office365 users) to user@xyz.com and user@123.com (On-premise users) will be delivered to on-premise Exchange server via the Connector.

    ** **

    ** **

    ** **

    ** **

  1. Changing Authoritative domains to Internal Relay Domains.

    ** **

    ** **

Office365 > Admin > Exchange Admin Center > Mail Flow > Accepted Domains

**

**

Select xyz.com, click Pencil and select “Internal Relay” and click Save. Repeat the same step for 123.com domain.

** **

Once all are done, you should see like that.

The second part is to create a Connector so that emails sent from user@abc.com will be delivered to user@xyz.com and user@123.com mailboxes residing in the on-premise Exchange servers.

Connector is used to relay/deliver email from Exchange Online to On-premise Exchange server and vice versa.

It’s very critical to understand that changing xyz.com and 123.com from Authoritative to “Internal Relay” is not the only want to “direct/change mail flow” or at least sending email from user@abc.com  to user@xyz.com and user@123.com

You could also create a distribution groups, called “on-premise users” and add all users’ email addresses of <@xyz.com> and @123.com in it. Then “Mail Flow > Rules” to create a rule defining that if the email is sent to members of “on-premise users” then use a connector to deliver the emails to On-premise Exchange.

You can manipulate “Mail Flow > Rules” to suite your requirements and then use a connector to deliver email to and fro.

Rule of thumb is that you create a condition, and once the condition is met/matched, then use a connector to deliver email to and fro.   

Mail Flow > Connector > “+” to create a new connector to deliver email from Office365 to On-premise Exchange servers

Type the domains that you converted/changed to “Internal Relay”. (a condition)

Please note that in you case, you may be using a transport rule (a condition) to relay mail to and from Office365 to your on-premise Exchange server or other partner server.

Type your on-premise Exchange server’s OWA FQDN (don’t include https://)        

 

Don’t select any SSL options and click Next.

Add an on-premise mailbox user, to test and click Validate to see if the email is routed to the On-premise mailbox.

 

Send test email between user@abc.com and user@xyz.com and user@123.com.