DNS Record Type Reference Guide

A reference covering the DNS record types you need for running mail and websites — A, MX, TXT, SPF, DKIM, DMARC and more — with purpose, syntax examples, and gotchas for each.

Last updated: 2026-09-20

DNS Record Types

Type	Purpose	Example	Note
A record	The most basic record type, mapping a domain name to an IPv4 address. It points to where a web server or mail server actually lives.	`example.com. 3600 IN A 192.0.2.1`	A TTL that is too short (3600 seconds = 1 hour in this example) increases load from repeated lookups against the authoritative server; too long delays propagation when the IP address changes.
AAAA record	Maps a domain name to an IPv6 address — essentially the IPv6 counterpart of the A record.	`example.com. 3600 IN AAAA 2001:db8::1`	Keeping an A record alongside it lets networks without IPv6 support fall back to IPv4 connectivity (dual-stack operation).
CNAME record	Treats one hostname as an alias for another canonical hostname — for example, pointing www.example.com to example.com.	`www.example.com. 3600 IN CNAME example.com.`	A hostname with a CNAME cannot have other records (such as MX or TXT) coexist on it (a constraint from RFC 1034). A CNAME also cannot be set at the zone root (@).
MX record	Specifies which mail server should receive mail addressed to a domain. Multiple servers can be listed with a preference value.	`example.com. 3600 IN MX 10 mail.example.com.`	A lower preference value means higher priority. Listing multiple servers at different priorities for redundancy is common. An MX target must point to a hostname with an A record, not a CNAME.
TXT record	A general-purpose record that attaches arbitrary text to a domain. Used for SPF, DKIM, and DMARC, as well as domain ownership verification and more.	`example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"`	A domain can have multiple TXT records, but placing more than one record for the same purpose (such as SPF) causes interpretation errors — consolidate them into a single record.
SPF record (a type of TXT record)	Lists the servers (IP addresses) authorized to send mail on behalf of a domain, providing sender authentication that helps prevent spoofed mail. Configured as a TXT record.	`example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all"`	Only one SPF record is valid per domain. Watch out for chains of "include" mechanisms, since exceeding the 10-DNS-lookup limit causes a permanent error. The dedicated record type (RRTYPE 99) was deprecated in 2014, so SPF is expressed purely through TXT records today.
DKIM record (a type of TXT record)	Attaches a digital signature to outgoing mail so receivers can verify the message was not tampered with in transit and came from a legitimate sender. The public key is published as a TXT record.	`selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."`	The selector (the leading part of the hostname) varies by sending service. The private key stays on the sending server — only the public key is published in DNS.
DMARC record (a type of TXT record)	Declares, based on SPF and DKIM results, how a receiver should treat mail that fails authentication (deliver it, quarantine it, or reject it) and provides a channel for receiving aggregate reports.	`_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"`	Starting with p=none for monitoring only, then tightening step by step to quarantine and reject once you have confirmed there are no issues, is the safe way to roll it out.
NS record	Identifies which servers are the authoritative DNS servers for a domain (zone) — the starting point for resolving names anywhere under it.	`example.com. 86400 IN NS ns1.example-dns.com.`	If the nameservers registered with the registrar do not match the NS records inside the zone, name resolution becomes unstable (a condition known as lame delegation).
SOA record	Holds administrative information for a zone — the primary server, administrator email, serial number, retry intervals, and more. Every zone must have exactly one.	`example.com. 86400 IN SOA ns1.example-dns.com. admin.example.com. (2026071200 3600 900 604800 86400)`	Whenever you update a zone file you must increment the serial number, otherwise secondary servers will never pick up the change (zone transfer relies on it).
CAA record	Restricts which certificate authorities (CAs) are permitted to issue certificates for a domain, preventing unintended CAs from issuing fraudulent certificates.	`example.com. 3600 IN CAA 0 issue "letsencrypt.org"`	If a domain has no CAA record at all, any CA is considered permitted to issue for it. Wildcard certificates require a separate issuewild tag.
PTR record	Resolves an IP address back to a hostname — the reverse of an A record. Configured in a reverse zone (in-addr.arpa / ip6.arpa).	`1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.`	Many mail servers flag or reject mail from senders with no reverse PTR record or one that does not match the A record, so this is effectively a required setting for outbound mail servers.

A reference to the kinds of DNS record and what each is for

This is a reference listing the DNS records a site and its mail need — A, AAAA, CNAME, MX, TXT, SPF, DKIM and DMARC — together with the purpose of each, an example of its form and the points that call for care. It serves as the place to look when you are unsure which record to write and where.

