SOA Record Explained: What It Controls and How to Fix It
Every domain has one DNS record almost nobody looks at until something's wrong: the SOA record. It doesn't point to your website or your mail server, but it quietly controls how fast DNS changes actually take effect, and when a stale secondary nameserver decides to stop trusting your zone. Here's what each field does, and the specific problems a bad one causes.
What an SOA Record Actually Is
SOA stands for Start of Authority. Every DNS zone has exactly one, and it's not something you add manually - cPanel, your registrar, or your DNS provider creates it automatically the moment the zone exists. It doesn't route traffic. Instead, it tells other nameservers (and resolvers caching your domain) three things: who's authoritative for this zone, how a secondary server should stay in sync with the primary, and how long a "this record doesn't exist" answer should be cached.
You'll rarely need to touch it. But when you're debugging why a DNS change hasn't shown up somewhere, or why a secondary DNS setup keeps falling out of sync, the SOA record is usually the reason.
Reading an SOA Record Field by Field
Run dig SOA yourdomain.com and you'll get something like this:
yourdomain.com. 86400 IN SOA ns1.getwebup.in. hostmaster.yourdomain.com. (
2026071801 ; serial
14400 ; refresh
3600 ; retry
1209600 ; expire
300 ) ; minimum (negative cache TTL)| Field | What it controls |
|---|---|
| Primary nameserver | The server that holds the master, editable copy of the zone (ns1.getwebup.in above) |
| Admin email | Zone contact, written with a dot instead of @ (hostmaster.yourdomain.com. = hostmaster@yourdomain.com) |
| Serial | A version number for the zone. Secondary servers compare this to decide if they need to re-fetch anything. |
| Refresh | How often (in seconds) a secondary checks the primary's serial for changes. |
| Retry | How long to wait before retrying a failed refresh check. |
| Expire | How long a secondary keeps serving the zone from cache if it can't reach the primary at all before giving up. |
| Minimum / negative TTL | How long resolvers cache an NXDOMAIN ("this record doesn't exist") answer. |
When SOA Actually Bites You
Symptom: You added a record, but a secondary DNS provider still doesn't have it
Cause: if you run secondary/slave DNS (common with registrar-side backup nameservers, or a split setup between Getwebup and Cloudflare-style providers), the secondary only pulls a fresh copy of the zone when it checks the primary and sees a higher serial number. If your primary DNS software didn't bump the serial when you edited a record - which happens with some manual zone file edits outside of a proper Zone Editor - the secondary sees no change and does nothing.
Fix: in cPanel's Zone Editor, edits made through the UI auto-increment the serial for you. If you're editing a raw zone file over SSH or through a custom DNS tool, bump the serial manually every time - the usual format is YYYYMMDDNN (today's date plus a two-digit revision), so 2026071801, then 2026071802 for a second edit the same day.
Symptom: A typo'd DNS record is fixed, but the site still can't be found for 10+ minutes
Cause: this is the negative-cache (minimum) TTL doing exactly what it's supposed to. If a resolver asked for a record that didn't exist yet (say, you queried www before adding the A record), it caches that NXDOMAIN answer for the minimum-field duration - often 300 seconds to an hour depending on your provider's default.
Fix: there's no way to force-clear a remote resolver's cache, but you can shorten the wait for next time by lowering the minimum TTL to something like 300 (5 minutes) instead of the old BIND-era default of 86400 (a full day). If you're testing right after a change, query an authoritative nameserver directly to bypass caching entirely:
dig @ns1.getwebup.in www.yourdomain.comSymptom: Secondary DNS stops answering for your domain entirely after an outage
Cause: the expire field. If your primary nameserver is unreachable for longer than the expire value, a secondary is supposed to stop answering rather than serve a zone it can no longer verify is current. With expire set too low (some legacy templates use 604800, one week), a short primary outage on a weekend can be enough to take a secondary out of service.
Fix: most current templates default expire to 1,209,600 seconds (2 weeks), which is a safer margin. Unless you have a specific reason to shorten it, leave it at 2 weeks or longer.
Symptom: DNS changes take unusually long to reach anywhere, even the primary itself
Cause: people sometimes confuse SOA refresh/retry with general DNS propagation delay. They're related but not the same thing. Refresh only governs secondary-to-primary sync inside your own DNS setup - it has nothing to do with how long ISP resolvers around the world cache your individual A, MX, or CNAME records. That delay is controlled by each record's own TTL value, not the SOA.
Fix: if you're planning a change in advance (a server migration, a mail provider switch), lower the TTL on the specific records you're about to change 24-48 hours ahead of time, not the SOA minimum field. We cover the general propagation timeline in more detail in our DNS propagation guide.
Changing SOA Values in cPanel/WHM
- In cPanel, open Zone Editor under the Domains section.
- Find your domain and click Manage.
- Look for the SOA row - most Zone Editor UIs group it near the top with the NS records, sometimes under an "Advanced" or "Edit" toggle since it's rarely touched.
- Adjust refresh, retry, expire, or minimum as needed. Leave the serial alone - the interface increments it automatically on save.
- Save, then verify with
dig SOA yourdomain.comfrom a terminal to confirm the new values are live on your nameservers.
If you're on WHM managing multiple accounts, the same Zone Editor is available per-domain from the account's cPanel, or in bulk through WHM's DNS functions if you're standardizing SOA defaults across a server.
Prevention Checklist
- Never hand-edit a zone file without bumping the serial - a secondary that sees no serial change assumes nothing changed, even if you rewrote half the zone.
- Keep expire at 2 weeks or more so a weekend primary outage doesn't drop secondary DNS coverage.
- Keep the negative-cache minimum reasonably short (5-15 minutes) so a typo'd record you just fixed doesn't stay "not found" longer than it has to.
- Don't confuse SOA refresh with record propagation - lower individual record TTLs ahead of planned changes instead.
- If you run secondary DNS outside Getwebup, confirm it's actually pulling zone transfers (AXFR) on a schedule that matches your refresh interval, not relying on a one-time import.
Most of the time, the SOA record just sits there doing its job invisibly. The moment it's worth opening is when DNS changes are propagating unevenly between your own nameservers, or a secondary/slave setup seems to be lagging behind - that's almost always a serial or refresh problem, not a mystery caching issue.
Frequently asked questions
Do I need to manually update the SOA serial every time I change a DNS record?
Only if you're editing a raw zone file directly. cPanel's Zone Editor and most managed DNS panels auto-increment the serial on every save, so normal record changes through the UI handle this for you.
What's a safe SOA serial number format?
The common convention is YYYYMMDDNN - today's date followed by a two-digit revision counter, e.g. 2026071801, then 2026071802 for a second change the same day. It just needs to always increase; the exact scheme doesn't matter as long as you never repeat or lower a number.
Why does a DNS record I just fixed still show as not found?
That's usually the SOA's negative-cache (minimum) TTL. Resolvers cache a not-found answer for that duration - often 5 minutes to an hour - so a fresh query from an ISP resolver may still return the old NXDOMAIN until that cache expires.
Does the SOA refresh value affect how fast my site's DNS propagates worldwide?
No. Refresh only controls how often your own secondary/slave nameservers check the primary for changes. Worldwide propagation speed is governed by each individual record's own TTL, not anything in the SOA record.
What happens if my primary nameserver goes down for a long time?
Secondary nameservers keep answering using their last known copy of the zone until the SOA's expire value is reached. After that, they're supposed to stop answering for the domain entirely, which is why a very low expire value is risky if outages are possible.