A checklist for changing DNS records safely

Two kinds of breakage, and only one is loud

When a DNS change breaks a website, you find out quickly. The page stops loading, someone messages you, and the fix is usually to put a record back. When a DNS change breaks email, you often find out weeks later, from a client who says they never received your reply. That difference is why this checklist spends as much time on mail as on the site.

We made a change like this on our own domain on 1 September 2026. Our www hostname had been returning an error page while the main address worked, and the fix meant replacing a CNAME record on www with an A record. It was a small edit to a zone that also carries our mail records, and this page is built from what we wrote down while doing it.

A small business domain usually holds records for several services that know nothing about each other: the host serving the website, the provider handling mail, and a handful of services that asked you to prove you own the domain. Each one only knows about its own records, and none of them will warn you when an edit meant for another one removes theirs.

What each record is holding up

Before changing anything, know which service depends on which record. These are the records a typical small business domain carries. Yours may have more.

Record	Usually at	What depends on it	What you notice if it breaks
A, and AAAA	The domain itself, and often www	The website, by pointing a name at the server's address	The site stops loading, quickly and obviously
CNAME	www or another subdomain	A website or service, by pointing one name at another name	That one hostname stops working while the others carry on
MX	The domain itself	Incoming mail, by naming the servers that accept it	Mail sent to you stops arriving, and a sending server may keep retrying for days before it reports a failure
TXT starting v=spf1	The domain itself	The list of servers allowed to send mail as your domain	Mail you send starts failing checks at the receiving end, usually with no message back to you
TXT under _domainkey	A selector name your mail provider chose	The public key that proves a message was signed by your provider	Signed mail stops verifying, which weakens the checks that rely on it
TXT at _dmarc	_dmarc in front of your domain	What receivers should do with mail that fails those checks	Receivers stop applying your policy, or apply one you did not intend
Other TXT records	The domain or a subdomain	Proof of ownership for services such as search consoles and hosting platforms	The service loses its proof that you own the domain
NS	The domain itself	Which servers answer for the whole zone	Everything, because every other record is served by these

Common DNS records, what depends on each, and how a break shows itself

A missing MX record does not always mean a domain receives no mail. The SMTP specification says that when no MX records exist, a sender treats the domain as if it had an implicit MX pointing at the domain itself. Treat the table as a map of what depends on what, not as a diagnosis.

Before you change anything

Find out where the zone is actually managed. That is wherever the domain's nameservers point, which is not always the registrar you bought the domain from or the company hosting your site. Run nslookup -type=NS followed by your domain and look at the names it returns.
Write down every record in the zone, not only the one you mean to change. Export the zone if your DNS panel offers an export, and take screenshots if it does not. It takes two minutes, and it is the only way to put things back exactly as they were.
Check for forwarding. Some registrars implement a domain forwarding feature by adding records of their own, which then take precedence over what you set without saying so. If forwarding is switched on for the name you are about to change, turn it off first.
Lower the TTL on the records you will change, then wait. The TTL is how long a resolver may keep a record before asking again, so it is the old TTL, the one resolvers already hold, that decides how long the old answer lingers. Lower it to around 600 seconds and wait at least as long as the old TTL before making the change. A mistake then clears in minutes rather than hours.
Decide on one change. If two separate tasks both need to touch the zone, finish and verify the first before starting the second.
Run your checks before the change as well as after it. If you only look afterwards, you cannot tell a problem you caused from one that was already there.

The rules that prevent most of the damage

These are the rules we worked to on our own zone. Each exists because the mistake it prevents is easy to make in an ordinary DNS panel.

Add TXT records, never edit them. Several services can each keep their own TXT record at the same name, and the ownership proof for one hostname can look almost identical to the proof for another. When we added the proof for our www hostname, its value differed from the existing one for the main domain by a few characters in the middle. Many DNS panels put an edit button on every row, so overwriting a proof another service relies on is one click. Use Add.
The exception is SPF, which you merge instead of adding. The SPF specification says a domain name "MUST NOT have multiple records" that a check would select, and a second record makes the check return a permanent error instead of a result. When a new mail service asks you to add an SPF record, add its include to the record you already have. In our survey of Pune business domains, 12 had published two.
Merging has a limit of its own. An SPF check may perform at most 10 DNS lookups, counting each include, and going over that is also a permanent error. A record that has collected includes from every tool a business ever tried can break without anyone editing it.
A name with a CNAME can hold nothing else. RFC 1912 puts it plainly: "A CNAME record is not allowed to coexist with any other data." That is why the bare domain, which always carries its nameserver records, cannot be a CNAME, and why replacing a CNAME with an A record on the same name means deleting the CNAME first. Our www change was exactly that.
Type the short name. Many DNS panels, including the one we use, add your domain to whatever you type in the host field, so entering the full www address creates a name with your domain in it twice. Enter www.
Never restore a whole snapshot to undo one change. If anything else was added to the zone since the snapshot was taken, restoring it deletes that as well. Put back only the records you changed.

Check the answer at the source, then everywhere else

After an edit, the most misleading thing you can do is ask a public resolver whether it worked. Resolvers keep answers for as long as the TTL allows, and they keep the absence of a record too. RFC 2308 sets how long a resolver may remember that a record does not exist, from the zone's SOA record: "the minimum of the SOA.MINIMUM field and SOA's TTL." So for a while a public resolver can show you a record you have deleted, or deny one you have just added.

That is what happened on our change. After the CNAME on www was deleted, public resolvers went on returning it. The authoritative nameserver, asked directly, already showed it gone. Nothing was broken. We were reading a cache.

