DNS Record Types Explained: A, CNAME, MX and TXT

A DNS record is one line of instructions that tells the internet what to do with a name: an A record points the name at a server's IP address, a CNAME makes one name an alias of another, an MX record says where email for the domain goes, and a TXT record carries text such as the string Search Console asks for. If you are opening a DNS panel for the first time as a shop, blog or business owner, knowing the job of each record keeps you from deleting the line that holds up your site or your mailbox. Registration, renewal and transfer of the name itself are outside this topic.

Anatomy of a record

MDN (Opens in a new tab) describes DNS as a hierarchical and decentralized naming system that keeps a list of domain names and the resources, such as IP addresses, tied to them; its best-known job is translating a human-friendly name into a numeric IP address, a step called a DNS lookup. The structure of a record comes from RFC 1034 (Opens in a new tab), the foundational document on domain names.

According to section 3.6 of RFC 1034, every resource record has five parts. Table: The five fields of a record.

Label names vary between providers, and the interface language changes them too. RFC 1034 says the TTL is a time limit on how long a record can be kept in a cache, that a zero TTL prohibits caching, and that the zone's administrator assigns the value. In other words, you or the DNS provider decides it, and after a change, resolvers still holding the old answer may keep serving it until their time runs out.

First five minutes in a panel

Change nothing at first. Scroll through the whole record list and copy it into a file or take screenshots. Then annotate each row: for the site, for email, for verification or unknown. List the unknown rows and ask the provider or whoever set the site up. The point of the first five minutes is a map, because any edit made without a map is a guess. Export or screenshot the list rather than retyping it: a typo in a copied value is the hardest kind of mistake to spot later.

Who answers: name servers, zones and resolvers

Records live on name servers. RFC 1034 says an NS record names the authoritative name server for a domain and that NS records are found only at the top node of a zone. It also requires every zone to be available on at least two servers. A resolver is the program that sits between user programs and name servers, and it caches answers for the length of the TTL.

The everyday reading is simple. Whoever runs your name servers is the place where you edit records. If the domain was bought from one company and the site is hosted at another, the records may sit with either, and an A record changed in the wrong panel does nothing. Learning where the name servers point is the first step of any DNS job.

TTL as a dial: a decision rule

TTL is a trade-off. A low value lets changes spread quickly; a high one lets resolvers keep an answer longer. RFC 1034 leaves the choice to the zone administrator. Google's Site moves without URL changes (Opens in a new tab) page says ISPs cache DNS settings by TTL and suggests lowering it to a conservative value, for example a few hours, at least a week before a move. Table: TTL approach by situation.

The rule: lower the TTL first and wait, then change the record. Reverse the order and the old value can linger in caches. A zero TTL is an extreme value that your provider may not permit. Google's guidance can change, so check the current page before you act.

Reading records aloud: a short drill

A quick way to learn the format is to read sample lines the way a resolver would. The addresses and names here are placeholders from documentation ranges. Table: Four sample rows decoded.

If you can say each row in a sentence, you can edit it safely. If you cannot, find out what the record serves before touching it. The same drill works as a review: read your whole list aloud once a year and mark every row you cannot explain.

A records

In RFC 1034, an A record carries a 32-bit IP address for the internet class. It is the record that ties your site's main name to the server that hosts it. When you change hosts, the A record is one of the first things to update, because the new host gives you a new address. This record carries only the 32-bit form; IPv6 addresses are outside this topic.

What an A record is like in daily life

Think of a shopfront sign. The name stays the same, but if the building moves, the sign must show the new address. An A record published with a long TTL can keep pointing visitors to the old address for a while after you update it.

When the address changes

Hosts can give you a new IP address when you change plan or move servers. The A record then needs the new value, and the old server should stay on until traffic to it reaches zero. Practical suggestion: ask your host in writing whether the address is fixed, and record the answer in your notes.

CNAME records and the one-record rule

