Usually, no. Moving a domain from one registrar to another does not automatically move or switch off your email. The trouble starts when the transfer also changes the DNS service, nameservers or mail records your email depends on.
Quick answer
Your mailbox normally keeps working because email routing is controlled by DNS records such as MX records, not by the fact that the registrar name has changed. The risk is losing or changing the DNS zone during the move.
A domain registrar, a DNS provider and an email provider can all be three different companies. That distinction is what matters here. Changing the registrar only changes who manages the domain registration. It does not, by itself, tell Microsoft 365, Google Workspace, your web host or another mail provider to stop handling your email.
Managing more than 300 domains has made me quite strict about this. Before I move a domain, I want to know exactly where its nameservers point and where its DNS zone is hosted. Email is one of those services that can look completely unrelated to a registrar transfer right up until an old DNS zone disappears.
Ask “who is hosting the DNS zone that contains my mail records?”. If that DNS service survives the transfer unchanged, the email service usually does too.
Your email address uses the domain name, but the registrar is not normally the thing delivering your mail.
Mail for you@example.com is normally directed by the domain's DNS. The most obvious records are the MX records, which tell other mail servers where to deliver incoming messages. SPF, DKIM and DMARC records also matter because they help receiving servers decide whether outgoing mail is legitimate.
If the nameservers and DNS zone stay exactly as they were, moving the registration to another registrar should not normally interrupt that setup. ICANN treats registrar transfers and nameserver changes as separate actions; its transfer guidance specifically notes that domain holders may update nameservers or the hosting IP without carrying out an inter-registrar transfer.
This is the big one. If your current registrar is also providing the authoritative DNS and removes that zone after the transfer, your MX and other mail records can disappear with it.
A new nameserver set means a different DNS zone is now authoritative. If the mail records were not copied correctly, email can fail even though the registrar transfer itself completed successfully.
If your mailbox is a paid service supplied by the registrar you are leaving, check whether that subscription continues after the domain moves. Registration and mailbox billing are separate issues.
Namecheap gives a very useful warning in its transfer documentation: the nameservers can remain unchanged after a transfer, but if the domain was using the old registrar's default DNS, that registrar may remove the DNS zone after the transfer, causing website or email downtime.
This is also why I would check whether your existing nameservers can stay in place before starting the move rather than assuming every registrar behaves the same way.
The answer depends less on the mailbox brand and more on where your DNS is hosted.
If your nameservers point to a separate DNS provider and your email is with Microsoft 365, Google Workspace or another external service, a registrar-only transfer is usually the cleanest scenario. Nothing in the mail path needs to move.
If the nameservers point to your web host and that host also manages the email records, keeping those nameservers in place will normally keep mail routing unchanged.
This needs more care. Your mailbox may be elsewhere, but the MX, SPF, DKIM and DMARC records may live in the registrar's DNS zone. If that zone disappears after transfer, the email provider cannot fix that automatically.
Check both products separately. The domain can transfer away while the mailbox subscription continues, or the provider may have terms that require action from you. Do not assume one service controls the other.
Cloudflare Registrar requires domains to use Cloudflare's authoritative DNS. A transfer to Cloudflare therefore involves moving the DNS to Cloudflare first. Cloudflare says its automatic DNS scan is not guaranteed to find every record, so I would manually compare all email records before proceeding.
If you are comparing where to move the domain, look beyond the headline transfer price. Our guide to choosing a domain registrar is useful here because DNS controls and support can matter just as much as the first-year cost.
I would rather spend five minutes checking the DNS first than discover the problem after mail has already stopped arriving.
That last point is easy to confuse with your domain email. Registrars may send transfer messages to the registrant contact address, but that contact address is not what controls delivery to mailboxes such as sales@yourdomain.co.uk.
I also prefer not to stack several changes together. If the nameservers are staying where they are, I leave them alone until the registrar transfer has completed. That makes troubleshooting much easier because only one thing has changed.
If you want to know how long the transfer itself may remain in progress, see our guide to how long a .com transfer can take. If you are still choosing where to move it, you can also compare domain transfer prices first.
The transfer mechanism for .uk-family domains is different from the standard ICANN gTLD process, but the practical email point is the same: changing registrar does not itself rewrite your MX records. You still need to know where the authoritative DNS is hosted and whether that DNS service will remain available after the move.
Do not immediately assume the mailbox has been deleted. Start with DNS.
If the DNS records are missing, recreate them at the authoritative DNS provider using the exact values from your email service. If the nameservers unexpectedly changed, correct those first and then allow time for DNS caches to update.
The important bit is to diagnose the DNS path before you start changing mailbox passwords, deleting accounts or recreating users. A registrar transfer can coincide with an email outage without the mailbox itself being the thing that failed.
My view
That is the outcome I aim for. Keep the DNS stable, know where the mail records live and verify them before you start. If the registrar move is the only thing changing, your users should not notice anything at all.
