DNS Records Explained: A, CNAME, MX, TXT, and More

DNS records are the entries that tell the internet where your domain's website and email live. Each of the DNS record types answers a different question, and most problems that look mysterious come down to one wrong entry. This guide covers the records you will meet in a hosting panel, which account owns each one, and how to change them without redirecting your mail.

This guide focuses on the checks a small-site owner can make safely. It also points out where a registrar, DNS provider, or host needs to take over. Read how to choose a web host if you need the broader setup, and our guide to migrating without downtime before changing live infrastructure.

Find which account owns your DNS records

Keep the registrar login, DNS provider login, and hosting login straight. They may be the same company, but they are different jobs. Confusing them is how a small DNS change becomes a long afternoon.

Make a short note with account names, domain names, the exact records involved, and the last known working values. Do not put passwords or recovery codes in the note. You want enough detail to retrace the work without creating a new security risk.

DNS record types in plain language

An A record points a name at a server's IP address. A CNAME record makes one name an alias for another, which is how www usually works. An MX record tells the world which server receives your email, and a TXT record holds text that other systems check, such as domain-verification strings and SPF.

Record the current value before you edit any of them. DNS entries are short, but a single missing dot, wrong record type, or stale nameserver can direct visitors and mail somewhere else.

Change one record, then verify it

Make DNS changes one at a time, then confirm them with an independent lookup. A browser is useful, but it can keep an older answer in cache. If the record has a long TTL, allow the old answer time to expire before assuming the change failed.

Test the path with the most consequence. For a website change, load the site from a second connection. For an MX change, send a test email from an outside account and confirm it arrives.

When to stop and ask for help

Stop when the next action could overwrite data, change production mail, or remove access to the account. Send support the domain, the exact record, time in UTC, and the changes you made. Include a screenshot when it shows the error, but do not include private keys, passwords, or full payment information.

ICANN's DNS overview has useful background on how the system fits together: ICANN's DNS overview. Use it to understand the terms, then return to the small, reversible next step.

A sensible maintenance habit

Put the final record values and the result in a short maintenance note. DNS problems repeat because nobody remembers which account owns a record or why a TXT entry exists. A dated note turns the next incident into a lookup instead of an investigation.

Keep the change auditable

Use a short before-and-after record. Write the DNS record you found, its old value, the exact time you changed it, and the result of the test. If the change has a delay, such as a long TTL, write the time you expect the new answer to be visible. This record is useful even when everything works. A few months later, it tells you why an entry has an unusual value.

Do not confuse an account dashboard with evidence from the live internet. A dashboard can show that it accepted a record. Resolvers still need to serve the answer you intended, and mail servers need to find the right MX. Test from outside the account, and use a second connection if a cached answer could mislead you.

If you hand the task to someone else, give them the record rather than a conclusion. "Email stopped working" is hard to investigate. "The MX record changed at this time, and mail from outside bounces with this error" gives the next person a useful starting point.

One last check

Before you close the ticket or move to the next task, look up the record again from the ordinary path a visitor would use, not only the account dashboard. If the result is different, note the difference and keep troubleshooting from that point. A quiet confirmation now is much easier than discovering a wrong entry during a launch.

Leave a useful handoff

Save the final values with the date and account involved. If someone else needs to revisit your DNS records, they should be able to see what changed without reconstructing the whole incident from browser history.

Bottom line

DNS records get easier when you treat them as a few small tools with separate jobs: A and CNAME for the website, MX for mail, TXT for proof. Change one at a time, write down the old value, and test the result where it matters.

Frequently asked questions

Should I change all my DNS records at once?

No. Change one record, test it, and keep the previous value written down until you know the result is stable.

What should I give support about a DNS record problem?

Give the domain, the exact record and its values, UTC time, error text, and steps already tried. That is usually enough for support to find the relevant logs.

Should I back up DNS records before editing them?

Yes. Save or export the current values before edits that affect DNS, email, or a live site.