Why consolidating email after an acquisition is a regulated change, not only a migration
Consolidating two mail estates after an acquisition is a sequence of routing, identity and evidence changes, and the platform choice comes second. The acquirer ends up with two mail tenants, two domain sets and a deadline set by integration work and by controls work that cannot wait for the mailboxes to settle. Before any mailbox moves, the team has to decide which domains stay, which addresses forward where, how mail flows during coexistence, and who can prove what was sent and received at each step. Self-hosted options such as Stalwart, mailcow and OX App Suite can all carry the end state, but none of them removes that sequence.
The acquired estate matters for three reasons that a pure migration plan often misses. First, mail and calendar systems sit inside the financial reporting and IT general control environment, so the acquirer may need to show how the newly acquired business is brought under its controls and what evidence supports them. Second, the acquired business may be a source of cybersecurity incidents that must be assessed quickly, so its logs, mailbox access records and sender authentication records need to be reachable on day one. Third, if the target holds EU personal data and the acquirer's administrators or support staff are located outside the EEA, remote access to that mail is a transfer that needs a documented legal basis. Confirm these obligations with your legal, finance and data protection leads before you pick a platform.
In practice, the first deliverable is a written inventory: every domain, mail-enabled service, shared mailbox, distribution list, journaling rule and third-party sender in the acquired tenant, with an owner and a regulatory tag for each. That inventory determines the coexistence design, the cutover order and the evidence pack you keep for auditors. Ask any implementation partner to show how they will map those tags to routing rules, DNS records and retained logs before they quote a migration window.
Which regulatory requirements shape the consolidation
This table maps each regulatory requirement in the supplied facts to what it means for merging two mail estates, and says which rows apply only to certain acquirers. Read the applicability column first, because a rule that binds a listed or EU-regulated acquirer may not bind a private buyer of a non-regulated business. Confirm scope with counsel and your compliance lead before design starts.
| Requirement | What it means for the build | Applies to |
|---|---|---|
| SEC ICFR exclusion for an acquired business | Management may exclude the acquired mail and identity estate from its internal control assessment for a limited period, but not beyond one year from the acquisition date. Record the exclusion and its significance for disclosure. | SEC registrants only |
| IT general control areas (program changes, access to programs and data) | Mail routing rules, admin roles, transport rules and migration scripts that touch financial reporting risks need change records, approvals and access reviews during coexistence. | SEC registrants with financial reporting risk in mail or identity |
| Form 8-K Item 1.05 and third-party oversight | Plan an incident path for the coexistence period, because a material cybersecurity incident may require filing within four business days of materiality. Document oversight of any migration or hosting provider. | SEC registrants only |
| NIS2 contact and IP range notifications | After the merger, update the competent authority with changed entity names, contacts, IP ranges and service locations, and notify changes without delay and within two weeks at most. | Acquirers or targets in NIS2 sectors |
| DORA ICT register and exit strategy | Add the new mail platform and any migration vendor to the ICT register, and keep a tested exit and transition plan for mail if it supports a critical or important function. | EU financial entities only |
| GDPR Article 28 instructions | If an integrator or hosting provider processes EU personal data during migration, the contract must limit processing to documented instructions, including for transfers. | Any controller or processor handling EU personal data |
| GDPR Article 30 records of processing | Update records to cover the merged mailbox population, new processors and the Article 32 security measures, where possible. | Any organization subject to GDPR |
| Chapter V transfer tool for non-EEA access | If staff of a non-EEA acquirer can view EU mailboxes or admin consoles remotely, including for support, a transfer mechanism is needed before access is granted. | Only where a non-EEA acquirer or affiliate gets remote access |
| HIPAA 164.314(a) business associate flow-down | Where migrated mail carries ePHI, the business associate contract must require Security Rule compliance, flow terms to subcontractors and report security incidents. | Covered entities and business associates only |
How mail routing works while both estates are live
The first decision in the coexistence period is which domains accept mail on which platform, and that decision drives every record you change afterward. Each domain that comes across from the acquired company needs a single answer to the question of where inbound mail lands today, where it will land after cutover, and who owns the MX record during the overlap. Stage the MX changes per domain, not for the whole estate at once, so that a misconfigured domain affects one group of addresses rather than every legacy address the acquired firm has ever published. Keep the acquired tenant's inbound path intact until you have confirmed that customers, suppliers and former staff who still use old addresses reach a mailbox or a forwarding rule on the target platform.
Address aliases carry most of the risk in this phase. Acquired staff often appear in customer contracts, invoices and vendor master data under addresses that no longer match the directory, so route those addresses through aliases or catch-all rules on the surviving platform before any MX change goes live. Calendars are harder. Free/busy lookups and shared calendars do not cross two systems on their own, so ask your mail platform vendor, in writing, whether it supports cross-server free/busy through CalDAV or a similar mechanism, how directory sync from the acquired directory is scheduled and which attributes it writes back, and whether resource booking rooms can be shared during the overlap. Test a meeting invitation sent from each side to each side before any user depends on it.
Cutover order matters because mail follows DNS, and DNS follows whichever system owns the mailboxes. Move the mailboxes of the smallest and least customer-facing group first, confirm delivery and calendar behavior for a full business cycle, and only then move shared customer contacts and the domains they email most often. Plan SPF, DKIM and DMARC for each added domain before its MX record changes, because outbound mail from a domain that is partly authenticated on the wrong platform is a common cause of rejected messages. Confirm your own rollback path for each stage, including who can reverse an MX change and how long DNS caches take to clear in your environment.
Rollout phases for merging two mail estates
The sequence moves two mail estates to one target platform without losing mail, calendar data or sender reputation, and each phase closes with a record the steering group can approve before the next one starts.
Inventory both estates and domains
The acquirer's and target's mail teams, with DeployOpen as implementation partner where engaged, catalog every domain, mailbox, shared mailbox, distribution list, resource calendar, journaling rule, relay, third-party sender (marketing, ticketing, scanners, line-of-business apps) and integration that depends on mail. Include the current DNS records for each domain, the directory source, retention and legal hold obligations, and any contract terms for the acquired tenant. Output: a signed inventory and a dependency map that the steering group accepts as the migration baseline. Confirm early whether the acquired estate is hosted by a SaaS provider, since export rights and exit terms will shape the timeline.
Plan domains and addresses
Decide which domains stay, which become aliases, which are retired, and how addresses map to the surviving naming scheme, including duplicate names across the two companies. Record the decision for each domain, the owner of each mailbox, and how external senders will see the change. Where the acquired business must keep its own regulated identity, note it here so that archiving and access rules are designed with it. Output: a domain and address register approved by legal, HR and the business owners of both companies.
Build the target platform
Stand up the target mail, calendar and contact platform in the environment the combined business has approved, with directory integration, TLS, backup, monitoring and an archiving path sized to the regulated scope of both companies. Build the platform on a supported release line and record the version and support window in the design document. Output: a platform acceptance record covering functional tests, restore tests and a security review, signed by the infrastructure owner and the security lead.
Add SPF, DKIM and DMARC for added domains
Publish SPF records that cover every sending system for each added domain, generate DKIM keys on the new platform and publish them, and start DMARC in monitoring mode with aggregate reports routed to a mailbox or tool someone reviews. Keep the existing sending path working while the records are checked. Do not tighten the DMARC policy until the reports show that legitimate sources align. Output: a sender authentication register per domain and a monitoring period record, showing which senders pass, which fail and who owns each fix. Confirm the exact DNS and reporting setup with your mail platform documentation before you publish.
Migrate a pilot group of mailboxes and calendars
Move a small, representative set of users from both estates, including shared mailboxes, delegated calendars and a user with a large archive. Verify message counts, folder structure, flags, attachments, calendar invitations, free/busy visibility and mobile client access against the pre-migration inventory. Run a rollback test. Output: a pilot results report listing every discrepancy, its root cause and the fix, which the steering group reviews before wider migration. Include the user acceptance result from each pilot department.
Route mail during coexistence
Configure inbound and outbound routing so that mail for migrated and unmigrated users reaches the right system, and so that calendar free/busy works across both estates for the transition period. Document each routing rule, the sending IP or relay for each domain, and the failure behavior if one side is unavailable. Test delivery in both directions, with external test accounts, and check that bounces and non-delivery reports reach a monitored queue. Output: a signed routing design and a test log showing successful delivery in every direction.
Migrate mailboxes in waves
Migrate the remaining users in groups defined by business unit, location or dependency, starting with groups that have the fewest external integrations. Before each wave, freeze the group's changes to directory data, confirm backups, and rerun the inventory checks for that group. After each wave, verify counts, delegations, forwarding rules and mobile devices, and collect support tickets for a defined stabilization window agreed with the steering group. Output: a wave completion record per group and a final reconciliation showing that every mailbox in the inventory is accounted for.
Retire the acquired tenant after the exit check
Before the acquired tenant or server is switched off, confirm that retention obligations are met by an archive that can be searched, that legal holds are carried over, that exportable data has been retrieved under the contract, and that no system still sends or receives on the old domains. Review the records that regulators, auditors or contract terms require to be kept, and note the disposal date for each. Decommission DNS, certificates and routing entries only after the review. Output: a retirement sign-off with the archive location, the export evidence, the disposal schedule and a closed list of open items, approved by legal, compliance and the infrastructure owner.
Which open-source platforms fit a merged mail estate and why
A merged estate usually means several domains, two sets of users and a period when both systems must route mail. The platforms below differ in how they handle multi-domain hosting, how much operational work they add and how their release lifecycles affect planning, so the choice depends on the target architecture you need at the end of the transition.
Stalwart as a single mail and groupware core
Stalwart is an all-in-one server supporting IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV, licensed under AGPL-3.0 with an optional Enterprise License from Stalwart Labs. For a merger, it can host the acquirer's and target's domains on one server, which simplifies routing during coexistence. Confirm how it handles multiple domains and per-domain policies at your expected scale, which migration tools exist for the acquired tenant, and whether the Enterprise License is needed for features you require.
mailcow as a Docker-based mail stack
mailcow-dockerized is licensed under GPL-3.0 and bundles mail, webmail, calendars and contacts into a Docker Compose deployment. It suits a merged estate with a modest number of domains and a team comfortable running Docker hosts. The operational load is mainly in updates, backups and deliverability for each added domain. Confirm the domain and mailbox limits you need, how upgrades are applied between releases and how the acquired domains will be authenticated with SPF, DKIM and DMARC.
OX App Suite v8 on Kubernetes
OX App Suite v8 is designed to run on Kubernetes and is delivered as Helm charts, requiring Istio or a basic ingress-nginx option, with Redis 7.4.x and MariaDB as data stores. Persistent attachments need a distributed file system such as NFS or object storage. This fits a larger merged estate with a platform team already operating Kubernetes. Some features may carry separate fees under the license agreement, so ask for the packaged feature list in writing before committing.
Support lifecycle and release planning
Plan the coexistence window around vendor support dates, not only feature needs. OX publishes a support commitment in which standard releases are supported for 12 weeks and LTS releases until the next LTS plus six months. Stalwart and mailcow publish frequent releases, so a pinned version and a tested upgrade path matter more. Confirm the support window for the version you will deploy and the date each platform's current release train ends.
Operational load and staffing per platform
Each option moves work to a different team. A single-server mail core concentrates work in mail administration and deliverability. A Kubernetes suite adds cluster, service mesh, database and storage operations. Estimate the staffing for both the coexistence period and the steady state after the acquired tenant is retired. Ask any implementation partner to describe the on-call coverage, backup and restore tests and monitoring they will run for the combined estate.
Migration tooling and multi-domain checks
Migration is often the deciding factor. Confirm that the target platform can import mailboxes, calendars, contacts and shared folders from the acquired tenant without loss, can run both domains on one tenant during coexistence and can route mail to the acquired address space until cutover. Test a sample of mailboxes with the exact client versions your staff use, including calendar free/busy lookups across the two organizations, before approving the design.
Deployment patterns for the transition: interim, target and retirement
During the transition, both mail estates usually have to work at once. Users on the acquired side still need to send to customers, receive mail on the old domains, and see each other's free/busy time. The interim design is therefore about routing, not storage: decide which system is authoritative for each address, how inbound mail for every accepted domain reaches the right mailbox, and how the two directories stay in step. Integration points to plan for:
- Directory: a single source of truth for users, groups and aliases, usually synchronized from the acquirer's identity provider, so a person does not exist twice with two passwords.
- DNS: MX, SPF, DKIM and DMARC records for each added domain, changed in stages so that outbound mail keeps passing authentication while routing moves.
- Certificates: TLS certificates covering every hostname the clients and peer servers will use during coexistence, with a plan for the acquired estate's expiry dates.
- Archive journaling and backup: both estates journaling to the archive that the acquirer's retention policy relies on, and backups of the old estate kept until its retirement date.
- Decisions before cutover: the mail flow for each address, the calendar sharing model between estates, and who answers mail that arrives at a retired alias.
Confirm with the mail server vendor how free/busy lookups and calendar invitations behave between the two systems before users depend on them.
The target platform is where the merged organization ends up, either as one tenant with several accepted domains or as a set of domains that share one identity layer and one administrative model. This design is built for steady-state operation, so it is the point where retention, filtering and deliverability settings should be finalized rather than inherited from either legacy system. Integration points to plan for:
- Directory: one identity provider, one group model and one mailbox provisioning process, with the acquired users migrated into it rather than synchronized indefinitely.
- DNS: delegated or managed records for every domain, with DMARC reporting addresses that the security team reads, and a documented process for adding a domain later.
- Certificates: a certificate lifecycle that covers the new hostnames and the clients that pin or trust them, including mobile devices.
- Archive journaling and backup: one archive policy applied to all mailboxes, and backups tested for restore into the target, not only copied.
- Decisions before cutover: the domain list and primary sending identity, the spam and malware policy, the retention periods, and the mailbox and calendar migration waves.
Ask the implementation partner how the platform handles multiple domains and whether mailbox quotas, aliases and shared resources can be managed across them without manual per-domain work.
When the acquirer or the target is a regulated firm, a public body or an EU-controlled organization, the transition has added constraints. Retention, audit, data location and third-party oversight obligations may apply to the acquired mail estate from the day of the deal, and some of them change how the interim and target designs can be built. For example, under EDPB Guidelines 05/2021, remote access to EU personal data from a third country, including support staff access, is a transfer, so the acquirer's administrators cannot simply open the target's mail servers to their own staff. Integration points to plan for:
- Directory and access: separate administrative roles for each legal entity, with logged access to the mailbox store and written instructions for any processor that touches the data.
- Records of processing: the target's processing records updated for the merged mail flows, with the security measures described where possible.
- Archive journaling: retention rules that cover the acquired mail from its first day of routing, and no gap where one estate has no archive.
- Regulatory notices: the NIS2 authority contact details and the DORA ICT register for the acquired service, where those regimes apply, updated without delay.
- Decisions before cutover: where administrators sit, which transfer tool covers any non-EEA access, and how the exit from the acquired provider is documented.
Confirm with legal counsel which regimes apply to each entity before the design is fixed, since the answers differ by sector and jurisdiction.
Retirement is the stage most often treated as an afterthought, and it is where mail is most often lost. The acquired tenant or server should not be switched off until its mailboxes are migrated, its archive is complete and its legal and retention obligations are either met or transferred. The retirement plan should define what is kept, for how long, and where, and it should prove that the kept data can be read after the original system is gone. Integration points to plan for:
- DNS: routing records changed only after the target has accepted mail for each domain, with a rollback path and a date after which the old MX records are removed.
- Certificates and clients: devices and bridges that still reference the old hostnames found and reconfigured before shutdown.
- Archive and backup: a final archive export, backups kept for the retention period, and a restore test from those backups.
- Contract and exit: the provider's data return and deletion terms confirmed in writing, since exit obligations may apply under some regulations.
- Decisions before cutover: the retirement date for each domain, the owner of legal holds on the old data, and the evidence kept to show the tenant was closed properly.
Ask the partner to show a documented retirement checklist and a restore test of archived mail from the old estate.
Evidence auditors and regulators ask for during consolidation
This table lists the records an acquirer's auditors or regulators are likely to request when two mail estates are merged, which component or team produces each record, and what to confirm with the vendor or partner. Use it to plan evidence collection before cutover rather than reconstructing it afterward.
| Evidence item | What it shows | Produced by | Confirm before cutover |
|---|---|---|---|
| ICFR scope exclusion record | Acquired business excluded from the year's internal control assessment, with its significance disclosed | Acquirer's finance and internal audit teams, with IT input | Exclusion window and whether the mail estate is in scope for the first annual report |
| IT general control records | Approvals for program changes, operations logs and user access changes to the mail platform | Change management system and the mail platform's admin audit logs | Whether the vendor or partner can export change tickets and privileged account activity |
| Cutover and reconciliation logs | Mailbox counts, calendar and contact item counts and migration errors before and after each wave | Migration tool reports, reviewed by the implementation partner | Log format, retention period and whether reports can be signed off per wave |
| DMARC reports and DNS records | SPF, DKIM and DMARC records for each added domain and the aggregate reports showing alignment | DNS administrators and the mail server's DKIM signing component, with DMARC report processing | Exact record values, DKIM key rotation plan and report source coverage for every domain |
| DPA and transfer documentation | Documented instructions for processing acquired personal data, and Chapter V transfer tools for any third-country access | Legal and privacy teams on both sides, with the processor's instructions | Whether non-EEA acquirer staff will access EU mailboxes, and which transfer tool applies |
| Register of ICT arrangements | Entries for the acquired mail service and its providers at each consolidation level | Third-party risk or vendor management team of the regulated acquirer | Vendor details, service scope and which entries change after the merger |
| Exit and transition plans | Tested steps for leaving the acquired tenant or provider and moving services in-house | Acquirer's operations team, with the provider's export and switching terms | Export formats, notice periods and whether a tested transition rehearsal is documented |
| Mailbox access audit logs | Who opened, delegated or exported mailboxes during and after migration | Mail server logging and the SIEM or log store of the acquirer | Log retention, coverage of administrative and delegated access, and time synchronization |
| Decommissioning records | Proof that the acquired tenant, mailboxes, backups and domains were removed or archived as planned | Acquirer's IT operations, with the former provider's deletion confirmation | Which legal holds, retention rules and backup copies must survive decommissioning |
What do buyers ask about consolidating email after an acquisition?
What drives the cost of consolidating email after an acquisition?
The cost is driven by how much mail estate has to be merged, not by the mail server alone. The main drivers are the number of domains and addresses to plan, the number of mailboxes and calendars to migrate, the volume and age of archived mail that must be carried across, and the terms of the acquired tenant's contract. Some costs are one-time, such as domain planning, migration tooling, testing and cutover work. Others recur, such as licenses or support for two environments during coexistence, storage, and the archive. Ask any partner to split the quote into these components and to state who pays for each, including any licensing for the target platform and any fees the current provider charges for exporting data or ending the contract early.
How long does email consolidation take and what sets the pace?
The pace is set by the slowest dependency, not by the migration itself. Coexistence needs mail routing, SPF, DKIM and DMARC records for each added domain, and calendars need free/busy visibility across both estates before users are moved. Regulated organizations may also need to keep the acquired tenant running until retention obligations are met. Sources bearing on timing include the SEC's rule that management may exclude a newly acquired business from its internal control assessment for no more than one year from the acquisition date and no more than one annual report, which shows that finance and audit teams often set a deadline. Ask for a timeline built around these gates, and confirm it in writing before work starts, since engagements are usually fixed-scope.
What does the acquiring company have to provide for the project?
The acquirer must supply decisions and access that no implementation partner can make on its behalf. That includes the target domain and address policy, the list of users and shared mailboxes with their owners, directory and identity sources, DNS administration rights for every added domain, and sign-off on retention rules and legal holds. It also includes access to the acquired tenant during the transition, a named owner for the business decisions, and a test plan with users who will verify calendars and mail flow before cutover. Missing inputs in these areas are a common reason coexistence periods run longer than planned, so confirm the responsibilities table before signing.
Can our internal IT team consolidate email after an acquisition alone?
A capable internal team can do parts of this alone, but the work combines several specialties that rarely sit in one group. The team needs mail server administration, DNS and email authentication expertise for SPF, DKIM and DMARC, migration tooling experience, and enough capacity to run testing and cutover while handling the integration of two organizations. Deliverability problems after a domain change are hard to diagnose without that experience. A practical split is to keep ownership of identity, business decisions and the target policy in house, and to bring in a partner for planning, migration execution, hardening and documentation under a fixed written scope. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in the client's own infrastructure, and it does not issue audit reports, so evidence for auditors still comes from the client's assessors.
What happens to the acquired tenant's data and retention after cutover?
The acquired tenant's data is not retired until the organization has confirmed what must be kept and where it now lives. Retention depends on the sector. For example, a broker-dealer must preserve copies of business communications for not less than three years under SEC Rule 17a-4(b)(4), and a HIPAA covered entity must protect ePHI during transmission and keep audit controls under 45 CFR 164.312. Plan for an export of exportable mailboxes, calendars and archives into the target or a separate archive, a documented legal hold process, and a decommissioning step that is recorded as evidence. Contract terms with the current provider also matter, including notice periods and data return obligations. Ask whether the plan includes a verified export and a retention review before any account is deleted.
How are admin access and transfer rules handled when a non-EEA acquirer's staff need access to EU mail?
Remote access to EU personal data from a third country, including for support or administration, counts as a transfer under EDPB Guidelines 05/2021. If a non-EEA acquirer's staff administer or view an EU target's mail systems from outside the EEA, a Chapter V transfer tool is needed before that access starts. Under GDPR Article 28(3)(a), a processor may act only on the controller's documented instructions, including on transfers. The practical steps are to map who will have access, restrict administrator roles to the people who need them, keep logs of administrative actions, and record the arrangement in the processing documentation. Ask your counsel to confirm the transfer mechanism and do not treat technical access controls alone as a substitute.
Do cross-border acquisitions trigger extra reporting or supervision rules for mail?
Several regimes can add obligations during the transition, and they depend on the acquirer's and target's sectors. NIS2 entities must give their competent authority their name, contact details, IP ranges, sector and the Member States where they provide services, and must notify changes without delay and in any event within two weeks under Article 3(4) of Directive (EU) 2022/2555. Financial entities under DORA must keep a register of ICT service arrangements under Article 28(3), which can include the mail platform and any hosted service still in use. Confirm with counsel which of these apply to each entity before the first domain is added to a new platform, since the register and notification records should show the change.
What to ask an implementation partner before signing
Start with coexistence and routing, because it decides how long two estates run side by side. Ask the partner to write down the stages: which domains route to which mailboxes at each step, how the acquired domain's MX records change and when, how mail sent from the acquired estate is relayed during cutover, and how rollback works if a stage fails. Ask whether the plan covers calendar free/busy lookups across both estates, since a calendar that cannot see the other side causes meeting failures that users notice first. Ask which parts are fixed-scope and which are a retainer, and whether a second cutover window is priced in.
Ask how they protect sender reputation for the added domains. The partner should show the SPF, DKIM and DMARC records for each domain, state whether DKIM keys are new or reused, and explain the order in which the DMARC policy moves from monitoring to enforcement. Confirm who owns the outbound IP reputation, who watches DMARC aggregate reports during the transition, and who answers for a blocklisting. Ask them to reconcile mailbox, alias, shared mailbox and calendar counts between the two sources before any migration starts, and to show the exception list they expect to produce. The count reconciliation is one-time work, but monitoring continues for as long as both domains send mail.
On archive and retention, ask where the acquired estate's business messages are kept and who is legally responsible for them after closing. The partner should explain how existing archives are preserved, whether journaling is redirected, and how legal holds carry over. Ask for the data processing agreement and any transfer documents, and confirm which party signs them and whether a non-EEA acquirer's staff will have remote access to EU data. Finally, require a written exit plan for the acquired tenant covering data deletion, certificate and DNS cleanup, and the retention period for final exports, and confirm whether the exit plan is included in the fixed scope or sold as a separate retainer.
How DeployOpen scopes, builds and supports a mail consolidation
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source mail platforms inside the client's own infrastructure. For a merger or acquisition, that means agreeing a written scope for the domain, mailbox, routing and DNS work before any cutover, then handing over the runbooks and evidence the combined organization needs.
How we scope
- Written scope lists every domain, mailbox group, calendar and shared resource being moved or retired.
- Scope records which mail routing, coexistence and cutover steps the engagement covers and which stay with the client.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Build the target mail platform in the client's cloud account, data center or air-gapped network.
- Configure SPF, DKIM and DMARC for each added domain and test alignment before routing changes.
- Test mailbox and calendar migration in a staging run, then document results and rollback steps for cutover.
How we hand over
- Deliver architecture, DNS records, routing rules and migration logs as documentation owned by the client.
- Walk through coexistence, routing and retirement runbooks with administrators and the operations team.
- Prepare the access records and change evidence that the client's auditors and compliance teams can review.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover monitoring of DMARC reports, sender reputation and blocklist status during the transition.
- Ask for the support commitment, escalation path and upgrade approach in writing before signing.
