For most business websites, launch day needs four kinds of DNS record: an A record (and AAAA if your host gives you an IPv6 address) for the main domain, a CNAME for www, MX records so email keeps working, and TXT records to prove your email is genuine. Get those right, lower your TTL beforehand, and check the result before you tell anyone the site is live. That is the whole job. The rest of this guide shows you how to do it without taking your website or your email offline.
We build websites for UK business owners, and DNS is the step that most often catches people out at the finish line. The design is signed off, the content is in, and then the domain points somewhere wrong for a day. It is easy to avoid.
TL;DR
- Point your root domain (
yourbusiness.co.uk) with an A record, and pointwwwwith a CNAME to your host’s hostname, unless your host tells you otherwise. - Lower the TTL on the records you will change at least one old-TTL period before launch, then raise it again afterwards.
- Never delete MX and TXT records when you swap the website’s records, or your email will stop or land in spam.
- Allow up to 72 hours for changes to settle worldwide, and check with
digrather than guessing. - Secure your registrar and DNS logins with strong authentication, and watch for unexpected changes to nameserver (NS) records.
Table of Contents
- What DNS records actually do
- The records you need on launch day
- A record vs CNAME: which one to use
- Set your TTL before you launch
- A launch-day DNS routine
- How to check your DNS records have updated
- Security: DNS is part of your business identity
- Our view: DNS belongs in the project plan
- When we can help
- FAQ
- Sources
What DNS records actually do
DNS is often called the address book of the internet. It turns a memorable name into the IP addresses computers use to find each other, as the NCSC explains in its guidance on managing public domain names. The NCSC also warns against treating it as a mere address book: it is part of your business’s identity, and its integrity matters as much as your website’s security.
A DNS record is one line in that address book. Each line says what should happen when someone asks for a particular name. cPanel’s documentation sums up the job: records control which server a domain points to and where it receives email.
One point trips up many owners. Your registrar (where you bought the domain) and your DNS host (where the records live) can be two different services. The GDS Way security guidance notes that DNS may be the same service as your registrar, and if it is not, the same security steps apply to the DNS service. Before launch, work out where your records are actually edited. Look at your domain’s nameservers: whichever company they belong to is where you make changes.
The records you need on launch day
Here is the short list, in plain English.
| Record | What it does | Typical launch use |
|---|---|---|
| A | Points a name to an IPv4 address | Root domain to your web host |
| AAAA | Points a name to an IPv6 address | Same, if your host supplies one |
| CNAME | Makes one name an alias of another | www to your host’s hostname |
| MX | Says which mail server receives email | Keeps your business email working |
| TXT | Holds text for verification and security | SPF, DKIM and DMARC for email |
| NS | Says which nameservers control the domain | Set at the registrar, rarely changed |
The definitions of A, AAAA, CNAME, MX and TXT above match cPanel’s record type descriptions. Your host will tell you exactly which values to enter. Copy them precisely, including any trailing dots your DNS panel asks for.
A and AAAA records: the front door
An A record sends your domain to an IPv4 address. An AAAA record does the same for IPv6. If your host gives you both, add both. If it gives you only an A record, add only that. Do not invent an AAAA value.
MX and TXT records: protect your email
This is where launches go wrong. Your old website and your email often share a DNS zone. If you replace the whole zone, or move nameservers without copying everything, your MX records vanish and email stops arriving.
Before touching anything, take a screenshot or export of every existing record. Then change only the ones that relate to the website.
TXT records matter just as much. They hold the SPF, DKIM and DMARC entries that help receiving mail servers trust messages from your domain. Your email provider will give you the exact values.
NS records: handle with care
NS records decide who is in charge of your DNS. You only change them if you are moving your DNS to a new provider. If you are, set the new zone up fully (every record copied across) before you switch the nameservers at the registrar.
A record vs CNAME: which one to use
This is the question most owners ask, and the answer is simpler than the jargon suggests.
- An A record maps a name directly to an IP address.
- A CNAME maps a name to another name, and the lookup then continues until it finds an address.
The practical rule: use an A record for your root domain and a CNAME for subdomains such as www. According to Valimail’s explainer on A records and CNAMEs, the DNS specification does not allow a CNAME at the root domain, which is why root domains use A records or provider-specific alternatives called ALIAS or ANAME records. The same piece notes that a CNAME adds one extra lookup, though in practice the two perform comparably.
Why use a CNAME for www at all? Because if your host changes its IP address, the CNAME follows the host’s hostname and you do not need to edit anything. An A record, by contrast, would need updating by hand.
Some platforms (website builders, e-commerce platforms, CDNs) give you a hostname rather than an IP address. In that case you use a CNAME for www, and for the root domain you use whatever the platform recommends: often an A record to a fixed address, or an ALIAS record if your DNS provider supports one.
A quick example
Say your domain is example-bakery.co.uk and your host gives you the address 203.0.113.10 and the hostname sites.example-host.com. (Both are placeholders.) Your records would look like this:
| Name | Type | Value |
|---|---|---|
@ (root) |
A | 203.0.113.10 |
www |
CNAME | sites.example-host.com |
The @ symbol simply means the root domain. Then decide which version is your main one, and set a redirect from the other. A site that answers on both www and non-www with no redirect can split your search visibility between two addresses.
Set your TTL before you launch
TTL (time to live) is how long other servers are allowed to remember a record before asking again. A long TTL means that when you change a record, some visitors keep going to the old server until their stored copy expires.
The GDS Way guidance suggests a short TTL of 300 seconds (five minutes) for your primary website records, so you can recover quickly if you need to switch servers urgently. For records that rarely change, such as MX and TXT, it suggests a much longer TTL of 86,400 seconds (24 hours), which cuts needless query traffic.
The order of operations matters:
- Check your current TTL on the records you will change. If it is 86,400, you must act at least 24 hours ahead.
- Lower it to 300 seconds.
- Wait for the old TTL to run out. This is the step people skip, and skipping it defeats the purpose, because other servers are still holding the old value.
- Make the change on launch day.
- Once everything works, raise the TTL again.
If you are launching on a Monday morning, lower the TTL on the Friday or earlier, not on Monday at 8.55am.
A launch-day DNS routine
Here is the sequence we would follow for a typical small business site.
- Record the current state. Export or screenshot every record in your DNS panel.
- Confirm login security. Make sure the registrar and DNS accounts are protected with strong authentication (more on this below).
- Build the new site on a temporary address. Test it fully before touching DNS. Our website launch checklist for UK small businesses covers what to test.
- Lower the TTL at least one old-TTL period ahead.
- Change the A (and AAAA) record for the root domain and the CNAME for
www. - Leave MX and TXT alone unless your email is moving too.
- Check the result with the tools below.
- Switch on HTTPS and confirm the certificate covers both the root and
wwwversions. - Raise the TTL once you are happy.
If you are still choosing where the site will live, our guide to website hosting for UK small businesses will help you decide before you get this far.
How to check your DNS records have updated
Propagation is the slightly misleading word for the time it takes the world’s caches to catch up. Google’s crawling documentation advises allowing up to 72 hours after updating DNS records. In practice, with a short TTL set in advance, most changes show within minutes to hours, but plan for the longer window.
To check, use the command-line tool dig. On a Mac or Linux machine, open a terminal and type:
dig yourbusiness.co.uk Ato see the root domain’s addressdig www.yourbusiness.co.uk CNAMEto see wherewwwpointsdig yourbusiness.co.uk MXto confirm your email records are intact
The same Google page recommends dig for verifying records resolve to the intended addresses. It also says to flush Google Public DNS’s cache if you are testing resolution, which can speed up troubleshooting. Windows users can use nslookup for a similar result, or an online lookup tool.
Check from more than one network. Your own computer and router keep their own caches, so a phone on mobile data is a useful second opinion.
If something looks wrong, the usual culprits are:
- a typo in the IP address or hostname
- a leftover old A record sitting beside the new one, so some visitors get the old site
- a CNAME added on a name that already has other records
- a missing record that was in the old zone
DNS problems also affect search engines. Google treats network timeouts, connection resets and DNS errors similarly to server errors, so a launch with broken DNS can interrupt crawling. The same documentation says to make sure your firewall does not block Google’s IP addresses.
Security: DNS is part of your business identity
Once the site is live, DNS becomes something to look after, not forget.
The NCSC’s advice on protecting your public domain name is practical and worth following:
- Secure your registrar account with strong authentication, and keep it under your organisation’s control, not tied to one person’s personal email address.
- Consider enabling DNSSEC if your registrar and DNS provider support it. It adds cryptographic verification to your records.
- Keep your administrative contact details accurate, using a generic shared business email address rather than an individual’s.
Then keep watch. The NCSC says unexpected changes to records, especially NS records, are a key sign of hijacking attempts. If you would like help spotting wider technical problems on your site, a regular check such as the one described in this guide to website audits can catch issues early, though DNS itself you should review directly in your DNS panel.
One more risk is easy to miss. UK Government Security’s guidance on expired MX or NS records explains that if a record points to a domain that has expired, someone else can register that domain cheaply and intercept your email or redirect your DNS queries. Every few months, look at your MX and NS records and confirm they point to services you still pay for.
The same page covers a related point: if you do not intend to send email from a domain, it advises explicitly disallowing it with specific MX and TXT records, to prevent spammers abusing it. That applies to spare domains you bought to protect your brand.
For the wider picture, our guides on securing your website and ongoing website maintenance cover what sits around DNS.
Our view: DNS belongs in the project plan
We have worked with business owners for over a decade, and the pattern is consistent. DNS is rarely the hard part of a launch. It becomes the hard part when nobody owns it.
Here is what we believe, and how we work:
- Know who holds the keys. Your domain should be registered in your business’s name, with logins you control. We would rather hand you a clear note on where everything lives than leave you depending on us.
- Plan DNS early, not on the day. Because we combine creative design and technical delivery, DNS planning sits inside the same project as the design and build. That means the TTL is lowered, the email records are noted and the redirects are agreed before anyone says “go live”.
- Email comes first. A beautiful new site is no use if your enquiries stop arriving. We treat MX and TXT records as untouchable unless email is deliberately changing.
- Check, then check again. A launch is only finished when the records resolve correctly from outside your own network.
If any of this feels like a lot, that is normal. It is one small task done carefully, and it is the sort of detail a good agency should carry for you.
— Kukoo
When we can help
If you would rather not do this yourself, we build and launch websites for UK small and growing businesses, with DNS and handover included in the plan. See our web design and development services to find out what we can do, or look at our website care plans (Fix, Steady, Secure and Scale) if you want someone keeping an eye on your site after launch. If your existing site feels slow, our £25 Website Speed Improvement is a low-cost place to start. You can also see how we approach a project in our Leeds web design process guide.
FAQ
Should I use a CNAME or an A record?
Use an A record for your root domain and a CNAME for www or other subdomains, unless your host’s instructions say otherwise. A CNAME cannot sit at the root under the DNS specification, which is why root domains use A records or provider-specific alternatives such as ALIAS. A CNAME on www has the advantage of following your host if its address changes.
Do I need DNS records for my website to work?
Yes. Without records pointing your domain to a server, visitors cannot reach the site, and without MX records you cannot receive email at that domain. Your host provides the values, and you enter them where your domain’s nameservers are managed. That may be your registrar or a separate DNS provider.
How long do DNS changes take?
Allow up to 72 hours, as Google’s crawling documentation advises. If you lowered the TTL a day or more ahead, most visitors will see the change much sooner. Use dig from different networks to confirm.
Where can I check my DNS records?
The simplest way is dig in a terminal, for example dig yourbusiness.co.uk A or dig yourbusiness.co.uk MX. You can also view them in your DNS provider’s dashboard, or use an online lookup tool. Test from a second network, such as your phone on mobile data, to avoid your own cache.
Will changing DNS for the new website break my email?
Not if you change only the A, AAAA and CNAME records and leave MX and TXT records untouched. Problems arise when a whole zone is replaced or nameservers move without every record being copied across. Export your existing records before you start.
Sources
- Managing Public Domain Names, NCSC
- Protecting your public domain name, NCSC
- Security overview for websites, The GDS Way
- Expired MX or NS, UK Government Security
- Managing DNS Records, cPanel & WHM Documentation
- Debug Network and DNS Errors for Google’s Crawlers, Google for Developers
- A Record vs. CNAME, Valimail