RFC 1034 says a CNAME record identifies its owner name as an alias, and the lookup is restarted at the name in the record's data. It says chains should be followed and loops signalled as an error, and that records should point at the primary name rather than at an alias. Its key rule: if a CNAME is present at a node, no other data should be present there. That means a name carrying a CNAME should not also carry an MX or TXT record.

Practical suggestion: a CNAME suits a subdomain such as www when a hosting service hands you a name to point to. For the bare domain, which also needs MX and TXT records, follow your provider's instructions, because providers solve that limit in different ways.

Chains and loops

A CNAME can point at another CNAME, and resolvers follow the chain, but each hop adds a place for a mistake. Keep chains short. If two names point at each other, the result is a loop and the name does not resolve.

Choosing between A and CNAME

Table: A and CNAME side by side.

Decision rule: if the provider hands you an IP address, use A; if it hands you a hostname, use CNAME. Copy the supplied value exactly, with no added spaces, dots or protocol prefixes.

MX records: priorities and a safe switch

RFC 1034 says an MX record identifies a mail exchange for the domain, and its data is a 16-bit preference value, where lower is better, followed by a host name. Several MX records can exist, and the preference numbers set their order. If you use addresses like hello@yourshop.com, your MX records must point to the servers your mail provider names.

• An MX record points to a host name, not to an IP address.
• Enter the host names and preference numbers exactly as the provider gives them.
• Do not delete the old provider's records before the new one is confirmed working.
• When name servers move, carry the MX records across too.

Switching mail providers

Practical suggestion: bring the new provider's mailboxes up first and confirm they work. Add the new MX records with a less-preferred (higher) number than the old ones, then adjust the order after testing, and delete the old records last. RFC 1034 states that a lower preference value is preferred, and the ordering follows that rule. Your provider's own migration guide takes precedence. To write the sender-authorization record, follow how to write an SPF record.

TXT records and Search Console ownership

Google's Verify your site ownership (Opens in a new tab) page says a domain property can only be verified through the domain name provider method: you add a TXT or CNAME record. Some providers can add it automatically; otherwise you add it by hand at your DNS provider. The page says to keep the record at your provider even after verification succeeds if you want to stay verified. A manually added record can take two or three days before the provider serves it, and a failed check is worth retrying a day or two later.

TXT records serve other purposes too. If you see TXT records you do not recognise, do not delete them; they might be verification or sender data for other services, so find out who added them first. For the difference between property types, see Search Console domain versus URL-prefix property.

Keeping the verification record safe

1. Write down the date you added it and why.
2. Before any cleanup, copy its value into a file.
3. When changing DNS providers, carry it across on day one.
4. If verification drops, read the Search Console notice and check whether the record is still present.

How the records fit together for a small shop

Records work as a set. Table: An example set with each row's job. Values are placeholders; use the ones your providers give you.

Compare this set with your own panel. Where a row has no counterpart, find out why. A missing row can silently stop a service, and an extra row may be a leftover from an old provider.

Subdomains and third-party services

A booking or store service may ask for a record on a subdomain, a CNAME or A record plus a verification TXT. When you stop using the service, remove those records too, because a record that points at a name you no longer control is left unattended. Practical suggestion: next to every subdomain record, note which service it belongs to and who approved it.

Before you move name servers

Moving name servers rebuilds the record list somewhere else. Enter every record at the new place first, then switch, and check that the new place is answering before you retire the old one. RFC 1034 requires each zone to be on at least two servers, so confirm the new DNS service gives you two.

Publishing a change and waiting for it to spread

A DNS change does not appear everywhere at once. Google's site moves page says the start of a move is pointing DNS records at the new host, and that the old server should stay on until traffic to it reaches zero. A temporary dip in Googlebot's crawl rate right after launch is called normal. The step-by-step version is in changing web hosts: DNS cutover checklist.

Planning the wait

Practical suggestion: make the change in the morning when support is reachable, wait out the TTL, and test from different networks such as mobile data. Delete the old record only after the new one is proven to work.

