Running company emails at two different suppliers

Quick question regarding Exchange:

We are a small company and have had our mail service hosted through Unoeuro until now. Now we have decided to move some of our mail accounts to Exchange because we would like the better service and more options. However, we would still like to keep some of our email addresses at Unoeuro due to price (employees who are not involved full time and just need a basic email account).

I have now spent a couple of hours setting up my own mail account in Office 365 (but we are still using Unoeuro’s nameservers so I’ve added CNAME, SRV etc. to the Unoeuro DNS) and it seems like my account is running fine. The other employees in the company can still use their emails through Unoeuro. However, I have one problem now – I can’t send emails internally now!

When I send an internal mail I get an error message that my mail couldn’t be delivered and that “XX” wasn’t found at “mydomain.com” (the mail I try to email is [email protected]).

How do I solve this issue if it can be solved at all?

Solution 1:

By default, when you configure your domain @domain.com in your email system, they typically assume they are completely authoritative for the entire namespace. In other words, they are the ultimate authority on whether to accept and deliver mail addressed to <anyone>@domain.com.

In this scenario, you have two independent email systems, with different (non-intersecting) user lists. We need to ensure each system is aware of users on the other system, so as not to reject legitimate email.

Internal delivery

At the moment, sending mail from users on one mail system to the other will fail. When the mail system doesn't know the other mail system exists, it will throw mail destined for users on that system away and send a bounce to you to indicate the user doesn't exist:

To remedy this, you need a shared SMTP namespace, so that messages are freely exchanged between both mail systems. The only time they get discarded will be if neither system knows whether the recipient exists:

In Office 365, you need to configure your domain.com as an internal relay domain. Per the documentation, an internal relay domain is used when:

recipients for this domain can be in Office 365 or your own email servers. Email is delivered to known recipients in Office 365 or is relayed to your own email server if the recipients aren’t known to Office 365.

You can find a detailed guide for configuring this online at the Office 365 community site. In this case, "A. Datum Corporation" refers to your Unoeuro mail system, while Office 365 is Office 365 as written.

Unoeuro will subsequently need to be configured to forward email to Office 365. This can be done in a couple of ways:

1. A central configuration on the Unoeuro mail server which directs it to pass email destined to unknown users to Office 365 for further processing. Care is required with this wildcard approach, as it means the Unoeuro server doesn't explicitly know about every user with @domain.com email addresses. When it doesn't know about an address, it must ask Office 365 for a final deliver/bounce determination, rather than making that decision locally. Therefore, care must be taken to avoid mail loops, and (for email received from external sources) NDR backscatter. I won't consider this approach further here.
2. Individual forwards on a per-mailbox basis at Unoeuro, which cause mail sent to [email protected] to be forwarded to [email protected]. domain.onmicrosoft.com is your Office 365 tenant domain, which will force delivery to the Office 365 mailbox.

The article linked above adopts approach number 2. For simplicity, I would recommend this approach, unless you have a significant number of users.

External delivery

The remaining part to discuss is external delivery of email.

Your MX record is the heart of your external email system. It instructs external mail systems what machine(s) are responsible for handling mail @domain.com. At the moment, you indicate your MX record points to Unoeuro.

At the moment, your MX situation looks like this:

Outside servers have no knowledge of your Office 365 environment. They will continue to deliver inbound email to Unoeuro's systems as present. The configuration made for internal email delivery between the two systems (above) will also apply to external email, causing that mail to be forwarded over to Office 365 for users resident there.

You may have other DNS records configured for security purposes, such as a Sender Policy Framework (SPF) record. You must ensure these records are updated to approve Office 365 as a trusted sender for mail from domain.com, otherwise your mail might be bounced. Talk to Unoeuro if you are unsure.

Should I add Office 365 as an MX record?

Maybe. You can, but it is not necessary to list both Unoeuro and Office 365. There is additional complexity to this approach, and you must take care to avoid duplicate delivery, mail loops and unknown user scenarios.

Listing both mail systems may provide higher uptime; in the event Unoeuro is down, Office 365 users can still receive mail and vice-versa.

I advise that you get this working with a single provider as the inbound MX destination initially before expanding to multiple inbound recipients.