On this page
.jpg){kind=link}
Your website can be available while company email is broken. Your domain can be paid for while its DNS records point to the wrong service. A new website provider can have access to edit pages without having the authority needed to move the domain.
These situations are easier to understand once you separate the domain name, registration, DNS, website hosting and email service. They may come on one invoice, but they do different jobs. Knowing which one is changing helps a business approve the right work and avoid disrupting something unrelated.
The five parts behind a business domain
| Part | Its job | What the business should identify |
|---|---|---|
| Domain name | The name people use, such as example.com | Which names the business relies on |
| Registrar | Manages the domain's registration and renewal | Registrant details, renewal responsibility and account recovery |
| Authoritative DNS host | Publishes the domain's DNS records | Where the active records are managed and who can change them |
| Website host | Runs or stores the website | Hosting account, website management and recovery arrangements |
| Email provider | Handles mailboxes and mail delivery | Which service receives mail and who administers it |
ICANN's domain-industry explanation distinguishes registrars, DNS hosts and website hosts. One company can provide several of those services. Separate providers can also work together perfectly well. The important part is an accurate record of the arrangement, rather than assuming the company that built the website controls everything.
What DNS does when someone visits or sends mail
DNS stands for Domain Name System. It supplies records that help internet services find destinations and obtain other information about a name. Authoritative nameservers hold the published answers for a domain. A resolver looks up answers for the device or service making a request and can keep a cached copy.
When someone visits www.example.com, the lookup can lead to the website's address. When another mail system sends to hello@example.com, it looks for the domain's mail destination. Those are different lookups, even though the business name appears in both. Cloudflare's nameserver reference explains the authoritative role.
DNS supplies directions and assertions; it does not contain your website's pages or the contents of your inbox. Recreating a DNS record cannot recover a deleted website or mailbox. Those need their own recovery arrangements.
The records business owners will hear about
You do not need to memorize every record type. A few names explain most provider-change discussions:
- A and AAAA: associate a name with an IPv4 or IPv6 address.
- CNAME: points one DNS name to another name. It does not itself create a website redirect or change the address shown in a visitor's browser.
- MX: identifies mail servers for receiving email for a domain.
- TXT: publishes text used for purposes such as service verification and some email-authentication records.
- NS: identifies authoritative nameservers in the DNS delegation system.
Cloudflare's record-type reference describes these records in more detail. A provider's request to add a record should name the service and its purpose. A verification record, a mail-routing change and a nameserver change should not be treated as interchangeable instructions.
Why a website move can affect email
A website-only move may need a change to its address records while leaving mail records alone. A nameserver change is broader: it changes which DNS service supplies authoritative answers. If the new service has only the website records, other services can stop resolving correctly.
Consider a company launching a replacement website. Its email stays with Microsoft 365, and a separate platform sends appointment reminders. The website designer prepares the new site, but the DNS handover copies only the website address. The company might see the new homepage while missing mail-routing or sending-authentication records cause trouble elsewhere.
The sensible approval question is: Are we changing a website destination, the DNS provider, the registrar, or more than one? Each has a different scope. Ask for the existing record set and the intended changes to be compared before a cutover, with a named person responsible for checking email and business applications afterward.
Changing an MX record directs new incoming mail toward the selected service; it does not migrate old messages. Microsoft's domain troubleshooting guidance also notes that mailboxes should be ready before mail is redirected to Microsoft 365. That is an email migration decision, even if the request arrives during a website project.
What “propagation” and TTL really mean
TTL, or time to live, tells DNS caches how long a record may be retained before it is looked up again. A resolver that already has an answer can continue using it until that cached answer expires. Another resolver with no cached answer may see a newer value sooner.
That is why two people can observe different results during a change. Lowering a TTL at the moment of a move does not retroactively shorten every copy already cached elsewhere. A rollout plan should consider the earlier TTL and allow time for different caches. Cloudflare's TTL explanation describes the trade-off.
Waiting is useful only when the records and delegation are correct. A missing record, an incorrect destination or a change made at an inactive DNS provider needs correction. “Give it 48 hours” should come with a reason and a check of what is currently published. Cloudflare's DNS troubleshooting reference covers missing records, nameserver changes and cached negative answers.
Protecting the accounts that control the name
Registrar and DNS accounts deserve careful access control because they can influence several business services. The business should know which organization is recorded as registrant, which accounts have administrative access, where renewal notices arrive and how access can be recovered if a provider or employee becomes unavailable.
Use available multifactor authentication and retain recovery information securely. An independent, protected recovery contact can help avoid a circular problem where a domain outage also prevents receipt of its own recovery emails. ICANN's registrant account-protection guidance discusses registration-account risks and recovery dependencies. Its operational principles remain useful, although the report dates from 2010 and individual providers' current controls differ.
DNSSEC is a separate protection that allows validation of signed DNS data. It does not encrypt website content or replace account security. DNSSEC needs to remain consistent with the domain's delegation when providers change; it should be part of the migration plan. See the DNSSEC reference.
What a clear provider handover should leave behind
A useful handover identifies the registrar, active nameservers, DNS administrator, website host, email service and the business contact responsible for each. It also records which subscriptions must remain active and the approved method for restoring access. Store passwords and recovery codes in an appropriate password manager, outside an ordinary document shared with several vendors.
Keep a dated record of changes so a later support issue can be traced to the work that actually happened. If mail stopped after a website launch, that history helps distinguish a DNS change from an unrelated mailbox problem. Our IT documentation reference covers the broader business record; the provider-switching guide covers the wider transition.
For the records used to authenticate outgoing email, continue with SPF, DKIM and DMARC explained. Those checks build on DNS, but they answer a different question: how a receiving system evaluates a sender's use of a domain.