Mergers and acquisitions: consolidating email domains without an authentication gap
By Thomas · virtual CISO · August 30, 2026
In a merger or acquisition, email almost never makes it into the data room. Lawyers comb through contracts, finance teams restate the accounts, technical teams audit code and infrastructure — but nobody asks for the list of DNS zones or the state of the target's DMARC policies. Yet on closing day, the acquirer becomes responsible for an estate it never built: dozens of email domains accumulated across brands, subsidiaries and previous acquisitions, at wildly uneven levels of authentication.
The issue goes beyond technical debt. The integration period is precisely when impersonation pays best: the deal is announced publicly, addresses change, forwarding rules multiply, and every employee expects unusual messages from people they have never dealt with. Fraudsters read the business press — from their side of the fence, an acquisition announcement is an attack calendar.
This guide walks through the method for getting across the deal without opening an authentication gap: email due diligence before integration, securing the transition period, the domain consolidation strategy, DNS governance after the merger, and the fate of inherited domains that will never send again.
What an acquisition really brings: an unknown fleet of domains
On paper, the deal covers one company and its primary domain. In practice, the target arrives with an entire fleet: the commercial brand domains, the local variants of country entities (.de, .es, .co.uk), the historical domains of companies it had itself absorbed a decade earlier, the defensive names registered against typosquatting, the campaign domains created by marketing for a launch and never decommissioned, and a long tail of parked names whose origin nobody remembers.
The authentication level of that fleet is uneven without exception. A primary domain sometimes properly configured; a few p=none records published one day with nobody ever reading the reports afterwards; contradictory SPF records patched by successive vendors; DKIM selectors pointing at platforms cancelled years ago; and a majority of domains with no record at all. Worse: the lawyers' list — registered trademarks, names renewed at the registrar — only partially overlaps operational reality. DNS zones live at a second registrar, opened by a local agency, sometimes under a personal account.
The classic mistake is to deal only with the target's primary domain and discover the rest of the fleet one incident at a time. The sound approach turns the problem around: inventory first, decide afterwards.
Email due diligence: three inventories before integrating
Ideally this due diligence happens before closing, on the same footing as the security audit; failing that, it opens the first weeks of integration. It comes down to three inventories.
The first is the domain fleet itself: which names, at which registrars, under which accounts, renewed by whom and until when. The target's accounts-payable records (renewal invoices) and a registrant search usefully complete the official list — that is where the domains opened by a subsidiary or an agency tend to surface.
The second is the authentication state, domain by domain: presence and content of SPF, active DKIM selectors, DMARC record and its policy, MX, and — a telling signal — the presence of a rua address, which says whether anyone, at any point, ever looked at the reports. It all fits in a table with one column per mechanism, which becomes the risk map of the integration.
The third, and the longest, covers the target's third-party senders: CRM, billing, payroll, support, marketing platforms, line-of-business tools that send "on behalf of" its domains. The method is exactly that of the third-party sender inventory, with a difficulty specific to mergers: the ecosystem to map is known to nobody on the integration team, and the people who did know it sometimes leave the company with the deal.
One immediate reflex pays off handsomely: publishing v=DMARC1; p=none; rua=mailto:… on every target domain that has nothing. A handful of TXT records is enough for data to flow in throughout the integration — by the time consolidation decisions are made, weeks of reports will already be on hand.
The transition period: the moment of maximum exposure
The transition usually starts with a decision that looks harmless: forwarding the old company's addresses to the new ones. firstname.lastname@example.net becomes an automatic forward to firstname.lastname@example.com, often for hundreds of mailboxes at once. But classic SMTP forwarding breaks SPF: every message a third party sends to the old address and that gets relayed onward fails the check on arrival, because the forwarding server's IP is not in the original sender's SPF record. DKIM survives as long as the content is untouched, and ARC helps at the major providers, but a massive stream of forwards mechanically degrades alignment, pollutes the reports of both fleets with false positives — and loses the messages of senders at p=reject whose DKIM signature does not hold up.
The second risk is more serious: opportunistic spoofing. A merger announcement is public by construction — press release, trade press, legal registries. The most profitable scenario is bank-detail fraud: an invoice reading "following our merger, our banking details have changed," sent to the suppliers and customers of both entities from a spoofed or lookalike domain. Conditions are ideal: everyone expects change, validation circuits are in disarray, counterparts do not know each other yet. A target domain left at p=none during that window is an open door, at the worst possible moment.
The third risk is silent: diluted responsibility. Two IT teams coexist, scopes overlap, and the aggregate reports go months without a designated reader. The countermeasure fits in one decision: appointing, from signature day, a single owner for email authentication across both fleets, with all reports gathered in one place.
The consolidation strategy: which domain survives
The first structural decision is the surviving domain — most often the acquirer's, sometimes the target's when its commercial brand is kept. When the brand must survive without its domain, a transition subdomain of the surviving domain (brand.example.com) offers a clean path: the visible identity is preserved, authentication sits under the group's organizational policy, and there is only one fleet left to govern. Then comes the calendar, in three phases.
Dual life. Both domains send in parallel while mailboxes and tools migrate, under report surveillance. This is the phase where application flows — billing, CRM, notifications, payroll — switch over to the surviving domain one at a time, with the same mechanics as a mailbox-provider migration: source by source, never as a big bang.
The sending freeze. From a date announced internally, no legitimate mail leaves the old domain anymore. The reports then serve as evidence: a few weeks of zero legitimate volume confirm the freeze is effective and no forgotten flow remains. The DMARCbis test mode (t=y, successor to the pct tag removed from the standard) allows the policy to be hardened while observing the effect before making it final.
The lockdown. The old domain's SPF shrinks to v=spf1 -all, the policy moves to p=reject, completed on the organizational domain by sp=reject and by the DMARCbis np= tag, which covers non-existent subdomains — precious on a domain whose historical tree is no longer under control. Reception, meanwhile, can continue: keeping the MX records for years so that no message addressed to the old mailboxes is lost is perfectly compatible with rejecting spoofed outbound mail.
Governance: who owns the DNS after the merger
The question sounds administrative; it is structural. As long as the target's DNS zones stay at their historical registrar, under the accounts of its former vendors, every authentication record can be modified outside any control. The governance work fits in five points: consolidating registrar accounts under the governing entity; revoking access for agencies, vendors and employees who left with the deal; putting zones under change control, ideally as infrastructure-as-code; naming an owner for each domain; and centralizing all report reception in a single multi-domain tool.
The target model is that of governing a multi-brand domain portfolio: central policy, delegated execution, and no authentication record modified outside the circuit. The months after a merger are exactly when a forgotten vendor patches an SPF record "the way it used to be" and breaks alignment without anyone understanding where the incident came from — an up-to-date record of who owns what is the only antidote.
The fate of dormant inherited domains
Once consolidation is done, the long tail remains: abandoned brands, the names of companies absorbed over the years, kept for intellectual-property reasons or out of plain caution. These domains will never send a legitimate email again — yet each one remains a spoofable identity, carrying the history and credibility of a real brand.
The treatment is standard and detailed in protecting parked domains: SPF reduced to v=spf1 -all, a p=reject policy — with a rua address, to watch spoofing attempts keep failing —, and a null MX (RFC 7505) if the domain no longer receives anything. Two rituals complete the setup: at every renewal, checking that the lockdown is still in place; and before any planned abandonment, remembering that an expired domain can be bought — it would then come back to life, with twenty years of brand history, in a stranger's hands.
In summary
A merger or acquisition always brings a fleet of domains that is larger, older and worse authenticated than expected. The method fits in five steps: inventory — domains, policies, the target's third-party senders — before or right at closing; publish p=none and reporting addresses wherever nothing exists; cross the transition knowing that mass forwarding degrades SPF and that the public announcement attracts fraud; consolidate in phases — dual life, sending freeze, lockdown at p=reject; then govern the unified DNS as an asset, all the way down to dormant domains reduced to v=spf1 -all.
The first step requires neither budget nor access: running every domain in the fleet — the acquirer's as well as the target's — through a free DMARC analysis yields the map of authentication gaps in seconds. To then track dozens of domains through the integration and document the climb to p=reject, opening an account centralizes reports, alerts and history — the natural tooling for a consolidation that leaves no domain behind.
Related guides
- Inventorying a domain's third-party senders: the map before DMARC
No DMARC project survives a forgotten third-party sender. Which families to hunt, three sources of truth, and how to map them all before p=reject.
- Multi-brand, multi-domain: DMARC governance at scale
Thirty brands, two hundred domains: DMARC becomes governance. Fleet typology, central registry, industrialized DNS and a p=reject rollout in waves.
- The domain is being spoofed: incident response, step by step
Complaints, surging RUA reports, waves of bounce-backs: how a domain spoofing incident is recognized, measured and resolved, all the way to p=reject.
About the author
Thomas — Thomas is the virtual CISO of DMARC.com: a copilot specialized in email authentication that walks organizations from p=none to p=reject without breaking their mail. His guides draw on real data from the DMARC Observatory and the RUA reports the platform analyzes.