DNS Record Types: A Complete Reference of Syntax, Examples, and Limitations

A precise reference of DNS record types with official syntax, real examples, and the limitations of each; from A and AAAA to CAA and SVCB, for when you want the correct value, not a general explanation.

7 min Updated 15 Oct 2026

The zone file is open, the panel says the record was saved, but dig doesn't respond or returns the wrong answer. The problem is almost always in one specific place: record syntax. One extra or missing dot, one wrong space, or choosing a record type that isn't allowed in that position. This is the short reference for exactly that moment; each record with precise syntax, a real example, and the limitation you'll actually run into.

The basic structure that all DNS record types are built on

Each line in a zone file has four parts: name, TTL, class, and type, then the value. TTL and class are optional, and if you don't write them, the zone's default value applies. The class is IN in 99% of cases and is practically always omitted.

www    3600    IN    A    185.10.20.30
^      ^       ^     ^    ^
name   TTL   class  type  value

A point that trips up a lot of people: in a zone file, a name that doesn't end with a dot gets appended to the end of the zone. That is, mail becomes mail.example.com. but mail.example.com. with a trailing dot is absolute. If you drop the trailing dot in an MX or CNAME record's value, your server refers to a completely different domain and you won't get any error either.

Address records: A, AAAA, and their real limitations

A and AAAA

An A record maps an IPv4 address and AAAA maps an IPv6 address. Both can have multiple values and DNS returns the response in random order; this is the simplest form of load balancing, but it has neither health checks nor failover.

example.com.     300   IN   A      185.10.20.30
example.com.     300   IN   A      185.10.20.31
example.com.     300   IN   AAAA   2a01:4f8:c17:1234::1

The number 300 seconds matters here. If you're changing the A record for a server migration, lower the TTL to 300 or less at least 24 hours before the change, otherwise until the previous TTL expires, some users will go to the old server. We've written about the details of this behavior in the guide to DNS propagation and TTL caching.

The CNAME record and the rule they violate

CNAME aliases one name to another name, not to an IP. Its strict rule is this: at a name, CNAME cannot coexist with any other record. Not MX, not TXT, not A.

shop.example.com.   3600   IN   CNAME   example.myshopify.com.

Here's where they make a mistake: they put the CNAME record on the domain root (example.com.) and then find that email doesn't work or the domain verification TXT record has disappeared. Some DNS providers hide this with CNAME flattening, and the problem isn't seen until the day a third-party service needs another record at that same name. If you need to connect the domain root to an external service, use an ALIAS or ANAME record, not a raw CNAME.

Email records: MX, SPF, DKIM, and DMARC

MX

An MX record has two parts: a priority number and a server name. A lower number means higher priority. If you set two servers with the same priority, the order becomes random and this is almost always a misconfiguration.

example.com.   3600   IN   MX   10   mail1.example.com.
example.com.   3600   IN   MX   20   mail2.example.com.

The MX value must be a name, not an IP. Writing an IP address in the value column is a common error that some panels silently accept and others reject.

SPF, DKIM, and DMARC

These three are TXT records with specific names. SPF sits on the root and only one SPF record is allowed; two TXT records with v=spf1 cause a permerror and the result is all emails failing.

example.com.                3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"
sel1._domainkey.example.com. 3600 IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
_dmarc.example.com.         3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

The 10-lookup limit in SPF is a real limitation, not a recommendation. Each include, a, and mx consumes one lookup, and exceeding 10 causes a permerror. If your SPF has reached 8, there's no room to add an include; it needs to be rewritten.

Service and routing records: SRV, CAA, TXT, and NS

SRV

SRV has four values: priority, weight, port, and target. It's used for services like SIP, XMPP, and Minecraft.

_sip._tcp.example.com.   3600   IN   SRV   10 60 5060 sipserver.example.com.

The SRV record name always starts with an underscore: _service._proto.name. If you remove the underscore, the record is valid but no one queries it.

CAA

CAA determines which CA is authorized to issue an SSL certificate for your domain. If you set CAA and authorize the wrong CA, automatic certificate renewal fails and the site comes up with an expired certificate error.

