What this analysis does
Select the real dependencies in the environment — legacy SMTP, forwarding, aliases, shared mailboxes and application senders — and Mailybox produces a risk-weighted cutover checklist.
Mailbox migrations fail on the dependencies nobody listed. The mailboxes usually move correctly; what breaks is the application that relayed through the old server, the authentication path that was never reconfigured, and the transport policy that still names the previous provider.
The dependencies that are missed most often
Applications relaying through the old infrastructure are the largest category — monitoring systems, backup jobs, invoicing platforms, ticketing tools and devices such as scanners configured years ago by someone who has since left. None appear in a mailbox inventory, and each stops silently at cutover.
Authentication is the second category. SPF, DKIM selectors and any custom bounce domain all need to be established for the new platform before the routing change, not after. Publishing them afterwards leaves a window where mail sends but fails authentication.
- Relay dependencies are invisible in a mailbox inventory.
- New authentication paths must be published before the routing change.
- Transport policy naming the old provider will refuse the new exchangers.
Sequence the change to keep it reversible
The safe order publishes new authentication first, verifies it with real messages, then changes routing, and only afterwards removes the old authorization. Removing the previous SPF include or DKIM selector at the same moment as the cutover eliminates the ability to fall back cleanly.
TTL reduction belongs at the start of that sequence, far enough ahead for the previous TTL to expire. Lowering TTLs on the day of the migration provides none of the intended benefit, because the old long-lived values are already cached.
Plan the coexistence period deliberately
Most migrations run both platforms simultaneously for a period, and that interval carries its own risks: split routing where some recipients reach one system and some the other, duplicate delivery, and calendar or free-busy lookups that resolve inconsistently.
Decide in advance which system is authoritative for each function during coexistence, and how long the period will last. An open-ended coexistence tends to become permanent, leaving a domain with two half-configured platforms and an authentication posture that reflects neither.
Read the migration risk guideUpdate transport policy for the new exchangers
Example: an application that stops silently
Evidence supplied
A cutover plan covering mailbox migration and MX change, with no inventory of systems relaying through the existing server.
How to read the result
The simulation identifies relay dependency as an unmitigated risk and explains that applications authenticating against the old host will fail at cutover without generating user-visible bounces, because the failures surface in application logs rather than in mailboxes.
Known limits
- Risk modelling reflects the scenario you describe; undocumented dependencies remain undocumented.
- Provider-specific migration behaviour varies and changes over time.
- A clean model does not substitute for a tested rollback plan.
Common questions
What should be done first?
Discovery. Inventory every system that sends or relays mail before scheduling any DNS change.
How long should TTLs be lowered in advance?
At least the current TTL of the records being changed, so the previous cached values have expired before the change is published.
When should the old authorization be removed?
After the new path is verified with real messages, not at the moment of cutover. Keeping it briefly preserves the ability to fall back.