How to migrate your domain's email without locking yourself out
Moving mail onto infrastructure you control puts your login address inside it. The loop that creates, why a second account beats a second address, and the registrar question to answer first.
A Yowl organisation has as many members as you like, each with their own independent sign-in — so the second-way-in that most of this page is about is not something you have to arrange. It is the default, it costs nothing, and nobody is billed per person for it.
Consolidating is fine. Consolidating onto one login is not
The warning below is usually written as “do not put your mail with the company that runs your DNS”, and that is the wrong lesson drawn from the right story. Spreading a domain across five providers is how the failures in the rest of this collection happen — the records nobody reconciles, the DS left behind at the registry, the migration where step one is at a company step two has never heard of. Fragmentation is not safety.
What actually bites is a single account holding the mailbox, the DNS and the only recovery path. That is a different thing, and it is fixable without scattering your infrastructure: the test is not how many companies but how many independent ways in.
So the question to ask any provider you are about to consolidate onto is a short one. Can a second human get in without me? At Yowl that is a member — their own address, their own password, their own second factor, and they can be on a domain you are not touching. Add one before the migration rather than after, and test it by signing in as them.
There is a third way in worth knowing about, and it is a new one: an agent, connected over MCP, with its own credential that is not tied to any person’s phone. It reads the mail, so “did the reset code arrive?” is answerable even from an account you are currently locked out of the web UI for. It is not a substitute for a second human, but it is a pair of eyes that does not go on holiday.
Work out what the address unlocks
Before you move a domain’s mail anywhere, work out what that domain’s address currently unlocks. For most people who own a domain it is more than they remember: the registrar, the DNS provider, the hosting account, the mail provider itself. Each of those sends its password resets and its login verification codes to an address on the domain you are about to move.
While the mail lives at Google, HEY or Fastmail, that is safe — those are companies with no relationship to your registrar. Moving the mailbox onto infrastructure you control is what closes the circle. This is written from doing it to our own company domain in September 2026, and the useful part turned out to be the survey of what each provider offers rather than the theory.
⛔ There is a second, worse way a migration locks you out, and it takes the whole domain rather than an account: a DS record left behind at the registry. Read that one first if you are about to change nameservers.
The loop
Here is the shape, with our own domain in it. The mail moves to a provider that runs on Cloudflare. Cloudflare also serves that domain’s DNS, so it decides where the MX record points. And the Cloudflare account’s login is an address on that domain.
brent@example.com → mailbox runs on Cloudflare
Cloudflare → also serves example.com's DNS
Cloudflare login → brent@example.comThree hops and it closes. Lose access to Cloudflare and you lose the mailbox that would receive the reset, and the DNS you would use to route around it.
The two failure modes are not equally serious. A forgotten password or a lost second factor is survivable — DNS keeps serving and the mailbox keeps running while you are locked out of the dashboard, so the reset mail still arrives. Suspension or termination is the one that bites, because the mailbox stops with the account.
The layer underneath
What usually makes this recoverable is the registrar. DNS and the registrar are different things, and people conflate them because one company often sells both: the registrar is where the nameserver delegation lives, a layer beneath DNS, and it can point the domain somewhere else entirely.
So the first question is not “where does my mail go”, it is: if I lost my DNS provider completely, could I still sign in to my registrar and repoint the nameservers? If the registrar also recovers through an address on the affected domain, there is no way out. If not, you have a bad afternoon rather than a lost domain. Check that before anything else — it took us ten minutes, and the answer changed how much effort the rest deserved.
A second account beats a different address
The obvious fix is to move every login to a mailbox somewhere else — a Gmail account, say. It works, and it is tedious: a dozen services, each with its own verification flow, several of which send confirmation links to both the old and the new address, so they have to be done while the old mailbox still works.
The better fix, where a service supports it, is to add a second account rather than changing the first one. A second admin user with its own password, its own second factor and its own mailbox on a domain you are not touching.
That is stronger for a reason worth spelling out: changing your login address protects you against losing a mailbox. It does nothing about losing your second factor. A second account covers both, because the second user can get in when the first one cannot, whatever the reason.
The second account has to be genuinely independent, and it has to be tested — a row in a members table is not proof of a working sign-in. Sign in as it, in a private window, before you need it. And check it is not one account wearing a disguise: a second address forwarding to the same inbox, or a second login whose authenticator lives in the same app synced to the same cloud account, is not a second way in.
Which services even offer one varies more than you would expect. Of the five we checked on our own accounts, two have no second-user concept at all — so for those, stored backup codes are the entire fallback. Count them when you save them, too: some providers display one code as several space-separated groups, which reads as several and is not.
While you are in there, read the whole members list. Ours held an admin nobody had recorded, and that cuts both ways — it might be the door that saves you, or a stale account on an address you are about to move.
Where the codes go
Backup codes are the only part of this that survives losing both a mailbox and a phone. Not in the mailbox you are migrating; not in a note on the phone that holds the authenticator, which is the same device twice. We keep ours in an age-encrypted file and read each one back after saving it, because a credential you have never decrypted is a credential you are assuming.
An order of work
Inventory what the address unlocks → check the registrar first → add and test a second user → turn on 2FA and store the codes off both the mailbox and the phone → clear DNSSEC if nameservers are changing → then move the mail.
Everything before that last step is worth doing whether or not you ever migrate. We started because of a migration and finished with a better recovery position than we had before, which suggests the migration was not really the problem.