DNS propagation (TTL)
Propagation is the delay between publishing a DNS record and the rest of the internet seeing it. Nothing is actually pushed anywhere: resolvers cache the previous answer for as long as its time to live allows, and only ask again when that expires. The old value therefore lingers for up to one TTL, which is why a correct record can look broken for hours.
At a glance
- Category
- DNS
- Caused by
- Caching in resolvers, not by any transfer
- Bounded by
- The time to live on the record being replaced
- Typical TTL
- 300 to 86400 seconds, set by you
- Negative caching
- A missing record is cached too, per the zone's SOA
- Specified in
- RFC 1034 and RFC 1035
How it works
When a resolver looks up a record it keeps the answer for the number of seconds the record's time to live specifies, and answers from that copy until it expires. Publishing a change updates your authoritative servers immediately, but every resolver that already has the old answer keeps serving it until its own timer runs out. A missing answer is cached too, under the zone's negative caching value, which is why a record added after a failed lookup can seem to take longer than one that is merely changed.
Why it matters
Most of the pain in publishing mail records is really impatience with caching. A DKIM record checked ten minutes after it was added may legitimately not be visible yet, and a team that reacts by editing the record again restarts the clock and creates two problems. Understanding that the delay is bounded by a number you chose turns waiting into planning: lower the time to live before a change, make the change, then raise it again afterwards.
Example
A domain's TXT records carry a time to live of 3600 seconds. A day before moving to a new sending service, the value is lowered to 300 and that change is allowed to propagate. The new records are then published, and within five minutes resolvers everywhere are asking again and getting the new answers. Once verification passes and mail is flowing, the time to live goes back to 3600 to reduce lookup traffic.
Common mistakes
- 01Editing a record repeatedly because it has not appeared yet, which guarantees that different resolvers hold different versions.
- 02Checking only your own resolver, which may have cached nothing and so shows the new value long before anyone else sees it.
- 03Leaving a long time to live in place during a migration, so a mistake takes a full day to correct everywhere.
Related terms
Frequently asked questions
How long does propagation really take?
At most one time to live for a record that already existed, counted from when each resolver last asked. There is no global process to wait for beyond that.
Why does one checking tool show the record and another does not?
Because each tool queries a different resolver, and those resolvers cached the previous answer at different moments. Querying your authoritative nameservers directly shows the true current value.
Should I use a very low TTL all the time?
No. A low value means far more lookups and a slower first connection for everyone. Lower it deliberately before a planned change and raise it again once the change has settled.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.