Which DNS record do you actually need?
Nobody opens a DNS panel wanting to learn about record types. They open it because a developer sent them an IP address, or Microsoft wants a domain verified, or the new site is ready and the old one is still showing. So this guide runs the other way round: find your job in the first table, change the one record it names, and ignore everything else on the screen.
Start here: what are you trying to do?
| The job | The record | Does it affect email? |
|---|---|---|
| Point the website at a new host or server | A on the root, plus whatever handles www | No |
Point www at the same place as the root | CNAME on www | No |
| Move email to Microsoft 365 or Google Workspace | MX, plus the TXT records they give you | Yes. This is the email change. |
| Prove you own the domain to a third party | One TXT record, occasionally a CNAME | No |
| Add a subdomain for a shop, app or booking system | One A or CNAME | No |
| Stop your mail landing in spam | TXT records for SPF, DKIM and DMARC | Yes, but it cannot stop mail arriving |
| Move your DNS hosting itself | The nameservers, not a record | Yes. The whole zone is replaced. |
The single most useful line in that table is the last one, because it is the job people think they are doing when they are not. Pointing a website somewhere new does not require moving your nameservers. Change the A record and your email cannot break, because you never touched it. If a host tells you a simple site move needs their nameservers, that is their preference and not your requirement. The full version of that argument, and what to do if you genuinely do need to move nameservers, is a guide of its own.
The records, in the order you will meet them
A: a name to an IP address
An A record maps a hostname to an IPv4 address, like 203.0.113.10. It is the record that answers "where does this website live", and it is the one you will edit most often. AAAA does exactly the same job for IPv6 addresses, and if your host has not given you one, you do not need it.
CNAME: a name to another name
A CNAME points one hostname at another hostname rather than at an address. The classic use is www pointing at the root domain, so that both show the same site and you only maintain one address.
A record or CNAME? Let what you were given decide it. If a provider hands you an IP address, use an A record. If they hand you a hostname such as yourshop.myshopify.com, use a CNAME. The reason this matters beyond today is maintenance: when the destination's IP address changes, a CNAME follows it automatically and an A record silently keeps pointing at the old address until somebody notices.
You cannot normally put a CNAME on your root domain (example.com.au with nothing in front of it). The DNS specification does not allow a CNAME to sit alongside other records on the same name, and your root already carries NS and SOA records. So the root needs an A record, and services that only give you a hostname appear impossible to use there.
Most modern DNS providers, Cloudflare included, solve this with CNAME flattening: you enter a CNAME at the root, and the provider resolves it and answers queries with the resulting IP address, which is legal. If your current DNS host does not support it and a service will only give you a hostname, that is a genuine reason to move your DNS somewhere that does.
MX: where your email is delivered
MX records name the mail servers that accept email for your domain, each with a priority number. Lower is tried first. A server at priority 10 is attempted before one at 20, and the numbers only matter relative to each other, so 1 and 2 behave exactly like 10 and 20.
Two things worth knowing before you touch them. An MX record must point at a hostname, never at an IP address. And MX records can never be proxied through a CDN: on Cloudflare, only A, AAAA and CNAME records can be proxied, so MX and TXT are always DNS only. If someone tells you a proxy is hiding your mail server, it is not.
TXT: free text that other systems read
TXT records hold arbitrary text, which is why they ended up carrying several unrelated jobs:
- Domain verification. Google, Microsoft and most SaaS platforms ask you to add a string to prove you control the domain. Harmless, and safe to delete once you are certain the service no longer checks it, which for many is never.
- SPF, which lists the servers allowed to send mail as your domain.
- DMARC, on the
_dmarcsubdomain, which tells receiving servers what to do when checks fail. - DKIM, which lives on selector subdomains like
selector1._domainkey.example.com.au. These are the records people lose in a migration, because a TXT lookup on the root domain does not show them.
Email deliverability is a bigger subject than DNS and it is not really a web design question, so we have not tried to cover it here. Our IT side has: see business email going to spam, and how SPF, DKIM and DMARC fix it.
NS and SOA: the ones you do not edit
NS records name the authoritative nameservers for the domain. You will see them in the zone, but the ones that actually decide delegation are set at your registrar, not inside the zone file. SOA holds administrative metadata about the zone. Neither is something you edit by hand in normal operation, and a panel that lets you delete them is offering you nothing you want.
SRV: service location
SRV records point a specific service, port and protocol at a host. In small business life they almost always relate to mail client autodiscovery or VoIP. Losing them does not stop email arriving, it stops phones and Outlook configuring themselves, which produces a fortnight of tickets that do not look like a DNS problem.
TTL: the number that decides how fast a change takes effect
Every record carries a TTL, in seconds, telling other servers how long they may cache the answer before asking again. It is the entire mechanism behind what people call propagation, and it is why "wait 48 hours" is usually wrong.
| TTL | Means | Use for |
|---|---|---|
300 | 5 minutes | Set this a day before a planned change, so the switch itself is quick. |
3600 | 1 hour | A sensible default for records that change occasionally. |
86400 | 24 hours | Records that essentially never change. Slow to undo a mistake. |
Auto | Provider's choice, often 300 | Fine, and what most Cloudflare users leave it on. |
The important part is the sequence: lower the TTL first, wait for the old TTL to expire, then make the change. Lowering it at the same moment you make the change does nothing, because the world is still holding the previous answer under the previous TTL. The longer explanation, with what to do when different people see different versions of the site, is worth ten minutes if you have ever been told to just wait.
Before you change anything
Two habits that cost a couple of minutes and save entire afternoons:
-
Write down what is there now
dig MX example.com.au +short,dig TXT example.com.au +short,dig A example.com.au +short. Paste the output into a text file. This is your rollback, and it is the only one you get, because DNS panels rarely have an undo button. -
Change one record, then check
Not four records and then check. When something breaks after a single change you know exactly what caused it. This sounds obvious and is routinely ignored under time pressure, which is precisely when it matters.
Questions we get asked
What is the difference between an A record and a CNAME?
An A record points a name at an IP address. A CNAME points a name at another name. Use an A record when you were given an IP, and a CNAME when you were given a hostname. If the destination's address later changes, a CNAME follows it and an A record does not.
Why can I not put a CNAME on my root domain?
Because a CNAME cannot coexist with other records on the same name, and your root domain already carries NS and SOA records. Providers that support CNAME flattening, such as Cloudflare, let you enter one anyway and answer queries with the resolved address.
What does the number next to an MX record mean?
Priority, and lower is tried first. Only the order matters, so 10 and 20 behave identically to 1 and 2.
What should my TTL be?
3600 for normal life. Drop it to 300 a day before a planned change, then put it back. A permanently low TTL just means more lookups for no benefit.
Which record do I change to point my website at a new host?
The A record on the root, plus whatever handles www. That is the whole job, and it carries no risk to your email.
I changed a record and nothing happened. What now?
Almost always caching, either the old TTL still running out or your own browser and operating system holding the previous answer. Check what the internet sees rather than what your laptop sees, and give it the length of the old TTL before concluding anything is wrong.
The short version
Work out the job first and the record follows: A to point at an IP, CNAME to point at a hostname, MX for incoming mail with the lower number tried first, TXT for verification and mail authentication. The root domain cannot hold a CNAME unless your provider flattens them. TTL decides how quickly a change lands, so lower it a day early rather than on the day. Capture the current records before you edit, change one thing at a time, and never move nameservers when a single A record was the actual job.
General guidance only. If the domain carries live business email and you are not confident, ask before you save rather than after.
Where this comes from
- Cloudflare: proxy status, the source of the rule that only A, AAAA and CNAME records can be proxied.
- Cloudflare: DNS record types reference, for record behaviour and the root domain CNAME restriction.
- Our own guides on the operational side: changing records and nameservers and what propagation actually is.