DNS records explained: A, CNAME, MX and TXT
DNS is the part of hosting that most often goes wrong, usually because someone changed a record without knowing what it did. It is not complicated once the vocabulary is clear. This guide covers the handful of records you will actually touch, in plain English.
What DNS actually is
Computers reach each other using numbers, called IP addresses. People use names. DNS, the Domain Name System, is the directory that turns one into the other. When someone types your domain, their computer asks DNS where it lives and gets an address back.
Your DNS records are that directory entry. They live wherever your domain's nameservers point, which may be your registrar, your host, or a service like Cloudflare. Working out which of those three holds your records is the first thing to establish, because that is where you make changes.
The records you will actually use
There are dozens of record types. Five cover nearly everything:
- A record: points a name at an IPv4 address. This is the one that puts your website somewhere. Changing it moves your site.
- AAAA record: the same thing for an IPv6 address. Modern hosts provide both.
- CNAME: points a name at another name rather than an address. Commonly used so www.yoursite.com follows whatever yoursite.com does, and by third-party services that want to manage the destination themselves.
- MX record: says which server receives email for the domain. Entirely separate from your website. Delete it and your mail stops, while your website carries on without noticing.
- TXT record: holds plain text. Used to verify ownership with services like Google, and for the email authentication records below.
Why changes are never instant
Every record carries a TTL, or time to live, in seconds. It tells other servers how long they may cache the answer before asking again. A TTL of 3600 means some people will keep using the old value for up to an hour after you change it.
This is why a change can look live to you and broken to a colleague. Nothing is wrong. You are simply seeing different cached answers.
If you know a change is coming, lower the TTL to 300 a day or two beforehand. Your change will then take effect in minutes rather than hours. Raise it again afterwards, because a longer TTL is slightly faster for everyone.
The email records
Getting mail delivered now takes more than an MX record. Gmail, Outlook and Yahoo all check that a message genuinely came from your domain, and mail that fails those checks goes to spam or is rejected outright.
SPF is a TXT record listing which servers may send mail as your domain. DKIM is a TXT record holding a key, so receiving servers can verify a message was not tampered with in transit. DMARC is a TXT record telling receivers what to do when a message fails the first two, and where to send reports about it.
You need all three. Your host or mail provider will give you the exact values, and there is no benefit in improvising them.
Common mistakes
Four errors cause most DNS support tickets:
- Changing nameservers when you meant to change one record. Moving nameservers moves every record at once, including mail, and any record not recreated at the new provider simply disappears.
- Having two SPF records. The specification allows exactly one, and a second causes both to fail. Merge them into a single record instead.
- Deleting the MX record while moving a website. The site and the mail are unrelated systems.
- Assuming a change failed because it has not appeared yet. Check the TTL before changing anything a second time.
Checking your work
Before you change anything, save a copy of your current records. A screenshot is enough, and it has rescued more migrations than any other single habit.
Afterwards, verify from outside your own network rather than trusting your browser, which caches aggressively. Public DNS lookup tools show what the rest of the world sees, and most mail providers offer a checker that tests SPF, DKIM and DMARC together.
If you would rather not touch any of this, OzVPS web hosting includes DNS management in the control panel, and we handle the records for you as part of a free migration.