Split Domain | Zimbra

In a traditional email system, we used to have an on-premises-based email server that is responsible for all user’s email accounts and also responsible for the email sending/receiving process.

Take a look at the image:

In this system,

• A server(mail.example.com) is listed as the MX record for the domain(example.com). Therefore, it will receive all emails destined to the domain(example.com).
• The server(mail.example.com) is also listed in the SPF/TXT record as a designated sender for the domain(example.com)

When is worth using Split Domain?

Now let’s consider the below-mentioned scenarios and imagine their solutions:

During the user migration phase

You have an on-premises-based email server. Now you need to migrate users from one system to another without interrupting the service. Also, you have to move them gradually over time. That means you will have two email systems with the same domain. As the users will be migrated from one to another gradually, both systems will be full-fledged email systems that store different users’ mailboxes.

Coexisting two email environments for a single domain

You have an on-premises Zimbra-based email system. But your management asked you for a solution where some of your users will have their mailboxes hosted on another system. Like a hybrid environment.

In both of the scenarios, you can implement the split domain technique which we often call a hybrid email system. The Split Domain technique is particularly useful in cases where you plan to migrate users to a Zimbra Environment over a period of time, instead of all at once, so you will migrate partial number of users to the new environment, leaving the others on the old one.

Another possibility is when you merge two businesses, but at least initially, you need to maintain two separate mail systems. This technique is typically used for smtp flow. For imap and pop webmail, on the other hand, specific arrangements must be made. With Zimbra as primary, for example, for pop and imap you can use Zimbra proxies as an access point

The Split Domain technique allows to share an email domain between two distinct email systems.

Key points to consider during the implementation of split domain:

1. Which system will be the primary System (MX Record)
2. What will be the structure of the SPF/TXT record?
3. How to manage the communication between two systems?

In the following article we’ll see how to configure the Zimbra environment both as primary or as secondary and how in both cases the mail flow is managed.

Please note that mail should be sent from a single server/multiple server with SPF and reverse correctly configured

In both scenarios, you can set one server primary and another one secondary. If you set zimbra server as primary, you will get some advantages like, inbound email prescreening,outbound smart host for secondary server. Also, if you set zimbra as primary server and your secondary server goes down, all email destined for secondary server will not bounce and will be waiting at zimbra server's mail queue as per configured policy.

The primary server must be;

1. be aware of, and accept mail for, all accounts on the domain
2. reject on RCPT TO: those accounts that do not exist in either system
3. forward mail to the secondary MTA for users hosted there.

The secondary server must be;

1. accept mail for any account allegedly on the domain
2. forward mail for all accounts on the domain that are not hosted on the secondary system to the primary MTA

A Split Domain Example

We would like to show you how to configure Zimbra, as a Primary or Secondary system, working on the following sample scenario:

• Your domain: example.com
• You have an existing mail infrastructure on mail.example.com
• The domain has MX records that point to mail.example.com
• You have users “usr@example.com” and “smpl@example.com” that exist on the old system
• On host zimbra.example.com you installed Zimbra, creating also the domain example.com on it
• The mailbox of user “usr@example.com” has been migrated to the Zimbra system

Zimbra as the Primary System

In this case, the MX record will be set so that the mail flow is routed to Zimbra, it will be authoritative for the domain so we need to create all the domain addresses, for all the ones that live on the secondary.

Let’s go with the below mentioned example:

user@example.com is at migrated zimbra so nothing needed for this account. But smpl@example.com still resides at OLD/Secondary system (mail.example.com) so when zimbra as an active server receives email for smpl@example.com it should forward the email to OLD/Secondary server.

To do this execute below command on primary server(zimbra.example.com)

$ zmprov ca smpl@exmaple.com <Password>
$ zmprov ModifyAccount smpl@example.com zimbraMailTransport smtp:mail.example.com:25

Now, when user smpl@example.com is migrated completely to new/Primary server (zimbra.example.com), you should execute below mentioned commands:

$ zmprov ModifyAccount smpl@example.com zimbraMailTransport lmtp:zimbra.example.com:7025

What this commands will do is, it will stop forwarding emails to secondary server (mail.example.com). As this email completely resides on primary server (zimbra.example.com), the primary server will deliver all emails locally to the destined email account (smpl@example.com).

Zimbra as the Secondary System

This second scenario, sees Zimbra as a secondary system. In this case, the secondary system must accept mail for accounts that are hosted by it, but must also forward the rest of the mail for accounts on this domain to the primary system. To perform this process, you need to run the following commands:

$ zmprov modifyDomain example.com zimbraMailCatchAllAddress @example.com
$ zmprov modifyDomain example.com zimbraMailCatchAllForwardingAddress @example.com
$ zmprov modifyDomain example.com zimbraMailTransport smtp:mail.example.com

The first two commands (in combination) tell the Zimbra postfix to accept all addresses in the @example.com domain as valid addresses. The third one, instead, is going to establish default mail routing for the domain. Any address that do not exist on the Zimbra system will have their mail routed according to this rule.

Another suggestion, is to turn off DNS lookups and internet wide message routing from the secondary host in case of a secondary Zimbra System, routing all mail through the primary. To do that you can use the following commands:

$ zmprov modifyConfig zimbraMtaRelayHost mail.example.com
$ zmprov modifyConfig zimbraMtaDnsLookupsEnabled FALSE

Be sure, then, to configure “mail.example.com” to accept mail forwarded by “zimbra.example.com” and to forward mail to “zimbra.example.com” for accounts hosted on Zimbra.

When you finish, restart MTA:

$ zmmtactl restart

Please note that Global Address List will contain only Zimbra users. To have all addresses, configure, if possible, GAL to use an external LDAP.

SPLIT DNS

In the case of Zimbra installations behind a firewall or NAT router, you often find yourself needing to create a Split DNS.
This is a DNS installation where machines receive different IP address responses to queries depending on whether they are inside or outside a firewall, and an IP address response from the DNS server gives a private network IP address that is different from the public IP of your internet connection.

This occurs because of the Postfix mail system used by Zimbra, which performs a DNS MX lookup for the Zimbra server followed by a DNS A lookup when attempting to route email to the back-end message store. Here, the scenarios are varied. For example, the DNS server may return the external address of the mail host instead of the internal address. Another possibility, depending on how your firewall and network are configured, is that the external address may not even be reachable by the mail host, and so this will not be delivered.
Split DNS is used to overcome this type of problem. It provides an internal DNS server that can be used to resolve the internal address of the server.

That’s all for today.