The short answer
A domain is the name you rent, hosting is the computer that holds your site, and DNS is the directory that connects the name to that computer and routes your email. DNS is made of records (A, CNAME, MX, TXT), each with a TTL that controls how long the answer is cached. One wrong record can take down your site or your email.
Three things people mix up
Think of a shop. The domain is the street address printed on your business card. The hosting is the building itself, with your products inside. DNS is the sign at the end of the road that tells visitors which building the address belongs to. If the sign is wrong, people arrive at the wrong place or nowhere, even though the building is fine.
Each of these is usually bought separately, and often from different companies. That is normal. It also means that "my website is down" can have three very different causes, and the fix depends on which one it is.
| Piece | What it is | Who you pay | What breaks if it fails |
|---|---|---|---|
| Domain | The name you rent, such as yourcompany.com | A registrar, usually yearly | Site and email both stop when it expires |
| Hosting | The server that stores and serves your website files | A hosting company, monthly or yearly | Site goes down, email usually keeps working |
| DNS | The records that point your name to hosting and email | Often included with the registrar, host or a service like Cloudflare | Site, email or both can fail depending on which record is wrong |
| Email service | Where your mailboxes live (for example Google Workspace or Microsoft 365) | The email provider, per user | Mail stops or is rejected, site keeps working |
How DNS works, in one picture
When someone types your domain, their device asks a DNS resolver, usually run by their internet provider or a public service, "where does this name live?" The resolver checks whether it already knows the answer. If not, it asks the authoritative name servers for your domain, the servers that hold your official records. Those servers answer, and the resolver remembers the answer for a set time before asking again.
The important point: your domain has one set of name servers that act as the official source. Wherever you edit DNS records, they only take effect if they are on the set of name servers your domain actually uses. A very common mistake is editing records at the registrar while the domain is pointed at name servers belonging to a host or Cloudflare. The edit saves fine and does nothing.
The record types you will actually meet
A record is one line in your DNS. For most businesses, four types cover nearly everything.
| Type | What it does | Looks like | Typical use |
|---|---|---|---|
| A | Maps a name to an IPv4 address (AAAA does the same for IPv6) | @ → 203.0.113.10 | Points your site to its server |
| CNAME | Makes one name an alias of another name | www → yourcompany.com | Sends www or a subdomain to another address or a service |
| MX | Says which mail servers receive email for the domain, with a priority number | @ → mail.provider.com (priority 10) | Delivers your email to Google, Microsoft or another provider |
| TXT | Holds free text that other systems read | v=spf1 include:... ~all | Email authentication (SPF, DKIM, DMARC) and proof you own the domain |
The example IP address above is a documentation placeholder, not a real server. Your own values come from your host or email provider. Cloudflare's reference describes these types the same way: an A record maps a name to an address, a CNAME maps a name to another name, an MX record is required to deliver email, and a TXT record holds text such as ownership proofs.
TTL and "propagation"
Every record carries a TTL, short for time to live, a number of seconds that tells resolvers how long they may remember the answer. A long TTL makes lookups faster but slows updates, because resolvers keep serving the old answer until the timer runs out. A short TTL means changes reach people sooner. Cloudflare's documentation describes exactly this trade-off, and lists a range from 60 seconds up to one day for records that are not proxied.
"Propagation" is the everyday word for those cached answers expiring around the world. It is not a single event. Different people see the change at different moments, which is why you may see the new site while a colleague still sees the old one. Some providers also say changes can take up to 48 hours, for example in Google's own setup guidance for SPF. Plan for the slow end, and lower the TTL before a planned change as described in point your domain to a new site.
Why one wrong edit breaks things
- Deleting or changing an MX record sends your email to the wrong place, or nowhere. Messages may bounce or be lost.
- Replacing the whole zone at a new host (a common step when switching providers) often drops the MX and TXT records, so the website works and email dies silently.
- Changing the A record on the main name moves the whole website. If it points at a server that does not have your site, visitors see an error or someone else's page.
- Adding a second SPF TXT record instead of editing the existing one makes SPF fail, and your mail starts landing in spam.
- A CNAME on a name that already has other records (such as the bare domain with its MX records) is not allowed in standard DNS and causes unpredictable results. Some providers offer a workaround, but check before using it.
Never delete a DNS record you do not recognize. It is usually there for email, a verification, or a service your team set up years ago.
A safe way to edit DNS
- 1Find out which name servers your domain really uses. Your registrar shows them under "name servers" or "nameservers". That tells you where the live records are.
- 2Open the live records and copy every one of them (a screenshot is fine) before changing anything.
- 3Change one record at a time, and note the old value next to the new one.
- 4If the change is planned, lower the TTL a day or more in advance so the switch is fast and reversible.
- 5After saving, test the website and send a test email both directions. See email and your domain for the test steps.
- 6If something breaks, put the old value back. That is why you wrote it down.
Example: A site move that silently killed email
A clinic moved its site to a new host. The new host said "point your name servers to us", so the owner changed them at the registrar. The site loaded fine the next day. Three days later patients complained that emails to the clinic bounced. The old DNS zone held the MX records for Google Workspace and a TXT record for SPF. The new host's zone was empty, so mail had nowhere to go. The fix took minutes once someone compared the old zone with the new one: copy the MX and TXT records across. The lesson is to export the old records first and to test email, not only the site.
When to ask us
Ask before you change anything if you do not recognize a record, if your domain, host and email are all with different companies, or if a launch is planned. Send a request through the support form and include: your domain name, who your registrar and host are (if you know), what you changed or want to change, and the date. Add a screenshot or link to a screenshot of your current DNS records (Google Drive, Dropbox or Loom). Do not send passwords. We can work out what is needed and guide the change without seeing a login.
If you are not sure who controls your domain, read who owns your accounts first, then tell us what you found.
