Hosting vs. DNS
Most people discover the difference between hosting and DNS on the worst possible day. The website gets redesigned,
everything looks fine, and then the invoices stop arriving because company email quietly died three days ago and
nobody connected the two events.
They are separate systems, usually bought from separate companies, and they fail in separate ways. Knowing which one
you are looking at is most of the work in fixing it.
Three Things People Think Are One Thing
When somebody says "my website," they are usually describing three purchases that have nothing to do with each
other.
The domain name is the name itself — yourcompany.com. You do not own it, you rent it, from a
registrar such as GoDaddy, Namecheap, or Google. If that rental lapses, everything attached to the name stops,
including email, no matter who else you are paying.
DNS is the lookup system that turns the name into a location. Computers do not route traffic by
name, they route it by number. DNS is what tells the rest of the internet that yourcompany.com means a particular
server, and that mail for yourcompany.com goes somewhere else entirely. DNS holds no content. It is signage.
Hosting is the server where your actual files live — the pages, the images, the database.
This is the only one of the three that contains anything. It is the building; the other two are the address and the
road signs that point to it.
The reason this gets confusing is that these three are frequently held by three different companies, and sometimes
nobody at the business knows which company holds which. That is the single most common thing we untangle on this
subject, and it is worth knowing before you need it rather than during an outage.
How They Actually Connect
When someone types your address into a browser, this is the sequence:
- The browser does not know where yourcompany.com is, so it asks a resolver — usually one run by the
visitor's internet provider.
- The resolver finds which nameservers are authoritative for your domain. Those nameservers are the ones listed
at your registrar, and they are the system of record for everything else.
- It asks those nameservers for your A record, which holds the IP address of your web server.
- The browser connects to that IP address, and your hosting company's server sends back the page.
So DNS is consulted first and hosting second. If DNS is wrong, the visitor never reaches your host at all, and the
host being perfectly healthy makes no difference. If DNS is right and hosting is down, the visitor arrives at the
right building and finds the door locked. Those two failures look almost identical to the person reporting them and
are fixed in completely different places.
The Records That Matter
A DNS zone is a short list of records. You do not need to know all of them, but five come up constantly:
- A record — points your domain at the IPv4 address of a server. This is the one that
makes your website load. (AAAA is the same thing for IPv6.)
- CNAME — makes one name an alias for another. Typically how www is pointed at
your root domain, or how a service like a booking system gets its own subdomain.
- MX record — says where email for your domain should be delivered. Entirely independent
of your website. This is the one that causes the disaster described below.
- TXT record — free-form text, used for verifying ownership and, importantly, for SPF,
DKIM, and DMARC, which decide whether your outgoing mail is trusted or treated as spam.
- NS record — names the authoritative nameservers. Change these and you have moved your
entire zone, every record in it, at once.
Each record also carries a TTL, measured in seconds, telling resolvers how long to cache the answer.
That number is the whole of what people call propagation. Nothing is being pushed anywhere; the old answer is simply
still sitting in caches until it expires. A TTL of 86400 means some visitors will see stale information for up to a
day after you change it.
Why Your Email Dies When You Change Your Website
This is the most expensive version of hosting-versus-DNS confusion, and it happens the same way every time.
A business moves to a new web host. The new host says to point the domain's nameservers at them, which is reasonable
advice and usually correct. The nameservers are changed at the registrar. The website comes up on the new host and
looks perfect.
But changing nameservers moved the entire zone, not just the website. The new host built a fresh zone containing the
records it knows about — its own web server — and it has no idea that this company's email is handled by
Microsoft 365 or Google Workspace. The MX records that used to send mail there are gone. Mail now goes to the web
host, which is not a mail server for this domain, and it either bounces or disappears.
What makes it costly is the delay. Outgoing mail still works, so nothing feels broken. Nobody notices that incoming
mail stopped until a customer asks why their message went unanswered, which is often days later. By then senders
have received bounces you never saw, and whatever did not bounce is simply gone.
The fix is to copy the MX records — and the SPF, DKIM, and DMARC TXT records, which also live in DNS —
onto the new nameservers before the change, not after. If you are planning a hosting move and nobody has written
down what your current zone contains, that is the moment to stop and call someone.
Finding Out What You Actually Have
You can answer most of this yourself in about two minutes. Open Command Prompt on Windows and run these, replacing
yourcompany.com with your own domain.
Who runs your DNS:
nslookup -type=NS yourcompany.com
The nameservers that come back tell you which company actually controls your records. This is frequently not the
company anyone at the business expected, and it is the answer you need before changing anything.
Where your email goes:
nslookup -type=MX yourcompany.com
Names containing outlook or protection.outlook.com indicate Microsoft 365. Names containing
google or googlemail indicate Google Workspace. Something matching your web host's name means your
mail is handled there, which may or may not be deliberate.
Where your website points:
nslookup yourcompany.com
Your mail authentication records:
nslookup -type=TXT yourcompany.com
Look for an entry beginning v=spf1. If there is none, your outgoing mail has no sender authentication, which
makes it considerably more likely to land in spam folders. That connects directly to the delivery problems covered
on our business email page.
Write down what those four commands return and keep it somewhere that is not on the computer in question. That one
page of notes is worth more during an outage than anything else you could prepare.
Which One Is Broken?
A quick way to tell the two apart when something is wrong:
- Nobody can reach the site, and the name does not resolve at all — DNS, or an expired
domain. Check the registration first.
- The site loads for you but not for a customer, or the reverse — DNS caching. Someone is
holding an old answer that has not expired yet.
- The name resolves, but the page errors or times out — hosting. DNS did its job and
handed the visitor to a server that is not answering properly.
- The website is fine but email stopped — DNS, almost certainly MX records, and almost
certainly something changed recently.
- Mail sends but recipients never get it, or it lands in spam — DNS, the SPF, DKIM, and
DMARC TXT records.
When to Stop and Call
Reading your own records is safe — the commands above only ask questions. Changing them is where it gets
expensive, because a wrong entry can stop mail for a whole company and the TTL means your mistake persists for
hours after you correct it.
Worth a call rather than an afternoon:
- You are moving hosts and want the zone copied properly first, so email never goes down.
- Email has already stopped and you need the MX records restored and the gap in delivery
assessed.
- Nobody knows who holds the domain, the DNS, or the hosting. This is common, it is solvable,
and it is much better solved before a renewal date arrives.
- Your mail is going to spam and you need SPF, DKIM, and DMARC set up correctly rather than
guessed at.
- A domain has expired or is close to it. There is a recovery window, it is not long, and the
cost rises the longer it sits.
Related Articles
Business email •
IT consulting •
Computer support •
Commercial installation and IT services