Leaving Squarespace, Part 5: Domains, DNS, and Not Breaking Email

Part 5 of 6.

The two things everyone thinks are one thing

A domain name feels like a single object you own. It isn’t. It’s two separate things wearing the same name, and the whole of this part hinges on telling them apart.

The first is the registration: the record at a registrar that says this name is yours, renews on this date, and bills this card. The second is DNS: the set of records that answer the question “when someone types this name, where do they actually go?” A record for the website, MX records for email, a handful of others for services you forgot you signed up for.

You can move these two things independently, and in a sane migration you should. I moved DNS first, weeks before I touched the registration. That ordering isn’t an accident, and it’s the single most important decision in this whole part.

Move DNS first, and nothing goes dark

Here’s why the ordering matters. If you point your website at a new host but leave DNS at the old provider, you’re still depending on the thing you’re trying to leave. And if you try to do everything at once, transferring the registration and moving DNS and repointing the site in one motion, you’ve got three moving parts failing together with no way to tell which one broke.

So I moved DNS to Cloudflare first, one domain at a time. Cloudflare scans your existing records, you import them, you change the nameservers at the registrar to point at Cloudflare, and you wait for that to propagate. Nothing about the site or email changes in that step. You’ve just moved who answers the questions, not the answers themselves. Once DNS was stable on Cloudflare and the site was serving correctly, the registration transfer became a boring afterthought instead of a high-wire act.

That’s the general lesson: decouple the risky steps and do them one at a time. A migration that fails in three places at once is unrecoverable. A migration that fails in one place, while the other two are already proven stable, is just a Tuesday.

The apex problem, and CNAME flattening

Here’s the first genuinely technical snag, and it trips up almost everyone who self-hosts.

My site runs on Cloudflare Pages, which gives you a hostname like beta-society-site.pages.dev. The clean way to point a name at a hostname is a CNAME record: “this name is an alias for that one.” Works great for www.thebetasociety.com.

It does not work for the bare thebetasociety.com, the apex (also called the root or zone apex). The DNS spec forbids a CNAME at the apex, because the apex has to carry other records (like MX for email) and a CNAME legally can’t coexist with them. So the textbook answer, “just CNAME it to your host,” is illegal at exactly the name people actually type.

The fix is CNAME flattening. Cloudflare lets you put what looks like a CNAME at the apex, then resolves it behind the scenes and hands out the resulting IP addresses as if they were normal A records. You get the convenience of “alias to my host” at the apex without violating the spec. My apex records for all three domains are flattened CNAMEs pointing at the Pages hostname, so if Cloudflare ever changes those IPs, I don’t have to touch anything.

If you’ve ever wondered why “just point your domain at the site” is harder than it sounds, this is why. The apex is special, and most beginner guides quietly skip it.

The records that break your business if you forget them

Now the part that would have actually hurt.

wcithipster.com runs Microsoft 365 email. That email has nothing to do with the website, but it lives in the same DNS zone. When you move DNS to a new provider, you are moving the email records too, and if you drop even one of them, mail stops flowing and you often don’t notice until someone tells you they’ve been emailing you for a week.

The website needs one record: the apex pointing at the host. Email needs a whole quiet family of them, and every one has a job:

• MX tells the world which mail servers receive your mail. Drop this and inbound email simply stops. This is the one everyone remembers.
• SPF (a TXT record) lists who’s allowed to send mail as your domain. Drop it and your outbound mail starts landing in spam folders, because receiving servers can no longer verify it’s really you.
• autodiscover is how Outlook and phones automatically find the mail server when someone sets up the account. Drop it and existing mail keeps working but new device setup turns into a support ticket.
• enterpriseregistration / enterpriseenrollment are for device management. Easy to not even know you have them.
• The Teams records (sip, lyncdiscover, and a couple of SRV records) keep Teams calling and presence working.

None of these have anything to do with the blog. All of them had to be imported into Cloudflare exactly as they were and left alone. My rule for this step was blunt: I don’t understand what every one of these does, so I move all of them, verbatim, and change nothing. DNS is not the place to be clever. Copy faithfully, verify mail still flows, then move on.

Cloudflare’s import scan caught most of these automatically, which is the argument for letting the tool read your existing zone rather than typing records by hand. But I still checked the imported set against the old provider’s records line by line, because “most” is not “all,” and the one it misses is the one that costs you.

Then, and only then, the transfer

With DNS proven stable on Cloudflare and email verified working, moving the registration was almost anticlimactic, which is exactly how you want it.

A registrar transfer has a fixed shape no matter who you’re leaving:

1. Unlock the domain. Registrars set a “transfer lock” by default to stop anyone stealing your domain. You turn it off.
2. Get the authorization code. Sometimes called an EPP code or auth code. It’s a password that proves you’re allowed to move this specific domain. The registrar emails it to the domain’s registered contact, which is a small security check in itself.
3. Start the transfer at the new registrar, paste the code, and pay. A transfer almost always includes a one-year renewal, so you’re not losing time on the clock, you’re adding a year.
4. Approve and wait. There’s a built-in waiting period, up to five days, that exists so a stolen transfer can be caught and reversed. You can usually approve early to speed it up.

Because DNS already lived on Cloudflare, the transfer moved only the billing and ownership. The site never blinked. Email never blinked. Nothing about how the domains resolve changed, because that had all been handled weeks earlier. The transfer was pure paperwork.

One wrinkle worth mentioning, because it’s the kind of thing that makes you think you’ve broken something: my domains were split across two separate accounts at the old registrar. One domain sat under a different login than the others, which meant the domain manager appeared to be missing a domain depending on which account I was signed into. Nothing was wrong. It was just registered somewhere I’d forgotten. If your domain manager seems to be hiding a domain, check whether you’ve got a second account before you panic.

The keys, and what they buy

There’s a bigger reason to consolidate registration and DNS in one place than tidiness.

The registered contact on a domain is the account that controls it. On my domains, that contact is an address at wcithipster.com, the same domain running the M365 email. Which means the mailbox and the domain protect each other, and losing either one puts the other at risk. Keeping them together, on infrastructure I control, with the lock back on and the contact address current, is what “owning it” actually looks like at the domain layer. Not a subscription that quietly lapses, but keys in my own pocket.

That was the whole point of the move, the same point as every other part in this series: owe nothing to the old platform, and hold the keys myself. The domains were the last physical thing still tied to the place I was leaving. Now they’re not.

The one thing to take away

If you skim everything else, take this: DNS and registration are separate, so move them separately. Get DNS onto your new provider first and prove the site and email work there. Copy every email record faithfully, especially the ones you don’t understand. Only then transfer the registration, which becomes a formality once nothing depends on the old place anymore.

Do it in that order and a domain migration is calm. Do it all at once and you’re debugging three systems in the dark while your email is down.

Next up, Part 6: the part I didn’t expect. What it’s actually like to run a whole content network as a workflow instead of a website, and what I’d tell someone standing where I was six months ago.