Field Note 002: Moving my domain — and finding the mail I didn't know was broken
Pointing a domain at a new site sounds like a five-minute job. Checking the DNS first turned up an email setup that had quietly stopped working.
The environment
The new site was live on a Cloudflare test address (Field Note 001). The domain, iamgiovannihale.com, was still registered at Squarespace and still pointed at my old, expired Squarespace site.
The last step looked simple: point the domain at the new site and set up a contact address — hello@iamgiovannihale.com — that forwards to my personal inbox.
Same setup as last time: Claude as my AI execution partner, working in the browser and DNS dashboards while I made the calls. Account sign-ins and password prompts stayed with me.
The challenge
Before changing anything, I pulled the domain’s public DNS records. Moving nameservers replaces every record at once, so anything I didn’t know about would break silently.
Two things stood out:
- Mail was routed to Google Workspace. The MX records pointed at Google. If anything still depended on that mail, the cutover would cut it off.
- No email authentication at all. No SPF, no DKIM, no DMARC. Anyone could send mail claiming to be from my domain, and receivers had no way to tell.
What I was thinking: I didn’t think of that address as personal email — I’d used it like a company address and hadn’t touched it in a while. My honest answer to “is anything still using it?” was I don’t know. So I stopped and checked before going further.
The answer: the Google Workspace subscription had been cancelled. The DNS still advertised Google as the mail server, so any mail sent to the domain was going nowhere. It had been broken for a while and nothing told me.
The decision
The original plan for hello@ was Cloudflare Email Routing: free forwarding, no mailbox to manage. But Email Routing requires replacing the MX records — which would have broken Google Workspace if it had still been in use.
| If Workspace was live | If Workspace was dead |
|---|---|
Keep Google’s MX records, create hello@ as an alias in Workspace | Replace MX with Cloudflare Email Routing, forward hello@ to my inbox |
Checking first turned a guess into a clear call: Workspace was dead, so Email Routing was the right tool.
I also decided to fix the authentication gap while I was in there. The domain doesn’t send mail, so it can carry the strictest policy there is: reject anything that claims to be from it.
The implementation
- Added the domain to Cloudflare on the Free plan. Cloudflare imported the existing records — four Squarespace web addresses, two Squarespace aliases, and five dead Google mail records.
- Deleted all eleven. None of them pointed anywhere I wanted traffic to go.
- Attached
iamgiovannihale.comandwwwto the site as custom domains. Cloudflare creates the records and the TLS certificate. - Set up Email Routing:
hello@forwards to my inbox, every other address is dropped. Cloudflare added its own MX, SPF, and DKIM records. - Added a DMARC record:
v=DMARC1; p=reject; adkim=s; aspf=s. - Swapped the nameservers at Squarespace to Cloudflare’s.
One snag: Squarespace’s nameserver page showed the list as read-only, with a single button labeled “Use Squarespace nameservers.” The domain was technically in “custom” mode already — with Squarespace’s own servers entered by hand, likely left over from a migration. Switching back to default first unlocked the “Use custom nameservers” option.
The results
- Faster than expected. I saved the new nameservers at 9:43 AM. Within about 15 minutes, public resolvers were returning Cloudflare’s nameservers. Registrars warn it can take up to 48 hours; it didn’t.
- Site live on both addresses.
iamgiovannihale.comandwwwboth serve the new site over HTTPS. - Mail works. A test message to
hello@landed in my inbox within the same minute it was sent. Gmail showed it relayed through my domain, with the original sender’s signature still intact. - Authentication in place. SPF, DKIM, and a strict DMARC policy are all published. Before today the domain had none of them.
One thing I didn’t anticipate: the first time I loaded the new domain, my browser autofilled /home — the old Squarespace homepage path — and hit a bare framework 404. Old links don’t die just because the site changed. I added redirects for the old paths (/home and /blog) and a proper 404 page that points visitors somewhere useful.
What’s next
- Watch the DMARC policy. If I ever send from this domain, the strict policy will need SPF and DKIM set up for whatever sends it.
- Decide whether to move the registration to Cloudflare before it renews next September.
What I’d tell someone else: look at your DNS before you change it. Mine was carrying a dead mail setup and no protection against spoofing, and I only found out because I checked.