DNS records explained: the eight records a small business actually needs
DNS is the part of your setup that nobody understands until it breaks, and then it breaks everything at once: website down, email bouncing, and a dashboard full of records whose names mean nothing to you. It is genuinely simple once you see what each record is for.
The records that matter
| Type | Answers the question | Do you need it |
|---|---|---|
| A | Which IPv4 address hosts this name? | Yes, for a website, unless you use CNAME |
| AAAA | Same, for IPv6 | Usually set by your host. Harmless and good |
| CNAME | This name is an alias for that other name | Very often, for www and hosted services |
| MX | Which server receives email for this domain? | Yes, if you have email on the domain |
| TXT | Free-form text, used for verification and email auth | Yes — SPF, DKIM, DMARC and site verification all live here |
| NS | Which nameservers are authoritative for this domain? | Yes, and getting these wrong makes everything else irrelevant |
| CAA | Which certificate authorities may issue TLS certificates? | Optional, genuinely useful |
| SRV | Which host and port provides a specific service? | Only if a provider asks for it |
A and CNAME: the one people get wrong
An A record points a name at an IP address. A CNAME points a name at another name, and whatever that name resolves to is used. The practical difference is maintenance: if your host changes IP addresses, a CNAME follows automatically while an A record silently breaks.
The rule that trips everyone: you cannot put a CNAME on the root domain (`example.com`) alongside other records, because the root needs to carry MX and NS records too. Providers work around this with "CNAME flattening" or "ALIAS" records — Cloudflare does this transparently. If a service tells you to CNAME your root domain and your provider refuses, that is why, and the workaround is a flattened CNAME or an A record.
MX: email, and the mistake that loses mail
MX records list mail servers with a priority number. Lower number means tried first.
- All your mail servers belong in the list. Partial lists cause intermittent delivery failures that are miserable to diagnose.
- MX must point at a hostname, never an IP address. A common invalid configuration.
- Changing MX moves your mail. There is no undo for messages delivered to the old provider during the switch. Set the new records, keep the old mailbox accessible for a fortnight.
- Website and email are independent. You can host the site anywhere and keep email where it is. People often break working email while changing a website for no reason.
TXT: small records, large consequences
TXT records do the unglamorous work that decides whether your email is trusted. If your quotes land in spam, this is where the cause lives, and our guide to SPF, DKIM, and DMARC covers the full setup.
| Purpose | What to know |
|---|---|
| SPF | Exactly one SPF record per domain. Two is a permanent failure. Stay under 10 DNS lookups |
| DKIM | Published at a selector subdomain your provider gives you. Enable in the provider and publish the record |
| DMARC | Lives at _dmarc.yourdomain. Start at p=none with a reporting address, then tighten |
| Verification | Google, Bing, and others ask for a TXT record to prove ownership. Do not delete these later — verification silently lapses |
TTL: why your change has not taken effect
TTL is how long resolvers are allowed to cache an answer, in seconds. 3600 means an hour. If you change a record, anyone holding a cached copy keeps the old answer until it expires.
The professional habit: lower the TTL to 300 a day before a planned migration, make the change, confirm it works, then raise it back. This turns a potential day of inconsistent behaviour into five minutes. It only works if you plan ahead, which is the entire point.
CAA: five minutes of real security
A CAA record states which certificate authorities are allowed to issue certificates for your domain. Without one, any public CA can issue a certificate for your name if someone convinces them. With one, the list is restricted. It costs one record and prevents a category of attack. Set it to whichever CA your host uses.
The outages this prevents
- Domain expired. Not a record, but the most common total outage. Auto-renew, plus a calendar reminder on a second person, as in our security baseline.
- Nameservers pointing at an old host you stopped paying. Everything resolves to nothing.
- A record still pointing at a decommissioned server. Site dead, email fine, confusing.
- Two SPF records after adding a new sending service. Mail authentication fails for everything.
- Verification TXT deleted during a tidy-up. Search Console access lost, and with it your indexing data.
- Proxy or CDN toggled on for an MX hostname. Mail stops. Mail hostnames must resolve directly.
A sane setup for a small business
- Register the domain somewhere you control, separate from your host — see choosing hosting for why ownership should not be bundled.
- Point NS at one DNS provider and make all changes there. One source of truth.
- A or CNAME for the root and www, both resolving to the same site, with one canonical version.
- MX for your mail provider, plus SPF, DKIM, and DMARC.
- CAA restricting certificate issuance.
- Export the full zone file and store it with your documentation. Reconstructing DNS from memory during an outage is a bad evening.
That is it. Eight record types, one provider, one exported backup. DNS stops being frightening the moment you can see the whole thing on one page.
No company paid for placement in this article. Verify current prices and terms with each provider before buying.