How to connect your domain to your website without breaking email

What the records in your DNS settings do

Think of your domain's DNS settings, known as the zone, as a switchboard. Each line answers one question about one name: where is the website, where should email go, which services may send mail on this domain's behalf. In many control panels, @ stands for the bare domain (example.com), and anything else, such as www, is a name in front of it.

An A record answers with an IPv4 address, such as 192.0.2.10: example.com lives at this number. An AAAA record does the same for the longer IPv6 addresses, such as 2001:db8::10. A CNAME record says one name is an alias for another: www.example.com is really example.com, so look that up instead.

An MX record says which server accepts email for the domain, and the number beside it is a preference: lower numbers are tried first. A TXT record holds text for other systems to read, most often an SPF line listing the services allowed to send email as you, or a code proving to a service that you own the domain. NS records name the nameservers, the servers in charge of answering for the whole zone.

Records or nameservers: know which change you're making

Hosts give one of two kinds of instruction. Some ask you to edit a record or two, typically an A record for the bare domain and a CNAME for www, leaving everything else where it is. Others ask you to change the nameservers, which hands the whole switchboard to a different provider.

The second kind is where email can quietly break. Once the change takes hold, the new provider answers every question about your domain, and it knows only the records that have been created there. If the MX and TXT records for your email aren't in the new zone before you switch, mail can bounce or go astray while the website looks perfectly fine. Copy every record across first, check them against your saved list, and only then change the nameservers.

Why changes take hours: it's caching, not propagation

When you save a DNS change, nothing is broadcast across the internet. Your DNS provider simply starts giving the new answer. The delay comes from everyone else: internet providers and public resolvers keep the last answer they fetched and reuse it until its time to live (TTL), set in seconds, runs out. A record with a TTL of 86400 may be remembered for a day; one with a TTL of 300, for five minutes.

Google Public DNS, for example, says it generally limits TTLs to six hours even when the actual TTL is longer, and offers a Flush Cache tool that refreshes its copy of a name on request. After a nameserver change, Google advises flushing the main domain before subdomains such as www, so they aren't refreshed with stale data from your old DNS servers.

This is also why a change can appear for you but not for a colleague: you're asking different caches. Resist the urge to keep editing while you wait, because each edit starts a fresh round of mixed answers.

Four mistakes that break domains, and how to avoid them

A CNAME on the bare domain. RFC 1912, a 1996 note on common DNS errors, is blunt: 'A CNAME record is not allowed to coexist with any other data', not even an MX or a TXT record. The bare domain always carries nameserver records, and usually the MX records your email needs, so a CNAME there collides with them. The same note calls this mistake one 'often attempted by inexperienced administrators'. Use the A record your host supplies, or your DNS provider's workaround for the bare domain if it has one, sometimes called an ALIAS record or CNAME flattening.

Forgetting www. www.example.com is a separate name with its own record. If only the bare domain points at your new host, anyone who types www reaches the old site or an error. Set up both, make sure your HTTPS certificate covers both, and redirect one to the other so everyone lands on a single address.

A second SPF record. When a new email or newsletter service asks you to add an SPF line, it's tempting to add another TXT record starting v=spf1. The SPF standard, RFC 7208, says a domain must not have more than one, and a check that finds two returns a permanent error, meaning the domain's published records could not be correctly interpreted. Merge the services into a single SPF record instead.

A value copied from a tutorial. The IP address in someone else's guide points at someone else's server. Use only the values your host gives you for your account, and don't add extra records to match several guides at once.

A safe change, step by step

Pick a quiet time for the switch rather than late on a Friday, and give yourself a way back. A short TTL is what makes the way back quick, but lowering it only helps once the old, longer TTL has expired from every cache. So lower it at least one old TTL in advance: a day ahead if it's currently 86400.

After the switch: certificates, clean-up and getting help

If the site appears but the browser warns about its certificate, don't start changing DNS again. A certificate authority has to confirm you control a domain before it issues a certificate. Let's Encrypt, which issues free certificates, can do this by fetching a small file from your domain over the web, and that only succeeds once the domain points at your new host. So the certificate may arrive a little after the site does. Give it some time, then use your host's option to reissue it, and check that it covers both the bare domain and www.

Once everything has worked for a day or two, raise the TTL again, for example to an hour (3600 seconds), and keep a note of what you changed and when, alongside your saved copy of the old records.

If you need help, send your host the domain, the exact address you tried, any error message, and that list of changes. Never include passwords or private keys.