Email on a Moving Domain: Keeping the Mailbox Alive

Of everything attached to a domain name, the mailbox is the component with the worst failure characteristics. A broken website announces itself: somebody calls, or you load the page yourself and see the problem. A broken mailbox produces silence on your side and a bounce message on the sender's, and by the time the silence registers as unusual you have lost a fortnight of enquiries.

This card is about what actually breaks mail when a domain changes hands, and the order that avoids it.

What a transfer does to your mail: nothing

Start with the reassuring half. Transferring a registration from one registrar to another changes which company holds the record. It does not change your nameservers, it does not edit a single DNS record, and it does not touch your mailbox.

Mail keeps flowing through a registrar transfer because mail routing lives in the zone, not in the registration. People brace for a transfer and then break their mail during the DNS change afterwards, which is a different operation entirely.

What a delegation change does to your mail: everything

Changing nameservers is the dangerous one, and it is dangerous in a specific and avoidable way.

Delegating a domain to a new DNS provider means that from that moment, every question about your domain is answered by the new provider's zone. Any record that is not present in that zone does not exist. Not "falls back to the old one" — does not exist.

So if the new zone has web records and no MX records, your website works and your mail stops. The site coming up is what people check, so the change looks successful. Mail failure surfaces days later, when somebody mentions they did not get a reply.

The defence is unglamorous: write down every record before you change anything. MX with priorities, every TXT record used for mail authentication, any CNAME a mail provider asked for, and anything else in the zone you do not recognise. Recreate the lot at the destination, verify it is being served correctly, and only then change the nameservers at the registrar.

What a plan cancellation does to your mail

This is the third scenario and the one that catches people who did everything else right.

If your DNS zone is hosted by the website builder — which is what happens when you delegate to them — then the zone lives inside an account. Close the account and the zone eventually goes with it. At that point the nameservers stop answering for your domain, and mail stops being delivered because nothing can find the mail servers any more. Your mailbox is fine. It is simply unreachable.

Separately, if the mailbox itself was bought through the builder, cancelling can end that subscription too, and that failure is final rather than a routing problem. Wix's documentation on business email is explicit that once the subscription expires you can no longer read, receive or send mail from the account. There is a recovery window governed by the mail provider's own retention terms, but it is a courtesy rather than a guarantee.

The notice periods nobody reads

Two timing details are worth knowing before you start.

Providers generally attempt renewal payment before the expiry date rather than on it — Wix's help centre says it tries up to thirty days ahead of a business email plan's expiry. So a cancellation made "before the renewal date" may be after the charge has already been attempted.

And the notices that would warn you go to the contact address on file, which in the worst case is an address on the very mailbox that is about to stop working. Point billing notifications at an address on a different domain, preferably one you cannot break by accident.

Splitting the mailbox out permanently

The structural fix is to stop having this problem. Buy the mailbox directly from the company that operates it rather than through the builder, so that the mail account is yours, the billing relationship is yours, and no decision about your website can reach it.

That turns a change of platform into a change of one or two DNS records, with the MX records untouched throughout. The reasoning and the alternatives are set out on business email with a website builder, and the choice of who holds your zone in the first place is covered in who controls your DNS zone.

The order that keeps mail up

1. Record the full zone: every MX with its priority, every mail-authentication TXT record, every CNAME a mail provider asked you to add.
2. Confirm where the mailbox subscription is billed and when it renews. If it is billed through a platform you are leaving, buy a replacement directly before you cancel anything.
3. If you are transferring the registration, do that first. It touches no records and gets the slowest step out of the way.
4. If the zone is moving, build the whole zone at the new host and verify it answers correctly while the old nameservers are still live.
5. Change the nameservers once. Watch for mail arriving before you believe it worked — send a message to the address from an outside account and confirm it lands.
6. Leave the old plan running for a month afterwards as insurance.
7. Cancel only after mail has been observed flowing through the new arrangement for several days.

How to tell it is broken

Do not rely on noticing an absence. Check positively.

Send a message from an account on a completely different provider to each address on the domain and confirm arrival. Send one out from each address and check the reply-to. If you use mail authentication, verify the records resolve from a machine that is not yours.

And do the checks on a weekday. A quiet Sunday inbox proves nothing at all, which is precisely why so many people conclude everything is fine.

If you are still at the point of choosing a provider, whether the mailbox is bundled with the plan is one of the things worth weighing alongside the registration terms — all of which are set out on free domain website builder plans.