DNS records explained: A, AAAA, CNAME, MX, TXT, NS and more

A DNS record gives one precise instruction about a domain. Use A or AAAA for server addresses, CNAME for an alias, MX for incoming mail, TXT for verification and email policy, and NS for authoritative DNS. The safest workflow is to copy the exact value supplied by the service, preserve unrelated records, and verify the public answer after the change.

Quick reference: choose the record by the job

A complete example zone for web and email

Assume example.hn hosts its website at 203.0.113.10, uses a vendor for email, and publishes a DMARC monitoring policy. A practical zone can contain the following records. The names and values are examples only, so replace every provider value with the instructions for your real service.

• Website: example.hn A 203.0.113.10 and www.example.hn CNAME example.hn.
• Mail delivery: example.hn MX 10 mx1.mail-provider.example and MX 20 mx2.mail-provider.example.
• Sender policy: example.hn TXT with the single SPF policy supplied by the mail provider.
• DKIM and DMARC: selector1._domainkey.example.hn TXT for the public key, and _dmarc.example.hn TXT for policy and reports.
• Certificates: example.hn CAA 0 issue letsencrypt.org when that is the authority actually used.

How the records behave

A and AAAA point directly to servers

An A record returns an IPv4 address; AAAA returns IPv6. Publishing both is useful only when the application works on both networks. A broken AAAA record can make a site fail for visitors whose devices prefer IPv6 even while IPv4 tests look healthy.

CNAME follows another name; ALIAS and ANAME flatten it

A CNAME delegates the final address lookup to another hostname. Standard DNS does not allow a CNAME at the zone apex because that name must also contain SOA and NS data. Some DNS providers offer ALIAS, ANAME or CNAME flattening at the apex, but these are provider features rather than a single universal record type.

MX routes mail, while TXT proves and authorizes

MX preference uses lower numbers first, but backup MX records still need valid configuration. TXT records do not route mail; they publish statements such as SPF authorization, DKIM public keys, DMARC policy or service verification. Keep exactly one SPF record at each sending name and merge authorized senders into that policy.

NS, SOA, SRV, CAA and PTR solve operational jobs

NS identifies the authoritative DNS service. SOA carries the zone serial and refresh timing used by DNS infrastructure. SRV advertises a service location and port. CAA limits certificate issuance but must include every authority your platforms need. PTR is controlled by the owner of the IP address, usually the hosting or network provider, not by the ordinary forward DNS zone.

TTL and planned changes

TTL is the number of seconds a recursive resolver may cache an answer. Lower the TTL before a planned migration, wait at least the previous TTL, make the change, test, and raise it after the new service is stable. Lowering TTL after an incorrect record is already cached cannot recall the old answer from resolvers that still hold it.

Common mistakes that break websites or email

• Replacing the whole zone: Change only the records required by the new service and export the old zone before editing.
• Using a CNAME at the apex: Use A, AAAA or a documented ALIAS or ANAME feature instead.
• Publishing two SPF records: Combine senders into one valid SPF policy and stay within the DNS lookup limit.
• Leaving stale AAAA or MX records: Remove only after confirming the replacement works and the old TTL has elapsed.
• Editing the wrong DNS provider: Check the delegated NS records before assuming the panel you opened is authoritative.

Verify the public answer before closing the change

1. Delegation: Run dig NS example.hn and confirm the nameservers match the DNS panel you edited.
2. Website: Run dig A example.hn and dig AAAA example.hn, then test the HTTPS hostname in a browser.
3. Email: Run dig MX example.hn and dig TXT example.hn, plus dig TXT _dmarc.example.hn.
4. Resolver comparison: Query a public resolver such as dig @1.1.1.1 A example.hn when local cache behavior is unclear.

Apply the same DNS discipline to a country domain

A ccTLD uses the same core DNS record types as .com. The difference is the registration layer: a country registry may require a local contact, documents, a minimum term or manual review before the name is active. Review those conditions and the renewal price first, then build and verify the DNS zone with the checklist above.