I’ll try in this article to list and briefly explain what need to be considered and checked while designing the coexistence scenario between the Exchange server and G Suite.

It is worth to mention that basically 90% of the work is not going to change for most of projects, so this can serve as a reference and a plan to apply for most of the projects to come.

Through out the work and experience I have got, I believe the below points are the most common settings and configuration that need to be checked and changed. I’ll also keep the list updated with anything I encounter that is not on it later on…

Put all contact objects used for forwarding in a separate special OU

You will face the need to create mail contacts on the Exchange server to forward mail to them. Depending on the size if the project, you might end up with a large number of those objects, which are basically (from AD perspective) just objects that might look ugly and without any benefit. So it will be a good idea to create a new OU, name it something relevant, like “G Suite Contacts” or whatever you like, and place those contacts in this OU.

Forwarding rules

Forwarding rules are important and set a workflow within the organization. Get all the rules that are existing on the Exchange server, and re-create them on the G Suite admin console.

Check distribution groups and re-create them on G Suite admin console

There are two types of distribution groups, the standard type, which you manually add members to them, and the dynamic distribution groups, which get their members based on filters and conditions you set upon creating the dynamic distribution group.

You can easily get the members of those distribution groups, using those useful cmdlets:

# First to get a list of all distribution groups:
Get-DistributionGroup

# Then, use this command to get the members of each distribution group:
Get-DistributionGroupMember -Identity [DISTRIBUTION_GROUP_EMAIL_FROM_CMD_ABOVE]

Get the list using the above cmdlets, then re-create the groups on the admin console of G Suite.

Check the other transport rules and re-create them on G Suite admin console

Exchange is different from G Suite. So not all transport rules can be created with the same exact actions or results on G Suite. So you will need for this to understand the logic of those rules, not the rules themselves. One example is the approval related transport rules… In G Suite, there is only approval for groups mail, but not for standard mail flow… so you will need to come up with a logic and a custom process/work flow to achieve the goal of providing a mail approval policy and work flow.

Email address policies

Having multiple email address policies means custom addresses for some users, check that and make sure you give each user his custom email addresses so he does not stop receiving email on them.

Check those rules also for any extra mail domain, if you see a user or a rule that enforces an email address with a different domain, then that is another accepted domain that need to be created in G Suite admin console.

Accepted domains

Other accepted domains than the primary one should be all added to the G Suite control panel, after you check whether they are being used in the previous step. Do not add any unused accepted domains on the Exchange server. Make sure only the accepted domains in use on the Exchange server are the ones you add on the admin console.

It is important to be aware that when adding more domains in G Suite admin console, verification and MX record change will be required for each domain.

Write down the public IPs of the Exchange server

All the public IPs that are related to the Exchange serve rand mail flow should be collected and recorded, whether the IP belonged to a firewall, or an Edge server, they all should be written down and added to the hosts list in G Suite Gmail configuration section in admin console.

Custom attributes for aliases (in case of using GADS)

If you are using GADS in the coexistence scenario, and if you will be using aliases for users, then you will encounter an issue for this, you can either dig in the AD schema for the attribute that holds the multiple email addresses for users, or utilize the custom attributes fields that gets added to user objects when expanding the schema for Exchange installation.

You will be having 13 custom attribute, you can add them in the GADS configuration section related to aliases and extra email addresses.

These attributes are called “extensionAttribute1” until “extensionAttribute15”

Default routing rules

The best option to setup the forwarding from G Suite side is to use the default routing option in Admin Console -> Apps -> G Suite -> Gmail -> Default routing

There you can set the rule to match a regex, and use the following template as a general regex criteria:

(?i)[a-zA-Z0-9\.]*@(DOMAIN.COM)$

The above rule will only forward mail explicitly sent to any address under the domain DOMAIN.COM, so this will help if you have multiple domains and want to make sure nothing goes wrong with the forwarding process.

Of course you will need to add the destination server IP in the hosts section of the default routing setting.

SPF, DKIM, and DMARC records

SPF, DKIM, and DMARC records are important because they will have a major and critical impact on how mail flow will behave once the coexistence scenario is activated and go live.

In order to adapt these records, start with the SPF record. There should be only one SPF record per mail-enabled domain. Find what that SPF record is, and modify it to include Google’s servers.

The standard SPF record for Google looks like this:

v=spf1 include:_spf.google.com ~all

So you will need to add include:_spf.google.com to the existing record, making sure it ends with ~all.

As for DKIM record, it is a bit different story… DKIM is a digital signature that is stamped on every message that goes out from Google’s servers… If you setup DKIM record and started mail authentication, all mail originating form the Exchange server will not have that signature, means it might not be considered a legit mail, and will get blocked if DMARC policy was in place.

So to solve this, you may want to configure the Exchange server to use Google’s SMTP Relay service, so all mail will actually go through Google’s servers, and then using the DKIM digital signature…

Before configuring the Exchange to use the SMTP relay service from Google, make sure you configure the SMTP relay form Google’s side to have all the related public IP addresses in the allow list, so it will accept mail from those IPs.

I believe these are the most important and common points that I mostly see and work with, each one of them has its own impact if configured wrong or left without configuration at all…

I’ll make sure this list is updated regularly with new points that I feel they need to be mentioned here, and of course any extra additions that come form you.

Checkout my other blog posts here.

Check out my channel on Youtube and subscribe ?