DNS changes look deceptively simple: choose a record type, enter a
name and value, then click Save. The risk is not the number of fields.
It is that DNS controls several independent services at once, including
the website, email delivery, verification, and security policies.
The safest rule is straightforward: never delete or replace an
existing DNS record unless you understand its purpose and the planned
change specifically requires it.
In everyday language, this problem often appears as ‘my website move
broke my email,’ ‘the domain points to the wrong place,’ or ‘Google says
it can’t verify my domain.’ Those symptoms can involve different DNS
records, so preserve the current zone before editing.
Understand the major record
types
- A and AAAA records direct a hostname to an IPv4 or
IPv6 address. - CNAME records make one hostname an alias of
another. - MX records identify the servers that receive email
for the domain. - TXT records carry verification values and policies
such as SPF, DKIM, and DMARC. - CAA records can restrict which certificate
authorities may issue certificates for the domain.
The root domain is often represented by @. Interfaces
vary, so confirm how the DNS provider expects the name field to be
entered.
Document the current zone
first
Before changing anything, export the zone if the provider offers that
feature. Otherwise, take full screenshots and copy important records
into a dated document.
Record the type, name, value, priority, and TTL for every entry.
Scroll through the complete list. DNS panels sometimes separate records
by type or hide older entries below the visible portion of the page.
This record becomes the rollback reference. It also makes it easier
to identify whether a new instruction conflicts with something already
present.
Separate
website instructions from email instructions
Moving a website does not automatically mean moving email. A domain
can use one company for registration, another for DNS, a third for
website hosting, and a fourth for email.
When connecting a new web host, the host may recommend replacing
nameservers. That can be valid, but nameserver replacement transfers
responsibility for the entire DNS zone. If the new zone does not
reproduce the existing MX and email-authentication records, mail may
stop even though the website works.
When email must remain with the existing provider, confirm how every
MX, SPF, DKIM, and DMARC record will be preserved before changing
nameservers.
Add
verification records without removing anything
Services such as Google Search Console commonly use a TXT record to
prove domain ownership. This is usually additive. Enter the supplied
value exactly and leave existing TXT records in place.
Multiple TXT records at the root are normal. The exception is SPF: a
domain should not publish multiple competing SPF policies. If a service
asks you to add SPF information, the existing SPF record may need to be
carefully merged rather than duplicated. Email-policy changes deserve
provider-specific review.
Change one logical service
at a time
Avoid combining a website move, email migration, nameserver change,
and analytics verification into one untracked session. Make one logical
change, save it, and verify the intended outcome.
DNS updates may appear quickly but can take longer because resolvers
cache old values according to TTL and other behavior. Do not repeatedly
edit a correct record just because one network has not updated yet.
Verify from more than one
perspective
After a website-related change, test the root domain, the
www hostname, HTTPS, and several internal pages. After an
email-related change, send messages both to and from an outside account.
Check spam placement and review whether SPF, DKIM, and DMARC still
pass.
For a verification TXT record, return to the requesting service and
use its verification function. Keep the verification record after
success unless the service explicitly documents that removal is
safe.
Recognize destructive
warning signs
Pause if an instruction would:
- Delete all existing records.
- Replace nameservers without recreating the current zone.
- Remove MX records during a website-only change.
- Publish a second SPF record.
- Point both a CNAME and another incompatible record at the same
hostname. - Expose a private key, password, or recovery code in a TXT
record.
Keep a DNS change log
For every change, record the date, reason, old value, new value,
source of the instruction, and verification result. This small habit
turns DNS recovery from guesswork into a controlled rollback.
DNS is shared infrastructure. Treating each record as part of a
larger system protects both the website and the services users cannot
see.
Build a rollback threshold
Before saving a change, decide what evidence would trigger rollback.
For a website move, that might be invalid HTTPS, missing pages, or
failure at both the root and www hostnames. For email, it
might be rejected external test messages or failed authentication.
Do not roll back solely because one resolver still shows the old
value during the expected propagation window. Compare authoritative DNS
with cached results and document the observation time.
Frequently asked questions
Can two services
use TXT records at the root?
Yes. Multiple TXT records are common. Preserve existing verification
and policy records. SPF is a notable case where separate competing
policies can cause problems and generally require careful
consolidation.
Should I lower TTL before
a migration?
Sometimes. A lower TTL established in advance can shorten caching for
a planned change, but it does not make every resolver update instantly.
Restore an appropriate steady-state TTL after the migration
stabilizes.
Is changing nameservers
reversible?
Technically yes, but cached delegations and incomplete zones can
prolong disruption. Export both zones and prepare the destination
completely before changing delegation.
Related guides
- Website Hosting and Email Hosting Can Be Separate
- How to Verify a Domain in Google Search Console