How to configure mail flow coexistence between GApps and O365 using internal relay domains and mail users

Are you planning to move your e-mail system from Google Apps to Office 365? Do you have a large number of users, and therefore migrate the users in stages, and therefore set up mail flow coexistence between the two systems? Keep reading.

On this blog post I am going to guide you through the process of setting up mail flow coexistence, between Google Apps and Office 365.

There are several ways to achieve the mail flow coexistence, from an Office 365 perspective, such as:

  • The Internal relay domain with mail users method
  • The Criteria Based Routing method

This blog article will guide you through the mail flow coexistence configuration, using the internal relay domain method. This method as some pros and cons when compared to others, such as:

Pros:

  • Easy to configure
  • If the processes are well defined it’s also easy to manage as the migration goes along

Cons:

  • Requires more processes during the migration stage
  • Requires more changes post migration
  • When not using Dirsync or AADsync the users on Office 365 need to be created via the Exchange Admin Centre or the Exchange Online PowerShell, which makes the user creation process more complicated.
  • When you enable a mailbox on Office 365, for a user being migrated, all new e-mails coming from other Office 365 users (and external users if you already changed the MX record to Office 365), will not reach the Google Apps mailbox and stay only on the Office 365 mailbox. This makes that the process of migrating the user data has to be managed in batches of users, and done ideally over the weekend.

In my opinion, if you’re using Dirsync this method is an option you should consider.

Now let’s get what matters: the steps for configuring mail flow coexistence between Google Apps and Office 365.

Step 1 – Validate your domain on Office 365:

Of course if you are moving to Office 365, the first thing you need to make sure is that your domain is validated there, and enabled for Exchange Online.

On my scenario, the domain that I am using is myexchlab.com

1

I am not going to give you a step by step guide on the simple tasks, such as adding and validating the domain on Office 365, to keep this blog post focused on the essential, which is to set up the mail flow coexistence.

As you can see above you need to make sure that your domain is added and validated, and that the domain purpose is set to ExchangeOnline.

2

As you can also see above, on my Google Admin Portal, my domain is also validated and working there, as that is my current production environment.

Step 2 – Create and enable your Office 365 users as mail users

Depending on the way you create the users, they can already be mail users on Office 365, i.e. if you are using Dirsync or AADSync to push your users to Office 365, you should have them as mail users on premises, which will also make them mail users on Office 365.

To sum up, there are two ways to create all your users as mail users on Office 365:

  • If you’re using Dirsync enable them as mail users on premises and push them to Office 365
  • If you’re not using Dirsync you need to create all your users via the Exchange Online PowerShell, or the Exchange Admin Centre, directly as mail users. The reason is simple: In Office 365, it’s not supported to enable a user without Exchange attributes (just a regular MSOL user) as a mail user. The only way to give him Exchange attributes is to enable an Exchange Online license and create him a mailbox.

In my case I am not using Dirsync, so I am going to show you how to create all my users as mail users. To do so you can use a script (let me know if you need one), or do it manually via the Exchange Online management Shell.

Connect to the Exchange Online Powershell, and run the following cmdlet:

New-MailUser -Name “GApps1” -Alias Gapps1 -ExternalEmailAddress Gapps1@myexchlab.com -FirstName GApps1 -LastName 1 -MicrosoftOnlineServicesID GApps1@myexchlab.com -Password (ConvertTo-SecureString -String ‘P@ssw0rd’ -AsPlainText -Force)

3

Repeat the step for each user you want to create.

4

Now I have GApps1 and GApps2 created on Office 365, both users also exist and have their productions mailboxes on Google Apps.

5

The users are also Exchange mail users, which is fundamental to have both an up to date Global Address list on Office 365, and to make the mail flow coexistence work.

I know that this way of creating the users might seem a bit manual, but there are two things you need to consider:

  • Most of you will be using Dirsync, which makes the user creation process much simpler.
  • You can script the user creation via the new-mailuser cmdlet and make your live easier.

Step 3 – Configure the routing domain in Office 365

In order to have mail flow coexistence between Google Apps and Office 365, you need to set up a forwarding address in each Google Apps user you move to Office 365. In order for it to work, the forwarding address needs to be from a sub domain of your main email domain. In my case I will use onprem.myexchlab.com which is a subdomain of myexchlab.com.

