Mail Flow

When migrating your email from Google Suite to Office 365, or simply having mail flow coexistence between the two systems, I am usually asked the same question: Which email domains can I use as forwarding addresses in Google, to forward email to Office 365?

The answer is not very straightforward, and first and foremost it’s important to understand that in Google, per user email forwarding can be done in two ways:

Forwarding domain options: User Level Routing

Basically, with this option, the administrator can select whatever domain he wants to be the forwarding address. A very common scenario is to choose the onmicrosoft.com address, as the example below.

Above you can see the forwarding in the Google Admin portal, to the address user10@myexchlab22.onmicrosoft.com. The SMTP envelope will remain intact and no copy will be saved in the Google mailbox.

And the user primary SMTP address on Google.

The list of SMTP addresses in Office 365, for User10.

And the email sent to User10@myexchlab.com, that was forwarded to Office 365.

Finally a quick look at the email headers. Some considerations on that:

you can see that the email is initially received by Google, coming from Office 365 (the sender is from a completely independent 365 tenant)

You can then see that the email is forwarded to User10 in my Office 365 test tenant. You will see it’s received in 365, coming from Google.

Finally a quick note on the SPF failure. It’s a soft fail and one that you can’t control. What it basically says is that Google is not a permitted sender for the senders domain.

Summary:

The summary of this method is that it has no limitations, but, the catch is, stamping forwarding addresses in the Google admin console is not something that you can automate, to make it scale, i.e there’s no good method (to the best of my knowledge) to stamp addresses in 1000+ users, which is a huge manual task.

The second option can be done by the end user, but can also be automated. With this option you’re a bit more limited in terms of what domain names you can use for forwarding. Why? Let me show you.

Above you can see a forwarding set, in the tab “Forwarding and POP/IMAP” of the mailbox settings. To set the forwarding all I needed to do was add a forwarding address and select the “Forward a copy…” option. But my forwarding above is done to the O365.myexchlab.com domain, which is a sub-domain of a domain that my Google tenant owns. What does that mean exactly? That Google knows for a fact that if I own the domain myexchlab.com I also own the forwarding domain O365.myexchlab.com, and therefore does not ask me for any validation.

Makes sense? Now lets see when I try to forward to a domain that is not on Google, nor it’s a sub-domain of one that it is.

As you can see Google is going to send a confirmation code to the destination address, in order for you to prove ownership.

And the address won’t be available until you confirm it.

Now what’s the biggest problem with this? It doesn’t scale. Which means that with this method you will need to use the sub-domain method. Automation tools to add those addresses, like the GAM tool or the BitTitan SDK, won’t work in such scenario with those forwarding email domains.

Summary:

This is by far my preferred method. The only drawback with this, in my opinion, is that administrators have no visibility to the forwarding configurations, via the UI. But they can export them via the GAM tool.

Bottom line

If you are planning to configure mail flow coexistence between Google and Office 365, I’d recommend that you create a sub-domain in Office 365 (i.e O365.mydomain.com – mydomain.com must be valid in Google), don’t forget to add all DNS records such as MX and SPF, and use that sub-domain in your forwarding addresses.

If you want to automate the configuration (and you should), you can either use the GAM tool, or even much better, use the BitTitan Management Console, part of the BitTitan SDK that comes with an option to manage forwarding addresses on Google, and you won’t have to bother learning how to use the GAM tool, that believe me it’s not easy.

I will soon be writing a blog post on how to use the GAM tool to get a list of forwarding addresses from Google.

Imagine this scenario: You have an anti-spam appliance in front of your Office 365 tenant, and you want outbound mail flow from your tenant to go via that appliance, but depending on what the email domain of the sender is. For example you have domainA.com and domainB.com as two vanity domains in Office 365, and you want User1@domainA.com outbound email to go via the mail appliance, but user2@domainB.com outbound email to go direct to the Internet.

The scenario above requires conditional routing, meaning the outbound mail flow path will be different depending on what the email domain of the source user (the sender) is. The example above is just one of several that might lead you to apply such configuration.

Now the important part: How do you configure it? Well, you can do it via PowerShell or via the UI, and to do the configuration you will need the following:

The command above creates a connector that goes directly to the Internet and it’s scoped to the transport rule we will create next. If you want to create a connector that goes via an appliance run the following:

The command above creates a transport rule, that uses the “To Internet Via appliance outbound connector, and that applies when the source domain is specific and the destination recipient is outside of the organization (very important setting).

Via the Exchange Online Admin Center

Navigate to Mail Flow > Rules and click “+ Create a New rule”

Click on more options

Give the rule a name

In the Conditions select “Apply this rule if..” > The recipient is located > Outside of the Organization

Click in Add Condition

Select “Apply this rule if..” > The Sender > Domain is > Enter the domain name of the source user

In the “Do the Following…” section select “Redirect the message to..” > The following connector. Select the outbound connector from the drop down list

Make sure the enforce rule option is selected

Now that you have both the transport rule and the outbound connector created, lets test and see if it’s being applied.

Test the routing

The first thing you should do is simple: Send an outbound email from the user that should have conditional routing applied to his domain. Make sure the email is to an external recipient.

Once you sent the email, in the Exchange Admin Center go to Mail flow > Message trace, select the sender you want to trace the message for and click on “search”

Note: It might take a few minutes after you sent the message before it shows in the message trace

Once you can see the message there, double click on it to see the details

In the details you can see if the transport rule was applied and the transport rule name

You will also be able to see if the message was delivered, is pending or has failed. This is key for you to troubleshoot the mail flow and see if the correct rules are applied and the correct outbound connectors are being used.

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

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.

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.

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

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.

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.

Make sure you verify that the MX record is created.

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.

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.

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.

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.

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.

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.

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.

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.

Categories

Disclaimer

The content of this blog is based on my technical knowledge and experience and presented as-is. The solutions and guides presented here are based on the infrastructure i work on. I don't have knowledge about your infrastructure and you should ALWAYS test before implementing solutions into production. All opinions and statements expressed here are solely mine.

Follow my Blog Via EMail

Enter your email address to follow this blog and receive notifications of new posts by email.