What is a DNS record? DNS records explained

The one-sentence version

A DNS record is a single instruction stored against your domain that tells the rest of the internet one fact about it: where your website lives, where your email should be delivered, or which security policies you publish. Your domain's DNS is just a list of these records, and almost everything that can break your email is one line in that list.

The anatomy of a record

Whatever its type, every DNS record is built from the same handful of parts. Once you can read these four, you can read any record:

• Name (the host). Which name the record applies to: the bare domain, www, _dmarc, and so on.
• Type. What kind of answer it gives (A, MX, TXT, and the rest below).
• Value. The answer itself: an IP address, a hostname, or a block of text.
• TTL. How many seconds resolvers are allowed to cache the answer before they ask again. This is why a change is not always instant.

There is also a class field, almost always IN (for Internet), that you will rarely think about. Written out in full, a record reads left to right as name, TTL, class, type, value:

example.com.   3600   IN   A      203.0.113.10
_dmarc.example.com.   3600   IN   TXT   "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

The record types you will actually meet

Dozens of record types exist, but a small set does almost all the real work. These are the ones you will run into setting up a domain and its email:

• A links a name to its IPv4 address. AAAA does the same for IPv6.
• CNAME is an alias: it points one name at another name.
• MX tells other servers where to deliver email addressed to your domain.
• TXT holds free-form text, and is where SPF, DKIM, and DMARC all live.
• NS names the servers that are authoritative for your domain, the ones that answer for it.
• SOA holds the zone's own metadata: a serial number and the timers that govern caching.
• PTR is reverse DNS: it maps an IP address back to a name, and lives in a special in-addr.arpa tree rather than alongside your other records.
• SRV says where to find a particular service, such as the endpoint a mail client uses to auto-configure itself.
• CAA lists which certificate authorities are allowed to issue certificates for your domain.
• DNSKEY, DS, and RRSIG are the records that make up DNSSEC, the cryptographic signing layer for DNS.

Why DNS is your email's control plane

Email authentication is not a separate system bolted onto your domain. It is DNS. Every policy a receiving mail server checks before it decides to trust a message from you is published as a record you control:

• SPF, DKIM, and DMARC are all TXT records, at your domain, at <selector>._domainkey, and at _dmarc.
• MTA-STS and TLS-RPT add two more TXT records that govern inbound encryption and its reporting.
• BIMI, the brand logo some inboxes show next to your name, is another.
• And the MX record decides where mail addressed to you is delivered in the first place.

One nuance is worth knowing, because it is the exception. MTA-STS is not only DNS: its TXT record merely advertises that a policy exists, while the policy itself is fetched over HTTPS from a fixed URL on your domain. (BIMI similarly points at a hosted logo file.) Everything else on that list is pure DNS. We cover the encryption pieces in MTA-STS and TLS-RPT for the security-curious.

The practical takeaway: a single wrong character in one of these records is enough for mailbox providers to stop trusting you, and DNS itself will never warn you.

Why a wrong record fails silently

Most broken DNS records announce themselves. Get an A record wrong and your website will not load; someone notices within minutes. Email-authentication records are different. They fail quietly:

• The check happens on the receiver's side, not yours, so nothing on your end logs it.
• A failure usually means your message is filed as spam, or bounced back to the original sender, who rarely forwards the bounce to you.
• By the time anyone connects “our email stopped landing” to a DNS change made three weeks ago, real mail has already been lost.

The only way to see it is to read the aggregate (RUA) reports mailbox providers send back, or to have something watch them for you. That gap, between a record breaking and anyone noticing, is the entire reason DMARC monitoring exists. trustyourinbox reads your email records continuously and tells you, in plain English, the moment one drifts.

Common questions

Where do I actually edit my DNS records?

At whoever your NS records point to, which is not always your registrar. If you bought your domain in one place but moved its nameservers to another host, the second host is the only place your edits take effect. Our universal provider guide shows how to find the right one.

How many DNS records can one domain have?

For practical purposes, as many as you need. A typical business domain carries a dozen or more: a couple of address records, an MX or two, and a stack of TXT records for SPF, DKIM, DMARC, and various service verifications. The risk is not the count, it is that one wrong one hides quietly among the rest.