Domains

DNS Management for Business Domains

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.

Secure Your Domain Name Now Get help choosing

DNS management for business domains starts with nameservers, not records

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.

  • Nameservers say which company holds the list of settings for your domain. They are set at your registrar.
  • Records are the entries on that list: where the website is, where mail goes, who may send as you.

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.

The registrar holds it

You edit records in the registrar account. One login covers the name and where it points.

The host holds it

The nameservers point at the hosting company, so the list lives there. Convenient until you move.

Something else holds it

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.

The records you will actually meet

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.

Coils of white rope running through weathered wooden pulley blocks in the rigging of a wooden sailboat, green trees behind.
Rigging blocks on a sailing boat route each line where it belongs, much as DNS records route a domain.Bjankuloski06, CC BY 4.0, via Wikimedia Commons. Cropped.
The DNS records a small business actually deals with
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.

A and CNAME, and the www question

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.

The TXT family, and why it is really about email

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.

TTL, and what propagation really means

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.

  • The wait is set by the old TTL, not the new one. Lowering it as you make the change achieves nothing: the answers already handed out still carry the old timer.
  • People move over at different times, in no useful order. A phone on mobile data may see the new answer while the office does not.

Your computer and browser cache separately too, which is why you see the old site longer than your customers do.

Lowering the TTL before a planned change

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.

The three changes a small business actually makes

Nearly every DNS request we take is one of three jobs.

1. Point the website at a new host

  1. Ask the new host what they want. They give you either nameservers or an address for an A record. These are not the same.
  2. Prefer the A record when mail is not moving. It moves the website and leaves MX and the TXT family alone.
  3. If you must change nameservers, copy the list first. Recreate every record at the new provider before switching. Anything you did not copy stops existing.
  4. Lower the TTL a day or two beforehand, as above.
  5. Change it, then check both addresses on a device you have not been working on.
  6. Check the certificate. A different server needs its own. See what an SSL certificate does.

The full order of operations for moving a site is on the website migration page.

2. Point email at a new provider

  1. Get the new mailboxes working first. Create them and send a test message between them, before touching DNS.
  2. Copy the existing mail across before you change anything, not after.
  3. Change the MX records only. Leave A and CNAME alone. The website is not moving.
  4. Replace the SPF value, do not add a second record. Two SPF records count as none, and that is what sends everything to junk.
  5. Add the DKIM record the provider issues, exactly as given.
  6. Leave the old mailboxes running for a couple of weeks. While both accept mail, nothing bounces.

The mailbox side, devices and aliases included, is on the email migration page.

3. Verify the domain for a third-party service

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.

  1. Copy the value exactly. One missing character is a failed verification with no explanation.
  2. Watch the host name field. Some panels add your domain automatically, so pasting the full name makes a record ending in yourbusiness.com.yourbusiness.com, which never verifies.
  3. Wait for the lookup before clicking verify. Ten seconds after saving is usually too soon.
  4. Leave it in place afterwards. Most services re-check quietly and disconnect if it vanishes. Deleting one in a tidy-up loses the service.

The golden rule: website records and mail records are independent

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.

How to check what is live right now

A control panel shows what you saved, not what the internet is answering. That gap is where afternoons go.

  • Look the records up publicly. Any public DNS lookup site reports your current A, MX, TXT and NS records from outside your network. Start with NS: it names the panel you should be editing.
  • Test from a network you are not sitting on. A phone on mobile data will do.
  • Send mail in and out. Nothing else proves email works.

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.

When to leave DNS alone

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.

How AldoMedia handles it

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.

DNS questions

How long does a DNS change take to work?

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.

Will changing my web host take my email down?

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.

Should I change the nameservers or just change the A record?

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.

Can I delete a DNS record I do not recognise?

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.

Does my DNS have to be at the same company as my domain?

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.

Related guides and services

Domain Names

Registration, transfers, renewals and locking: the guide to owning the name itself.

Read the domains guide

Not sure what to change?

Tell us what you are trying to do and we will tell you which record it is.

Ask AldoMedia

Let somebody else hold the DNS panel

Most 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.

Secure Your Domain Name Now Get help choosing