DNS records explained: A, CNAME, MX and email authentication

DNS is the system that turns your domain name into an IP address. Most domain management problems come from not knowing what a handful of record types actually do.

The core record types

A record — binds a domain to an IPv4 address. This is the record that says which server your site lives on.

textyourdomain.com.      A      203.0.113.10

AAAA record — the same job for an IPv6 address.

CNAME record — points one name at another. Commonly used for the www subdomain:

textwww.yourdomain.com.  CNAME  yourdomain.com.

One important rule: you cannot put a CNAME on the root domain (yourdomain.com). The root needs an A record.

MX record — tells senders which server receives mail for this domain. Lower priority values are tried first:

textyourdomain.com.  MX  10  mail.yourdomain.com.
yourdomain.com.  MX  20  backup.yourdomain.com.

TXT record — carries free-form text. In practice it is used for email authentication and domain ownership verification.

NS record — states which nameservers are authoritative for the domain.

TTL: how fast a change propagates

TTL (Time To Live) sets how many seconds a record stays cached. The default is often 14400 (4 hours).

If you are planning a migration, drop the TTL to 300 at least 24 hours before the change. The cutover then propagates within minutes. Restore the original value once you are done.

Email authentication: SPF, DKIM, DMARC

The number one reason your email lands in spam is that these three records are missing or wrong.

SPF — who may send on your behalf

Lists which servers are allowed to send mail for your domain:

textyourdomain.com.  TXT  "v=spf1 mx a ip4:203.0.113.10 -all"

The trailing -all says no server outside the list is authorised. If you use a service like Google Workspace, add their include: entry too.

Critical rule: a domain may have only one SPF record. Two separate SPF records cause both to be treated as invalid. If you have multiple providers, merge them into a single record.

DKIM — a signature proving the message was not altered

Adds a cryptographic signature to outgoing mail, which the receiving server verifies against a public key in DNS. Your mail provider generates the record; you only publish it:

textselector._domainkey.yourdomain.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0G..."

DMARC — what to do when authentication fails

Once SPF and DKIM are in place, this tells recipients what to do when they fail:

text_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Start with p=none: nothing is blocked, reports are collected. After watching the reports for a few weeks and confirming every legitimate sender authenticates, move to p=quarantine and then p=reject.

Starting straight at p=reject is how your own invoices and form notifications stop reaching people.

The most common migration mistake

When moving a site, the A record is pointed at the new server — correct so far. But if email is hosted with a different provider, the MX record must be left alone.

Switching MX to the new server during a migration is the number one cause of email suddenly not arriving. We covered the full migration sequence in our server migration guide.

Verification commands

bashdig +short yourdomain.com A
dig +short yourdomain.com MX
dig +short yourdomain.com TXT
dig +short _dmarc.yourdomain.com TXT

Use these to confirm your changes have propagated. If you would like your records reviewed, get in touch.