So check in this order. Ask the nameservers that own the zone first, because their answer is the truth about what you changed. Then check the website and mail from outside, which tells you whether everyone else has caught up.

# 1. Which servers answer for the zone
nslookup -type=NS example.com

# 2. Ask one of them directly, so no cache is involved
nslookup -type=A   www.example.com  ns1.your-dns-provider.example
nslookup -type=TXT example.com      ns1.your-dns-provider.example
nslookup -type=MX  example.com      ns1.your-dns-provider.example

# 3. Every hostname, and a deep path, not only the home page
curl -sSI https://example.com/
curl -sSI https://www.example.com/some/page

The website check is about more than whether the page loads. Request the main domain and the www form, and follow a deep link through any redirect to confirm the path survives it. A redirect that sends every deep link to the home page looks fine if the only address you test is the root.

Test the mail, because nothing else will tell you

Mail breaks quietly because of how the checks are defined. An SPF record ends with a qualifier on its all mechanism: -all asks for a fail on any server not listed, and ~all asks for a softfail. DMARC then tells receivers what to do when a message fails. RFC 9989, which replaced the earlier DMARC specification in May 2026, says p=none means the domain owner "offers no expression of preference", p=quarantine means the owner "considers such mail to be suspicious", and p=reject means the owner treats a failure as "a clear indication that the use of the domain name is not valid."

Quarantine is not a bounce. What a receiver does with mail it has been told is suspicious is the receiver's decision, and the sender is not informed. There is a second quiet path as well. RFC 9989 warns that some receivers check SPF before DMARC runs at all, so an SPF hard fail can get a message "rejected early in the SMTP transaction", and that those rejections "will never appear in aggregate DMARC reports". A domain owner reading their reports would see nothing wrong.

Our own domain is set up that way, with an SPF record ending in -all and a DMARC policy of quarantine. It is a sound configuration. It also means a damaged SPF record would not announce itself, which is why we test mail after every change to the zone, including changes that had nothing to do with mail.

Send a message from your domain to an account at a large mail provider that you can open, such as a Gmail address.
Open it there and view the full original message. In Gmail, that is the More menu beside Reply, then Show original.
Find the Authentication-Results header. It records what the receiving server concluded, with entries such as spf=pass and dkim=pass. Anything other than pass, on a message you have just sent yourself, is the first thing to fix.
Reply to that message from the same account and confirm the reply arrives, which tests incoming mail and your MX records.

If you send in volume, the stakes are higher. Gmail's sender guidelines require everyone sending to personal Gmail accounts to set up SPF or DKIM, and senders of five thousand or more messages a day to set up SPF, DKIM and DMARC, with the From domain aligned to one of them. Google applied those requirements from 1 February 2024.

If something breaks anyway

Put back only the records you changed, from what you wrote down before starting. Leave everything else alone.
Check the restored records at the authoritative nameserver, not at a public resolver, for the reason above.
Wait out the TTL before deciding the fix has failed. With the TTL lowered in advance, that is minutes.
If the website works but mail does not, split the problem. Mail not arriving points at MX. Mail you send failing its checks points at SPF and DKIM first, and DMARC after them, because DMARC is judged on the results of the other two.

Keep the record you made at the start even after everything works. The next person to change the zone, who may be you in a year, will want to know what it looked like the last time it was known to be right.

What this does not cover

It covers editing records in a zone you already run. Moving a domain to a new registrar, changing nameservers and DNSSEC each carry risks this checklist does not address.
DNS panels differ. Labels, defaults and whether the host field appends your domain vary by provider, so confirm how yours behaves rather than assuming it matches ours.
It does not explain how to set up DKIM signing. Your mail provider generates the key and tells you what to publish, and the steps differ by provider.
Checking records proves what the zone says, not that mail is delivered. The only complete test is sending and receiving real messages, and even that only tests the providers you tried.
The count of domains with two SPF records comes from one survey of Pune business domains, read in September 2026. It shows the mistake happens, not how often it happens anywhere else.

Sources

The whatscene.in DNS zone, before and after the www change of 1 September 2026. Every record in the zone written down before the change, the CNAME on www replaced with an A record, then each record queried at the authoritative nameserver and through public resolvers, and each hostname requested directly with its status code and redirect target recorded. Run: OWNER-ACTIONS.md section 0, recorded 2026-09-01.
Pune business survey, 836 registrable domains. The count of domains publishing two SPF records is read from the DNS survey behind our research piece on what local business domains leave open, where the full method and its limits are set out. Run: scripts/pune-dns.mjs, 2026-09-03 10:23 UTC.
RFC 9989, DMARC, which obsoleted RFC 7489 in May 2026, IETF. Retrieved 17 September 2026.
RFC 7208, Sender Policy Framework, including the single-record rule and the lookup limit, IETF. Retrieved 17 September 2026.
RFC 6376, DKIM Signatures, including selectors and the _domainkey namespace, IETF. Retrieved 17 September 2026.
RFC 1912, Common DNS Operational and Configuration Errors, section 2.4 on CNAME records, IETF. Retrieved 17 September 2026.
RFC 2308, Negative Caching of DNS Queries, IETF. Retrieved 17 September 2026.
RFC 1035, Domain Names, including the definition of TTL and MX preference, IETF. Retrieved 17 September 2026.
RFC 5321, Simple Mail Transfer Protocol, including retry time and the implicit MX rule, IETF. Retrieved 17 September 2026.
RFC 8601, the Authentication-Results header field, IETF. Retrieved 17 September 2026.
Email sender guidelines, Google. Retrieved 17 September 2026.
Trace an email with its full header, Google. Retrieved 17 September 2026.

Revisions

17 September 2026 First published.

This page is revised in place rather than replaced, so its address does not change.