What is DNS propagation?

DNS propagation is the time it takes for a DNS record change to be visible to resolvers worldwide. Each resolver caches records for the duration of the record's TTL (time to live). Until that cache expires, the resolver returns the old answer: which is why a new record can be live at one resolver and stale at another for minutes to days.

How long does DNS propagation take?

Most propagation completes within minutes to a few hours. The upper bound is the record's TTL: commonly 300 seconds (5 minutes) to 86400 seconds (24 hours). Some ISP resolvers ignore short TTLs and cache for longer, which is why a small number of resolvers can lag for a day or more.

Why do different DNS resolvers show different results?

Each resolver caches independently. When you change a DNS record, resolvers that already had the old record cached will keep serving it until their TTL expires, while resolvers that had no cached entry fetch the new record immediately. Geo-aware DNS (GeoDNS) can also legitimately return different answers to resolvers in different regions.

What is a TTL in DNS?

TTL (time to live) is the number of seconds a resolver is allowed to cache a DNS record before re-fetching it from the authoritative server. Lower TTLs mean faster propagation but more queries; higher TTLs mean slower propagation but better performance and lower load.

How does WhereIsDNS check propagation?

WhereIsDNS sends DNS-over-HTTPS (DoH) queries to 14 public resolvers in parallel: Cloudflare, Google, Quad9, OpenDNS, AdGuard, NextDNS, Yandex, AliDNS, DNSPod, CleanBrowsing, Mullvad, ControlD, Hurricane Electric, and DNS4EU. Results stream in as each resolver responds. The consensus row tells you how many resolvers agree.

Yes, completely free with no signup. The site is supported by unobtrusive Google AdSense ads.

SPF Check

Check the SPF record for any domain across 12 global DNS resolvers. Free real-time DNS propagation checker.

What is SPF?

SPF (Sender Policy Framework) is the oldest of the three email-authentication standards. It lets a domain publish, in DNS, the list of IPs and providers authorized to send mail on its behalf. Receiving servers check the connecting IP against the SPF record and accept, soft-fail, or reject accordingly.

SPF lives at the apex of your domain as a TXT record. Type your bare domain above: we'll query its TXT records and you'll spot the one starting with v=spf1.

Anatomy of an SPF record

A typical SPF record looks like: v=spf1 include:_spf.google.com include:mailgun.org ~all. Reading left to right:

v=spf1: version marker.
Mechanisms: ip4:, ip6:, a, mx, include:<domain>, exists:, etc. Each authorizes one source.
Qualifier prefixes: + (pass, default), - (fail/reject), ~ (softfail/spam-flag), ? (neutral).
The "all" mechanism at the end: typically ~all (softfail anything else) or -all (reject anything else). +all is dangerous: it authorizes the whole internet.

Common errors and pitfalls

10 DNS-lookup limit exceeded: each include: + every nested lookup counts toward a hard cap of 10. Stacking Google + Mailchimp + HubSpot + Salesforce blows it, and SPF stops working entirely (PermError).
Two SPF records on the same name: RFC-illegal. Some receivers return PermError; merge into one.
SPF ending in +all: neutralizes the whole point. Almost always a typo or test record left behind.
SPF survives forwarding poorly: when mail is forwarded, the forwarder's IP isn't in your SPF, so SPF fails. That's why DMARC requires either SPF or DKIM to pass and align.

FAQ

How do I reduce my SPF lookup count?

Audit your include: chain: many providers publish flattened lists you can substitute (e.g., directly include their IPs as ip4: mechanisms). Alternatively, services like Valimail offer SPF flattening as a managed product.

Is `~all` or `-all` better?

~all is the cautious choice: failing mail is marked as suspicious but not outright rejected. -all tells receivers to reject. If you're confident your SPF is complete, use -all.

Background reading

See the SPF glossary entry, plus DKIM and DMARC for the full picture. The DNS Records Explained guide connects them.

All record-type lookups

WhereIsDNS has dedicated pages for each common DNS record type. Each one defaults the tool to that record type and includes background on what the record means and what to look for.

A Record Lookup: IPv4 addresses for a hostname
AAAA Record Lookup: IPv6 addresses for a hostname
CNAME Lookup: Aliases pointing one hostname to another
MX Record Lookup: Mail servers for a domain (with priorities)
NS Record Lookup: Authoritative nameservers for a domain
TXT Record Lookup: SPF, DKIM, DMARC, and other text records
SOA Record Lookup: Authority metadata for a DNS zone
CAA Record Lookup: Which CAs may issue certs for the domain
SRV Record Lookup: Service location records (SIP, XMPP, _autodiscover, etc.)
DNSKEY Record Lookup: DNSSEC public keys for a zone
DS Record Lookup: DNSSEC delegation signer at the parent zone
HTTPS Record Lookup: Modern HTTPS service binding (ALPN, ECH, etc.)
SVCB Record Lookup: Generic service binding (RFC 9460)
PTR (Reverse DNS) Lookup: Reverse DNS: IP back to a hostname
DMARC Check: DMARC policy at _dmarc.<domain>
DKIM Check: DKIM public key at <selector>._domainkey.<domain>
Home (defaults to A records)