To properly configure the subdomain you need to:

  • Validate it on Office 365 and configure it for Exchange Online
  • Create an MX record for that subdomain, that points to office 365
  • Make sure that the users have a secondary SMTP address for that subdomain, that you will use as forwarding address on google

To validate the routing domain, go to the domains section on your Office 365 portal and click to add a domain.

As the domain is a subdomain of your main e-mail domain, the validation should be instant.

Skip the steps to add users, and make sure that you choose Exchange as domain purpose, as sown below.

6

The Office 365 wizard will give you an option to add the DNS records (depending on your domain name provider), or you can just copy and paste the DNS records and add them yourself. The only relevant record that needs to be created, is the MX record.

7

Make sure you verify that the MX record is created.

8

Step 4 – Configure Exchange Online for mail flow coexistence

On the Exchange Admin Centre of your Office 365 tenant, you need to do two things:

  • Configure your main domain as internal relay
  • Create a send connector to send e-mail to your Google Apps

To configure your domain as internal relay, log in to your Office 365 tenant, and on the bottom left click on “Admin > Exchange”.

On the Exchange Admin Centre go to “Mail Flow” and click on the “Accepted Domains” tab.

9

Select your main e-mail domain, in my case myexchlab.com, and click edit.

10

Select “Internal Relay” and click save.

Now let’s create the send connector. On the Exchange Admin Centre, select “Mail Flow” and click on the “Connectors” tab.

11

Click on the “+” to add a new connector.

12

When creating the new connector, select from Office 365 and to your organization’s email server.

13

Select a name and keep the existing options selected.

14

Select “Only when email messages are sent to these domains” and click on “+” to add your main email domain.

15

Enter one (or several) of the available Google Apps MX record as a smarthost.

16

You can check the Google Apps MX records by doing an nslookup to your domain.

17

Untick the always use TLS option and click next twice.

18

Finally enter a valid e-mail address from your Google Apps environment, and click validate. Make sure the test succeeds.

Migration steps

Now that you have Office 365 configured for mail flow coexistence, let me give you a quick overview on the migration steps:

Define a migration batch

The first thing you need to do is define a group of users to be migrated. Because there’s no sharing of resources cross platforms (i.e calendars), I highly recommend you approach your migration batches on a per department basis. You might want to export all e-mail addresses of the users being migrated, into a CSV file, in order to use that file to script all the forthcoming tasks.

Activate the user licenses in Office 365

Once you have your group of users defined, you need to activate an Exchange Online license for them on Office 365. Like stated previously you can script that, but for the purposes of this blog post I will just activate the license manually, as the main goal here is to explain how to set up the mail flow coexistence.

19

Go to your Office 365 admin portal, click on “Users > Active Users”, select the user you want to license and add an Exchange Online license.

20

Via the Exchange Admin Centre you will be able to see that, the user is no longer a mail user, and it’s now a mailbox.

Note: As stated before, all e-mail coming from other Office 365 users, or external e-mail if you changed the MX record of your main domain to point to Office 365, will now stay on the GApps1 Office 365 mailbox and not on his Google Apps mailbox.

Migrate your user’s data

Now it’s time to push all the data from Google Apps to the newly created Office 365 mailbox. And how can you do that? Well the answer is simple: Use the best tool in the market. MigrationWiz from BitTitan.

https://www.bittitan.com/products/migrationwiz/about

21

MigrationWiz will move all your emails, calendars and contacts, from Google Apps to Office 365. In addition you can also move your Google Drive and your Google Vault data, with other types of migrations supported by the same tool.

Set up the forwarding address on Google Apps

Now at the same time you start to move the data, you need to set up a forwarding address on the Google Apps accounts you’re migrating. I’ll be blogging soon an explanation on how MigrationWiz automatically sets that up for you, but for now I will again do it manually on my GApps1 user.

Log in to https://admin.google.com

Go to Users and click on the user you want to set up the forwarding. Click on “Account”.

22

On the Email routing section add the forwarding address. Untick the “Change SMTP envelope”, the “Google Apps email” (leave a copy on the source) and the “Inherit routes from <your domain>”.

Important note: do not leave a copy on the source mailbox, or else when moving the data to Office 365 via MigrationWiz, you might get duplicates.

23

