The Zone Editor is where you add, change and remove the DNS records for domains on your account. It is also the tool with the widest blast radius in cPanel: a wrong record takes the website or the email offline, and the correction takes as long to spread as the mistake did.
Nothing here is difficult. The care is entirely in the order you work.
Opening it
In cPanel, open Zone Editor under Domains. Every domain on the account is listed with two options: a quick add for common record types, and Manage for the full record list.
Use Manage. The quick add is fine once you know what you are doing, and the full list is what lets you see whether a record for that name already exists, which is the thing that most often makes a change behave unpredictably.
Before editing: copy the zone
Select all the records and paste them into a text file on your own machine. Thirty seconds.
If something breaks, you have the original in front of you and the fix is retyping one line. Without it you are reconstructing a zone from memory while a client's mail is down.
This matters more here than almost anywhere else in cPanel, because DNS mistakes are not instantly reversible. The wrong answer is now cached across the internet.
Adding a record
Choose Add Record and fill four fields.
Name. The subdomain part, or the domain itself. cPanel usually appends the domain automatically, so entering blog produces blog.example.com. Entering the full name when it also appends produces blog.example.com.example.com. A common and confusing mistake. Look at what the field shows after you type.
TTL. How long resolvers may cache it. 14400 is a normal default; 300 while you are testing.
Type. A, CNAME, MX, TXT and the rest.
Record / value. What the record points at. Paste exactly what a service gave you: verification strings are checked character for character.
Changing one
Use Edit beside the record. Change one thing, save, and verify before touching another.
Two changes at once means that if something breaks you do not know which caused it, and you are now debugging with a cache full of both.
Check for duplicates first
This is the most common cause of a change that does not behave.
Adding an A record for a name that already has one leaves two records. Resolvers return them in no guaranteed order, so the site works for some people and not others, which looks exactly like propagation, and is not.
Read the full record list for that name before adding anything. The leftover is usually a record somebody added months ago for a reason nobody remembers.
Records you should not edit here
SOA serial. cPanel increments it when a zone changes, and that number is how other servers know something changed. Editing it by hand can stop changes propagating entirely.
NS records, unless they are genuinely wrong. Changing them takes the domain away from this server.
The A record for the domain itself, unless you are deliberately moving the site. That is the record that decides whether the website loads at all.
Verify with a query, not a browser
After saving:
dig example.com dig MX example.com dig TXT example.com
Your browser caches, your operating system caches, and your network's resolver caches. A page that loads for you says nothing about what anyone else is getting, and it is why the person making the change is usually the last to see it work.
To see what the wider internet has:
dig @8.8.8.8 example.com
Resetting a zone
cPanel offers to reset a zone to defaults. It is occasionally the right answer when a zone is genuinely tangled, and it deletes every custom record you have.
MX records for external mail, SPF and DKIM, verification records, subdomains pointing elsewhere: all gone. Mail stops immediately.
Only reset with the full record list saved somewhere, and expect to spend twenty minutes putting things back.
When you cannot edit the zone
If the Zone Editor shows no records, or changes have no effect, the domain's nameservers probably do not point here.
dig NS example.com
If those are not this server's nameservers, the zone here is being ignored entirely and you should be editing wherever DNS actually lives. Editing records on a server the domain does not use is the most common wasted hour in DNS work. The DNS troubleshooting guide starts with exactly this check.
Export the zone before you touch it
The editor makes changes immediately and there is no undo, so the copy has to exist beforehand.
dig example.com AXFR @ns1.example.com > zone-$(date +%F).txt 2>/dev/null for t in A AAAA MX TXT CNAME NS CAA SRV; do echo "; $t"; dig example.com "$t" +short done > zone-backup-$(date +%F).txt wc -l zone-backup-*.txt
Where transfer is refused, the second loop captures the records you can query, which covers everything in ordinary use.
Keep the file outside the account. A zone backup stored on the server it describes is not available during the outage that a bad zone edit causes, which is the only time you will want it.
The record types that behave differently
Most entries are straightforward. Three of them have rules that produce confusing failures when broken.
An alias record cannot coexist with any other record for the same name, so adding one where a mail record already exists breaks mail. It also cannot be used at the domain itself.
Text records longer than the maximum length have to be split into several quoted strings, and a panel that accepts a long value without splitting it produces a record that reads as invalid.
dig example.com TXT +short | awk '{ print length($0), $0 }' | sort -rn | head -3
dig www.example.com CNAME +short
dig www.example.com MX +short
The last two together find the common mistake: a name with both an alias and a mail record, which resolvers handle inconsistently and which explains mail that arrives for some senders only.
Confirm the change reached the world
The editor shows what it stored. Whether that is being served is a separate question with a separate answer.
dig example.com A @"$(dig example.com NS +short | head -1)" +short for r in 1.1.1.1 8.8.8.8; do printf '%-10s %s\n' "$r" "$(dig "@$r" example.com A +short)"; done
Ask the authoritative server first. If it does not have the change, the edit did not take effect and no amount of waiting will help.
If it has the change and the public resolvers do not, the record is correct and the previous value is still cached. That is a wait rather than a problem, and the length of the wait was decided by the TTL that was in place before you made the change.
