DNS Records Cheat Sheet: A, AAAA, CNAME, MX, TXT, NS, CAA

This is a quick reference you can keep open while editing a zone. Each record type has its format, a realistic example, a dig command to check it, and the mistake people make most often with it. For the concepts behind DNS (resolvers, delegation, caching), start with DNS explained for website owners. Here the aim is speed and accuracy.

All examples use example.com and addresses from documentation ranges (203.0.113.0/24, 198.51.100.0/24 and 2001:db8::/32), which are reserved for examples and never route on the real internet.

The summary table

A and AAAA

An A record maps a hostname to an IPv4 address. AAAA does the same for IPv6.

example.com.       3600  IN  A     203.0.113.10
example.com.       3600  IN  AAAA  2001:db8::10
www.example.com.   3600  IN  A     203.0.113.10

Several A records for one name give you simple round-robin distribution, and clients may try them in any order. This is not health-checked load balancing; if one server dies, some visitors still get its address until you remove it. See load balancer health checks for real failover.

dig +short example.com A
dig +short example.com AAAA

Common mistake: leaving an old AAAA record after moving servers. Browsers prefer IPv6 when it works, so the site appears to load the old server for IPv6 users or time out for them while IPv4 users are fine.

CNAME

A CNAME makes one name an alias of another. The resolver restarts the lookup at the target.

www.example.com.    3600  IN  CNAME  myshop.platform-example.net.
blog.example.com.   3600  IN  CNAME  hosting.example.org.

Rules: a name with a CNAME cannot have any other record type (so no MX, TXT, or A at the same name), and CNAMEs at the zone apex are not allowed. The reasons and the workarounds are in CNAME flattening and the apex domain.

dig www.example.com CNAME +short

Common mistake: pointing the apex CNAME at a platform, or adding a CNAME at the same name as your _dmarc TXT or MX records, which silently breaks mail. Another is leaving CNAMEs to services you cancelled; see subdomain takeover.

MX

MX records tell other mail servers where to deliver mail for your domain.

example.com.  3600  IN  MX  10  mx1.mailhost.example.net.
example.com.  3600  IN  MX  20  mx2.mailhost.example.net.

The number is a preference: lower is tried first. The target must be a hostname with its own A/AAAA record and must not be an IP address or a CNAME. If you have no mail, publish a "null MX" (0 .) to tell senders not to try.

dig +short example.com MX

Common mistake: keeping an old MX with a lower priority number than the new provider's, so mail keeps going to the old system. The MX lookup tool shows the current set, and MX records explained goes deeper.

TXT

TXT records hold arbitrary text, and most of what you do with them is email authentication and domain verification.

example.com.                  3600  IN  TXT  "v=spf1 include:_spf.mailhost.example.net -all"
_dmarc.example.com.           3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
selector1._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0G..."
example.com.                  3600  IN  TXT  "google-site-verification=abc123"

A single TXT string is limited to 255 characters, but a record can contain several quoted strings that the receiver concatenates, which is how long DKIM keys are published. Many TXT records at one name are fine. The exception is SPF: there must be exactly one v=spf1 record per name.

dig +short example.com TXT
dig +short _dmarc.example.com TXT

Common mistakes: two SPF records at the apex, and more than ten DNS lookups inside SPF (fix guide). Use the SPF record checker and read SPF, DKIM and DMARC.

NS

NS records name the authoritative nameservers for a zone.

example.com.  86400  IN  NS  ns1.example-dns.com.
example.com.  86400  IN  NS  ns2.example-dns.com.

There are two places these exist: in your zone, and as delegation records at the registry (set through your registrar). They should match. Use at least two nameservers on different networks.

dig +short example.com NS
dig +trace example.com

Common mistake: changing NS records inside the zone without changing them at the registrar. Only the registrar's delegation actually moves the domain. See change nameservers without downtime and the nameserver lookup.

SOA

The Start of Authority record describes the zone. You do not usually edit it by hand, as your DNS host manages it.

example.com. 3600 IN SOA ns1.example-dns.com. hostmaster.example.com. (
    2026100501 ; serial
    7200       ; refresh
    3600       ; retry
    1209600    ; expire
    300        ; minimum (negative-caching TTL)
)

Fields: the primary nameserver, the admin mailbox (the first dot stands for @), the serial number (usually a date plus counter) that secondaries use to detect changes, refresh/retry/expire timers for secondary servers, and the minimum, which is today used as the negative-caching TTL (see TTL explained).