Checking records from three angles

You can verify DNS in three layers: read what the panel says, ask what the internet sees, and test the service itself. Table: The three layers.

Practical suggestion: if the panel and the outside query disagree, you may be editing at the wrong name servers, or the TTL may not have run out yet. Check which name servers are authoritative first.

Symptom to record

Table: Where to look for each symptom.

Example scenario: a small hair salon

Example scenario: A small hair salon takes appointments through a booking form on its own site. The person who built the site has left, and the owner decides to change hosts. The new host supplies an IP address, an email provider supplies mail server names, and Search Console already holds a verification string. Nobody on the salon's side remembers which records the old setup needed, which is exactly why the list is copied before anything is touched.

The owner first copies the DNS list: an A record, a www CNAME, two MX records and two TXT records. She confirms the TTL was lowered ahead of time, writes the new IP into the A record, points the MX records at the new mail provider, and checks that the Search Console TXT record is still there. Last, she opens the salon's site on her phone using mobile data and sends herself an email from another account.

She also submits the booking form once from the phone and checks that the confirmation message reaches her inbox, because a form that quietly stops sending mail still looks healthy on screen. Then she writes the date, the old IP address and the new one into the notes file, so that if a client reports a problem a week later, the record shows which line changed and when.

Four things that could go wrong

Table: Risks and safeguards in the scenario.

What the scenario teaches

Every record has a job and every job has a check: the site for A, email for MX, verification for TXT. A change is not finished until those three checks pass, and a fourth check, the booking form, belongs on the list whenever the site sends mail of its own.

A checklist before you publish a DNS change

• The current record list is exported and dated.
• You know which name servers are authoritative and which panel to edit.
• New values are copied from the provider with no stray spaces or prefixes.
• No other record sits at a name that carries a CNAME.
• MX preferences match the provider's instructions.
• The Search Console record and other TXT records you recognise are in place.
• The TTL was lowered at least a week before the change.
• A test plan for site, email and verification is ready.
• The old server and old MX records stay until the new ones are proven.
• The change is logged with date, person and reason.

Record inventory template

Keep one row per record. Table: Inventory columns.

Frequently Asked Questions

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

An A record ties a name directly to an IP address. A CNAME makes a name an alias of another name and the lookup restarts there. Under RFC 1034, no other data should be present at a node that holds a CNAME.

What happens if I have no MX record?

RFC 1034 defines the MX record as naming a mail exchange for the domain. If you use email, enter every MX record your provider supplies.

What does a TXT record do?

Per Google's Search Console page, you add a TXT or CNAME record to verify a domain property. TXT records serve other purposes too; for sender authorization, see the separate SPF article.

Can I delete the Search Console verification record?

Google's page says not to remove the DNS record from your provider if you want to stay verified. If it is removed, verification can no longer be confirmed and you are notified.

What TTL should I use?

RFC 1034 defines TTL as a cache time limit and leaves the value to the zone administrator. Google suggests lowering it to a conservative value, for example a few hours, at least a week before a move.

How long does a DNS change take to show up?

It depends on the TTL and on resolver caches. Google's Search Console page says a manually added record can take two or three days to be served by the provider.

Conclusion

A, CNAME, MX and TXT records look small but they hold up the site, the mailbox and the ownership check. Knowing each record's job, exporting the list before every change and testing the site, email and verification separately afterwards is the safest way to work. Lowering the TTL ahead of time, knowing where the name servers are and never deleting a TXT record you cannot explain are the three core rules. Panel labels differ between providers, so read each record next to your own provider's documentation. Before you remove or edit a record, learn what it serves and save its old value; those two habits make every change reversible. Writing the rules down turns DNS knowledge from one person's memory into a shared document, so that a change of agency, a departing colleague or a hosting move leaves no gaps. A yearly review of the inventory is a good time to clear out records left behind by services you no longer use.

When the infrastructure is in order, our backlink packages are one way to promote what you publish.