Skip to main content

What is DNS propagation?

When you add or change a DNS record, the change doesn’t take effect everywhere instantly. DNS propagation is the process of your updated records spreading across DNS servers worldwide. Until propagation completes, some servers may still have the old records (or no records at all). This is why domain verification in SendKit can sometimes take minutes to hours after you add the required DNS records.

How DNS works

DNS is a distributed system. There’s no single server that stores all DNS records. Instead, records are cached across thousands of servers worldwide in a hierarchy:
1

Your DNS provider (authoritative server)

Publishes your DNS records.
2

Root DNS servers

Delegate queries to the correct TLD servers (.com, .dev, .io, etc.).
3

TLD servers

Delegate queries to your provider’s authoritative nameservers.
4

Recursive resolvers

ISPs, Google (8.8.8.8), and Cloudflare (1.1.1.1) cache your records and serve them to end users.
5

End users and services

Applications like SendKit query recursive resolvers to look up your DNS records.
When you update a record at your DNS provider, recursive resolvers around the world still have the old record cached. They’ll keep serving the old record until the cache expires.

TTL (Time to Live)

TTL controls how long a DNS record is cached before resolvers check for updates. It’s measured in seconds.
TTLDurationPropagation speed
3005 minutesFast
36001 hourStandard
8640024 hoursSlow
When you set a TTL of 3600 (1 hour), resolvers will cache your record for up to 1 hour before checking for changes. This means changes can take up to 1 hour to propagate.
SendKit recommends a TTL of 3600 (1 hour) for all DNS records. This is a good balance between propagation speed and DNS performance.

Why propagation takes time

Several factors affect how long propagation takes:

1. Previous TTL

If your domain previously had a different record with a high TTL (e.g., 86400 — 24 hours), resolvers that cached the old record will wait for that TTL to expire before fetching the new one. The propagation time depends on the old TTL, not the new one.

2. Resolver caching behavior

Not all resolvers respect TTL exactly. Some ISP resolvers cache records longer than the specified TTL to reduce load. There’s nothing you can do about this — it resolves itself over time.

3. Negative caching

If a resolver looked up your record before you added it and got a “no record found” response, it caches that negative result too. This negative cache also has a TTL (defined by the SOA record), typically 1–24 hours. This is why verification can sometimes take longer if SendKit checks your domain before you’ve added the records.

How to check propagation

You can verify if your DNS records have propagated by querying different DNS resolvers:

Using dig (macOS/Linux)

# Check against Google's resolver
dig @8.8.8.8 sendkit._domainkey.yourdomain.com TXT

# Check against Cloudflare's resolver
dig @1.1.1.1 sendkit._domainkey.yourdomain.com TXT

# Check against your authoritative nameserver
dig @ns1.yourprovider.com sendkit._domainkey.yourdomain.com TXT

Using nslookup (Windows)

nslookup -type=TXT sendkit._domainkey.yourdomain.com 8.8.8.8
If the record appears when querying your authoritative nameserver but not Google’s resolver, propagation is still in progress.

Tips for faster propagation

  1. Lower the TTL before making changes — if you know you’ll be updating DNS records, lower the TTL to 300 (5 minutes) a day before. This ensures the old high-TTL cache expires before you make the change.
  2. Add all records at once — add all SendKit DNS records (DKIM, SPF, MX, and optionally DMARC) at the same time to avoid multiple propagation waits.
  3. Double-check your records — typos cause “record not found” errors that look like propagation issues. Copy values directly from the SendKit domain detail page.
  4. Be patient — most records propagate within minutes to a few hours. In rare cases, it can take up to 48 hours.

Propagation and SendKit verification

SendKit automatically checks pending domains on a schedule:
Time since domain addedCheck frequency
First 2 hoursEvery 10 minutes
2–12 hoursEvery 30 minutes
12–72 hoursEvery 60 minutes
You can also click Refresh on the domain detail page to trigger a manual check at any time.
If your records are correct but verification fails, wait 30 minutes and try again. The most common cause is that SendKit’s resolver hasn’t received the updated records yet.

FAQ

Most likely, DNS propagation hasn’t completed yet. Verify the records using dig against your authoritative nameserver. If they appear there but not on Google (8.8.8.8), wait for propagation. If they don’t appear anywhere, double-check the record name and value at your DNS provider.
You can’t force global propagation, but you can minimize the wait by lowering the TTL before making changes. Once records are published, propagation depends on caches expiring across the internet.
Changing nameservers triggers its own propagation (for the NS records). Your DNS records then need to propagate from the new provider. This can cause a temporary period where records are unavailable.