**The least widely known pitfall here is that a CNAME cannot sit at the apex of a zone, that is, at `example.com` itself.** A CNAME declares that a name is an alias, which leaves no room for any other record under the same name. Yet the apex must always carry NS and SOA records, so **pointing `example.com` at a CDN by CNAME is impossible under the specification.** Many providers work round this with proprietary ALIAS or ANAME records. **The other thing worth grasping is TTL, which states how many seconds each resolver may cache an answer.** If a migration is coming, the settled practice is **to shorten the TTL some days before the work.**

How to use it

Find the kind of record you need The entries are gathered by type: A, MX, TXT and the rest.
Check the example of its form **You can confirm the points most easily got wrong, such as how to write a host name and whether a trailing dot belongs there.**
Read the notes of caution **They set out where practice bites: the restriction on CNAME, the handling of TTL and the like.**
Verify with the related tools Once configured, you can move on to checking propagation or diagnosing the authentication records.

Tips for getting more out of it

If you are unsure about SPF, DKIM, or DMARC, diagnose your current records first with the "SPF/DKIM/DMARC Record Checker" tool, then compare them against the syntax examples on this page.
A TTL of about one hour (3600 seconds) is a safe default for ordinary records; shortening it to around 300 seconds just before a DNS migration makes the cutover propagate faster, then you can raise it again afterward.
TXT record values over 255 characters may get split into multiple strings automatically, so check that quotation marks line up correctly after copy-pasting.
If you also want to check the format of an email address itself, the "Email Address Format Validator" tool covers that gap.
When rolling out a new mail sending service, start DMARC at p=none, watch the reports for a week or two to confirm there are no issues, then switch to an enforcing policy — it is the safer path.

Where it comes in useful

Setting up a new domain

**You can establish which records are needed at the very least.**

Adding a sending source for mail

Where SPF or DKIM has to be extended, you can confirm the form it takes.

Moving to a new server

**It makes plain why the TTL should be lowered before the move.**

Looking up what a term means

The names of the fields on a configuration screen can be checked on the spot.

DNS record terms

A record: Maps a host name to an IPv4 address. The AAAA record is its IPv6 counterpart.
CNAME record: Makes one name an alias for another. **Since no other record may share that name, it cannot be used at the apex of a zone.**
MX record: Names the server that receives mail for the domain. The lower the priority number, the earlier it is tried.
TXT record: A record holding arbitrary text. **SPF, DKIM and DMARC are all written in this form.**
TTL: The number of seconds each resolver may cache an answer. **Shortening it before a migration makes the change spread quickly.**
Apex of a zone: The domain itself without any prefix such as `www`, that is, `example.com`. **No CNAME may sit here.**

Frequently Asked Questions

SPF verifies the legitimacy of the sending IP address — essentially "which server did this come from" — while DKIM verifies message integrity through a digital signature — "was the content tampered with." Only when both pass does sender authentication provide meaningful protection.

It is not a legal requirement, but major receivers such as Gmail and Yahoo Mail effectively require DMARC for bulk senders, and without it the risk of being marked as spam or rejected outright increases significantly.

Common causes include the MX target pointing to a CNAME instead of a hostname with an A record, an incorrect preference value, or the mail server itself not being configured to accept mail for that domain.

Use an A/AAAA record when the IP address is fixed and you want it set at the domain root (@); use a CNAME when you want the hostname to act as an alias for another host, such as a CDN endpoint.

For normal operation, around one hour (3600 seconds) is common. Shortening it to about 300 seconds just before a server migration or DNS cutover makes the change propagate faster once you switch.

Side Note — the history behind DNS records and email authentication

DNS is best known for mapping domain names to IP addresses, but in reality many more record types exist beyond A and AAAA, each with a distinct role. In the world of email delivery in particular, several records — MX, TXT (carrying SPF/DKIM/DMARC), and PTR — only add up to "legitimate, non-spoofed mail" when they all work together; missing even one raises the risk of landing in a spam folder or being rejected outright.

Looking back at the history of sender authentication, SPF was proposed in the early 2000s as a countermeasure against spam, and DKIM, aimed at detecting tampering with message content, was standardized around 2007. But neither one, on its own, defined what a receiver should actually do when authentication failed — DMARC arrived in 2012 to fill that gap. DMARC evaluates SPF and DKIM results together and provides both an enforcement policy for failures and a reporting mechanism, functioning as a kind of command center for authentication.

Some DNS records have changed shape over time for historical reasons. A dedicated record type for SPF (RRTYPE 99) was defined once in a 2006 RFC, but caused implementation confusion and was formally deprecated by RFC 7208 in 2014 — today SPF is expressed purely through TXT records. DKIM and DMARC likewise have no dedicated record type of their own; both are implemented entirely inside TXT records using a specific syntax (strings beginning with v=DKIM1 or v=DMARC1), which says a lot about how extensible DNS really is.

Browse all trivia