example.com.   3600   IN   CAA   0 issue "letsencrypt.org"
example.com.   3600   IN   CAA   0 iodef "mailto:security@example.com"

TXT and NS

TXT has a length limit: each string is at most 255 characters and the whole record is up to about 4096 bytes. For long values like a DKIM key, break the string into several parts inside quotes; the DNS software concatenates them itself.

An NS record in your own zone only makes sense for subdomains (delegation). Changing the root NS record from inside the DNS panel is usually ineffective, because the root NS is registered in the registry, not in the zone. For .ir domains, this is done from the IRNIC panel; the details are in the guide to registering and managing .ir domains with an IRNIC handle.

Quick comparison of DNS record types

TypeValueMultiple values?Key limitation
AIPv4YesNo health check
AAAAIPv6YesIf the server has no IPv6 route, extra latency is added
CNAMEAbsolute nameNoNot allowed alongside any other record
MXPriority + nameYesThe value must be a name, not an IP
TXTStringYesOnly one SPF is allowed
SRV4 numbers + nameYesThe name must start with _
CAAflag + tag + valueYesWrong CA = SSL renewal failure
PTRAbsolute nameNoIn the in-addr.arpa zone and controlled by the IP provider

I'm highlighting the PTR record separately because it has the most misunderstandings. You can't create PTR in your domain's DNS panel; the IP provider must set it. If you have a mail server and the PTR doesn't match your helo name, Gmail rejects the email and the error message isn't explicit either.

The order to check when something doesn't work

  1. With dig +trace example.com, see which level the answer comes from.
  2. With dig @1.1.1.1 example.com A +short, compare the public resolver's answer with the authoritative answer.
  3. If they differ, the TTL hasn't expired; wait, rather than saving the record again.
  4. For email, run dig example.com TXT +short and count how many v=spf1 records came back.

The complete order of checking and the signs of each step are in the practical guide to DNS troubleshooting. If you want to see from the outside what resolvers see, use the DNS record lookup tool; it's faster than clearing your browser cache.

Choosing TTL: a decision that creates regret later

The 3600-second default is correct for static records. For records that might change during a migration or failover, 300 seconds is more reasonable. But a short TTL has a cost: the query load on your nameserver multiplies, and if your DNS is on weak infrastructure, it itself becomes a source of outages. For high-traffic domains, I only set TTL 300 on A and CNAME records and keep the rest at 3600.

If your destination server is a VPS and you want to set up the A record through to the SSL certificate all at once, the order of work is laid out step by step in the guide to connecting a domain to a virtual server. For dynamic subdomains, the wildcard record and subdomain management guide also has a tip that saves you from creating hundreds of manual records.

One practical note: if you're hosting DNS on infrastructure you control yourself, nameserver stability is as important as web server stability. For small and medium loads, Linux hosting with full access to the zone file is a reasonable place to start.

Frequently asked questions

Can you put a CNAME record on the domain root?

By the standard, no. A CNAME on the root conflicts with NS and SOA records. Some providers simulate this with CNAME flattening and it appears to work, but if you later want to put an MX or TXT record at that same name, you'll run into trouble. The correct way is an ALIAS or ANAME record.

Why do I still see the old IP after changing the record?

Because the previous record's TTL hasn't expired and resolvers return the cached answer. With dig @8.8.8.8 example.com A +short, see the resolver's answer and compare it with the authoritative answer using dig @ns1.example.com example.com A +short. A difference means caching, not a configuration error.

How many SPF records can I have?

Only one. Two TXT records with v=spf1 cause a permerror and the result is validation failing. If you need a new service, add the include to that same existing record and watch out for the 10-lookup limit.

Where do I set the PTR record?

You can't from your domain's DNS panel. PTR is placed in the in-addr.arpa zone, which is controlled by the owner of the IP block. You must ask your server or IP provider to set it to your helo name. For mail servers, this isn't optional.

Before any change, run dig +short once and save the output. When something breaks, that one line is the difference between five minutes and five hours of troubleshooting.

Was this page helpful?