Network
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.
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. |
Tips
- 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.
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.