Outrings
Web observability and evidence

What do my DNS records actually say?

Reading your own DNS from first principles — which records exist, what each one decides, and the four commands that show you all of them.

4 min read
Short answer

DNS is the layer that decides where your website is served from, where your email is delivered, who is allowed to send mail as you, and who may issue certificates for your domain. Most of it is invisible in a browser and all of it is one dig command away.

The records that matter, and what each one decides

RecordDecidesSymptom when wrong
A / AAAAWhich IP address serves the siteSite unreachable, or serving from the wrong place
CNAMEThat this name is an alias for anotherRedirect loops; cannot coexist with other records at the apex
MXWhere email for the domain is deliveredInbound mail silently lost
TXT (SPF)Which servers may send mail as youYour legitimate mail goes to spam
TXT (DMARC)What to do with mail that fails authenticationAnyone can forge your domain
CAAWhich certificate authorities may issue for youAny CA can issue a certificate for your domain
NSWhich nameservers are authoritativeChanges never take effect — you are editing the wrong zone

Reading them yourself

dig +short A example.com
dig +short AAAA example.com
dig +short MX example.com
dig +short NS example.com
dig +short CAA example.com
dig +short TXT example.com            # SPF lives among these
dig +short TXT _dmarc.example.com     # DMARC has its own name

Two of those are commonly missed. SPF is not its own record type — it is a TXT record beginning v=spf1, sitting alongside verification strings from every service you have ever connected. DMARC is a TXT record at the _dmarc subdomain, which is why looking at the apex and seeing nothing means nothing.

The mistakes that actually happen

Two SPF records

The rule is one v=spf1 record per domain. Adding a second — usually when a new mail service is connected without noticing the first — makes the whole thing a permanent error, and receivers treat it as no SPF at all. Merge them into one record with multiple include: terms.

More than ten DNS lookups in SPF

Each include:, a, mx and redirect costs a lookup, and the limit is ten in total, counted recursively through everything you include. Exceed it and the result is permerror, which most receivers treat as a failure. Four or five providers is enough to breach it without any single one looking excessive.

DMARC left at p=none forever

p=none means "monitor and do nothing", which is the correct place to start and a poor place to stay. Until you move to quarantine or reject, the policy is documentation rather than protection.

A CNAME at the apex

The apex — example.com with no subdomain — cannot hold a CNAME alongside the NS and SOA records it must have. Some providers offer ALIAS or ANAME as a workaround; a genuine apex CNAME is a misconfiguration even where the interface allows it.

No CAA record

Without one, any public certificate authority may issue a certificate for your domain. Adding one is a single line and narrows that to the CAs you actually use.

example.com. IN CAA 0 issue "letsencrypt.org"
A change you made hours ago and cannot see is usually a TTL, not an error. Check the current TTL with dig example.com and read the number in the answer section — that is how long resolvers were told to cache the old value. Lower TTLs before a planned change, not after.

Checking the right zone

One diagnostic worth knowing when nothing you edit takes effect. Compare the nameservers the registrar publishes against the ones you are editing:

dig +short NS example.com

If those are not the nameservers of the provider whose control panel you have open, you have been editing a zone nobody is reading. This is a surprisingly common outcome after a host migration, and no amount of waiting fixes it.

What our audit reports about this

Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.

  • Every A, AAAA, MX, NS, CAA and TXT record as returned by the resolver, with the values shown rather than summarised.
  • SPF parsed and validated — syntax, a count of the DNS lookups it costs, and whether more than one record exists.
  • DMARC policy read from _dmarc, reporting whether it is none, quarantine or reject.
  • Whether a CAA record exists and which authorities it permits. DNSSEC validation and DKIM are reported as untested, with the reason.

For agents and scripts, the same measurement is at /api/v1/dns?url=yoursite.com — see the API documentation.

Related questions

Why can I not see a change I made?

Almost always TTL caching. Resolvers were told to hold the previous value for a set time and they are doing exactly that. If it persists well beyond the TTL, verify with dig +short NS that you are editing the zone your registrar actually delegates to.

Do I need both A and AAAA records?

An A record is required. AAAA adds IPv6, which a growing share of networks prefer — worth having, and not urgent. What matters is that if you publish an AAAA it must actually work, since clients that prefer IPv6 will try it first and a broken one is worse than none.

Is DNSSEC checked?

It is reported as untested, with the reason given. Validating a DNSSEC chain properly requires a validating resolver and trust-anchor handling that a shared PHP host cannot honestly guarantee, so it is declared as not measured rather than guessed at.

How do I know if my SPF is too long?

Count every include, a, mx and redirect term, following each include into the records it points at. Ten total is the limit. The audit reports the count directly, which is quicker than tracing it by hand.

Read next

All 100 guides · How every check works · API for agents