This guide is aimed at system administrators who are capable of connecting to remote systems such as G Suite for Business and Office 365 Admin Panel. Mail routing is usually a detailed setup that requires a high level of competence and experience with mail servers.
Although we provide support for our own products, we do not provide support for third party products such as PowerShell or server administration of Google or Exchange.
If you are concerned you might have any difficulty completing these steps, please consider a solution with our consulting team, contactable via firstname.lastname@example.org. This will ensure a fast, cost-effective and stress-free implementation.
1.2. Using this guide
This guide provides steps for setting up mail routing using the Cloudiway platform, as well as details of any remote system configuration required. It uses the domain drypizza.com as an example of mail routing between Office 365 tenants. It also uses warmsushi.com as an example of a non-Office 365 system.
The screen dumps used in this guide reflect these business names to provide typical examples of data to enter into each field.
Whitepapers and guides covering Cloudiway’s other products, such as general mail migration, are available from the Cloudiway website (www.cloudiway.com).
Cloudiway’s mail routing migration solution helps businesses implement elaborate mail forwarding systems through a simple SaaS interface. As a result, mail routing with Cloudiway requires no additional software installation or overhead. You simply need to point your MX records to Cloudiway’s mail routing platform and/or set up a smart host agent.
In addition, the Cloudiway mail routing platform is flexible, so mail migrations can be performed before, during or after mail routing, depending on your system setup and business requirements.
Regardless of the approach, all mail routing via the Cloudiway platform can be achieved without interruption to the end user.
2.1. Will mail routing work with my systems?
Mail routing can take place from any remote server that works on the application layer protocol (SMTP) to Office 365, Gmail or Exchange On-Premises. It can also take place between any of these services.
If you are using Exchange On-Premises 2010 or any other system, please get in touch with our technical consultants at email@example.com to discuss how mail routing can be implemented with your combination of remote systems.
Mail routing can also be a long-term solution, providing one aspect of enterprise coexistence (along with free/busy calendar synchronization and global address list synchronization, both explained later in this chapter), or it can be a short-term solution during a transition involving mail migration. Two of the most common mail routing scenarios are discussed in detail below.
2.2. Scenario 1: Mail routing during cutover mail migration
A cutover mail migration is a strategy normally completed over a single weekend. This one-shot approach is the simplest method of mail migration, and therefore the most popular choice.
After a cutover migration, many businesses need to update their domain names at their new mail system to match their previous system. However, moving domains from Office 365 tenants can take up to 48 hours. During this time, domains are unavailable. As a consequence, emails sent to users in those domains will result in non-delivery reports. Cloudiway’s mail routing platform can be used to prevent delivery failures during the transition, ensuring all incoming mail is routed to the intended user regardless of the status of the domain.
The following diagram is an example of cutover migration between two Office tenants. Prior to migration or mail routing, when a mail was sent to firstname.lastname@example.org, it was delivered to the old office 365 tenant, which was associated with the domain name drypizza.com.
This changes during mail routing (when the process can begin to detach drypizza.com from the old tenant). A new mail sent to email@example.com will be routed to the Cloudiway platform. In the example below, Cloudiway will then redirect mail to the old tenant (dp.onmicrosoft.com), changing only the ‘to’ header in the original email message. Other paths are possible, but we recommend this one.
Note that Bob can reply to the email, but it will be sent from firstname.lastname@example.org because outbound mail is not set up for short-term cutover migrations (and drypizza.com has begun being detached, so it’s no longer available). To avoid this situation and other similar situations, Cloudiway recommends that you keep mail flow pointing to the old tenant (as shown above) and perform a cutover during non-working hours.
As well as the seamless delivery of mail offered by Cloudiway mail routing, using the service during a cutover mail migration has the following benefits:
The TTL (‘Time To Live’ setting) of your DNS MX records may maintain cache. The issue may be addressed by decreasing the value of the TTL to the allowed minimum. The TTL is displayed in seconds, so 3600 is equal to 1 hour, for example. The minimum is often 15 minutes, which is equivalent to 900 seconds.
2.3. Scenario 2: Mail routing during staged migration
A staged migration allows you to migrate batches of mailboxes over the course of a few weeks or months. During the process, your messaging system is subjected to constant variations. For example, user mailboxes might be created or deleted; or some DNS domains might be added or depreciated.
The Cloudiway platform provides the redirection of incoming emails to the correct mailbox regardless of its migration status (inbound service).
The diagram below shows a typical migration from Gmail to Office. A non-migrated user, email@example.com, continues to receive new mails in her inbox at the old Gmail tenant. A migrated user, firstname.lastname@example.org, will now receive emails sent to email@example.com at the new Office 365 tenant.
The Cloudiway mail routing platform also performs proxy server services, and rewrites any From mail headers to match the business needs and system setup (outbound service). This means that Bob can continue to send emails as firstname.lastname@example.org until mail routing is deactivated.
As well as the seamless delivery of mail offered by Cloudiway mail routing, using the service during batch migrations has the following benefits:
The Cloudiway mail routing platform does not yet support TLS/SSL encryption. The mail routing platform requires authorizes IP addresses on both sides.
2.4. Scenario 3: Mail routing during enterprise coexistence
Enterprise coexistence allows businesses to work as one company and is often used during mergers and acquisitions, and sometimes indefinitely if the business need requires it.
The coexistence platform is made up of three tools
2.4.1. Calendar free/busy
Cloudiway provides a coexistence tool for calendar free/busy time display. For example, a G Suite user on one can check the free/busy time of an Office 365 user. Coexistence manages cross-platform communication with no impact on the end user. It provides a seamless connection between two or more different remote systems during migration.
Calendar free/busy synchronization works between any mix of Office 365 tenants, G Suite and Exchange On-Premises.
GALsync stands for global address list synchronization, allowing automatic updates between global address lists to ensure they remain synchronized. GALsync works between multiple address books through a simple configuration online, which sends pull requests to other address books configured for communication. When mail routing is used during long-term coexistence, this ensures that all address book updates, such as new users, deleted users, or users with changed details, are propagated to all other address books configured for GALsync.
More information about each of these products is on the Cloudiway website at www.cloudiway.com. To discuss any of these tools further, please get in touch with your existing Cloudiway contact, or via email@example.com.
For more information about security, please refer to this article.
4.1. Before you start
Before you start, please ensure you have the details outlined in the following table.
|Cloudiway login||Stores details and provides communication between the systems you already use.||https://apps.cloudiway.com|
|Knowledge base access||Our extensive knowledge base is always accessible, with videos, troubleshooting tools, samples and more.||http://kb.cloudiway.com|
|Decreased TTL of DNS MX records||If inbound mail routing is part of your business need, ensure the TTL of each MX record is set to the minimal value: this reduces caching time when you will switch your MX records.||Your domain provider.|
4.2. Contact Cloudiway
Mail routing requires some configuration by your Cloudiway contact firstname.lastname@example.org, so you will need to get in touch with Cloudiway at the start of your project. A Cloudiway consultant will add the mail routing add-on to your project account and will work with you to setup the mail routing.
Follow the scenario sections below to suit your situation:
Scenario 1 Short-term domain transformation configuration (maximum around 48 hours).
Scenario 2: Longer-term domain routing (during batch migration or coexistence), using inbound or outbound rules or both, with the option of creating rules for individual users.
4.3 Scenario 1: Short-term domain transformation configuration
The Relay section of the Cloudiway mail routing platform is the simplest form of mail routing. It’s used for inbound, short-term mail routing only, such as when moving a domain between Office 365 tenants, which normally takes up to 48 hours, and when no changes to usernames are required.
For longer term or more involved mail routing, skip these steps and go to section 4.4.
There is no user list associated here. If you need to make username changes, please contact Cloudiway, or follow the next sections instead. Otherwise, you can skip to section 4.4.
4.4. Scenario 2/3: Setup inbound and/or outbound mail routing rules (domain level)
The Cloudiway mail routing platform can work as an incoming or outgoing mail server for any domain. Setting up routing rules will ensure that all users within one domain have their mail routed. However, if any mail alias changes are required (ie, the prefix before the @ symbol in an email address), it’s imperative that users are added to the user list on the Cloudiway mail routing platform. The steps are covered later in this scenario. The steps below cover the domain level.
To use inbound mail routing, simply follow the steps below to configure the Cloudiway platform, then add your users and point your MX records to the Cloudiway mail routing server (covered in later sections). You can have as many inbound mail rules as you need for multiple domains and multiple Office 365 tenants.
Outbound mail routing is setup in exactly the same way on the Cloudiway platform, so you can follow the steps below if your mail routing scenario requires outbound mail routing. You can have as many outbound mail rules as you need for multiple domains and multiple Office 365 tenants. Remember that when configuring outbound mail routing, the ‘original’ email domain or sender will be the address you wish to rewrite, rather than your preferred domain name.
4.5. Scenario 2/3: Setup inbound and/or outbound mail routing rules (user level)
If your mail routing needs don’t involve any mail alias (username@) changes, the Cloudiway mail routing platform will use any domain level rules you’ve already setup to blanket route mail (for example, from *@youroriginal.domain to *@yournew.domain).
However, if any mail alias changes are required, they will need to be added to the mail routing user list. The Cloudiway mail routing platform will first check this user list before redirecting any incoming mail or rewriting any outgoing mail. If it finds a mail alias, it checks the updated mail alias and routes mail accordingly (for example, if email@example.com is listed with an updated email address of firstname.lastname@example.org, email will be redirected to email@example.com). If it doesn’t find an entry for firstname.lastname@example.org, it will check the server level routing rules and, using the examples in this guide, redirect email to email@example.com.
Note that if outbound mail from Bob’s new alias (firstname.lastname@example.org) still needs to look like it’s coming from email@example.com, this it should be listed in the Outbound user list too. The source in this case would be firstname.lastname@example.org with a target of email@example.com.
Users added to the mail routing user list do not require a license.
There are two ways to add users to the mail routing user list. These include:
4.5.1. Option 1: CSV import
If you have a CSV file of users affected by username changes, you can upload the file to Cloudiway. The file must have the following fields in the header row, ‘;’ is used as a field separator:
When uploading a CSV file, please note that any existing users will be overwritten. Therefore, once you have users in your user list, make sure you export the existing user list via the Users, Export UserList command on the Action bar before re-uploading the exported CSV file.
4.5.2. Option 2: Single user creation details
If you only need to add a new user or change just one or two users in your mail routing user list, you can use the single creation tool directly on the Cloudiway platform to save time. No need to export your existing CSV list, edit and re-upload!
Currently, existing users cannot be edited, so if you wish to update an existing user, make sure you delete the user first by selecting the checkbox beside the username and using the Users, Delete User(s) Mapping command from the Action bar.
4.6. Activate the Cloudiway mail routing service
Now is a good time to double-check that your mail routing configuration on the Cloudiway platform matches the scenario you wish to achieve. If everything looks correct, you can activate the mail routing service.
Activating the service doesn’t mean that mail routing will begin right away. For incoming mail routing, you need to point your MX records to the Cloudiway platform. For outgoing mail, you must configure your remote system or systems to first reroute outgoing mail to Cloudiway (see the following sections).
Using the Push command on the Cloudiway platform will launch an asynchronous update job, and when the update is complete, you will receive a confirmation email in the inbox associated with your Cloudiway account. This means that mail routing on the Cloudiway side has successfully activated.
Mail routing will normally commence right away, and you will receive a confirmation email at the email address associated with your Cloudiway account. If you haven’t received the confirmation email within two hours, please open a ticket via http://support.cloudiway.com.
If your business requirements include outbound mail routing, you will need to follow the sections below to ensure that your remote systems are setup to route emails via the Cloudiway platform, to allow for the email addresses and any From headers to be rewritten.
5.1. Before you start
Before you start, you will need to ensure you have the details outlined in the following table. As a courtesy, this guide provides remote system configuration details for the most popular mail systems — Office 365/Exchange and Gmail. If you use a different system and need help, consider engaging a Cloudiway consultant.
|Knowledge base access||Our extensive knowledge base is always accessible, with videos, troubleshooting tools, samples and more.||http://kb.cloudiway.com|
|Google Admin console||If Gmail is to be used as part of a mail routing setup, this is where the outbound mail configuration is set by a system administrator.||https://admin.google.com|
|Office 365 admin account||If Office 365 is to be used as part of a mail routing setup, this is where the outbound mail configuration is set by a system administrator.||https://outlook.office365.com|
|Domain provider admin account||This is required for access to change MX record to point to the Cloudiway servers (inbound flow or domain detaches).||–|
5.2. Inbound routing: Update your MX records
If your mail routing scenario uses inbound mail routing, you must point your DNS MX records to the Cloudiway mail routing service before mail routing can commence. If you haven’t already, make sure you decrease the TTL of each MX record to the minimal value, so that there will be no caching issue when you will switch your MX records. You should already have the Cloudiway mail routing service’s address, so point your MX records to this when you’re ready to begin inbound mail routing.
5.3. Add the Mail Routing Server IP as an allowed IP address
To avoid having the incoming emails arrive in your spam folder, you have to add the mail routing server IP address as an allowed IP address in your target tenant. To do so follow the steps below:
5.4. Outbound routing: G Suite — Configure your outbound flow
This section only applies if you’re using G Suite for outbound mail flow. For routing outbound mails, or rewriting From mail headers, you will need to reroute your mail flow to use Cloudiway’s mail routing service.
Once you have heard back from Cloudiway and have the outbound gateway for details for mail routing, you can begin configuration.
5.5. Outbound routing: Office 365/Exchange — Configure your outbound flow
This section only applies if you’re using Office 365 or Exchange On-Premises for outbound mail flow. For routing outbound mails, or rewriting From mail headers, you will need to reroute your mail flow to use Cloudiway’s mail routing service.
Once you have heard back from Cloudiway, you should have the outbound gateway details for mail routing, which means you can begin configuration.
5.6. Outbound routing: Add an SPF record to your DNS
An SPF record (Sender Policy Framework record) identifies which mail servers are allowed to send email on behalf of your domain. This prevents spammers from sending messages with forged From addresses at your domain.
An SPF record to each domain involved with mail routing is therefore is required before mail routing can begin. This ensures that the Cloudiway mail routing service is not blacklisted, avoiding delays and downtime. When adding each SPF record, use the same Cloudiway IP or domain name given to you for creating the external connector or outbound flow.
6.1. Check logs
The Cloudiway mail routing platform provides a text log of actions performed. You can check it at any time from the Relay, Inbound or Outbound areas of the platform but clicking on the Logs sub-menu.
6.2. Stop mail routing
When you’re ready to stop using Cloudiway’s mail routing service, follow the checklists below.
For inbound mail:
For outbound mail
Cloudiway provides an extensive knowledge base with many resources, including common error messages, video guides and downloads.
Please visit the mail migration knowledge base area here:
Please visit the entire knowledge base here (where you can search for keywords or read through topics): http://kb.cloudiway.com/
The knowledge base also contains information on how you can ask for further support, should you require it.