Check TTLs
Reads the TTL from an authoritative-fresh answer via Cloudflare's resolver. The value shown is the record's configured TTL, not what is left in any particular cache.
How it works
Query
Each record type is fetched over DNS-over-HTTPS. The TTL in the answer is the configured value on a fresh lookup, or what remains in Cloudflare's cache on a repeat.
Classify
Under five minutes is fast, up to an hour normal, up to four hours slow, longer than that very slow for anything you might need to change in a hurry.
Negative cache
The SOA minimum tells you how long a resolver remembers that a record did not exist — the reason a DKIM record 'does not work' for an hour after you add it.
Plan
The notes name the records to lower before a change and when to raise them back.
What a TTL does
Every DNS record carries a time-to-live in seconds. A resolver that looks it up keeps the answer for that long and does not ask again. Change the record and every resolver that has it cached carries on serving the old value until its copy expires — which is why a DNS change "propagates" at all. It is not the change spreading; it is caches expiring, at different times, everywhere. An MX with a 24-hour TTL means a day during which some of your mail goes to the old provider and some to the new.
The migration routine
Lower the TTL on every record you are about to change to 300 — five minutes — at least one full old-TTL period before the change, so that by the time you edit the record every cache has the short value. Make the change. Wait, check with the propagation checker, fix whatever you got wrong while a mistake still only lasts five minutes. A day later, raise TTLs back to an hour or more so resolvers stop querying your nameservers constantly. Skipping the first step is the most common way to turn a ten-minute cutover into a day of lost mail.
Negative caching
The SOA record's last field is the negative TTL: how long a resolver remembers that a name did not exist. This is the reason a freshly published DKIM or DMARC record "still fails" when you test it — you tested before it existed, the resolver cached the miss, and it will keep reporting the miss until that timer runs out. Create records before anything queries them, and test through a resolver that has not seen the name yet.
What the values should be
An hour is a sensible default for most records. Five minutes during migrations and for anything you change often. NS records are cached at the parent too, usually for 48 hours on .com regardless of what you set, so a nameserver move needs a week of overlap where both old and new providers serve identical zones. There is no deliverability signal in TTL values; the only cost of a low TTL is more queries to your nameservers, which Cloudflare absorbs without noticing.
Frequently asked questions
How long does a DNS change take to propagate?
As long as the record's old TTL, plus a little. A one-hour TTL means most of the internet sees the change within an hour; some ISP resolvers take longer.
What TTL should I set before a migration?
300 seconds, set at least one old-TTL period before the change so every cache has picked up the short value first.
Why does my new DKIM record fail when I test it?
Negative caching. A resolver that looked the name up before you created it remembers the miss for the SOA minimum TTL. Test from a different resolver or wait it out.
Does a low TTL hurt anything?
Only nameserver load, which is irrelevant on Cloudflare or Route 53. Raise it back after the change anyway so the record is not re-fetched every five minutes forever.
Why does the TTL shown change when I re-run?
Cloudflare's resolver returns the remaining time on a cached answer. The first lookup shows the configured value; repeats count down.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace — Silver Partner
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.