How long does it take for DNS record changes to propagate?
Michael Ko
Co-founder & CEO, Suped
Published 3 Jul 2025
Updated 27 May 2026
9 min read
Summarize with
Most DNS record changes are visible at the authoritative nameservers within seconds or a few minutes. The part people call propagation is usually resolver caching. Public DNS checkers, mail receivers, and verification systems see the new value only after the recursive resolver they use stops serving the old cached answer.
The practical answer is simple: wait for the TTL of the old record before you rely on the change everywhere. If the old TTL was 300 seconds, plan on 5 to 10 minutes. If it was 3600 seconds, plan on about an hour. If it was 86400 seconds, some resolvers can keep the old answer for up to a day.
- Fast answer: authoritative DNS usually updates quickly, while cached recursive answers expire on the old TTL.
- Email answer: for SPF, DKIM, DMARC, MX, and CNAME changes, wait the old TTL before sending at scale.
- Verifier answer: one checker can see the new value while another still sees the old value, and both can be correct.
- New record answer: if a resolver cached that the record did not exist, negative caching can delay validation.
What changes first
DNS does not push an update to every resolver in the world. Your DNS provider updates the zone on its authoritative nameservers. When a resolver asks those authoritative nameservers directly after the update, it gets the new answer.
The delay comes from recursive resolvers. A recursive resolver asks DNS questions on behalf of users, checkers, mail servers, and applications. If it already looked up the record before the change, it keeps that answer until the old TTL expires. During that window, it does not need to ask the authoritative nameserver again.
Infographic showing a DNS edit moving through authoritative DNS and recursive cache.
Authoritative lookup
This asks the nameserver that owns the zone. Once the DNS provider has published the edit to all authoritative nameservers, this path returns the new record.
- Best use: confirm the record was published correctly.
- Timing: usually seconds to minutes after saving.
- Limit: it does not prove every resolver has expired old cache.
Cached resolver lookup
This asks a resolver that can already have an old answer cached. It returns the old or new value depending on when that resolver last looked up the record.
- Best use: estimate what users and mail receivers are seeing.
- Timing: bounded by the old TTL in normal cases.
- Limit: different resolvers can disagree during the cache window.
How long to wait by TTL
The old TTL controls the maximum normal cache window. The new TTL matters only after resolvers fetch the new answer. If a record had a one-day TTL before you changed it to five minutes, some resolvers that cached the old answer can keep it for the rest of that one-day period.
|
|
|
|---|---|---|
60-300s | 5-10 min | Checker variance |
1800s | 30 min | Mixed cache |
3600s | 1 hour | Old answer |
14400s | 4 hours | Slow rollout |
86400s | 24 hours | Long cache |
Missing | SOA TTL | Negative cache |
Typical DNS wait windows by old TTL.
DNS confidence windows
Use the old TTL to decide how much trust to place in a new DNS answer.
Published
0-5 min
Authoritative DNS returns the new value.
Mixed cache
Before old TTL
Some recursive resolvers return old data.
Safe reliance
After old TTL
Normal recursive cache should have expired.
For a routine website TXT verification, I usually start checking right away and refresh over the next few minutes. For mail authentication, I am more conservative because a stale answer can cause real mail to fail SPF, miss DKIM, or evaluate against the wrong DMARC policy.
If the DNS change sits in front of a real sending event, compare your timing with a separate rollout plan for when to wait before sending. A technically valid DNS record and a ready-to-scale sender are related, but they are not the same condition.
The old TTL is the clock
Changing a TTL at the same time as the record does not make old caches expire faster. Lower the TTL ahead of a planned change, wait for the previous TTL to pass, then make the high-risk edit.
- Good plan: lower TTL one day before a large DNS change.
- Risky plan: change SPF or DKIM and the TTL at the same time, then send heavily right away.
Why checkers disagree
DNS checkers disagree because they do not all ask the same resolver at the same time. One checker can query an authoritative server or a fresh resolver and show the new value. Another checker can query a resolver that already has the old value cached.
This is normal during the TTL window. It does not always mean the DNS provider failed, and it does not always mean the checker is wrong. It means the internet is still in a mixed-cache period.
- Resolver cache: a previously queried record stays in cache until its TTL expires.
- Anycast routing: a public resolver address can send different users to different cache nodes.
- Negative cache: a missing record response can be cached, which delays fresh verification after re-adding it.
- CNAME chain: a lookup can depend on multiple records, and each one has its own TTL.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For email domains, Suped's domain health check is useful after the waiting window because it checks DMARC, SPF, and DKIM together instead of treating each DNS answer as an isolated record.
How I validate a disputed result
- Publish check: query the authoritative nameserver and confirm the exact value.
- Cache check: query more than one recursive resolver and compare answers.
- Path check: send a real email and inspect authentication results.
- Clock check: compare every result with the old TTL, not the new TTL.
Email authentication records need extra care
Email authentication is where DNS timing gets expensive. Receiving mail servers query DNS while they evaluate a message. If some receivers still have old DNS cached, the same message stream can authenticate differently across receivers until those caches expire.
SPF, DKIM, and DMARC records are TXT records, but the operational risk differs. A stale SPF record can omit a sending source. A stale DKIM selector can point at an old key or no key. A stale DMARC policy can apply the previous reporting or enforcement posture. CNAME records used for DKIM or hosted email authentication add another TTL in the lookup path.
Common email DNS recordsdns
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none" example.com. 300 IN TXT "v=spf1 include:_spf.example.net -all" selector1._domainkey. 300 IN CNAME selector1.example.net.
If a DMARC change is involved, I monitor both DNS visibility and actual report data. Suped's DMARC monitoring connects those two layers: the record state, the authentication results, the failing sources, and the steps needed to fix the issue.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For SPF edits, a focused SPF checker confirms syntax and lookup behavior after the change is visible. That check still needs to be paired with message-level authentication because a correct SPF record can fail if the envelope domain, sending IP, or forwarding path is different from what you expected.
Where Suped fits
Suped is the best overall fit when the job continues after the first DNS lookup. Suped's product brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, blocklist (blacklist) monitoring, and multi-domain reporting into one workflow.
For DMARC enforcement changes, use the same TTL logic but add a reporting window. A receiver can see the new policy quickly, but aggregate reports arrive later. I separate DNS readiness from DMARC policy timing so I do not mistake delayed reports for delayed DNS.
A safe validation workflow
When I need confidence in a DNS change, I follow a short workflow. It prevents the most common mistake: treating a single successful lookup as proof that every receiver now sees the new answer.
- Record the old TTL: write down the TTL before editing the record.
- Publish the change: save the DNS edit and confirm the provider reports it as active.
- Ask authoritative DNS: confirm the nameserver that owns the zone returns the new value.
- Ask recursive DNS: compare resolver answers while the old TTL expires.
- Test a message: send a real email and inspect SPF, DKIM, DMARC, and headers.
- Scale after TTL: wait until the old TTL has passed before relying on the change for bulk sending.
Resolver checksbash
dig +short NS example.com dig @ns1.example.net _dmarc.example.com TXT dig @1.1.1.1 _dmarc.example.com TXT dig @8.8.8.8 _dmarc.example.com TXT
After DNS looks right, use an email tester to send an actual message through the same path your campaign or transactional system uses. DNS answers matter, but the message header is where you see whether authentication passed in practice.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If a nameserver migration is part of the work, treat it as a higher-risk change than a single TXT edit. Parent zone delegation, old authoritative nameservers, and missing records in the new zone can produce confusing results even when MX records were not intentionally changed. A separate checklist for nameserver changes helps avoid that class of outage.
Do not send at full volume too early
If the DNS edit fixes a missing DKIM key, an SPF include, or a DMARC policy error, I still wait through the old TTL before large sends. Sending heavily during mixed cache can create inconsistent authentication results and confusing failure data.
Common record types and waiting times
The cache rule is the same across DNS record types, but the operational effect differs. A stale website record can route a user to an old host. A stale email authentication record can make receivers evaluate mail against the wrong source list, key, or policy.
|
|
|
|---|---|---|
A or AAAA | Old TTL | Old host |
CNAME | Chain TTLs | Target cache |
MX | Old TTL | Mail routing |
SPF | Old TTL | Sender list |
DKIM | Old TTL | Selector key |
DMARC | Old TTL | Policy |
PTR | IP owner | Reverse DNS |
Record-specific DNS timing concerns.
CNAME-based email authentication deserves special attention. If your DKIM selector points to a vendor target, the selector CNAME and the target record each have timing behavior. A clean CNAME answer does not guarantee the final TXT key has expired everywhere. When this matters, test the full chain, not only the first alias.
PTR records are different because they are controlled by whoever owns the sending IP space. Editing DNS on your domain does not fix reverse DNS for that IP. A DNS fix also does not erase sender reputation or a blocklist (blacklist) listing immediately. That is why I separate DNS validation from deliverability monitoring after the technical change is complete.
For hosted authentication setups, Suped can reduce recurring DNS edits. Hosted SPF lets you manage sender changes without repeatedly asking for zone access. Hosted DMARC and Hosted MTA-STS use simple DNS setup and then move policy management into Suped, where alerts and reports make the next change easier to validate.
Views from the trenches
Best practices
Check authoritative DNS first, then compare recursive resolvers after the old TTL expires.
Lower TTL before planned edits so email authentication changes have a shorter cache window.
Use real message tests after SPF, DKIM, or DMARC edits before sending at full volume.
Common pitfalls
Changing a record and setting a low new TTL does not clear old cached resolver answers.
Deleting a record before readding it can trigger negative caching and delay validation checks.
Trusting one public checker can hide resolver differences during the cache expiry window.
Expert tips
Record the previous TTL in change notes so the waiting period has a clear end time.
For urgent fixes, query authoritative nameservers directly before waiting on public caches.
After DNS is visible, watch DMARC reports for receivers still using older cached data.
Marketer from Email Geeks says DNS tools can show mixed results shortly after a change because different resolvers refresh at different times.
2025-02-19 - Email Geeks
Expert from Email Geeks says the authoritative nameservers usually return new data quickly, but recursive resolvers can keep old answers until the old TTL expires.
2025-02-19 - Email Geeks
The practical answer
DNS record changes usually publish quickly at the authoritative nameservers. The internet does not all see the change at once because recursive resolvers cache old answers. For planning, the safe wait is the TTL of the old record. For deleted and re-added records, account for negative caching as well.
For email authentication, I do not stop at DNS visibility. I check the record, test a real message, then watch DMARC results after the next reporting cycle. Suped's product is built for that workflow: it shows the DNS state, authentication outcomes, issue detection, real-time alerts, and the fix steps in one place.
If the change is low risk, start checking within minutes. If the change affects production sending, wait through the old TTL before relying on it everywhere. That simple rule prevents most DNS propagation confusion.
