The DNS records a small business actually needs

DNS is a lookup table. Somebody's computer asks "what is yourdomain.com?" and your DNS answers. Everything below is one kind of answer, and the reason the panel feels intimidating is that it offers you every kind anyone has ever needed, including the ones designed for problems you do not have.

There is one idea worth having before the list. A record has a TTL, measured in seconds, which tells everyone else how long they may remember the answer. That single number decides how long a change takes to reach the world, and it is why "DNS takes 24 to 48 hours" is usually wrong — more on that at the end.

A and AAAA: where the website is

An A record points a name at an IPv4 address; an AAAA record points it at an IPv6 address. This is the one people picture when they think of DNS.

@ means the domain itself — yourdomain.com with nothing in front. Most hosts give you an IP address and you put it here. If your website is on a platform rather than a server, you usually will not need these at all; you will need a CNAME instead.

You do not need both A and AAAA. Having only A is fine and very common. Having an AAAA record pointing somewhere that is not actually serving your site is worse than having none, because browsers on IPv6 networks will try it first.

CNAME: this name is really that name

A CNAME says "look up this other name instead". Platforms use it so they can change their own servers without you touching anything.

There is one hard rule that catches almost everybody: a name with a CNAME cannot have any other record. That is why you generally cannot put a CNAME on the bare domain — the bare domain already has to carry your MX records for mail, and the two cannot coexist. Providers work around it with their own extensions, variously called ALIAS, ANAME or CNAME flattening. If yours offers one, that is the right tool for pointing a bare domain at a platform.

MX: where mail is delivered

MX records say which servers accept mail for your domain. Each has a priority number, and lower means tried first.

Two things reliably go wrong here. The first is leaving an old provider's MX record in place alongside the new one — mail then arrives at whichever is tried first, which means some of it lands in a mailbox nobody reads. The second is the trailing dot. A hostname without one may be interpreted as relative and quietly become mail1.yourprovider.com.yourdomain.com, which does not exist. Most panels add the dot for you; some do not, and the failure is silent either way.

If you are changing these on a domain that is already receiving mail, read moving your email to a new domain first — the order matters more than the values.

TXT: the three that decide whether mail is believed

A TXT record holds arbitrary text, which is why it ended up carrying several unrelated jobs. For a small business it carries four:

• SPF — which servers may send mail as you. One record only, on the bare domain.
• DKIM — the public key your mail is signed with, on a selector name your provider gives you.
• DMARC — on _dmarc, saying what to do when the first two fail, and where to send reports.
• Verification tokens — a string a provider asks you to publish to prove you control the domain. Harmless, and safe to delete once verified, though most people leave them.

These three are the difference between mail that arrives and mail that lands in junk, and they have enough detail to deserve their own piece: why your business email goes to spam covers what each one does and the order to add them in.

CAA: who may issue certificates for you

A CAA record names the certificate authorities allowed to issue HTTPS certificates for your domain. Without one, any public CA may issue for you; with one, the others are supposed to refuse.

It is optional and almost nobody has it, which is a shame because it is the cheapest thing on this list — one record, no maintenance, and it closes off a whole category of misissuance. The one caution: if you add it and later move to a host that uses a different CA, certificate renewal will fail until you update the record. That failure is quiet right up until the certificate expires.

What you do not need

The panel will also offer SRV, NS, PTR, SOA and others. SOA and NS for your own zone are managed for you and should be left alone. PTR is reverse DNS and belongs to whoever owns the IP address, not to you. SRV is for service discovery — some mail clients use it for autoconfiguration, which is a convenience rather than a requirement.

If a guide tells you to add a record type you have never heard of, the right response is to find out which product asked for it. A record nobody can explain is a record nobody will remove when the product it served is gone.

TTL, and why "48 hours" is mostly a myth

TTL is how long other servers may cache an answer. A record published with a TTL of 3600 can be remembered for an hour; one with 300 for five minutes. New records appear almost immediately, because there is no cached answer to expire — the delay only applies to changing a record that already existed.

Which gives you the one genuinely useful DNS technique: before a planned change, drop the TTL to 300, wait for the old TTL to pass, then make the change. It will propagate in minutes rather than hours. Raise it back afterwards, because a low TTL means every visitor's resolver asks again constantly.

The number in the second column of that output is the TTL remaining on the cached answer, counting down. Watching it reach zero is the most reliable way to know a change is about to be visible.