DNS Records Explained: A, AAAA, CNAME, MX, TXT and More

DNS Records Explained: A, AAAA, CNAME, MX, TXT and More

The Domain Name System (DNS) is the address book of the internet. When someone types example.sa into a browser or sends email to you@example.sa, DNS is what translates that human-friendly name into the machine instructions that actually route the request. Those instructions live in DNS records — small, structured entries stored in your domain's zone.

Getting these records right is the difference between a site that loads, email that arrives, and SSL that validates — versus hours of confusing downtime. This guide explains the records you will actually touch, with correct syntax and real-world examples.

How a DNS record is structured

Every record shares the same basic shape:

NAME        TTL     CLASS   TYPE    VALUE
www         3600    IN      A       192.0.2.10

• NAME — the hostname the record applies to (www, @ for the root domain, or * for a wildcard).
• TTL (Time To Live) — how many seconds resolvers may cache the answer. Lower it (e.g. 300) before a planned change, raise it (3600+) once stable.
• TYPE — the record type, covered below.
• VALUE — the data: an IP address, another hostname, or text.

The core records

A record — name to IPv4

The A record maps a hostname to an IPv4 address. This is the most common record on the internet.

@       3600    IN  A   192.0.2.10
www     3600    IN  A   192.0.2.10

Use it to point your domain at a web server, cloud hosting instance, or VPS.

AAAA record — name to IPv6

The AAAA record ("quad-A") does the same job for IPv6 addresses. If your server has an IPv6 address, publish both A and AAAA so dual-stack clients can reach you over either protocol.

@       3600    IN  AAAA    2001:db8::10

CNAME record — name to another name

A CNAME (Canonical Name) aliases one hostname to another. It is ideal when several names should follow a single target — for example pointing www and shop at the same place, or pointing a subdomain at a CDN or SaaS endpoint.

www     3600    IN  CNAME   example.sa.
blog    3600    IN  CNAME   hosting.provider.net.

Two rules matter:

• Never put a CNAME on the root/apex (@, e.g. example.sa) alongside other records like MX or NS — it breaks the zone. Use an A record (or your DNS provider's ALIAS/ANAME flattening) at the apex instead.
• A CNAME's target must itself resolve via A/AAAA; chaining many CNAMEs adds latency.

MX record — where email goes

MX (Mail Exchanger) records tell the world which servers accept mail for your domain. Each has a priority (lower number = preferred); a second, higher-priority backup adds resilience.

@       3600    IN  MX  10  mail.example.sa.
@       3600    IN  MX  20  backup-mail.example.sa.

The MX value must be a hostname (with its own A/AAAA record), never an IP address. If you run business email hosting, your provider gives you the exact MX targets to publish.

TXT records — verification, SPF, DKIM, DMARC

TXT records hold arbitrary text. In practice they carry the three records that keep your email trusted and out of spam folders:

TXT is also how you prove domain ownership to services like Google Search Console (google-site-verification=...).

NS records — who is authoritative

NS (Name Server) records list the authoritative servers for your zone. They are set both at your registrar (the delegation) and inside the zone itself, and they must match.

@       86400   IN  NS  ns1.alskyline.com.
@       86400   IN  NS  ns2.alskyline.com.

Less common but useful records

• SRV — locates a service on a host and port, used by SIP, XMPP, Microsoft autodiscover, etc.: _sip._tcp 3600 IN SRV 10 5 5060 sip.example.sa.
• PTR — reverse DNS, mapping an IP back to a name. Set on the IP's network (often by your hosting provider), it is essential for email deliverability.
• CAA — restricts which Certificate Authorities may issue SSL certificates for your domain: @ 3600 IN CAA 0 issue "letsencrypt.org".

A worked example: a full small-business zone

@       3600    IN  A       192.0.2.10
www     3600    IN  A       192.0.2.10
@       3600    IN  AAAA    2001:db8::10
shop    3600    IN  CNAME   example.sa.
@       3600    IN  MX  10  mail.example.sa.
mail    3600    IN  A       192.0.2.20
@       3600    IN  TXT     "v=spf1 include:_spf.example.sa -all"
_dmarc  3600    IN  TXT     "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.sa"
@       3600    IN  CAA  0  issue "letsencrypt.org"

Verifying your records

Always confirm changes from the command line rather than the browser, which caches aggressively:

dig example.sa A +short
dig example.sa MX +short
dig _dmarc.example.sa TXT +short
# Windows equivalent:
nslookup -type=MX example.sa

Remember that propagation is governed by your TTL. If you set a long TTL and need to change a record, resolvers that already cached the old answer will keep serving it until that TTL expires.

Why managed DNS and data residency matter

Hosting your DNS on a fast, reliable, anycast-backed platform reduces lookup latency for visitors and protects you from registrar-level outages. For organisations in the Kingdom, running DNS and the services behind it on in-Kingdom infrastructure supports PDPL, NCA and SDAIA data-residency expectations while keeping Arabic-language support close at hand.

Skyline managed DNS gives you a clean editor for every record type above, sensible default TTLs, and templates for SPF/DKIM/DMARC and .sa domains — all backed by local support.

Get started

Ready to point a domain, host a site, or run business email with full control over your DNS?

Create your Skyline Cloud account and configure your first zone in minutes — with data residency and Arabic support built in.