BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
DNS Records Explained: A, AAAA, CNAME, MX, NS, and TXT Records for Any Domain
A DNS record is a single instruction stored in a domain’s zone file that tells the internet how to handle one kind of request for that domain. The six records nearly every domain relies on are A and AAAA, which point a name to an IP address, CNAME, which points one name at another, MX, which routes email, NS, which names the authoritative servers, and TXT, which holds verification and email-authentication data.
Every record follows the same five-field shape and is defined by an internet standard, so once the pattern is clear, a zone file reads like a short list of rules instead of a wall of jargon. This guide defines each of the six core record types, shows the real syntax of each, and maps the wider set: SOA, PTR, SRV, CAA, and the DNSSEC keys.
It also covers the case the generic explainers skip: what happens to these records when a domain changes hands. An aged or expired domain arrives carrying the previous owner’s DNS picture, and rebuilding that zone correctly is the difference between a clean cutover and weeks of silent email loss. SEO Domains operates the curated marketplace where those domains are screened before they are listed, so the name is a known quantity before its records become the new owner’s responsibility.
DNS records explained: the short answer
DNS records are the individual entries inside a domain’s zone file, each one a rule that tells DNS servers how to answer a specific type of lookup. The six that nearly every domain relies on are A and AAAA (name to IPv4 and IPv6 address), CNAME (name to another name), MX (where email is delivered), NS (which servers are authoritative), and TXT (verification and email-authentication text).
The Domain Name System turns a readable name into the numbers and routing instructions machines need. Records are how that translation is written down. When a browser, a mail server, or a certificate authority asks a question about a domain, the answer is whichever record matches the question.
A and AAAA
Map a hostname to an IP address. A returns a 32-bit IPv4 address, AAAA returns a 128-bit IPv6 address. This is what loads a website.
CNAME
Points one name at another name instead of an IP. The lookup retries against the target. Used for subdomains and managed services.
MX
Lists the mail servers that accept email for the domain, each with a priority number. Without it, email has nowhere to go.
NS
Names the authoritative nameservers for the zone. This is the record that delegates control of the domain to a DNS provider.
TXT
Holds free-form text, in practice the SPF, DKIM, and DMARC strings that authenticate email plus the tokens services use to verify domain ownership.
What is a DNS record and how does it work?
A DNS record is a text entry inside a zone file, the file that holds every record for one domain. The zone file lives on the authoritative nameserver, the server that holds the final answer for that domain. A lookup travels from a recursive resolver to that authoritative server, which returns the matching record, and the resolver caches it for the length of its TTL.
The zone file and the authoritative nameserver
IBM describes a DNS record as a subset of data within a zone file, a text-based file written in DNS syntax that acts as a set of commands for how to handle queries. Each domain has one zone, and that zone is a list of records. The authoritative nameserver is the machine that holds the official copy of the zone and answers for it. The wider relationship between the zone, the registry, and the registrar sits in the DNS and Nameservers pillar.
How a lookup reaches a record
A request for a domain does not go straight to the zone file. It passes through a recursive resolver, usually run by an internet provider or a public service, which walks the DNS hierarchy from the root, to the top-level domain servers, to the domain’s authoritative nameservers, and finally reads the record that answers the question. The resolver then keeps a copy for the record’s TTL so the next identical request is answered from cache.
The anatomy of a DNS record: the five fields
Almost every DNS record shares the same five-part structure: the name it applies to, the TTL or cache lifetime, the class (nearly always IN for internet), the record type, and the value or data. Reading those five fields in order is how a zone file stops looking like noise and starts reading as a list of rules.
A single line in a zone file looks like this: www.example.com. 3600 IN A 203.0.113.10. That line says the name www.example.com, cached for 3600 seconds, in the internet class, is an A record, and its value is the IPv4 address 203.0.113.10. Every record below follows the same template, with only the type and value changing.
| Field | What it is | Example value |
|---|---|---|
| Name | The host or domain the record applies to | www.example.com. |
| TTL | Seconds a resolver may cache the record | 3600 |
| Class | The protocol family, almost always internet | IN |
| Type | Which kind of record this is | A |
| Value | The data the record returns | 203.0.113.10 |
A and AAAA records: pointing a domain to an IP address
An A record maps a hostname to a 32-bit IPv4 address, and an AAAA record maps the same hostname to a 128-bit IPv6 address. Both are defined so a browser can turn a name into the numeric address it connects to. A is governed by RFC 1035 and AAAA by RFC 3596, and a domain can carry both at once to serve IPv4 and IPv6 visitors.
The A record
The A in A record stands for address. It is the record that loads a website: ask for the name, get back the IPv4 address of the server. A line such as example.com. 3600 IN A 203.0.113.10 sends every visitor of example.com to that address. A single name can hold more than one A record, which spreads traffic across multiple servers.
The AAAA record
An AAAA record does the identical job for IPv6, the 128-bit addressing scheme that exists because the IPv4 pool is exhausted. The four As reflect that an IPv6 address is four times the size of an IPv4 one. A domain that publishes both an A and an AAAA record is reachable over both protocols, and the visitor’s device picks whichever it supports.
A record versus CNAME, the recurring question
People searching for DNS records repeatedly ask whether to use an A record or a CNAME. The answer turns on what the target is. Point at a fixed IP address and an A record is correct. Point at another name, such as a managed host that changes its own IP from time to time, and a CNAME is correct. The root of a domain, the bare example.com with no subdomain, cannot use a CNAME under the original standard, which is why the apex takes an A record.
CNAME records: aliasing one name to another
A CNAME, or canonical name record, points one domain name at another name instead of at an IP address. When a resolver hits a CNAME, it abandons the original name and repeats the lookup against the target, following the alias to wherever it ultimately resolves. CNAME is defined in RFC 1035 and is the standard way to attach a subdomain to a managed external service.
How the alias-and-retry behaviour works
Set shop.example.com. 3600 IN CNAME stores.myplatform.net. and any request for shop.example.com is told to go ask about stores.myplatform.net instead. The resolver then looks up that target’s A or AAAA record and returns its address. The benefit is maintenance: when the platform changes its server IP, its own A record updates, and the alias follows automatically with nothing to change on the original domain.
The two rules that trip people up
A CNAME cannot coexist with any other record for the same name, because the alias replaces the whole name. That rules out a CNAME at the domain apex, where the SOA and NS records already live. It also means a name with a CNAME cannot also carry an MX or TXT record. Providers that appear to break this rule use proprietary flattening at the apex instead of a true CNAME.
MX records: routing email for a domain
An MX, or mail exchange, record names the servers that accept email for a domain and assigns each a priority number. Mail is delivered to the available server with the lowest priority value first. MX is defined in RFC 1035, and without a correct MX record email for the domain has no destination and bounces or disappears.
Priority and the format
An MX line carries a preference number before the server name: example.com. 3600 IN MX 10 mail.example.com. The lower the number, the higher the priority, so a value of 10 is tried before a value of 20. Listing a second MX at a higher number gives a fallback server when the primary is unreachable. The target of an MX must itself resolve to an address through an A or AAAA record, never through a CNAME.
NS and SOA records: who is authoritative for the zone
NS, or nameserver, records name the authoritative servers responsible for a domain, the act of delegation that hands control to a DNS provider. The SOA, or start of authority, record opens the zone and holds its administrative parameters: the primary nameserver, the administrator email, and the serial and timing values that govern how the zone is refreshed. Both are defined in RFC 1035 and both are mandatory for a working zone.
NS records and delegation
An NS record such as example.com. 86400 IN NS ns1.provider.net. declares that the named server holds the authoritative records for the domain. Changing the NS records at the registrar is how a domain is moved to a new DNS provider, the single highest-impact record change during a domain handover. The mechanics of that move are covered in the DNS and Nameservers pillar.
The SOA record and its fields
Every zone begins with exactly one SOA record. It holds the primary authoritative nameserver, the responsible party’s email written with a dot in place of the at sign, and a serial number that increments on each edit so secondary servers know the zone changed. It also carries refresh, retry, and expire timers and a minimum TTL. The serial number and email in an inherited SOA are an ownership fingerprint, which is why diligence on an acquired domain reads them, a discipline detailed in the WHOIS and RDAP hub.
TXT records: verification, SPF, DKIM, and DMARC
A TXT record stores free-form text in the DNS. RFC 1035 created it for arbitrary human-readable notes, but in practice TXT records now carry machine-readable strings: the SPF, DKIM, and DMARC policies that authenticate a domain’s email, and the verification tokens that services use to confirm domain ownership.
Email authentication lives in TXT
Three email-security standards all publish through TXT records. SPF lists which servers are allowed to send mail for the domain. DKIM publishes the public key that validates a cryptographic signature on each message. DMARC sets the policy that tells receivers how to act when SPF or DKIM fails. Together they decide whether a domain’s mail lands in the inbox or the spam folder, and all three are read straight from TXT records.
Ownership verification tokens
When a service such as a search console, an email platform, or a certificate provider asks for a TXT record to prove control of a domain, it is using the fact that only the domain’s controller can publish a record. A stale verification token from a previous owner is harmless to traffic but signals that the zone was never cleaned, which matters on an acquired domain.
The wider record set: PTR, SRV, CAA, and DNSSEC
Beyond the core six, a handful of records handle specialised jobs. PTR does reverse lookups from IP back to name, SRV locates services on a host and port, CAA constrains which certificate authorities are permitted to issue for a domain, and the DNSSEC records DNSKEY and DS carry the cryptographic keys that sign a zone. Each is defined by its own RFC.
PTR (RFC 1035)
The reverse of an A record: it maps an IP address back to a name. Mail servers check the PTR of a sending IP, so a missing PTR hurts email deliverability.
SRV (RFC 2782)
A generalised service-location record that publishes the host and port for a protocol, used by services such as chat, voice, and directory systems.
CAA (RFC 8659)
Certification Authority Authorization. It lists which certificate authorities are allowed to issue TLS certificates for the domain, narrowing the attack surface.
DNSKEY and DS (RFC 4034)
The DNSSEC keys. DNSKEY publishes a zone’s signing key and DS links it to the parent zone, so a resolver can verify the records were not tampered with.
Reverse-DNS PTR records are unusual in that they live in a special reverse zone managed by whoever controls the IP block, not in the domain’s own zone. CAA and DNSSEC are increasingly expected on a serious domain, and DNSSEC in particular is covered as its own decision in the DNS and Nameservers pillar.
TTL: how long a record is cached and why it matters
TTL, or time to live, is the number of seconds a resolver is allowed to keep a cached copy of a record before it must fetch a fresh one. IBM defines it as the value that tells a resolver how long to cache a record before contacting the authoritative server again. A low TTL means changes spread fast but lookups are more frequent, and a high TTL means the opposite.
The cache tradeoff
A record with a TTL of 86400 seconds, one day, is cached aggressively, which is efficient but slow to change everywhere. A record with a TTL of 300 seconds, five minutes, updates across the internet quickly at the cost of more queries hitting the authoritative server. Steady-state records run high. Records about to change run low.
Why TTL is the lever during a domain move
The practical rule is to lower the TTL before a planned change, not after. Drop the A or MX TTL to 300 seconds a day ahead of a cutover, make the change, and resolvers pick it up within minutes instead of holding a stale answer for a full day. Forgetting this step is why a domain migration can leave a fraction of visitors on the old server long after the new record is live.
DNS records reference: type, RFC, syntax, and typical TTL
This single table consolidates what the leading guides spread across separate pages or omit: every common record type, the RFC that defines it, a real zone-file syntax line, and a typical TTL. The RFC column is sourced from the IETF standards and the public list of DNS record types, so each row is grounded in the published specification instead of asserted.
| Type | What it does | RFC | Example zone-file line | Typical TTL |
|---|---|---|---|---|
| A | Name to IPv4 address | 1035 | example.com. IN A 203.0.113.10 | 3600 |
| AAAA | Name to IPv6 address | 3596 | example.com. IN AAAA 2001:db8::10 | 3600 |
| CNAME | Name to another name (alias) | 1035 | www IN CNAME example.com. | 3600 |
| MX | Mail servers, by priority | 1035 | example.com. IN MX 10 mail.example.com. | 3600 |
| NS | Authoritative nameservers | 1035 | example.com. IN NS ns1.provider.net. | 86400 |
| TXT | Text: SPF, DKIM, DMARC, verification | 1035 | example.com. IN TXT "v=spf1 -all" | 3600 |
| SOA | Zone administrative master record | 1035 | example.com. IN SOA ns1.provider.net. admin.example.com. ... | 3600 |
| PTR | IP address back to a name (reverse) | 1035 | 10.113.0.203.in-addr.arpa. IN PTR example.com. | 3600 |
| SRV | Service location: host and port | 2782 | _sip._tcp IN SRV 10 5 5060 sip.example.com. | 3600 |
| CAA | Which CAs may issue certificates | 8659 | example.com. IN CAA 0 issue "letsencrypt.org" | 3600 |
| DNSKEY / DS | DNSSEC signing keys | 4034 | example.com. IN DNSKEY 256 3 13 ... | 3600 |
Setting DNS records on a newly acquired aged domain
When an aged or expired domain is acquired, it does not arrive blank. It carries whatever DNS picture the previous owner left, and rebuilding the zone in the right order is what turns a purchased name into a working property. The sequence below is the practical handover: take control of the zone, point the core records at the new infrastructure, then purge the inherited records that no longer apply.
This is the step every generic DNS explainer leaves out, and it is the one that matters to anyone buying domains instead of registering a fresh one. The records themselves are the same A, MX, NS, and TXT covered above. The difference is that on an acquired domain, the wrong inherited record fails silently.
-
Take control of the zone at a DNS provider
Point the domain’s NS records at the DNS provider whose console will hold the new zone, set at the registrar. Until the NS records change, edits go nowhere because a different server is still authoritative. This is the single change that hands the zone over. The sourcing of clean names that reach this step starts on the SEO Domains marketplace, where the domain’s history is screened before purchase.
The mistake: editing records at the old provider while the registrar still delegates to a different nameserver. Nothing takes effect, and hours are lost chasing a change that was never authoritative.
-
Set the A and AAAA records to the new host
Create the A record, and an AAAA record if the host serves IPv6, pointing the domain at the server that will run the new site. Lower the TTL to 300 seconds first if the previous A record is still cached widely.
The mistake: leaving an inherited A record that points at the previous owner’s released server IP. That address can now belong to someone else, sending visitors to a stranger’s content.
-
Decide the MX records, or remove them
If the domain will send and receive email, set the MX records to the new mail provider with correct priorities. If it will not, remove the inherited MX entirely so mail does not route anywhere.
The mistake: keeping a stale MX that still points at the previous owner’s mailbox. Email addressed to the domain is silently delivered to an inbox the new owner does not control, with no bounce to reveal it.
-
Purge inherited TXT records
Review every TXT record. Delete the previous owner’s SPF, DKIM, and DMARC strings and their old verification tokens, then publish a clean SPF and DMARC policy for the new mail setup. The new SOA contact and serial replace the inherited ones automatically when the zone is rebuilt.
The mistake: leaving an old SPF record that authorises the previous owner’s mail servers, or a stale DMARC policy that quarantines the new owner’s legitimate mail.
-
Verify, then restore normal TTLs
Confirm each record resolves as intended with a lookup tool, check that mail and the site respond, then raise the TTLs back to steady-state values such as 3600 once the cutover is stable. Reviewing the registration record alongside the zone is part of the same diligence, covered in the WHOIS and RDAP hub.
The mistake: declaring the move done without a lookup check. A typo in a single record can pass visually and still break mail or the site for everyone whose resolver already cached it.
Common DNS record mistakes and the fix
The errors that break a zone are a short, repeatable list, and each has a known fix. They cluster around three failures: the wrong record type for the job, an inherited record left in place on a domain that changed hands, and a TTL set wrong for the moment. This table is the scannable reference for catching each one before it ships.
| The mistake | Why it breaks | The fix |
|---|---|---|
| CNAME at the domain apex | A CNAME cannot coexist with the SOA and NS records the apex requires | Use an A or AAAA record at the apex, or the provider’s flattening feature |
| Dangling A record to a released IP | The previous owner’s server IP may now belong to someone else | Repoint the A record to the new host, and delete any address you no longer control |
| Stale inherited MX record | Mail routes silently to a mailbox the new owner does not control, with no bounce | Reset MX to the new mail provider, or remove MX entirely if mail is not used |
| Old SPF, DKIM, or DMARC in TXT | The wrong senders are authorised, or legitimate new mail is quarantined | Delete inherited email-auth TXT records and publish a clean policy for the new setup |
| Missing PTR record | Receiving mail servers distrust a sending IP with no reverse record | Set the PTR for the sending IP through whoever controls that address block |
| MX or NS pointed at a CNAME | The standard forbids an MX or NS target that is itself an alias | Point MX and NS at names that resolve directly through A or AAAA records |
| TTL left high before a change | Stale answers persist for the full cache lifetime after the edit | Lower the TTL to 300 seconds a day before a planned change, then raise it back |
| No lookup check after editing | A single typo passes a visual review and still breaks the site or mail | Confirm every edited record with a lookup tool before calling the change done |
DNS records frequently asked questions
The five questions that recur when people search for what DNS records are and how to handle them, answered against the RFC record set and the acquired-domain context this guide draws.
Q1What are the three main types of DNS records?
There is no fixed list of three, but the records nearly every domain needs are the A record, which points the name to an IPv4 address, the MX record, which routes email, and the TXT record, which holds the SPF, DKIM, and DMARC strings that authenticate that email. Add AAAA for IPv6, CNAME for aliases, and NS for delegation, and that six-record set covers almost every real domain.
Q2CNAME or A record: which one fits?
An A record is right when the target is a fixed IP address, and a CNAME is right when the target is another name, such as a managed host whose own IP shifts over time. The CNAME follows the target automatically, which saves maintenance. One hard limit: a CNAME cannot sit at the domain apex, where the SOA and NS records already live, so the bare domain takes an A record.
Q3What do 8.8.8.8 and 8.8.4.4 do, and are they DNS records?
They are not records. 8.8.8.8 and 8.8.4.4 are the IP addresses of Google’s public recursive resolver, the kind of server that looks records up on a device’s behalf and caches the answers. A DNS record lives in a domain’s zone file on its authoritative nameserver, whereas a resolver like 8.8.8.8 is the service that fetches and caches those records for the devices that ask it.
Q4How long do DNS record changes take to apply?
The change is published instantly at the authoritative nameserver, but resolvers around the internet keep their cached copy until its TTL expires. A record with a TTL of 3600 can take up to an hour to update everywhere, and one set to 86400 up to a day. Lowering the TTL to 300 seconds before a planned change is how the update spreads in minutes instead.
Q5Which DNS records need checking after buying an aged or expired domain?
Check the NS records first, since they decide which provider is authoritative, then the A and AAAA records so the domain points at your host, the MX records so email does not route to the previous owner, and every TXT record so no inherited SPF, DKIM, or verification token survives. Starting from a screened domain on the SEO Domains marketplace means the history behind those inherited records is already known before the zone becomes yours to rebuild.
DNS records start with the domain: source one with a known history
Every record covered here is only as trustworthy as the domain it sits on. On a freshly registered name the zone is blank and predictable. On an aged or expired domain it arrives inherited, and the records carry the previous owner’s choices until they are deliberately rebuilt. Sourcing from a screened catalogue means the history behind those records is a known quantity, not a blind inheritance.
Why the domain decides the DNS picture
A stale MX, a dangling A record, or an old SPF policy is not a flaw in the DNS standard. It is a residue of who held the domain before. The clean way to inherit a zone is to know the domain’s history going in, so each inherited record is explained instead of mysterious. That is a property of the acquisition, not of the configuration.
The marketplace, not a DNS service
SEO Domains sells the domain, the raw material every record depends on, not a DNS host or a managed service. The product is an aged or expired domain whose backlink profile and registration history are screened before it is listed and priced, so the name reaching the zone-rebuild step above is one whose past is documented. Browse the catalogue for a domain to build on, and the DNS work that follows starts from a clean, known foundation.
