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

When someone says to change your DNS, they mean editing these entries at the company that hosts your domain's records. Get one wrong and the website or the email stops. This guide explains the record types from the standards that define them, and gives a short routine for changing them safely. The examples use example.com and a documentation address.

What is in the address book?

The Domain Name System turns names into the data computers need. The original specification, RFC 1035, lists the record types by number. An A record (type 1) is “a host address”: it ties a name like www.example.com to an IPv4 address such as 203.0.113.10, a number from the range set aside for examples. An NS record (type 2) names an authoritative name server, the computers that answer for your domain. A CNAME (type 5) is “the canonical name for an alias”: it says that one name is another name. An MX record (type 15) is the mail exchange: where email for your domain should be delivered. A TXT record (type 16) holds text strings.

Each record has a TTL, the time in seconds that others may keep a copy before asking again. A short TTL makes changes show up sooner.

Which record does what for a small business?

Use this map:

• Website: an A record for example.com and for www.example.com pointing to your web host's address, or a CNAME from www to the main name. The host will tell you which.
• Email: MX records pointing to your mail provider, with a priority number; the lowest number is tried first. One wrong MX and mail goes to the wrong place.
• Email authentication: TXT records. RFC 7208 states that SPF records “MUST be published as a DNS TXT (type 16) Resource Record,” for example a line beginning v=spf1. See the deliverability guide.
• Proof of ownership: many services ask you to add a TXT record with a code, to show you control the domain.
• Name servers: NS records tell the world which company holds the rest of your records. They are set at your registrar.

What are the limits and quirks?

RFC 1035 limits a label, the piece between dots, to 63 octets, and a whole name to 255 octets. A CNAME cannot live beside other records for the same name, so the bare domain, example.com, usually takes an A record and not a CNAME. And RFC 7208 section 4.6.4 caps an SPF check at 10 terms that cause DNS lookups, such as include, a and mx; go over it and the check returns an error, which is a reason to keep the SPF line short when you add senders.

How to change records safely

Follow this routine:

• Find where your records are hosted. The registrar where you bought the name is often, but not always, the DNS host; ICANN advises always keeping your registrant account information private, secure and recoverable.
• Copy every existing record to a text file before you change anything.
• Change one thing at a time. Lower the TTL a day ahead if you plan a move.
• Test with the service's own check, send a test email, and load the website from another network, such as a phone on cellular.
• Keep the old records for a few days in case you need to switch back.

What can High Desert say?

High Desert lists domain registration, web hosting and email among its services, and customer email uses the hosts pop.hdiss.net and smtp.hdiss.net with the full email address as the username. How it handles DNS for customer domains is not published here, so ask when you call 775-575-9593 any day from 9 to 5. Our guides on what a domain name is, moving a website and email on your own domain show where DNS fits.

If you are choosing a provider, send your address through the check form. A person looks at the path from the nearest tower and calls you back, and you can ask about hosting and domains on that call.