// how to fix
DNS changes not visible yet: propagation and TTL
You added or fixed a record but tests still show the old value. DNS answers are cached for a while; here is how long to wait and how to check the real value.
What it means
When a server needs your SPF, DKIM or MX record, it does not ask your DNS provider every time. It asks once and keeps the answer in a cache for a while. That duration is the TTL (time to live), set on each record in seconds.
300= 5 minutes3600= 1 hour86400= 24 hours
Until the cache expires, some servers still see the old value. This delay is called "propagation".
Why it matters
After a fix, your test may still fail for a while, and you may think the fix did not work. Worse, you may change things again and create a real mistake. Knowing how caching works helps you wait the right amount of time.
How long to wait
- A new record (that never existed): usually a few minutes. But if someone looked it up just before you created it, the "does not exist" answer is also cached, sometimes for up to an hour or more.
- A changed record: up to the old TTL. If the old TTL was 24 hours, some servers may see the old value for a day.
- New nameservers (moving your whole DNS to another host): up to 24 to 48 hours.
- Some DNS providers also take time to publish your change after you click "Save".
How to check the real value
- Ask your DNS host directly. Find your nameservers (for example
ns1.your-dns-host.com), then ask them, which skips all caches:dig TXT yourdomain.com @ns1.your-dns-host.com dig TXT _dmarc.yourdomain.com @ns1.your-dns-host.com
- If that answer is wrong, the problem is not propagation: the record was not saved, is at the wrong name, or you edited DNS at a provider that is not in use. Check which nameservers your domain really uses.
- If that answer is right, just wait. Public tools like the Google Admin Toolbox Dig show what large resolvers see.
- Use the Domain scanner at
/domain-scannerto see your SPF, DKIM, DMARC and MX records as a receiving server would.
Plan big changes ahead
- A day before changing an important record (MX, SPF), lower its TTL to
300. Wait for the old TTL to pass, make the change, then raise the TTL again (3600is a good normal value). - When changing email provider, keep the old mailboxes working for two days, because some emails may still arrive there.
- Do not change the same record many times in a row. Make one careful change and wait.
Check that it is fixed
Once your DNS host gives the right answer and the TTL has passed, run the Domain scanner again. Then send a new test email from the Delivmail home page: the report reads the records fresh at the time of the test and should show them passing.
Check that it is fixed
DNS changes can take from a few minutes to a few hours. Then send a new test email or scan your domain again.
Related guides
- No SPF record on your domainYour domain does not say which servers may send email for it. Add one TXT record and receivers can tell your real emails from fakes.
- SPF error: too many DNS lookups (permerror)SPF allows at most 10 DNS lookups. Above that, the whole record breaks and receivers treat it as invalid. Here is how to slim it down.
- Several SPF records on one domainA domain must have only one SPF record. With two or more, SPF breaks for every email. Merge them into a single line.
- SPF fails: the sending server is not authorizedYour domain has an SPF record, but the server that sent your email is not in it. Find which service sent the email and add it.
- No DKIM signature on your emailsDKIM adds a digital signature that proves an email really comes from your domain. Turn it on in your email provider and publish its key in DNS.