DNS Records Explained: A, AAAA, CNAME, MX and TXT for Your Launch

When a visitor types your domain name, their device asks the Domain Name System (DNS) where to go. The answer comes from small entries in your DNS zone called records. Each record has a name, a type and a value, and each type answers a different question: where is the website, where does the email go, which text proves that you own this domain.

Most launch-day outages blamed on "the server" are really DNS mistakes: a missing record for www, a CNAME where it is not allowed, an MX record pointing to the wrong place, or a verification record that was deleted after it worked. This guide explains the records you will actually meet, in plain English, and shows how to set up and check them before you send real traffic.

It is for site owners and developers who manage their own domain, with or without a DNS provider such as a registrar panel or Cloudflare. By the end you will know which records your launch needs, what to enter for each, and how to confirm with a command-line lookup that the world sees what you intended.

Before you begin

You need login access to wherever your DNS is managed. That may not be your registrar: if the domain uses another provider's nameservers, the zone is edited there. Export or copy the current records first. If the provider cannot export, take screenshots.

Gather the values you will need from your hosting and email providers, such as the server IP address or target hostname, and the mail server names with their priorities. Allow time: caches may hold an old answer until its time to live (TTL) runs out.

You also need dig (installed on macOS and most Linux systems; on Windows use nslookup or an online DNS lookup tool).

The record types in plain English

Type	Question it answers	Example value
A	What IPv4 address is this name?	`203.0.113.10`
AAAA	What IPv6 address is this name?	`2001:db8::10`
CNAME	What other name is this name an alias for?	`sites.hosting.example.net.`
MX	Which servers accept mail for this domain?	`10 mail.example.com.`
TXT	What text is attached to this name?	`"v=spf1 include:mail.example.net ~all"`
NS	Which servers are authoritative for this domain?	`ns1.dns-host.example.`

A and AAAA map a name to an address. An A record holds an IPv4 address, an AAAA record an IPv6 address. You can publish both, and visitors will use whichever their network supports. If you publish an AAAA record, make sure the server really answers on that IPv6 address, or some visitors will see failures that others do not.

CNAME makes one name an alias of another. The target must be a hostname, not an IP address, and the target's own records then supply the answer. It is the standard way to point www at a hosting platform that tells you to use a hostname rather than an IP address. The key rule, from the original DNS specification, is that if a CNAME exists at a name, no other data should exist at that name. That is why you cannot put a plain CNAME at the apex (the bare example.com), which must also hold records like NS and SOA. Some providers offer CNAME flattening or an ALIAS record to work around this; Cloudflare, for instance, uses flattening, but the behavior is provider-specific, so read your own provider's documentation.

MX records say which servers receive email for the domain. Each has a preference number; lower numbers are preferred, and senders try the most preferred first. Records with equal preference may be shared at random for load spreading. The value of an MX record must be a hostname that has address records, and must not be an alias: the DNS specifications say the name used in an MX or NS record must not point to a CNAME. If a domain has no MX records, mail senders fall back to treating the domain's own address record as the mail server, which is rarely what you want.

TXT records hold free text. They are used for proof of ownership (Google Search Console, certificate authorities, other services) and for email authentication: SPF and DMARC are published as TXT records, and a DKIM key is usually a TXT record too (some providers use a CNAME instead). Values are text strings in double quotes; a mismatch in quotes causes validation errors in some panels. Providers often add the quotes for you.

NS records name the authoritative servers for the zone. You normally change these at your registrar when you move DNS hosting, not inside the zone itself. CAA and SRV records also exist; you need them only if a provider asks.

Step-by-step instructions

Step 1: List the hostnames your launch needs

Write down every name that should work: usually example.com (the apex), www.example.com, and any subdomains such as shop or app. Decide which of the apex or www is your canonical address, and plan to redirect the other to it. www vs Non-www: Pick One Canonical Host explains the choice and the redirect.

What success looks like: A short table of names, with the target (IP address or hostname) for each.

Step 2: Point the website records

For a host that gives you a fixed IP, create an A record (and an AAAA record if it gives you an IPv6 address) for the apex, and for www either another A record or a CNAME to the apex. For a platform that gives you a hostname, create a CNAME for www and follow the platform's instructions for the apex, which may be an ALIAS or A records.

An example zone fragment:

example.com.        300  IN  A      203.0.113.10
www.example.com.    300  IN  CNAME  example.com.
example.com.        300  IN  MX     10 mail.example.com.
mail.example.com.   300  IN  A      203.0.113.25
example.com.        300  IN  TXT    "v=spf1 mx ~all"

The numbers (300) are TTLs in seconds, and the addresses use documentation-only ranges. If your provider offers a "proxy" option, as Cloudflare does, understand what it changes before you turn it on. Cloudflare notes, for example, that a proxied CNAME must ultimately resolve to an A or AAAA record. See Cloudflare SEO Settings That Help or Hurt Crawling for the crawling side.

