Cloud Platform
DNS turns names into addresses. That much everyone knows. What causes outages is the second half: DNS is a distributed cache with no undo button, so a change made at 4pm can still be causing problems at 4pm the following day.
The records you'll actually touch
A and AAAA — where the name points
An A record maps a name to an IPv4 address; AAAA does the same for IPv6. These are the foundation. If your site is down and the A record points at an address you no longer control, nothing else you do matters.
CNAME — an alias to another name
A CNAME says "this name is really that name; go ask about that one instead." Useful for pointing at services whose addresses change without warning. Two rules that catch people out: a name with a CNAME cannot have other records alongside it, and you cannot put a CNAME at the root of a domain. Providers offer workarounds with various names, but the underlying restriction is real.
MX — where email is delivered
MX records tell other mail servers where to deliver your mail, with a priority number where lower means preferred. The classic mistake is changing hosting providers, updating the A record, and forgetting that the MX records were pointing somewhere else entirely. Mail then goes to a server that no longer expects it, and it's often days before anyone connects the dots.
TXT — arbitrary text, which is where things get interesting
TXT records hold free-form text, and the email world has built its entire authentication stack on top of them.
The three records that decide whether your email arrives
If your mail lands in spam and you don't know why, it's almost always one of these.
SPF — who is allowed to send as you
A TXT record listing the servers permitted to send mail using your domain. Two things break it constantly: forgetting a legitimate sender (your CRM, your invoicing system, your marketing platform), and exceeding the limit on DNS lookups it's allowed to perform, which silently invalidates the whole record.
DKIM — a cryptographic signature on each message
Your mail server signs outgoing messages; the public key lives in DNS. Receiving servers verify the signature. It survives forwarding better than SPF does, which is why both exist.
DMARC — what to do when the first two fail
A policy record telling receiving servers how to treat mail that fails SPF and DKIM, and where to send reports about it. Start with a monitoring-only policy and read the reports for a few weeks before enforcing anything. Going straight to a rejection policy is how organisations discover, loudly, that their payroll system was sending mail nobody had accounted for.
Before any migration: lower your TTL — the time other servers are allowed to cache your records — at least 24 hours before you make changes. Drop it to a few minutes, make the change, verify, then raise it back. This one habit converts a potential day-long partial outage into a few minutes of inconsistency.
Other records worth knowing
- NS — which nameservers are authoritative for your domain. Changing these moves DNS hosting entirely, and it's the slowest change to propagate.
- PTR — reverse lookup, address back to name. Lives with whoever owns the IP address, not with you. Mail servers care about it more than anything else does.
- SRV — service discovery, used by protocols that need to find a specific host and port. Common in collaboration and voice platforms.
- CAA — restricts which certificate authorities may issue certificates for your domain. Cheap to add, genuinely useful, almost universally ignored.
A short discipline that prevents most DNS incidents
- Keep a documented record of every zone and who owns it, outside the DNS provider's console.
- Lower TTLs before planned changes; restore them after.
- Never make DNS changes on a Friday afternoon. The cache outlives your working week.
- Verify from outside your own network — your internal resolver may be answering from a different source entirely.
- Treat domain expiry with the same seriousness as certificate expiry. It's the same failure with a longer recovery.
