When a small business moves its website, the website is rarely what breaks. The site either works at the new host or it does not, and you find out immediately. What breaks quietly is email, because for most small companies the same DNS zone that points www at a web server also tells the entire internet where to deliver mail and how to trust it.
We moved planetek.org from a traditional virtual server to AWS in July 2026, with company mail staying on its existing provider throughout. Nothing bounced and nobody noticed, which is the whole point. This note is the order of operations, told through our own move.
Why website moves break email
Changing where DNS is hosted means replacing your domain's entire zone, not just the one record that points at the website. If the new zone is missing the MX records that route mail, or the SPF, DKIM, and DMARC records that authenticate it, delivery fails in the worst possible way: gradually, as caches expire, and often straight into spam folders rather than with a clean error. The sender gets a bounce. You get silence.
The order of operations
- Inventory every DNS record first. Export or screenshot the full zone at your current DNS host before touching anything: MX, TXT, CNAME, everything, including records you do not recognize. Those mystery TXT records are usually domain verifications that something depends on.
- Build the new zone before you need it. We created a Route 53 hosted zone and recreated every record verbatim: the mail provider's MX records, the SPF policy, the DKIM signing key, the DMARC policy, and several old verification records. The zone sat there, complete and unused, while we checked it.
- Stand up the new website behind its temporary URL. The new site ran on S3 and CloudFront and was fully tested at its CloudFront address, with the TLS certificate already issued, before any visitor could reach it under the real domain.
- Verify the new zone from the outside. Query the new nameservers directly with
digand compare every answer against your inventory. This is the step that catches the typo that would have eaten your mail. - Cut over the nameservers, and only the nameservers. At the registrar, point the domain at the new DNS servers. Domain registration itself does not need to move; ours stayed where it was. Renewal dates and ownership are untouched by a DNS hosting change.
- Prove it after. Send mail to the domain from an outside account, confirm it arrives, and confirm outbound mail still authenticates. Then leave the old hosting running for a few days as a safety net before retiring it.
The one-sentence version: replicate the whole zone first, verify it from outside, and change nameservers last, so the cutover is a routing change instead of a leap of faith.
What it looks like after
The result for us is a website served from CloudFront's edge worldwide, mail exactly where it always was, and a hosting bill measured in pennies. The contact form runs on a small Lambda function that emails our own inbox only, so the form cannot be abused to send mail to anyone else. The old server is gone. The site now loads faster, costs less, and has one less thing to patch on a weekend.
If your business wants the same move, our web development practice handles the site and our managed AWS services handle the account, the DNS, and the guardrails. We have done this carefully enough times to make it boring for you too.
Planning a move and worried about a specific record? Email info@planetek.org or book a free consultation. More notes live on the Insights page.