Another thing that you need to make sure is that all the users being migrated have a @onprem.myexchlab.com secondary SMTP address.

Connect the users to Office 365

Once all the data is migrated all you have to do is set up your users to connect to Office 365 and start working there.

BitTitan also has a tool to help you automate that process: DeploymentPro

https://www.bittitan.com/products/deploymentpro/about

DeploymentPro will configure Outlook for all your users, and bring all attached PST files and signatures from the old profile (if applicable).

Test mail flow

Now that we’ve covered all the migration steps, it’s time to test mail flow between:

  • GApps1 that was migrated to Office 365
  • GApps2 still in Google Apps

Test message from the Internet to GApps1 (Office 365)

With the MX record still pointing to Google Apps, we will send a test message from the Internet to GApps1, that was already moved to Office 365.

24

25

As you can see the message got delivered to Office 365.

Test message from GApps2 (Google Apps) to GApps1 (Office 365)

Now let’s send a message from a Google Apps user to an Office 365 user.

26

27

And again message delivered to GApps1 Office 365 mailbox.

Test message from GApps1 (Office 365) to GApps2 (Goggle Apps)

Now the most relevant test, the one this blog post is all about: mail flow between Office 365 and Google Apps.

Let’s reply to the GApps2 email.

28

29

And there you go. Working!

Internet mail flow considerations

On this coexistence scenario, there is no centralized outbound mail flow, which in essence means that Office 365 users will email directly to the Internet, and the same of course will happen to Goggle Apps users. Having said that, you need to make sure that your SPF record is up to date, and reflects that scenario. For help setting up your SPF record, go to the Microsoft SPF record wizard page.

Summary

Most of the configurations described above only need to be done once, but on the migration steps section you will want to automate everything. I’ve seen a lot of companies concerned with things like setting up the forwarding address on Google Apps, or scripting the way you enable licenses for users. One of my next blog post will be how MigrationWiz automates the forwarding address configuration, and you can ping me if you need more information about that, or if you need scripts for things like enabling the licenses on Office 365.

As stated on the beginning of this post, there are other methods to configure mail flow coexistence between Google Apps and Office 365, and I will soon be blogging about them so stay tuned.

