We need to move a domain between Microsoft 365 tenants, and there may be a period when the recipients do not exist in either tenant. Delayed delivery is fine, but I want to avoid permanent rejections. Is there a service that can hold mail until the new tenant is ready?
How can I queue mail during a Microsoft 365 tenant migration?
Asked by
m814!clamp_7
Answers
Look for a hosted mail gateway with a hold and release feature. Services mentioned for this kind of job include DuoCircle, Mimecast, AppRiver, SpamHero, Securence, and MailRoute. Check the current product details with the provider rather than assuming their normal outage queue can be paused manually.
Before changing MX, confirm how the service handles recipient validation, how long it retains messages, and whether you can direct the released queue to the new tenant. Let the MX change propagate before starting the domain move, then test delivery after the new tenant and recipients are ready.
Reply to this answer
A temporary SMTP relay could do this too, if you are comfortable operating one. It needs to accept mail into durable storage before acknowledging it, hold delivery during the move, and then forward to the new tenant.
Plan recipient validation rather than blindly accepting every address. A catch-all can accept messages for nonexistent users and create backscatter when those messages later bounce. You will also need to monitor queue capacity and test the release process.
Reply to this answer
Sender-side retries can help, but only for temporary failures. If the old or new tenant responds that a recipient does not exist, that can be a permanent rejection and the sender may not retry. An online server with missing recipients is not the same thing as an unavailable server.
Some senders may queue mail for days when delivery fails temporarily, but retry periods vary. Pointing MX at an unavailable or unresolvable host relies on those senders and their handling of the failure, so I would not treat it as a guaranteed hold service.
m814!clamp_7:
That distinction is the concern. There may be a gap between removing the domain from the old tenant and being able to assign it in the new one.
Reply to this answer
Check mail paths beyond the public MX record. Messages sent through Microsoft 365 or an existing direct relay may not take the same route as external mail, so a gateway in front of MX may not protect every flow.
Map those routes and test them as part of the cutover plan. You may need a separate relay or connector arrangement for traffic that bypasses the public gateway.
Reply to this answer
Lowering the MX TTL ahead of time is useful for the cutover, but it does not solve the missing recipient problem by itself. You can prepare the new tenant where possible, then allow time for the domain move and address assignment before releasing queued mail.
Reply to this answer
Add your answer
Answers are reviewed before publication.
n4~turnsignal_306:
Also check what happens if the gateway can still reach Microsoft 365 but gets a permanent recipient rejection. That is different from the destination server being offline.