DNS Records Explained: A, CNAME, MX and TXT in Plain English

Nameservers vs DNS records: who holds the list

Every domain has nameservers, set at the registrar where you bought it. Cloudflare's nameserver documentation describes them as the authoritative servers that hold the definitive DNS records for your domain. Whoever runs those nameservers is where you edit your records.

This is the first thing to check when 'my DNS change did nothing'. If your domain was bought at one registrar but the nameservers point to Cloudflare or your web host, edits at the registrar are ignored. Change records where the nameservers point, not where you pay for the domain.

If you are choosing where to register, our guide to the best domain registrars in Singapore compares the main options.

One example domain, every record explained

Here is a typical small business setup for an example domain, example.sg, with its website on a web host and email on Google Workspace. IP addresses are from the documentation range, not real servers.

'@' means the domain itself (the apex, example.sg). Anything else in the Name column is a subdomain: www, mail, shop or _dmarc.

A and AAAA records: where the website lives

Cloudflare's record types reference defines A and AAAA records as mapping a domain name to one or more IPv4 or IPv6 addresses. An A record holds an address like 192.0.2.10; an AAAA record holds the longer IPv6 form.

• When you need one: your web host or website builder gives you an IP address to point your domain at.
• What breaks if it is wrong: the website does not load, or loads an old site from a previous host. Email is not affected, because email uses MX.
• Common mistake: leaving an old A record in place alongside the new one, so visitors randomly reach either server.

CNAME records: one name pointing to another

A CNAME maps one domain name to another, canonical name. Instead of an IP address, it says 'look up this other name instead'. Website builders and SaaS tools often ask for a CNAME such as shop pointing to a hostname they control, so they can change their servers without you editing anything.

• When you need one: the www version of your site, a booking or shop subdomain, or a verification step for a service.
• Rule to remember: a name with a CNAME should not have other records. That is why the apex (example.sg) normally uses an A record, unless your DNS provider offers a workaround such as Cloudflare's CNAME flattening.
• What breaks if it is wrong: that subdomain stops working, or a third-party service cannot verify your domain.

Our guide to connecting a domain to a new website without breaking email shows which A and CNAME records to change and which to leave alone.

MX records: where your email goes

Google's MX setup article explains that when someone emails you, their mail server looks up your domain's MX records to find where to deliver. Each MX record has a priority; lower numbers are tried first.

• When you change them: only when you move email to a new provider, such as from your web host to Google Workspace or Microsoft 365.
• What breaks if it is wrong: incoming email bounces, goes to the old provider or disappears. Outgoing email still works, which is why the problem is often noticed late.
• Common mistake: adding the new MX but keeping the old ones. Google says to remove other MX records, because mail may still go to the old server.

Planning a switch? Follow our steps for changing MX records without downtime.

TXT records: verification, SPF, DKIM and DMARC

A TXT record simply holds text. Services use it to check you control the domain, and email systems use it for the three anti-spoofing records. Cloudflare's email records guide notes that without these, anyone can send email that appears to come from your domain.

• Verification: a one-off code from Google, Microsoft, Meta or another service. Safe to leave in place after verifying.
• SPF: lists the services allowed to send mail for your domain. Have only one SPF record per domain; combine includes into a single line.
• DKIM: a public key, usually at a name like selector._domainkey, that lets receivers check your mail's signature.
• DMARC: at the name _dmarc, tells receivers what to do with mail that fails SPF and DKIM, and where to send reports.

If invoices or quotes land in spam, these three are the first thing to check. Our guide to SPF, DKIM and DMARC walks through fixing them.

TTL and propagation: why changes take time

Every record has a TTL (time to live). Cloudflare's TTL reference describes it as how long each record is cached, and therefore how long updates take to reach users. A longer TTL means faster lookups but slower changes. On Cloudflare, proxied records use Auto (300 seconds), and DNS-only records can be set from 60 seconds to 1 day on non-Enterprise plans.

If you are planning a move, lower the TTL on the records you will change a day or two before, make the change, then raise it again. Google says MX changes can take up to 72 hours to be recognised, so do not panic if a change is not visible everywhere within minutes.

Do it yourself or get help?

Reading your own DNS is worth doing yourself: log in where your nameservers point and compare the list with this guide. Editing it is where mistakes cost money, because one deleted MX or SPF line can stop email without warning.

Our Domain & DNS Setup (S$99) registers or transfers the domain in your name and sets the website and email records correctly. Adding a second domain for email? See our guide to adding a domain to Google Workspace.