DNS is the system that turns human-friendly names into the addresses and instructions computers actually use. If you have ever pointed a domain at a server or set up email, you have edited DNS records — possibly without fully understanding what each one does. Here is a clear guide to the records you will actually encounter.
A Record
An A record maps a hostname to an IPv4 address. When someone types your domain, the A record tells their browser which IPv4 address to connect to. It is the most fundamental record for pointing a name at a server.
Example: example.com → 203.0.113.10
AAAA Record
An AAAA record (“quad-A”) does the same job as an A record but for IPv6 addresses. As IPv6 adoption grows, having an AAAA record alongside your A record lets IPv6-capable clients reach you over IPv6.
Example: example.com → 2001:db8::10
CNAME Record
A CNAME record (canonical name) points one hostname to another hostname rather than to an IP. It is useful when you want several names to follow wherever a primary name goes — for example pointing www.example.com to example.com. A common rule: you generally cannot use a CNAME at the root of a domain (the bare example.com), only on subdomains.
MX Record
An MX record (mail exchange) tells the world which mail servers receive email for your domain, and in what priority order. Lower priority numbers are preferred. Without correct MX records, email addressed to your domain has nowhere to go. MX records point to hostnames (which then resolve via A/AAAA records), not directly to IP addresses.
TXT Record
A TXT record holds arbitrary text, and over time it has become the home for several important verification and email-authentication mechanisms:
- SPF — lists which servers are allowed to send mail for your domain.
- DKIM — publishes the public key used to verify signed email.
- DMARC — tells receivers what to do with mail that fails SPF/DKIM.
- Domain verification — many services ask you to add a TXT record to prove you own the domain.
NS Record
An NS record (name server) specifies which name servers are authoritative for your domain — that is, which servers hold the real DNS records. These are usually set at your domain registrar and point to your DNS provider’s name servers.
Other Records You Might Meet
- SRV — specifies the host and port for specific services (used by some applications like VoIP and chat).
- CAA — declares which certificate authorities may issue TLS certificates for your domain.
- PTR — reverse DNS, mapping an IP back to a hostname (set by whoever controls the IP block).
The Role of TTL
Every record has a TTL (time to live), the number of seconds resolvers may cache it. A low TTL means changes propagate quickly but increases lookups; a high TTL means better caching but slower changes. Before a planned migration, lower the TTL ahead of time so the cutover propagates fast.
PTR Records: Reverse DNS and Why Mail Servers Check It
Every record above answers "what IP does this name point to?" A PTR record answers the opposite: "what hostname belongs to this IP?" The two directions are configured independently, which is why an IP can resolve forward perfectly while having no reverse record at all.
Mail is where this bites. When your server connects to a recipient's mail server, the receiving side typically checks three things: does the sending IP have a PTR record at all, does that PTR hostname resolve forward back to the same IP (forward-confirmed reverse DNS, FCrDNS), and does the hostname look like a real mail host rather than a generic provider default. Missing or mismatched reverse DNS is one of the most common avoidable reasons outgoing mail lands in spam. It does not replace SPF, DKIM and DMARC; you need all four.
Why you usually cannot set a PTR yourself
Reverse DNS lives in the in-addr.arpa (IPv4) and ip6.arpa (IPv6) zones, and authority over those zones belongs to whoever controls the IP block, normally your hosting provider. PTR records are therefore set either through a panel the provider exposes for the IPs assigned to you, or by the provider delegating the reverse zone to your own nameservers, which is common for larger blocks. If you bring your own allocation, you control the reverse delegation yourself through your RIR.
IPv6 reverse DNS
The mechanism is the same, but ip6.arpa zones are enormous and the nibble-reversed notation is tedious to write by hand, so generate them with a tool. If your mail server sends over IPv6, set the PTR for the exact IPv6 address it uses; some receivers check it just as they do for IPv4.
Reverse DNS checklist
- Every public-facing server, and especially every mail server, has a PTR record.
- The PTR hostname resolves forward (A or AAAA) to the same IP.
- The hostname is meaningful (
mail.yourdomain.com), not a provider default. - Both IPv4 and IPv6 addresses are covered if you serve traffic on both.
On NODED you manage reverse DNS for the IPs assigned to your services from the client area, and for larger allocations we delegate the reverse zone to your nameservers.
How Noded Can Help
Whether you are pointing a domain at a new server, setting up email authentication, or planning a migration, we can help you get your DNS records right the first time. If you are configuring SPF, DKIM, and DMARC for deliverability, or you are unsure why a change has not taken effect, tell us what you are trying to do and we will walk you through the records involved.
FAQ
What is the difference between an A record and a CNAME?
An A record points a hostname to an IPv4 address. A CNAME points a hostname to another hostname, which is then resolved further. Use A records to point at servers and CNAMEs to alias one name to another.
Why isn’t my DNS change working yet?
DNS changes are cached for the duration of each record’s TTL, so updates can take time to appear everywhere. If you lowered the TTL in advance, propagation is faster. Otherwise you may need to wait for old cached values to expire.
Which records do I need for email?
At minimum, MX records to receive mail, plus TXT records for SPF, DKIM, and DMARC to authenticate outgoing mail and improve deliverability. A PTR (reverse DNS) record for your sending IP also helps.
Can I use a CNAME at my domain root?
Generally no — the root (bare domain) usually cannot be a CNAME due to how DNS works. Use an A/AAAA record at the root, or a provider feature that emulates root aliasing, and reserve CNAMEs for subdomains.