What success looks like: dig +short example.com A and dig +short www.example.com return the values you set.

Step 3: Set up mail records

Add MX records exactly as your mail provider gives them, with their priorities, pointing to hostnames. Check that those hostnames are not aliases. If the domain should never receive mail, publish the single "null MX" (priority 0, host .) instead. Crawvix's MX check treats that as a deliberate "no mail" and reports it as a pass for a domain that does not send mail.

Then add the SPF, DKIM and DMARC TXT records. Each has its own rules, covered in Fix Your SPF Record: One Record, 10 Lookups, Correct Ending, Set Up DKIM Signing and Check Your Selector and Set Up DMARC: From p=none to Quarantine and Reject.

What success looks like: dig +short example.com MX returns your provider's servers, and a test message arrives.

Step 4: Add verification TXT records and leave them in place

To verify a domain property in Google Search Console, you add a TXT record whose value looks like google-site-verification= followed by a string unique to your account. Copy the exact string. Leave the host field blank or enter @, depending on your provider. Google says a manually added record can take up to two or three days to be served by some providers, and that you must not remove the record afterwards if you want to stay verified.

If verification fails, wait and try again, and use Google's Admin Toolbox to check that your provider is serving the record. If a CNAME already exists at the name, check Google's rules before choosing the TXT method.

What success looks like: Search Console shows the property as verified, and the record remains in your zone.

Step 5: Plan the TTL and the cutover

TTL is how long resolvers may cache an answer. It is a maximum, not a promise, so some resolvers may serve the old value until it expires. Before you change a live record, lower its TTL to a short value your provider allows, wait for the old TTL to pass, then make the change. After things settle, raise the TTL again to reduce lookups. Cloudflare's documentation says that proxied records use an automatic TTL of 300 seconds, while DNS-only records can have a custom one.

Keep the old server running during the cutover, so visitors who still get the old answer reach a working site.

What success looks like: After the change, the new value appears from several networks, and the old server stops receiving traffic.

Step 6: Verify from the outside

Query the records directly, and ask a public resolver as well as your provider's authoritative server, to catch caching:

dig +short example.com A
dig +short www.example.com CNAME
dig +short example.com MX
dig +short example.com TXT
dig +short example.com NS
dig @8.8.8.8 +short example.com A

Then load the site in a browser and with curl -I https://example.com/ to confirm HTTPS and the redirect. Crawvix's scan checks that the domain resolves, that the home page loads, that there are at least two nameservers and that MX records exist, which is a quick way to catch several of these problems at once.

What success looks like: Every command returns the intended answer, from both your provider and a public resolver.

Final verification checklist

The apex and www both resolve, and one redirects to the other over HTTPS.
AAAA records, if present, point to a server that answers on IPv6.
No CNAME exists at a name that also has other records.
MX records point to hostnames with address records, not aliases, or a single null MX is published on purpose.
SPF, DKIM and DMARC records are present and syntactically valid.
Search Console verification TXT remains in place.
At least two nameservers are listed for the domain.
TTLs were lowered before the change and a copy of the old zone is saved.
dig from a public resolver matches the answer from your DNS provider.

Common mistakes to avoid

A CNAME at the apex. It conflicts with the NS and SOA records that must exist there. Use A records or your provider's ALIAS or flattening feature.
A CNAME and another record on the same name. Remove one; the DNS specification says no other data should be present beside a CNAME.
MX pointing at a CNAME. The name in an MX record must have address records and must not be an alias.
Doubling the domain in the name field. Many panels append the domain for you, so entering the full name can produce www.example.com.example.com.
Deleting the verification record once it works. Google asks you to keep it to stay verified.
Multiple SPF TXT records. Publish one SPF record and merge sources into it.
Changing nameservers without recreating records. New DNS hosting starts with an empty zone unless you copy the records over first.
Assuming the change is instant. Resolvers cache answers until the TTL passes; test from more than one network.

Frequently asked questions

What is the difference between an A record and a CNAME?

An A record maps a name directly to an IPv4 address. A CNAME maps a name to another name, and the answer comes from that other name's records. Use an A record when you have a fixed IP and a CNAME when a platform gives you a hostname.

Can I use a CNAME for my root domain?

Not as a plain CNAME, because the root also needs other records. Many DNS providers offer flattening or an ALIAS feature for this. Check what your provider supports.

How long do DNS changes take?

It depends on the old record's TTL and on how resolvers cache. Google notes that some providers take up to two or three days to start serving a manually added verification record, so test and be patient rather than repeatedly editing.

Where do SPF, DKIM and DMARC go?

SPF and DMARC are TXT records: SPF at the domain name and DMARC at _dmarc. DKIM lives at selector._domainkey, as a TXT record or, with some providers, a CNAME. Your mail provider shows the exact values to publish.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.