If your aliases are on a domain you own, migration is a DNS change and nothing else moves. The addresses stay identical, so no account anywhere needs updating. If they're on the provider's domain, there is no migration — only a re-addressing project across every account you own, one settings page at a time. Which of those you're facing was decided when you chose the service, not today.
Case 1 — Your own domain
The easy one. Your addresses are shop@yourdomain.com and they remain shop@yourdomain.com; only the routing behind them changes.
- Set up the new service and add your domain to it, but don't switch DNS yet.
- Recreate anything explicit. On a catch-all setup there may be nothing to move — but any disabled aliases must be recreated as disabled, or the new catch-all will happily start accepting mail for addresses you deliberately switched off.
- Set the forwarding destination on the new service.
- Lower your MX TTL a day ahead if you can, so the cutover propagates quickly.
- Switch the MX records to the new service. Update SPF/DKIM/DMARC as it instructs.
- Test before decommissioning — send to an existing alias and a brand-new one, and confirm both arrive.
- Keep the old service running for a week. DNS propagation isn't instant and mail in flight has to land somewhere.
Disabled aliases. They're invisible — no mail arrives from them, so they don't come to mind during a migration. Move to a fresh catch-all without recreating them and every sender you cut off starts getting through again, silently. Export the disabled list first. Why disabled state matters on catch-all
Case 2 — The provider's domain
There's no migration available, because you can't take @duck.com or @mozmail.com with you. Every address has to be replaced at every service that uses it:
- Log into each account.
- Change the email address.
- Confirm via a link sent to the new address.
- For anything you can't log into, run a password reset — which goes to the old address, so keep the old service alive throughout.
- For anything where that also fails, open a support ticket.
For a few dozen addresses that's an afternoon. For a few hundred, attached to banks and utilities, it's a project measured in weeks — and any account you can't recover is a permanent loss.
Making it survivable
- Audit first. Know what depends on the old addresses before touching anything. How
- Migrate to your own domain, not to another provider domain. Otherwise you'll be doing this again.
- Critical accounts first — bank, government, insurance, email recovery.
- Let the long tail move opportunistically, as services email you.
- Never close the old account until you're confident. Leave it forwarding indefinitely if you can.
The lesson worth extracting
The difference between a ten-minute DNS change and a three-week project isn't the service you're leaving or the one you're joining — it's whose domain the addresses sit on, decided when you started.
If you're currently on a provider domain and this article is uncomfortable reading, that's the argument for moving to your own domain now, while the number of accounts is smaller than it will ever be again. The full case
More: custom domain vs provider domain · every service compared