dig +short example.com SOA

Common mistake: forgetting to bump the serial when self-hosting with secondaries, so they never update.

CAA

Certification Authority Authorization records restrict which CAs can issue certificates for your domain. CAs must check them before issuing.

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issuewild ";"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

issue allows a CA to issue regular certificates, issuewild controls wildcards (";" forbids them), and iodef is a contact for policy violations. If any CAA record exists and none authorizes your CA, issuance fails. If there are no CAA records, any CA may issue.

dig +short example.com CAA

Common mistake: adding a CAA for one CA and forgetting that a hosting platform or CDN uses another to issue its managed certificates. If renewals suddenly fail with "CAA record prevents issuance", see Let's Encrypt renewal failures.

SRV

SRV records locate a service by name, giving priority, weight, port and target.

_sip._tcp.example.com.  3600  IN  SRV  10 60 5060 sip1.example.com.
_sip._tcp.example.com.  3600  IN  SRV  10 40 5060 sip2.example.com.
_submission._tcp.example.com. 3600 IN SRV 0 1 587 smtp.mailhost.example.net.

Fields in order: priority (lower first), weight (share among equal priorities), port, and target hostname. The name encodes the service and protocol with leading underscores. Websites do not use SRV, but Microsoft 365, XMPP, SIP and Minecraft-style game servers do.

dig +short _sip._tcp.example.com SRV

Common mistake: pointing an SRV target at a CNAME, which the specification forbids, or forgetting the trailing dot in a hand-edited zone file so the name is appended to the zone.

PTR

PTR records map an IP address back to a hostname. They live in the special in-addr.arpa zone for IPv4 and ip6.arpa for IPv6, and are controlled by the owner of the IP block, usually your hosting provider or ISP, not by your domain's DNS host.

10.113.0.203.in-addr.arpa.  3600  IN  PTR  mail.example.com.

The octets are reversed. Use dig -x:

dig -x 203.0.113.10 +short

PTR matters for mail: many receivers expect the sending IP's PTR to resolve to a hostname whose A record points back to the same IP (forward-confirmed reverse DNS). Set it in your hosting control panel or by asking the provider. See reverse DNS and PTR for email and the reverse IP lookup tool.

Other records you may run into

• DNSKEY, DS, RRSIG: DNSSEC data. Check with the DNSSEC checker and read DNSSEC explained.
• HTTPS and SVCB: Newer records that advertise HTTP/2, HTTP/3 and alternative endpoints for a name.
• NAPTR, TLSA, SSHFP: Specialist records for telephony, DANE, and SSH fingerprints.

Reading a full dig answer

$ dig example.com MX

;; ANSWER SECTION:
example.com.   3600   IN   MX   10 mx1.mailhost.example.net.

Columns: name, remaining TTL in seconds, class (almost always IN), type, and data. Add +noall +answer for clean output and @8.8.8.8 to choose a resolver. Use +trace to follow delegation from the root.

Zone editing checklist

1. Check whether the DNS panel wants a fully qualified name with a trailing dot, or appends the zone automatically. A target like mail.example.com entered without a trailing dot in a raw zone file becomes mail.example.com.example.com..
2. Do not create a CNAME where other records already exist.
3. Keep the apex records (MX, TXT, CAA) in place when adding or flattening an apex pointer.
4. Lower TTLs ahead of a planned change; raise them afterward.
5. Verify from the authoritative servers and from public resolvers, using the DNS checker.
6. Document why each record exists. Orphaned records are how takeovers and mail failures start.

अगले कदम

• Inspect every record type on your domain with the DNS checker.
• Verify mail routing with the MX lookup और SPF record checker.
• Confirm delegation using the nameserver lookup and domain details with WHOIS.
• Get alerted on unexpected edits with DNS change alerts in the uptime monitor.

सामान्य प्रश्न

What is the difference between an A record and a CNAME?

An A record maps a name directly to an IPv4 address. A CNAME maps a name to another name, and the resolver follows that name to find the address.

Can I have multiple TXT records on one name?

Yes, with the exception that SPF must be a single v=spf1 record. Verification and DKIM TXT records can coexist with it.

Do I need AAAA records?

Not required, but useful if your server and network support IPv6. If you publish AAAA, make sure it actually works; a broken IPv6 address is worse than none.

Who controls my PTR record?

Whoever allocated the IP address to you, usually your hosting provider. You cannot set it in your domain's DNS zone.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.