DNS is the directory that tells browsers and email systems where to go. If a domain is the address people remember, DNS is the set of instructions that routes each kind of traffic.
That sounds simple, but DNS is one of the few places where a small change can affect a website, email, or a service that depends on the domain. The safe rule is not “never touch DNS.” It is: never change a record until you know what it controls and how you would undo the change.
What DNS does
When someone visits a website, DNS translates a name such as example.com into the destination that serves the site. Different DNS records can direct different jobs:
- A and AAAA records direct a name to an IPv4 or IPv6 address.
- CNAME records point one name to another name.
- MX records tell other mail systems where to deliver email.
- TXT records are often used for email authentication, site verification, and other configuration.
A website and its email can use the same domain while being managed by completely different services. That is why a website move does not automatically mean the email records should change.
The records that deserve extra care
For most small businesses, the highest-risk records are the email-related ones:
- MX records for incoming email
- SPF TXT records that state which systems may send mail for the domain
- DKIM records that help mail providers verify messages
- DMARC records that tell receiving systems how to handle messages that fail authentication
Removing or replacing those records while changing only the website can interrupt delivery or cause messages to be treated as suspicious. The same caution applies to verification records used by payment, analytics, or identity services.
A safe DNS-change checklist
Before changing DNS, write down the answer to these questions:
- What is the one outcome I need? For example: point the website to a new host, verify a service, or add a new subdomain.
- Which records are involved? Do not assume every record is connected to the website.
- What is currently there? Save a complete record inventory, including the host/name, type, value, and TTL.
- Who owns the login? Confirm that the person making the change has authorized access to the registrar or DNS provider.
- What is the rollback? Keep the old values so the exact previous configuration can be restored if verification fails.
-
How will we test? Check the intended page, HTTPS, common subdomains such as
www, and the business email flow after the change.
A useful habit is to change only the records required for the task, wait for the expected DNS propagation, and verify before making another change. Changing several unrelated records together makes troubleshooting much harder.
Website changes and email changes are separate projects
A common mistake is to replace a domain’s entire DNS zone with instructions supplied by a new web host. That can overwrite email or verification records that the new host does not know about.
For a website-only move, the goal is usually to preserve the mail-related records and change only the web-routing records. If email is also moving, treat that as a separate migration with its own inventory, sender tests, receiving tests, and rollback plan.
What to ask a managed website provider
A managed service can reduce the day-to-day work, but the owner should still understand the process. Ask:
- Who will make the DNS change?
- Will the current records be inventoried before anything changes?
- How will email-related records be protected?
- What does the provider need from the domain owner?
- What is the verification and rollback process?
As the founder of Borg Sites, I built the service so we can connect and manage the website side of a client’s infrastructure instead of asking them to operate it every day. That does not mean we treat DNS casually: when a domain also serves business email, I expect the change process to protect the records and services that the owner already relies on. That careful, hands-on approach is why I built Borg Sites.
The practical takeaway
DNS is not mysterious, but it is shared infrastructure. A careful plan protects the website, the inbox, and the other services connected to a business domain.
What DNS change has caused the most unexpected issue in your experience?
Top comments (0)