DNS records explained
What each DNS record type does, in plain English: A, AAAA, CNAME, MX, TXT, NS and the rest, and which ones matter for security.
Your DNS zone is a set of records, each a different kind of instruction. Here's what each type does, and why an unexpected change to it matters.
A / AAAA Address records
An A record points a hostname at an IPv4 address; AAAA does the same for IPv6. This is how example.com becomes a server your browser can reach.
Why it matters: If an attacker changes your A/AAAA record, they repoint your domain at their server: the classic DNS hijack. Because A/AAAA are the records users actually hit, an unexpected change here is the highest-severity alert of all.
The details
A records hold a 32-bit IPv4 address, AAAA a 128-bit IPv6 address. A hostname can have several of each for redundancy and load spreading; resolvers typically rotate through them.
When a site sits behind a CDN or proxy (e.g. Cloudflare), these records point at the provider's edge, not your origin, and those edge addresses rotate on their own.
CNAME Canonical name (alias)
A CNAME makes one hostname an alias for another, e.g. www.example.com → example.com. The resolver follows the alias to find the real address.
Why it matters: A CNAME aimed at a service you no longer own is the setup for a subdomain takeover: if that target is de-provisioned, an attacker can claim it and serve content from your subdomain. Dangling CNAMEs are worth auditing regularly.
The details
A CNAME must point to a name, never an IP, and can't coexist with other records on the same name (which is why you can't CNAME a bare apex in classic DNS, hence provider "CNAME flattening").
CNAMEs commonly point at third-party services (a SaaS app, a CDN, a status page).
MX Mail exchange
An MX record says which mail servers accept email for your domain, each with a priority number (lower = tried first).
Why it matters: Change the MX and you reroute a domain's inbound mail, a stealthy way to intercept password resets and confidential messages. MX changes should always be intentional and alert-worthy.
The details
MX values are hostnames (which then need their own A/AAAA), plus a 16-bit priority. Multiple MX records give failover; equal priorities load-balance.
NS Name server
An NS record delegates a zone to the authoritative name servers that answer for it. These are the source of truth for every other record in the domain.
Why it matters: Changing NS records hands the entire domain to a different provider, the most total form of DNS hijack. Unexpected NS changes are a five-alarm event.
The details
The parent zone (e.g. the .com registry) publishes NS records pointing at your provider's name servers; your provider then serves the rest of the zone.
SOA Start of authority
The SOA record holds zone-level metadata: the primary name server, an admin contact, and the timers that govern how secondaries refresh and how long errors are cached.
Why it matters: Rarely attacked directly, but the SOA reveals the authoritative primary and the negative-cache TTL, which affects how long a bad answer (or an outage) lingers.
The details
It carries a serial number that increments on every zone change, plus refresh/retry/expire and a negative-cache TTL. Monitoring deliberately ignores the serial, it bumps on every edit and would otherwise be constant noise.
TXT Text records
A TXT record holds free-form text. In practice it's where domain policy lives: SPF, DKIM and DMARC for email auth, plus ownership-verification strings for various services.
Why it matters: Because email authentication is stored in TXT, a tampered or missing TXT record can silently disable your spoofing protection. Validating these against the RFCs, not just checking they exist, is what actually protects you.
The details
SPF lives in a TXT at the apex; DMARC at _dmarc.yourdomain; DKIM at selector._domainkey.yourdomain. See the email-security guide for how they fit together.
CAA Certification authority authorization
A CAA record names which certificate authorities are allowed to issue TLS certificates for your domain. CAs are required to honour it.
Why it matters: CAA is a guardrail against mis-issuance, a rogue or tricked CA handing someone else a valid certificate for your domain. Missing CAA leaves any CA free to issue.
The details
e.g. 0 issue "letsencrypt.org" permits only Let's Encrypt. You can also set an iodef address to be notified of policy violations.
SRV Service record
An SRV record advertises the host and port for a specific service (SIP, XMPP, Microsoft services, etc.), with priority and weight for selection.
Why it matters: Tampering can redirect a service (like VoIP or chat) to an attacker's host. Less common than A/MX attacks, but worth tracking where services depend on them.
The details
Named as _service._proto.name (e.g. _sip._tcp.example.com) and carrying priority, weight, port and target.
PTR Pointer (reverse DNS)
A PTR record maps an IP address back to a hostname, the reverse of an A record. It's used mostly to establish mail-server reputation.
Why it matters: Mail receivers often reject or penalise senders whose IP lacks matching forward/reverse DNS, so a missing PTR quietly hurts deliverability.
The details
PTRs live in the reverse zone (in-addr.arpa / ip6.arpa) and are usually set by whoever controls the IP block (your host), not in your forward zone.
DNS Canary monitors all of these record types, records a full change history, and grades your domain A–F, so an unexpected A, MX or NS change reaches you by email instead of going unnoticed.