34 thoughts on “How to configure mail flow coexistence between GApps and O365 using internal relay domains and mail users

  1. Jody Leukes August 24, 2015 / 11:33 am

    Hi

    Thank you so much for this post. It helped me out big time. We have google apps running at a college but I am having massive and endless issues with the google apps outlook sync. Your solution would work for our staff and faculty that live by the Outlook desktop app. The students (being the new generation so to speak) love the gmail app. I would just like to ask. Instead of creating a subdomain, could one not use the temporary/setup domain provided by office 365? For example, you register company1.com. Office365 provides you with company1.onmicrosoft.com. Once a user is created, a email address with company1.onmicrosoft.com is automatically created. I tested the forwarding from Gmail with these addresses and it seems to work. Are there any implications doing it this way?

  2. AMVargas August 24, 2015 / 7:50 pm

    Hi Jody, thanks a lot for your positive feedback. Based on this article https://support.google.com/a/answer/2707558?hl=en the only limitation seems to be forwarding e-mail to a domain owned by GApps, hence the use of the o365.domain.com as a secondary subdomain, which will be easy to validate and create an MX record to, since it’s a subdomain of the one that you own. As for the use of the yourtenant.onmicrosoft.com secondary smtp address I see no issues with that, so you can test and use it. Just make sure you test with the forwarding set up by the Google Apps admin, on the Google Apps admin console, as the forwarding requirements and limitations are different when comparing the “Admin based forwarding” with the “User based forwarding”. Have a look at the link I sent above. Again I haven’t tested it but i don’t see why it shouldn’t work. Do you have a tool to migrate the data? MigrationWiz can automatically set up all those forwarding addresses for you, plus provide you an awesome experience when moving the data. Let me know if you have any questions or if your tests don’t go as expected.

    • Jody Leukes August 25, 2015 / 8:19 am

      Hi again. Thanks for your reply.
      I tested the forwarding using the onmicrosoft.com domain and you were right, it has to be within the primary domain. I setup a subdomain and will forward the mail from the admin portal in google apps. We plan to use both platforms. The mx records for the base domain will remain pointed to google. Reason for this is the google app suite is more suited to us. The only downside that I find with google services is the poor google apps sync app for outlook. Its a massive pain to deal with. So I got a E1 license for office365 and began figuring out a way to get a back and forth email routing scenario between office and google. Your solution is perfect. This led me to dig a little deeper into the 365 platform and see that I can setup sso between my onsite AD and 365, which is something I will setup now to get users synced to office365 then implemented to desktop level. In terms of migration, I have not thought of how I am going to go about moving staff and faculty email over to office. The only way I know which is a bit tedious is setting up two accounts on outlook and moving objects from one to the other. this is for +- 60 users. I will have a look at Migrationwiz

      • AMVargas August 25, 2015 / 11:56 am

        I thought I used the subdomain for a very specific reason, but was unable to find my notes on it. Now we know. Don’t forget you need mail users on Office 365 to maintain the mail flow coexistence on that side and to have the unified GAL. Have a look at migrationwiz, for that number of users you will get everything done at a minimum cost and with almost zero effort. Any questions let me know.

  3. David Ruess February 27, 2016 / 11:59 pm

    Hey, I’m wondering if you can help me out of the goodness of your heart. I’m new to this, in the thick of it, and sort of lost. If you won’t help me no worries, just let me know 🙂

    So I’m currently migrating about 15 users from a hosted exchange 2010 to Office 365.
    I used migration-wiz and have all of the mail/calendar/etc… migrated over to Office 365, except three people (because I’m still waiting on their passwords, and one guy is out of the country.

    Ideally, I’d like to change the mx records tonight to point to Office 365, change the outlook settings of the 12 to Office 365, but then migrate the last three later this week, without messing up anyone’s ability to send or receive mail.

    I guess I’m wondering this:
    1. Can I use a mail-flow coexistence to somehow to set this up – like you were using with Google Apps above?
    2. If so, would any steps change? I’m mostly confused about the subdomain part, (whoa de ja vu) the purpose of the subdomain, and how long I would keep it.

    If you’d be willing to write back I’d super appreciate it!
    – David

    • AMVargas March 9, 2016 / 12:40 am

      Hi David, sorry about the delay I have been travelling. Did you manage to get this resolved? The answer to your question is:
      1- yes you can have mailflow coexistence
      2- yes the steps are slightly different

      Let me know if you still need my help

  4. Drew Clauson July 13, 2016 / 10:40 pm

    “I’ll be blogging soon an explanation on how MigrationWiz automatically sets that up for you, but for now I will again do it manually on my GApps1 user.”

    Does MigrationWiz do this or do I need to set that up in it’s options?

  5. Drew Clauson July 13, 2016 / 10:41 pm

    “I’ll be blogging soon an explanation on how MigrationWiz automatically sets that up for you, but for now I will again do it manually on my GApps1 user.”

    Does MigrationWiz do this or do I need to set that up in it’s options?

    • Drew Clauson July 13, 2016 / 10:41 pm

      (sorry if this got double or triple posted)

      • AMVargas July 16, 2016 / 1:08 am

        That’s ok 😄

  6. AMVargas July 16, 2016 / 1:07 am

    Hi Drew. Yes MigrationWiz can set the forwarding addresses on the GoogleApps side automatically. Feel free to reach out to me at avargas@bittitan.com and i can send you some information on how this is done. You can also search for it @ learn.bittitan.com or community.bittitan.com. Looking forward to hear from you.

  7. Mr. T Wade April 21, 2017 / 12:28 pm

    Thanks for this walk through, it was extremely helpful in getting ours setup and helping the migration go much smoother for the end users.

  8. Alex Moin May 6, 2020 / 11:41 am

    I understand the routing for incoming mail to G-Suite, and how that’s forwarded to O365, but am having trouble grasping the outgoing mail routing for the migrated O365 user. Can you explain the functions of the internal relay and send connector?

    • Antonio Vargas May 20, 2020 / 11:02 am

      Hi Alex,
      sorry for the delay. I can explain, yes.
      In Office 365, the combination between internal relay and the send connector is what sets up the logic to forward the email to Google. For example, if John@abc.com is still in Google, and abc.com is set as an internal relay domain, when someone in Office 365 emails John, because the object does not exist in 365, Exchange Online will search and find a connector to send it elsewhere. When a domain is “authoritative” that won’t happen and an NDR is generated, because authoritative means “deliver locally or if the mailbox does not exist generate an NDR”.
      Hope that helps,

      AV

  9. Jim SUllivan May 21, 2020 / 4:25 pm

    so if you have o365 (mx)as internal relay and a send connector to my on prem server . how will it send to google. do i need to set the onprem as internal relay and create a send connector to google.
    thanks for your time

    • Antonio Vargas May 22, 2020 / 12:39 am

      You don’t need a 2 hop. If john@abc.com does not exist in Exchange online, you create a send connector to send it elsewhere, which can be Google. No need to go on premises.

    • Antonio Vargas May 23, 2020 / 11:36 am

      Jim, to be more precise, you can use Criteria Based Routing to send direct to Google. Meaning if the user is part of a group then use a connector to send to Google. Ping me if you need professional help setting this up.

  10. LINH October 1, 2020 / 1:14 am

    I understand the routing for incoming mail to G-Suite and forward it to O365. Can I route for incoming mail to O365 and forward it to G Suite? Can you guide me? And I only added O365’s MX record.

  11. LINHHHHH October 1, 2020 / 4:38 am

    I understand the routing for incoming mail to G-Suite, and forward it to O365. But I want to know about the routing for incoming mail to O365 and forward it to G Suite. Can you guide me? And I only added MX record in DNS console. Thanks

  12. Antonio Vargas October 2, 2020 / 11:16 am

    You can yes. You can use several methods to do that:
    1- when the mailbox does not exist in 365 you can use the method described in this post, which is basically configure the email as internal relay and create a connector to send to google
    2- if the user exists in 365, as a mailbox or a mail user, you can configure Criteria Based Routing, as per this article https://help.bittitan.com/hc/en-us/articles/115008260168-Set-up-mail-routing-on-Office-365-when-migrating-users-in-batches
    Let me know if that helps.

  13. skunkworks October 8, 2020 / 12:44 pm

    Hello there and thank you for this writeup. This is one of the more informative ones on this topic.

    I’m having an issue with validating the O365 to G-Suite connector:

    The smart host gets validated but the test email fails, and with no logs so I can’t really tell what’s happening.

    Is there anything else to check in terms of G-Suite settings that may be blocking the connector?

    • Antonio Vargas October 8, 2020 / 12:54 pm

      Hi. Did you tested emailing from a 365 user to a google one? I mean outside of the test feature at the end of the connector creation. Also try and send to an address exclusively in gsuite and see how that works. Sometimes the connector validation test might not mean the mail flow isn’t setup correctly

      • SKUNKWORKS October 8, 2020 / 1:58 pm

        Just did and it’s working now. Thank you!

        One more oddity: It seems to be working with direct emails only, and not groups.

      • Antonio Vargas October 13, 2020 / 3:43 pm

        Well that might depend on those groups being able to accept external email in google as well as the group and maybe the members having to be a part of the cbr. Did you resolved it?

  14. LINHHHHH October 13, 2020 / 6:58 am

    I set up a connector from “Office 365” to “Your organization’s email server” in Exchange admin center. When I sent email, email don’t save in MS 365 mailbox but it directly delivered to G suite mailbox. How can I save a copy of message in MS 365 mailbox before it is delivered to G Suite mailbox?

    • Antonio Vargas October 13, 2020 / 3:44 pm

      By using forwardings. Criteria based routing is applied at the email pipeline level so that 365 mailbox will never see the message to keep a copy of it

      • LINHHHHH October 15, 2020 / 3:34 am

        Can you guide me using forwardings? And I have only domain use both G Suite and O365. The MX record only of O365.

      • Antonio Vargas October 15, 2020 / 11:18 am

        You can create a subdomain gsuite.abc.com, add that subdomain as a secondary address in google and forward the email by adding a forwarding address in the exchange online mailbox. Any reason why you want to keep a copy at the source? I ask because it’s not what I would recommend

  15. Yeap December 19, 2020 / 6:00 am

    In your example, do we still need to assign Exchange online license to GApp2 although this mailbox is seating on GApps?

    • Antonio Vargas December 19, 2020 / 7:55 am

      Hey Yeap, not until you want to start migrating him. Assigning the license will create the mailbox, which is a requirement to start migrating the user, but not before.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s