Implementing a Split Domain Scenario
Summary
With the advent of the Exchange hosting industry, the term "Split Domain" was generated. This term signifies the method that allows companies to utilize Exchange server features as well as features from another server...such as a Linux POP3 server. The typical reasoning for a split domain is to save cost.
Please note: A split domain is VERY ill-advised as the peripheral negative impact is often more than the intended benefit.
Pros
With the ability to move the Exchange users onto another (typically free) server for email functionality, the cost savings can be a significant. For example, this allows your Executive and Sales Team to utilize the collaboration and mobile features of Exchange and place the "less critical" employees on the POP server, all while maintaining a unified user@domain.com company format for email.
Cons
There are several disadvantages to splitting a domain. It is important to know as much as possible before proceeding with a split domain scenario.
Complicated Server Management - Since there are two servers (POP3 and Exchange Server) each server will need to know about the users on the other server or inter-company communication between the employees on separate servers will be impossible. Configuring and maintaining the functionality can be difficult and laborious.
No Complete GAL (Global Address List) - Because some of the users will be on the POP3 server (server #1) and some of the users will be on the Exchange server (server #2) users will not be able to send to users on the POP server using the GAL (Global Address List). This may cause problems with the instances involving communications to the entire company, or employees not on the domain server in a Distribution List.
A Single Authority for your Domain - A domain can only be registered to one SPF record in your DNS zone. This SPF record is referenced for simple reverse DNS lookups by the recipient server to validate that the email is coming from the server that is handling the email for the domain (this is to prevent spoofing, spam, phishing). Since email coming from the server is NOT on the MX records it will look like spam. Note that SPF records are not fully supported, however it is considered a standard in Exchange server and is growing fast.
Limited Support - Because email is linear and there are so many points in the line with the new servers in the equation, it becomes very difficult to troubleshoot the original point of a problem.
Steps to Implement
Assuming that your MX records are pointing to your POP3 server...
1. Create a Primary domain at saashost.net Exchange servers (i.e. domain.com) and notify our engineer team that this domain will be part of a split domain scenario.
2. Create mailboxes on the Exchange servers.
3. Add a Domain Alias (exchange.domain.com).
4. Change the MX records for exchange.domain.com.
5. Add an SPF record to your DNS settings for the sending servers
6. Create all the mailboxes on the POP3 server.
7. Create a forwarding rule on the POP3 server for every user on the Exchange Server. i.e. forward john@domain.com to john@exchange.domain.com
