Record types that matter
A, AAAA, CNAME, MX, TXT and CAA - what each one does, how they interact, and where they collide.
The core set
| Type | Points at | Used for |
|---|---|---|
A | IPv4 address | Serving a site, any address on the internet |
AAAA | IPv6 address | Same as A over IPv6; omit only if you mean it |
CNAME | Another name | Delegating a hostname to a provider that manages its own IPs |
MX | Mail exchanger, with priority | Where email for the domain is delivered |
TXT | Free text | Domain verification, SPF, DKIM, DMARC |
CAA | Which CAs may issue | Restricting certificate issuance for the domain |
NS | Name servers for the zone | Delegation, set at the registrar |
SOA | Zone metadata | Serial number, refresh, negative-cache TTL |
Two records that are easy to forget: AAAA is used automatically by any client that supports IPv6, so publishing one you cannot serve causes timeouts for those clients; and CAA silently blocks certificate renewal if it lists a CA you no longer use.
A zone file you can read
; zone file for example.com - note the trailing dots on FQDNs
$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
2026091801 ; serial - bump on every change
7200 3600 1209600 300 )
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
@ IN A 203.0.113.10 ; apex points at the server
www IN CNAME example.com. ; www follows the apex
api IN A 203.0.113.11
@ IN AAAA 2001:db8::10
@ IN MX 10 mail1.example.com.
@ IN MX 20 mail2.example.com. ; higher number = lower priority
@ IN TXT "v=spf1 include:_spf.example.net -all"
@ IN CAA 0 issue "letsencrypt.org"@means the apex (example.com itself); a missing trailing dot makes a name relative, which causes the classicexample.com.example.commistake.- Mail servers try the lowest
MXpriority first; keep them in the same order everyone expects. - Bump the SOA serial on every edit or secondary servers will never pick the change up.
CNAME rules and collisions
A CNAME means "this name is an alias for that name" - so it cannot coexist with any other record on the same name, and it must never sit at the apex of a zone, because the apex also needs NS and SOA records.
| Situation | Allowed? | Instead |
|---|---|---|
CNAME at www | Yes | - |
| CNAME at the apex | No | A/AAAA, or an ALIAS/ANAME record if the provider supports it |
| CNAME plus MX on the same name | No | Move mail to a subdomain, or use an A record |
| CNAME plus TXT on the same name | No | Use the target name directly, or a provider flattening feature |
| CNAME to a name that no longer resolves | Technically yes | Remove it - dangling aliases are a takeover risk |
⚠️
Never point a CNAME at a hostname you do not control and no longer monitor. If the target is deleted, whoever registers it next inherits your traffic - this is how subdomain takeover happens.
FAQ
Do I need both A and AAAA?
Add AAAA only if the server truly answers on IPv6. Half-configured IPv6 makes some clients wait for a timeout before falling back, which looks like random slowness.
Why do platforms ask me to CNAME to them?
It lets them change IPs and route you through their edge without you editing records. That is also why you must not delete the record while using the service.
Related
How name resolution works Custom domains and TLS
Last refreshed 2026-09-18.