DNS records explained: A, CNAME, MX, TXT and friends

What’s in a record

Every record has the same four parts, whatever its type.

The name is usually typed without your domain on the end: www, not www.yourname.com.au. For the domain on its own, most editors use @. You’ll also see it called the bare domain, root domain or apex. The TTL is covered in the previous lesson.

The record types at a glance

A and AAAA: point a name at a server

An A record maps a name to an IPv4 address, and an AAAA record (“quad-A”) maps it to an IPv6 address. These do the main job of DNS: turning yourname.com.au into the IP address of your web server. Your web host tells you the address to use.

CNAME: an alias for another name

A CNAME says “this name is another name for that one; look there instead”. It’s handy when a provider gives you a hostname and not an address, such as yourshop.shopplatform.example. If they later move servers, your record still works.

CNAMEs come with two rules that catch people out:

• A CNAME can’t share its name with any other record. RFC 1034 says: “If a CNAME RR is present at a node, no other data should be present”. So www can have a CNAME, or an A record, but not both.
• That rules out the bare domain. The domain itself always has other records (its NS and SOA at least), so a CNAME can’t go on @. Use an A record there and put the CNAME on www. Some DNS hosts offer a workaround, usually called ALIAS or CNAME flattening.

MX: where email is delivered

MX (mail exchanger) records name the servers that accept email for your domain. Each has a priority number. The rule in RFC 1035 is short: “Lower values are preferred.” So priority 10 is tried before priority 20, and the higher numbers are backups.

An MX record points at a server’s name, never an IP address, and that name “must not be an alias” (RFC 2181), meaning it can’t be a CNAME. Your mail provider gives you the exact values, so copy them as they are.

TXT: notes for other systems

A TXT record holds a line of text. Two things use it constantly: services that ask you to prove you control the domain (“add this code as a TXT record”), and email security.

SPF, DKIM and DMARC

These three work together to stop other people sending email that pretends to be from your domain.

• SPF lists the servers allowed to send email for your domain. It’s a single TXT record starting with v=spf1. Single matters: RFC 7208 says a domain “MUST NOT have multiple records”, and two SPF records make the check fail. If two services each ask you to add one, merge them into one record.
• DKIM lets your mail provider sign outgoing messages. The matching public key is published in a TXT record under a name ending in _domainkey (RFC 6376). Your provider supplies the record.
• DMARC tells receiving servers what to do with mail that fails those checks, and where to send reports. It’s a TXT record at _dmarc in front of your domain (RFC 7489).

The MX & Email tab of our toolbox checks the MX, SPF and DMARC records of any domain. Email and your domain goes through all three properly.

NS and SOA: who’s in charge of the zone

NS records name the nameservers that are authoritative for a zone. They exist in two places, at the registry and inside your own zone, and which copy matters when is the heart of the next lesson.

The SOA (start of authority) record is the zone’s housekeeping entry: there’s one per zone, and it holds a serial number that goes up whenever the zone changes, along with some timers. Your DNS host creates and maintains it. You’ll see it in listings and can leave it alone.

SRV and CAA: the occasional extras

An SRV record “specifies the location of the server(s) for a specific protocol and domain” (RFC 2782), including a port number. You’ll only add one when a setup guide for a phone or chat system hands you the exact values.

A CAA record “allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name” (RFC 8659). With no CAA record, any certificate authority may issue, which is how most domains run. HTTPS and SSL certificates explains where certificates come from.

DS: the one that doesn’t live in your zone

DNSSEC adds digital signatures to DNS answers so they can’t be forged on the way. If you use it, the DS record is the link between your zone’s signing key and the level above. Unusually, it “appears only on the upper (parental) side of a delegation” (RFC 4034): it’s held at the registry, so you add it where the domain is registered, not in your DNS editor. DNSSEC explained covers the whole chain.

A worked example

Here’s a complete, realistic set of records for a small business with a website at one company and email at another:

Name     Type     Value
@        A        203.0.113.10
www      CNAME    yourname.com.au
@        MX 10    mx1.mailhost.example
@        MX 20    mx2.mailhost.example
@        TXT      v=spf1 include:spf.mailhost.example -all
_dmarc   TXT      v=DMARC1; p=quarantine; rua=mailto:reports@yourname.com.au

Line by line: the bare domain points at the web server. www follows it. Email goes to the mail provider’s first server, with a second as backup. Only that provider may send email as the domain, and mail that fails the checks should be treated as suspicious.

Common mistakes

• Wiping the email records when moving the website. A new web host only needs the A (and maybe www) records changed. Delete or replace the MX and TXT records and your email stops.
• Two SPF records. Merge them into one.
• A CNAME on the bare domain, or next to another record with the same name.
• Setting up only one of www and the bare domain. They’re separate names. Visitors will type both.
• Doubling the name. Some editors add your domain to whatever you type, so entering www.yourname.com.au creates www.yourname.com.au.yourname.com.au. Check how the saved record reads.
• Editing the right record in the wrong place. If your domain’s nameservers point at a different provider, your edits are never seen. See Nameservers and DNS zones.

Terms in this lesson

Record

One instruction in a zone: a name, a type, a value and a TTL.

Apex

Your domain with nothing in front of it: yourname.com.au, not www.yourname.com.au.

A record

A DNS record that points a name at an IPv4 address, such as 203.0.113.10.

CNAME record

A DNS record that makes one name an alias of another name.

MX record

A DNS record that names the servers accepting email for your domain.

TXT record

A DNS record that holds a line of text for other systems to read.

NS record

A DNS record naming the nameservers in charge of a zone.

SOA record

A zone’s housekeeping record: one per zone, created and maintained by your DNS host.

TTL

The number of seconds an answer may be reused before it has to be looked up again. 3600 is one hour.

Every term, in full, is in the glossary.

Sources

All read on 2 October 2026.

• RFC 1034, Domain Names: Concepts and Facilities (IETF): a CNAME can’t share a name with other records.
• RFC 1035, Domain Names: Implementation and Specification (IETF): MX preference values and the SOA record.
• RFC 2181, Clarifications to the DNS Specification (IETF): MX and NS records must not point at an alias.
• RFC 7208, Sender Policy Framework (SPF) (IETF): SPF is a TXT record, and a domain must not have more than one.
• RFC 6376, DomainKeys Identified Mail (DKIM) Signatures (IETF): DKIM keys are TXT records under _domainkey.
• RFC 7489, DMARC (IETF): DMARC policies are TXT records at _dmarc.
• RFC 2782, A DNS RR for specifying the location of services (DNS SRV) (IETF): what an SRV record specifies.
• RFC 8659, DNS Certification Authority Authorization (CAA) Resource Record (IETF): what a CAA record does, and that issuance isn’t restricted without one.
• RFC 4034, Resource Records for the DNS Security Extensions (IETF): the DS record sits on the parent side of a delegation.