The risk after an acquisition is not the well-known primary domain. It is the side domains, marketing campaign domains, and defensive registrations. The 30-day playbook: inventory everything, set unused domains to hard reject plus null SPF, and monitor what remains.
The typical M&A integration tracker has a row for HRIS, one for IAM, one for collaboration tooling, one for source code and CI, and one for cloud infrastructure. We rarely see a row for email authentication posture across every acquired domain until after an incident.
The pattern is predictable: company A acquires company B. A few weeks after announcement, attackers register a lookalike, or more commonly find a forgotten side domain of company B: a marketing campaign domain, a defensive registration, or a product-launch domain nobody told security about. Then they send fraudulent invoices to company B's customers and suppliers, timed around the confusion of the ownership change.
What you inherit
A medium-sized company typically brings more domains than the deal team expects:
- One primary domain, usually the one on the website.
- Three to eight operational domains, such as support, help, product, international, or legacy mail domains.
- Five to 25 defensive registrations, including typo variants and country-code variants.
- Five to 50 marketing campaign domains, often created for one-off launches and events.
The primary domain is often already at p=reject. Everything else is commonly at p=none or has no DMARC record. Defensive registrations frequently have no useful DNS at all and still resolve to a parking page.
Each one is a usable platform for spoofing.
The 30-day playbook
We have seen this compress cleanly into four weeks.
Week 1: inventory
Get the complete list of every domain the acquired company owns, registered, or has DNS authority over. The best sources, in decreasing order of completeness:
- The acquired company's registrar accounts. There are often multiple.
- DNS zone exports.
- Internal trademark or IP registers, usually held by legal.
- Marketing CMS and ESP records used as From domains.
- Subdomain enumeration on the primary domain.
- Current DNS status: active, parked, or NXDOMAIN.
- Current SPF, DKIM, and DMARC posture.
- Last-known business purpose.
- Named owner in the combined organization.
Week 2: categorize and triage
Each domain falls into one of three buckets.
Live and sending. If it already enforces DMARC, inherit the posture and monitor it. If it does not, treat it as a new onboarding and run the five-week ramp in parallel, compressed where the integration timeline requires it.
Parked but kept. These are domains the business wants to keep registered for trademark protection, future use, or brand defense. They should receive deny-all email authentication immediately.
Decommission. These have no current use and no future use. Put them into a tracked path to let registration lapse.
Week 3: lock the parked domains
For every parked-but-kept domain, publish records like these:
@ IN TXT "v=spf1 -all"
*._domainkey IN TXT "v=DKIM1; p="
_dmarc IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:r-...@dmarcify.dev; fo=1; aspf=s; adkim=s"
@ IN MX 0 "."The SPF -all says no IP is authorized to send for the domain. The empty DKIM record at the wildcard selector revokes any DKIM signature. The DMARC record tells receivers to reject mail claiming to be from the domain or its subdomains. The null MX tells senders the domain does not accept mail.
For a parked domain, the worst case of p=reject is that a domain that was not sending mail continues not sending mail. That is the point.
Week 4: monitor and finalize
Even with lockdown records published, send every parked domain's aggregate reports to the same reporting destination you use for active domains. You want to see attempts. They will come.
For active senders, by the end of week four you should have:
- A unified reporting view that includes every inherited domain.
- Owner assignments for each live domain.
- An incident path for unknown senders appearing in reports.
What we see in the wild
In one acquisition, a defensive registration that had not sent mail in six years started being spoofed within 72 hours of the M&A announcement. The attacker sent invoices to the acquired company's German distributors with new post-merger banking details. Reporting caught the spike, the customer published lockdown records that afternoon, and the campaign stopped within hours.
Where integration teams push back
We cannot change DNS yet because registrar consolidation is not finished. You do not need registrar consolidation. You need DNS authority over the zone, which is usually available via existing registrar credentials shortly after close. Push DMARC records as a pre-consolidation step.
We do not want to break anything by setting p=reject on a domain we do not fully understand. That is the right instinct for a live-sending domain. It is the wrong default for a parked domain. Parked domains should be explicitly non-sending.
Where DMARCify fits
Bulk onboarding inherited domains is something we tuned for specifically. DMARCify supports multi-domain import, staged lockdown records across many domains, and reporting views that group domains by acquired company so the integration team does not have to inspect 40 domains one by one.
The bigger point: if the integration budget is already going to be spent, spend it in the first 30 days. Day 90 is too late.