DNS propagation in one sentence#
When you publish a DNS record, the rest of the internet doesn't see it instantly — it takes minutes-to-hours for caches around the world to refresh and discover the new value.
Why caching exists#
Every DNS resolver caches responses. Without caching:
- Every email recipient's spam filter would re-query your SPF record on every message
- Your DNS host would get billions of queries per day
- DNS would be massively slow
Instead, resolvers cache for TTL (Time-To-Live) seconds before re-checking.
What TTL is#
TTL is published per-record. Sample:
Type: TXT
Name: yourdomain.com
Value: v=spf1 include:amazonses.com -all
TTL: 3600 (seconds = 1 hour)
This tells caches: "Remember this value for 3600 seconds. After that, refresh from authoritative DNS."
Typical TTLs:
- Short (300s = 5 minutes) — when expecting changes; faster propagation
- Default (3600s = 1 hour) — common balance
- Long (86400s = 24 hours) — for super-stable records
For initial publication, set TTL=300. After verified working, raise to 3600 or 86400 for cache-friendliness.
Propagation in practice#
When you publish a new record, the propagation timeline:
| Time |
What's happened |
| 0 min |
Record published at your DNS host's authoritative server |
| 5-15 min |
First resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8) query authoritative and cache |
| 30-60 min |
Most large resolvers globally see the new value |
| 1-4 hours |
Smaller resolvers + ISP-local caches refresh |
| Up to 24 hours |
Stubborn caches finally expire (worst case) |
| Up to 48 hours |
Truly slow caches (rare, but happens) |
For high-stake records (SPF, DKIM), assume 1-4 hours is typical. 24 hours is the SLA most DNS hosts publish.
Verify in AcelleMail#
Open the sending-domain detail#
In AcelleMail's sidebar, Sending → Sending domains. The list shows every domain you've registered with status chips (Verified / Pending / Failed) and per-auth indicators:

Click into your domain row. The detail page surfaces exactly which DNS records to publish (TXT for SPF, CNAMEs for DKIM, TXT for DMARC) with copy-paste-ready values + current verification state per check:

