Launch day: moving your domain without losing your email

The most common fear we hear before a launch is not about the website. It is about email. “If you point the domain at the new site, will our email stop?” It can, if the wrong records are touched. On our builds it does not, because launch day changes one kind of record and leaves the rest alone. This post explains which is which, so you can check the work yourself.

What a domain actually is

Your domain name is an address people can read. Computers do not use it directly. MDN describes domain names as “a human-readable address for any web server available on the Internet”^[1]. Behind the name is a lookup system called DNS. When someone types your address, their computer “goes on to ask a DNS server, whose job is precisely to tell your computer which IP address matches each registered domain name”^[1].

Two companies are usually involved. The registrar is the one you pay to hold the name: “Companies called registrars use domain name registries to keep track of technical and administrative information connecting you to your domain name.”^[1] The DNS host is wherever the list of records for your domain is kept. Often it is the same company. Often it is not.

The records, and which ones move

A domain has a list of records. Each answers one question: where is the website, where does email go, who may send email in this name. Cloudflare’s reference describes the common types in one line each^[2]:

• A and AAAA “map a domain name to one or multiple IPv4 or IPv6 address(es)”. These are the records that say where a website lives.
• CNAME “records map a domain name to another (canonical) domain name”. The 1987 standard says of the record’s owner that “The owner name is an alias”^[3]: a CNAME says “this name is a nickname for that name”.
• MX: “A mail exchange (MX) record is required to deliver email to a mail server.”
• TXT: “A text (TXT) record lets you enter text into the DNS system.” This is where the email security records live.
• NS: “A nameserver (NS) record indicates which server should be used for authoritative DNS.” It says who holds the list itself.

Record	What it does	Changes on launch day
A / AAAA	Points the website name at a server address	Yes, if the old site used one
CNAME	Points the website name at another name (the new host)	Yes, this is the launch
MX	Says which server receives your email	No
TXT (SPF, DKIM, DMARC)	Proves your email is genuine	No
NS	Says who holds the list of records	No

Only the rows that describe the website move. On this site the domain is a CNAME pointing at our Cloudflare Pages project, and that is the pattern we use for client builds. Cloudflare’s instructions for a domain held elsewhere are short: “After logging in to your DNS provider, add a CNAME record for your desired subdomain, for example, shop.example.com. This record should point to your custom Pages subdomain, for example, <YOUR_SITE>.pages.dev.”^[4] That one edit is the cut-over.

Why email is a separate question

Email does not travel through the website. It travels to whichever server the MX record names. The standard defines the record as “A which specifies a host willing to act as a mail exchange for the owner name”, with a preference number where “Lower values are preferred”^[3]. Cloudflare’s guide to email records puts the practical version in two steps: “Add an A or AAAA record for your mail subdomain that points to the IP address of your mail server. Add an MX record that points to that subdomain.”^[5]

Those records were set up by your email provider, not your web developer, and a website launch has no reason to touch them. The TXT records deserve the same care, because they keep your email out of spam. Cloudflare summarises the three^[5]:

• SPF “Lists the IP addresses and domains authorized to send email on behalf of your domain.”
• DKIM “Authenticates the sender’s domain and verifies that email content was not altered in transit, using a cryptographic signature.”
• DMARC “Tells receiving servers what to do when SPF or DKIM checks fail.”

Delete one of those by accident and mail still sends, but receiving servers start refusing it or filing it as junk. That is the quiet failure a rushed launch produces. It is why our launch inclusion reads: DNS and SSL cut-over, your email and other domain services stay intact. Before we change anything we take a copy of every record, so the whole list can be put back in minutes.

Why the site is tested on a temporary address first

The new site does not go straight to your domain. Every Cloudflare Pages project gets a temporary address of its own; until a domain is attached, “your Pages project will only be accessible through the *.pages.dev subdomain you chose when creating your project”^[4]. That address is where the site lives during the Build stage, and it is what you see in the staged previews.

Cloudflare also explains that “Preview deployments allow you to preview new versions of your project without deploying it to production”, and that “Any custom domains, as well as your user-example.pages.dev site, will not be affected by preview deployments”^[6]. So the contact form, the analytics and every page are tested on a real, public address while your old site keeps running. Our Launch stage is DNS, SSL, form testing, analytics and handover notes, and the form is tested again after the cut-over before you sign off.

How fast the change is seen: TTL

