M&A Email Integration
Consolidating domains post-acquisition without dropping a single message.
Overview
M&A email integration is where everything you know about DNS, authentication, and routing gets tested simultaneously, under time pressure, on an environment you may never have seen before. Answer the five questions below with the operational thoroughness of an administrator who has to get this right the first time.
Read before you answer
Email integration during mergers and acquisitions is one of the highest-risk operational tasks an email administrator faces. The combination of time pressure (business leadership wants integration completed before the deal is fully understood), technical complexity (the acquired company's mail environment is typically unknown until due diligence), and disruption risk (a misconfigured cutover can result in lost mail or broken authentication for thousands of users) makes M&A integration a genuine test of email infrastructure expertise. The first step is always discovery: mapping the acquired organisation's email architecture — what mail systems they run, what domains they own, how authentication is configured, what third-party sending services are in use, and where their MX records currently point.
Coexistence strategies allow the acquired organisation's mail to continue functioning independently while integration work proceeds, typically via cross-forest trust or SMTP relay between the two organisations' mail systems. This avoids the big-bang cutover risk but introduces complexity: addresses from both organisations must be resolvable for internal mail routing, calendar and free/busy lookups must work across both systems, and SMTP relay between systems must be properly authenticated to prevent open relay conditions. The technical mechanisms include: adding the acquired domain as an accepted domain in the parent organisation's Exchange environment; configuring an inbound connector to route mail for the acquired domain to the acquired organisation's mail servers; and eventually migrating mailboxes and pointing MX records at the parent's gateway.
DNS cutover planning for an acquired domain follows the same TTL-reduction discipline as any MX change, but with added complexity: the acquiring organisation must ensure their gateway is fully configured to accept and route mail for the new domain before the MX record change takes effect. The checklist before cutover includes: gateway accepted domain configured; MX records lowered to short TTL (300–900 seconds) 24–48 hours prior; SPF record for the acquired domain updated to authorise the parent's sending infrastructure; DKIM signing configured for the domain on the parent's gateway; DMARC record updated to report to the parent's reporting address; inbound routing rule in the gateway directing mail to the correct Exchange tenant; Exchange accepted domain and routing configured; and a rollback plan (the old MX record value) available if delivery problems are detected after cutover.