The migration inventory must include machines, not only people
Mailbox projects usually begin with users, aliases and shared mailboxes because those objects are visible in the administration console. The highest-risk failures often come from systems that never appear in that list: multifunction printers, monitoring appliances, website forms, ERP jobs, payroll systems, security devices and old scripts. Some send rarely enough that nobody remembers them until the new provider rejects their authentication.
Use multiple evidence sources because none is complete
Public SPF records can reveal authorized providers, DNS aliases can expose vendor infrastructure, application configuration can reveal SMTP hostnames, and message headers or DMARC aggregate reports can reveal real sending sources. Each source has blind spots. A stale SPF include can suggest a service that is no longer active, while a device using an IP relay may not appear under an obvious vendor name. Build an evidence-backed dependency list rather than assuming one scanner is authoritative.
Classify dependencies by authentication method
Separate modern API or OAuth-based senders from SMTP AUTH, unauthenticated trusted relay, IP allowlisting and provider-specific connector paths. This tells you which systems can move by changing credentials and which require an architectural replacement. Pay special attention to legacy AUTH LOGIN or AUTH PLAIN dependencies when a provider is tightening basic-authentication support; a working path today can still be a scheduled migration risk.
Map business criticality and frequency
A system that sends password resets every minute is easy to notice during testing, while a compliance report sent once per quarter can be missed for months. Record owner, business purpose, expected frequency, From identity, envelope sender, relay and recovery path for every dependency. That turns a technical inventory into a cutover plan with priorities and acceptance tests.
Model the target state before disabling the source path
For each dependency, define the replacement endpoint, authentication method, sender identity and DNS requirements. Simulate SPF and DMARC consequences when a new provider is added. Where possible, validate the target path in parallel before changing MX or disabling legacy credentials. Parallel verification reduces the number of unknowns attached to the final cutover window.
Retire authorization only after evidence shows the dependency moved
Leaving old SPF includes, DKIM selectors or relay permissions indefinitely creates authorization debt, but removing them too early can interrupt a forgotten sender. Use post-migration message evidence and report telemetry to confirm that traffic has moved, then remove obsolete credentials and DNS authorization in a controlled cleanup. Mailybox’s Dependency Discovery tool focuses on public and supplied evidence without requiring mailbox access, making it useful at the first inventory stage.
Verify the evidence
Use the live analysis that matches this workflow instead of relying on a generic status check.
- Email Provider Detector
- Email Migration Risk Simulator
- Email Dependency Discovery
- Email DNS Drift Analyzer