The registrar holds it
You edit records in the registrar account. One login covers the name and where it points.
You know the domain points at your site. DNS decides where. Most DNS management for business domains comes down to two questions: which record does what, and how to change one without losing email.
Registering the name and keeping control of it are covered in the domains guide. This page is about what comes after: the settings that decide where the name sends people once it is yours.
Two words get used as though they mean the same thing. They do not.
So the first question is not what a record does. It is whose list is being read. That company's panel is the only one that matters. Records edited elsewhere change nothing.
You edit records in the registrar account. One login covers the name and where it points.
The nameservers point at the hosting company, so the list lives there. Convenient until you move.
A separate DNS provider sits in front. Records edited at the registrar are then ignored.
Not sure which you have? Look up the domain's NS records. They name the company whose panel you need.
There are dozens of record types. A business domain deals with five: A, CNAME, MX, TXT and NS. TXT does several different jobs, which is why it appears more than once below.
| Record | What it does | When you touch it |
|---|---|---|
| A | Points a name at a server's numeric address. Where the website loads from. | When the site moves to a different server. |
| CNAME | Points one name at another name, so it follows wherever that goes. | Setting up www, or pointing a subdomain at a service. |
| MX | Says which mail server accepts email. Nothing to do with the website. | When email moves provider, and never otherwise. |
| TXT (SPF) | Lists which servers may send mail using your domain name. | When anything that sends mail as you changes. |
| TXT (DKIM) | Publishes the key that proves a message came from your mail provider unaltered. | At mailbox setup, using the value your provider issues. |
| TXT (DMARC) | Tells receiving servers what to do with mail that fails those checks. | Once SPF and DKIM are confirmed working. |
| TXT (verification) | Proves to a third party that you control the domain. | Connecting a search console, analytics or mail platform. |
| NS | Names the nameservers holding the list. Set at the registrar. | When you hand DNS to another company. Rarely. |
Most sites need both yourbusiness.com and www.yourbusiness.com to work. The usual arrangement is an A record on the bare domain and a CNAME on www pointing back at it, so a server move is one edit instead of two.
SPF, DKIM and DMARC do one job between them: making it hard for somebody to send email that appears to come from your business. They belong to your mail provider, not your website, and they are the records most often lost in a host migration.
Two rules avoid most of the trouble. A domain may have only one SPF record, so replace the value when a provider changes rather than adding a second. And DMARC goes in last, once the other two are confirmed passing, because a strict policy on a broken setup sends your own mail to junk. The business email page covers the mailbox side.
Propagation sounds like something spreading outward across the internet. Nothing spreads.
Every answer DNS gives out carries a shelf life called the TTL, or time to live. Providers and office networks keep that answer until the timer runs out, then ask again. The new value is available the moment you save it. The delay is only the old copies that have not expired.
Your computer and browser cache separately too, which is why you see the old site longer than your customers do.
Set the shortest value your DNS panel allows, a day or two ahead. Wait out the old TTL: if it was a day, the internet needs a day to notice the shorter one. Then make the change, and put the TTL back up afterwards. Skipping the wait is the same as doing none of it.
Nearly every DNS request we take is one of three jobs.
The full order of operations for moving a site is on the website migration page.
The mailbox side, devices and aliases included, is on the email migration page.
Search consoles, analytics accounts and mail platforms ask you to prove you control the domain. They generate a value, you publish it, they look it up.
A and CNAME point at the website. MX and the TXT family point at the mail. They sit on the same list and have nothing to do with each other. The site can live at one company and the mailboxes at another, permanently.
Which is why the sentence to watch for is any version of "we will just switch the nameservers over". That replaces the whole list, mail records included.
A control panel shows what you saved, not what the internet is answering. That gap is where afternoons go.
If something looks wrong, resist changing more records to see whether it helps. Put back what you changed. Our support centre lists the first checks for common faults.
Most businesses touch DNS a handful of times in the life of the company. There is nothing to tune and no benefit in tidying a list that works. Do not delete records you do not recognise: a stray TXT record is almost certainly proving your domain to a service somebody connected years ago.
For the domains we manage we make these changes ourselves, and we copy the existing records before replacing anything. Many of our calls come from somebody halfway through a change that has not gone as expected. Tell us what changed.
Still working out which part of your setup is which? Domain name vs web hosting draws that line, and domain privacy covers the other registrar setting.
That depends on the TTL set before you made the change, not on anything you do afterwards. Some people see the new answer in minutes, others keep the old one until their cache expires.
Only if the mail records get lost along the way. Changing one A record moves the website and leaves email untouched. Changing nameservers hands the whole list over, so the mail records have to be recreated there first.
Change the A record if the website is moving and nothing else is. Change nameservers only when you want the new company to hold the whole list, and only after every record has been copied.
Not before finding out what it is. Unfamiliar TXT records are usually proving your domain to a service that will quietly disconnect once the record disappears. If everything works, leave it alone.
No. The registrar holds the name and the nameservers decide who holds the records, so the two can sit at different companies. Keeping them together means one place to look when something breaks.
Registration, transfers, renewals and locking: the guide to owning the name itself.
Read the domains guideWhat you are renting, and how a host move is sequenced.
Read the hosting guideTell us what you are trying to do and we will tell you which record it is.
Ask AldoMediaMost businesses would rather nobody at the office ever had to open one. Put the domain in our hands and nobody there will. If nobody is sure who controls your records, start there.