After publishing, click Verify domain. AcelleMail's dig-check runs against multiple resolvers; if at least one returns the new value, AcelleMail considers it propagated.
If status stays Pending:
- Wait 30-60 minutes; re-click Verify
- After 4 hours, suspect a real DNS issue (record actually not published)
- After 24 hours, definitely investigate (something is wrong)
Diagnose with dig#
From your terminal:
# Check from your default DNS resolver
dig TXT yourdomain.com +short
# Check from Cloudflare's 1.1.1.1
dig TXT yourdomain.com @1.1.1.1 +short
# Check from Google's 8.8.8.8
dig TXT yourdomain.com @8.8.8.8 +short
# Check from your local ISP's resolver (if you can identify it)
dig TXT yourdomain.com @your-isp-dns +short
If all 4 return the new value: fully propagated. AcelleMail's pending state should resolve immediately.
If some return new + some return old: partial propagation — keep waiting.
If all return old (or nothing): the record isn't actually published. Check your DNS host's admin panel.
What controls propagation speed#
| Factor |
Effect |
| Source TTL (what you published) |
Lower = faster discovery (but more queries) |
| OLD TTL (what was cached before your change) |
The previous TTL controls how long old caches survive |
| DNS host's authoritative responsiveness |
Fast hosts (Cloudflare) propagate in minutes |
| Resolver-specific caching policies |
Some resolvers ignore very low TTLs (security against cache-poisoning) |
If your previous record had TTL=86400 (24 hours), THAT determines max wait time for the change — even if your new record has TTL=300, old caches will hold the previous value for up to 24h.
Always lower TTL BEFORE making a change, then change, then optionally re-raise:
Day 0: Lower TTL on existing record to 300 (5 min)
Day 1: Wait 24 hours for that low TTL to fully propagate
Day 2: Publish your change → propagates in ~5 minutes
Day 3: Optionally raise TTL back to 3600
For one-off setup (first-time SPF/DKIM/DMARC), skip the pre-stage; publish directly + accept the wait.
Common propagation issues#
| Symptom |
Cause |
Fix |
| AcelleMail shows Pending for >2 hours |
Slow propagation (normal) |
Wait; use dig to check actual progress |
dig confirms record visible but AcelleMail says Pending |
AcelleMail caching its own check |
Re-click Verify; rare AcelleMail-side cache issue |
dig returns nothing |
Record actually not published |
Re-check DNS host admin panel; common typo errors |
Different dig @resolver returns different values |
Partial propagation |
Keep waiting; eventually consistent |
| Old value persisting >48 hours |
Pre-change TTL was very high (>86400) |
Wait the full previous TTL; force-flush isn't possible globally |
| ISP-local cache stuck |
Your ISP's resolver caching aggressively |
Switch to public DNS (1.1.1.1, 8.8.8.8) temporarily |
What you CAN'T do#
| Tempting |
Why it doesn't work |
| "Just force-refresh my DNS globally" |
Impossible — caches are everywhere, no central control |
| "Clear my browser's DNS cache" |
Helps locally; doesn't affect the rest of the internet |
| "Restart my router" |
Local cache flush; doesn't help recipients' resolvers |
| "Use a different DNS host" |
Doesn't speed up — once published, the cache timeline is the same |
When to consider longer waits#
DNS propagation can occasionally take longer than expected. Consider:
- Region-specific delays — sometimes APAC propagation lags US by 6-12 hours
- Recently-changed authoritative DNS — if you recently switched DNS hosts, propagation takes longer
- Vendor-specific delays — some authoritative DNS hosts have slower-than-typical refresh rates
If after 48 hours something is still Pending, contact your DNS host's support.
Advanced: TTL pre-staging, monitoring propagation programmatically, and DNSSEC + propagation
TTL pre-staging strategy:
For any planned DNS change:
Day -7: Lower TTL on the existing record to 300 (5 minutes)
This change takes 24h+ to propagate to all caches.
Day -6 to -1: Wait. All caches eventually pick up TTL=300.
Day 0: Publish the actual change.
Propagation: ~5 minutes globally (because all caches now hold TTL=300).
Day +1: Optionally re-raise TTL to 3600 for cache-friendliness.
Total prep: 7 days. Worth it for high-stakes changes (sending domain migrations, MX changes).
Programmatic propagation monitoring:
#!/bin/bash
# Check propagation across multiple public resolvers
resolvers=("1.1.1.1" "8.8.8.8" "9.9.9.9" "208.67.222.222")
record="yourdomain.com"
expected="v=spf1 include:amazonses.com -all"
for r in ${resolvers[@]}; do
actual=$(dig TXT $record @$r +short | head -1 | sed 's/"//g')
if [ "$actual" == "$expected" ]; then
echo "✓ $r: matches"
else
echo "✗ $r: still propagating (got: $actual)"
fi
done
Run as cron every 5 minutes during expected propagation window. Alert when all resolvers match.
DNSSEC + propagation:
DNSSEC-signed zones add cryptographic signatures. Propagation is the same speed, BUT:
- If signatures expire mid-propagation, some resolvers may return SERVFAIL
- Re-signing takes additional steps at your DNS host
- Some old caches may briefly return BOGUS responses
For most users, DNSSEC just works. If you operate authoritative DNS or troubleshoot DNSSEC failures, this is a meaningful gotcha.
Geographic propagation differences:
- North America + Europe: fastest (minutes to hours)
- APAC: slightly slower (hours to half-day)
- Africa / South America: sometimes meaningfully slower
For global audiences, allow 24h+ for full propagation before assuming the change is complete.
Resolver-specific behavior:
Some resolvers have unique caching rules:
- Google 8.8.8.8 — respects TTL strictly
- Cloudflare 1.1.1.1 — respects TTL strictly; sometimes faster than authority
- OpenDNS 208.67.222.222 — slightly more conservative caching
- ISP-local resolvers — varies wildly; many ignore low TTLs as DDoS protection
For comprehensive checks, test against all 4 + your local ISP.
When propagation FAILS to complete:
Rare but possible:
- Authoritative DNS host has a bug — contact support
- Glue records misconfigured at registrar — verify NS records
- BGP routing issue — DNS resolver can't reach your authoritative server (very rare)
If after 48 hours something genuinely isn't propagating, this is the territory.
Related articles#