Workstream 01
Start with a sender, recipient and domain inventory
List every verified domain, secondary SMTP alias, shared mailbox, distribution list, forwarding address and application that sends business email. Include CRM notifications, invoice systems, marketing platforms, web forms and printers. A platform migration may alter where an address exists without migrating the sender that uses it.
Trace at least one example of external-inbound mail, external-outbound mail, employee-to-employee mail, delegated replies and a system-generated message. Record the message path before changing anything so that aftercare can distinguish a new failure from a pre-existing one.
| Flow to prove | What to test | Typical hidden dependency |
|---|---|---|
| External inbound | Sender outside both tenants to moved and unmoved users | MX and recipient routing |
| External outbound | Reply and new message from both environments | SPF/DKIM/DMARC alignment |
| Shared identity | Send-as/delegation from approved employee | Mailbox rights and X500 history |
| Application mail | CRM or website notification arrives at outside recipient | SMTP credentials and third-party DNS |
| Calendar invitations | Free/busy and update to external invite | Recipient resolution and coexistence |
Workstream 02
Choose the correct coexistence model for the business
Microsoft supports a range of Exchange Online mail-flow and connector options depending on whether the source is another tenant, an on-premises Exchange estate or an external hosted system. The design must reflect who owns the accepted domain at each stage, which platform is authoritative for recipient discovery, and where undeliverable mail is reported.
A cutover can involve temporary domains, mail contacts or routing addresses, transport connectors and staged MX changes. Avoid proposing a generic forwarding chain without considering loops, spam filtering, service security and the effect on replies. A clear diagram showing current and transitional paths is a useful deliverable.
What to capture before the decision
- Confirmed control of each verified domain and registrar
- Approved transitional address/routing design
- Known source and target recipient inventory
- Time window and authority for DNS/connector edits
- Documented test for any transport loop or ambiguous alias
Workstream 03
Make authentication changes as carefully as MX changes
Every sender using the domain must be considered when SPF, DKIM and DMARC are reviewed. An MX update changes where mail is received; it does not automatically authorise outbound mail from Microsoft 365 or remove an old vendor's sending authority. A premature SPF replacement can cause invoices or contact-form messages to fail authentication.
Review the existing TXT, CNAME and MX configuration, then plan a controlled change with propagation allowances and a validation procedure. Microsoft documentation explains how SPF, DKIM and DMARC work together; approval depends on the actual combination of business senders.
Workstream 04
Acceptance and recovery after the final routing change
Use independent senders and recipients outside both tenants to prove delivery and reply routing. Exchange message trace can show whether mail was delivered, rejected or deferred; combine that technical evidence with the end user's inbox confirmation. Test priority shared mailboxes and non-human senders as separate cases.
Identify the people authorised to pause the cutover or reverse DNS changes where technically feasible. A DNS rollback does not automatically undo mailbox identity changes or a completed native migration; an agreed recovery procedure must reflect the state of each workload. Retain logs, an exception register and user communications.
What to capture before the decision
- External end-to-end mail round trips passed
- All expected aliases and shared mailboxes tested
- Application senders confirmed with their owners
- Authentication and message-trace evidence retained
- Final routing owner signs off the operating state
Coexistence succeeds when ordinary correspondence keeps working during the transition and the business can explain exactly where every important address is delivered.
Source documents and limitations
These references establish current vendor behaviour; they do not verify an individual customer's configuration or imply Microsoft affiliation. Technical claims should be rechecked before execution.