When the CNAME changes, not everyone sees the new site at once. Every record carries a number called TTL, time to live. Cloudflare defines it as “a field on DNS records that controls how long each record is cached and — as a result — how long it takes for record updates to reach your end users”^[7].

The trade-off is plain: “Longer TTLs speed up DNS lookups by increasing the chance of cached results, but a longer TTL also means that updates to your records take longer to go into effect.”^[7] On Cloudflare, “all proxied records have a TTL of Auto, which is set to 300 seconds”^[7], five minutes. Even so, “It may take longer than 5 minutes for you to actually experience record changes, as your local DNS cache may take longer to update.”^[7] MDN gives the wider picture: “Within a few hours, all DNS servers will have received your DNS information.”^[1]

So for a short time after launch you may see the new site on your phone and the old one on the office computer. Both are correct. It settles on its own, and the old site stays up until it has.

SSL is not a separate job

A visitor should never see a security warning on launch day. On our hosting nobody installs a certificate. Cloudflare “issues — and renews — free, unshared, publicly trusted SSL certificates to all domains added to and activated on Cloudflare”, and “handles issuance, renewal, and deployment automatically”^[8]. We check the padlock on your domain and on the www version before asking you to sign off.

What nobody should change in a hurry

Two changes look like launch tasks and are not. Both can take your whole domain down, email included.

Changing nameservers. The NS records say who holds the list. Move them and you move every record at once, so anything missing at the new host simply stops. Cloudflare’s setup guide is blunt: if you switch “without setting up the correct DNS records for your domain, your visitors may experience DNS_PROBE_FINISHED_NXDOMAIN errors”^[9]. The names must be “copied exactly” or “your DNS will not resolve correctly”, and you then “Wait up to 24 hours while your registrar updates your nameservers”^[9]. A nameserver move is sometimes right. It is never right on launch morning.

Changing registrar. Moving a .au domain to a different registrar is a separate process again. auDA, the body that administers .au names, says you “start the transfer process by contacting the registrar you wish to transfer your .au domain name licence to”, which “will include providing the transfer authorisation code (EPP authInfo) for your .au domain name licence”^[10]. “There is no fee for any transfer of a .au domain name licence between registrars”, but “Once the transfer has been approved, it can take up to three days for the transfer to take effect”^[10]. None of that is needed to launch a website. If you want to consolidate providers, do it in a quiet week.

What you should check before launch is that you can log in to the registrar, and that the contact details are yours. auDA’s advice: “When your contact details change, it’s important you update them with your .au domain name provider”, so that you receive “renewal notifications so you can renew your .au domain name registration before it expires and not risk losing it”^[11]. A domain that lapses takes the website and the email with it.

What you can do next

Before your launch, find out three things: who your registrar is, where your DNS records are kept, and who set up your email. Those answers are most of the launch plan. If you are planning a build, the brief builder takes three minutes, and the reply will say how we would handle your domain and your email. For what happens to the site once it is live, the posts on React and islands explain the build, and the home page carries the measurements.

Reference list

All sources accessed 15 July 2026.

1. MDN Web Docs (n.d.) What is a domain name? Mozilla. https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/What_is_a_domain_name
2. Cloudflare (n.d.) DNS record types. Cloudflare Docs. https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/
3. Mockapetris, P. (1987) RFC 1035: Domain Names - Implementation and Specification. IETF, November 1987. https://www.rfc-editor.org/rfc/rfc1035
4. Cloudflare (n.d.) Custom domains. Cloudflare Pages documentation. https://developers.cloudflare.com/pages/configuration/custom-domains/
5. Cloudflare (n.d.) Set up email records. Cloudflare Docs. https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/
6. Cloudflare (n.d.) Preview deployments. Cloudflare Pages documentation. https://developers.cloudflare.com/pages/configuration/preview-deployments/
7. Cloudflare (n.d.) Time to Live (TTL). Cloudflare Docs. https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/
8. Cloudflare (n.d.) Universal SSL. Cloudflare Docs. https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/
9. Cloudflare (n.d.) Set up a primary zone (Full setup). Cloudflare Docs. https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/
10. auDA (n.d.) How to transfer your .au domain name. .au Domain Administration. https://www.auda.org.au/au-domain-names/manage-your-au-domain-name/transfer-your-au-domain-name/
11. auDA (n.d.) Update your .au domain name information. .au Domain Administration. https://www.auda.org.au/au-domain-names/manage-your-au-domain-name/update-your-au-domain-name-information/