# DNS Propagation Checker for Email Records

> Compare exact SPF, DKIM, DMARC, MX, and custom DNS observations from Google Public DNS and Cloudflare 1.1.1.1. Review answer sets, DNS status, remaining TTL, DNSSEC validation flags, negative-response evidence, and an optional expected value without treating two resolver responses as proof of worldwide propagation.

- **Canonical page:** [https://emailbump.com/tools/dns-propagation-checker](https://emailbump.com/tools/dns-propagation-checker)
- **Interactive tool:** [Open the DNS propagation checker](https://emailbump.com/tools/dns-propagation-checker)
- **Category:** Email infrastructure and DNS operations
- **Updated:** July 2026
- **Providers observed:** Google Public DNS and Cloudflare 1.1.1.1
- **Query transport:** DNS over HTTPS using the providers' documented JSON interfaces
- **Privacy:** The browser sends the queried DNS name directly to each provider; Email Bump does not proxy the request

## What this tool is designed to answer

The checker answers a narrow and operationally useful question:

> What did these named public recursive DNS providers return to this browser for this exact owner name and record type at this recorded time?

It can help an operator determine whether:

- Both selected recursive providers returned the same normalized record set
- The providers returned different old and new values
- A specific expected value is present
- A record expected to be absent is absent
- The DNS response was successful but contained no requested-type answer
- A provider returned NXDOMAIN, SERVFAIL, REFUSED, or another DNS status
- A browser or HTTP failure prevented a DNS conclusion
- A validating resolver set the DNSSEC Authenticated Data flag
- Answer TTLs differ between observed caches
- Negative responses include authority or SOA evidence
- The surrounding zone has observable NS and SOA context

The checker does not answer:

- Whether DNS is “100% propagated worldwide”
- What every ISP, enterprise resolver, device, geography, or mailbox provider sees
- Whether every authoritative nameserver currently publishes identical data
- Which physical data center handled an anycast request
- Whether an email message will authenticate or reach an inbox
- Whether a mail server accepts SMTP connections
- Whether a DKIM key is actively used to sign mail
- Whether SPF stays within its DNS-lookup budget
- Whether DMARC identifiers align in an actual message

Those questions require additional evidence.

## Why the page avoids a global propagation map

Many DNS propagation pages draw a world map with location pins and report a percentage such as “85% propagated.”

That presentation can imply more certainty than the underlying checks provide.

Public recursive resolvers commonly use anycast. One service address can be announced from many network locations, and routing selects a reachable service edge. A browser request to a JSON DNS-over-HTTPS endpoint does not automatically prove:

- The country in which the recursive lookup occurred
- The precise cache node that answered
- That all users of that provider share the same cache state
- That another network in the displayed city would see the same response
- That the response came directly from an authoritative nameserver

This tool therefore names the provider, endpoint, status, exact answer, TTL, validation flag, latency, and timestamp. It says **observed agreement** when the answer sets match. It never translates two observations into “global propagation complete.”

## DNS publication and observation model

DNS changes involve several distinct roles.

### Zone owner or DNS operator

The operator updates data in a DNS provider or authoritative server configuration. A control panel can accept a change before that change is published to every authoritative server operated by the provider.

### Parent delegation

The parent zone delegates the child zone to nameservers. Changes to nameserver delegation and DS records have their own cache behavior and operational risks.

### Authoritative nameserver

An authoritative server provides zone data for names it serves. It is the publication source selected through the delegation chain.

### Recursive resolver

A recursive resolver finds the answer on behalf of clients. It can retain positive or negative results in cache according to DNS rules and its policies.

### Stub resolver and application

An operating system, browser, local network, VPN, security product, container, or application can add another resolution or caching layer.

The interactive page observes public recursive providers through their HTTPS APIs. It does not bypass those recursive caches and does not directly query every authoritative server.

## Supported record presets

### SPF

The SPF preset queries:

```text
example.com TXT
```

SPF is normally published as a TXT record at the domain whose authorization is evaluated. The propagation checker reports every requested-type TXT answer. The dedicated [SPF lookup budget checker](https://emailbump.com/tools/spf-record-checker.md) should be used to identify the applicable SPF record, follow include and redirect chains, and count DNS-triggering terms.

Agreement on TXT data does not prove that SPF passes for a particular message. SPF evaluation also depends on the connecting IP address, SMTP identity, DNS dependencies, and evaluator behavior.

### DMARC

The DMARC preset queries:

```text
_dmarc.example.com TXT
```

An expected-value check can look for a stable token such as:

```text
v=DMARC1
```

or compare an entire normalized record.

The checker does not validate every DMARC tag or policy relationship. Use the [DMARC record builder](https://emailbump.com/tools/dmarc-record-builder.md) for policy construction and rollout considerations. Use the [email header analyzer](https://emailbump.com/tools/email-header-analyzer.md) to inspect DMARC results from a received message.

### DKIM

The DKIM preset builds:

```text
selector._domainkey.example.com TXT
```

The operator must provide the exact selector used by the signing configuration.

Some email providers publish a CNAME at the selector owner name instead of a TXT key. If the TXT query does not show the expected key, use custom CNAME mode or the [DKIM record checker](https://emailbump.com/tools/dkim-record-checker.md), which follows provider aliases and reviews key material.

DNS agreement does not prove that outgoing mail uses the key. A received message and its DKIM-Signature header are needed to connect publication to active signing.

### MX

The MX preset queries:

```text
example.com MX
```

MX data includes both preference and exchange hostname. The normalization preserves the preference number and removes only a terminal DNS dot from the target. A lower preference value is attempted before a higher value; preference is not a latency measurement or traffic weight.

Use the [MX routing inspector](https://emailbump.com/tools/mx-record-lookup.md) to expand exchanger addresses and distinguish explicit MX, implicit fallback, and Null MX states.

### Custom records

Custom mode supports:

- A
- AAAA
- CNAME
- MX
- TXT
- NS
- CAA
- SRV
- SOA

The operator controls the exact owner name and record type.

## Exact provider queries

The browser sends the same name and record type to:

- Google Public DNS at `https://dns.google/resolve`
- Cloudflare at `https://cloudflare-dns.com/dns-query`

The request uses an `Accept: application/dns-json` header and asks the provider to perform DNSSEC validation rather than disabling checking.

For Google Public DNS, the request also specifies an empty EDNS Client Subnet scope:

```text
edns_client_subnet=0.0.0.0/0
```

This avoids intentionally adding a client subnet to the Google JSON query. It does not make the network request anonymous. The DNS owner name, IP-level connection metadata, browser and network characteristics, and provider policy still matter.

The browser uses an HTTP no-store request mode. This avoids treating the browser's HTTP cache as the source of a repeat result. It does **not** flush or bypass the DNS provider's recursive cache.

## How answer sets are normalized

The comparison should not report a false difference for harmless presentation details.

The tool performs type-aware normalization:

- Owner names are compared through requested-type answer selection
- Answer sets are sorted before fingerprinting
- Duplicate normalized values are collapsed
- DNS target names are lowercased
- A terminal dot on a DNS target is removed
- MX preference is retained
- SRV priority, weight, and port are retained
- TXT character-string chunks are joined
- TXT wrapping quotes are removed
- Repeated whitespace becomes one space
- Case is ignored for expected-value comparison

The raw provider record data is still included in the resolver ledger and JSON export.

TXT chunk joining matters because a long TXT record can be encoded as several quoted character strings in one resource record. Those chunks are one logical TXT value, not several separate policies.

## Expected-state modes

### No expectation

The checker compares providers without claiming that either answer is correct or current.

Use this when investigating an unknown state.

### Value present

The operator supplies a value and chooses:

- **Contains:** a normalized record must contain the normalized expected string
- **Exact record:** one normalized record must exactly equal the normalized expected string

Contains matching is useful for stable tokens such as `v=DMARC1` or a known DKIM public-key fragment. Exact matching is more appropriate when the complete intended record is known.

The match applies to one record. It does not concatenate independent records into one artificial value.

### Record absent

The expected state matches when the provider returns NXDOMAIN or returns no requested-type answer.

Those are different DNS states:

- NXDOMAIN says the queried name does not exist
- NOERROR with no requested-type answer says the name can exist but the requested record type is absent

The interface displays the distinction even though both can satisfy an explicit absence expectation.

## DNS statuses and transport failures

The tool preserves standard JSON response status values:

- 0: NOERROR
- 1: FORMERR
- 2: SERVFAIL
- 3: NXDOMAIN
- 4: NOTIMP
- 5: REFUSED

A successful HTTP request can still contain a DNS error status.

A failed HTTP request, CORS restriction, offline browser, endpoint outage, extension block, or other fetch failure has no DNS status. The interface labels that as a browser or HTTP error. It does not convert the failure into NXDOMAIN, “not propagated,” or an empty record.

If one provider fails and one succeeds, the result is incomplete. If both fail, the report makes no DNS conclusion.

## TTL interpretation

TTL means time to live. It tells a caching resolver how long DNS data may be retained.

The TTL in a recursive response is often the amount of cache lifetime remaining at the responding resolver. It can be lower than the authoritative zone's configured TTL.

Consider a record with an original TTL of 3,600 seconds:

1. Resolver A caches the old value one second before the zone change.
2. Resolver B has no cached copy and asks after the change.
3. Resolver A can continue serving its old cached value for nearly an hour.
4. Resolver B can return the new value immediately.

Both behaviors can be consistent with the TTL.

This is why the checker shows the TTL beside each exact answer instead of publishing a generic propagation countdown.

The lowest observed TTL metric is not the time until worldwide consistency. It is only the lowest remaining TTL among answer records in this run.

## Negative caching

Absence can be cached.

RFC 2308 specifies negative caching for DNS. A resolver can retain:

- NXDOMAIN: the queried name does not exist
- NODATA: the name exists but no record of the requested type is available

SOA data in a negative response helps determine the negative cache lifetime. Creating a previously missing record does not force every resolver to forget a still-valid negative cache entry.

This is especially important for:

- A new DMARC owner name
- A new DKIM selector
- A new verification token
- A corrected typo in a DNS owner name
- A newly created subdomain

The report preserves authority records returned by the provider interfaces. It does not claim to calculate the exact remaining negative lifetime for every resolver, because provider responses and policies can differ.

## DNSSEC evidence

The JSON APIs can return the DNS Authenticated Data flag, abbreviated AD.

When AD is set, the validating recursive resolver indicates that it authenticated the data according to DNSSEC validation.

AD does not mean:

- The browser independently validated the DNSSEC chain
- Every resolver will validate the same way
- Every record in an unrelated query is signed
- The DNS configuration is operationally complete
- The absence of AD identifies one specific fault

The tool reports **DNSSEC AD: yes** or **DNSSEC AD: no** as resolver evidence. It does not convert the flag into a complete DNSSEC health score.

## Delegation context

In addition to the primary comparison, the page asks Google Public DNS for NS context at a derived parent-like zone and for SOA context around the query name.

The output is labeled:

> Zone context, observed through a recursive resolver.

It is not labeled authoritative truth.

A complete authoritative consistency investigation would need to:

1. Follow the delegation from the DNS root
2. Identify the correct zone cut
3. Query every delegated authoritative nameserver directly
4. Compare serial numbers, statuses, flags, and answer sets
5. Review timeouts, lame delegation, DNSSEC, and network reachability

The browser JSON interfaces used by this tool do not perform that direct-authoritative workflow.

## A safer change runbook

### 1. Inventory the exact record

Record:

- Owner name
- Type
- Current value or values
- Current TTL
- Expected new value
- DNS provider
- Authoritative nameservers
- Dependent mail service
- Rollback value

Do not begin with only a screenshot of a provider form.

### 2. Lower TTL before the maintenance window

When appropriate, lower the TTL before the planned change. Wait at least the previous, longer TTL so older caches can age out before relying on the lower number.

Lowering TTL at the same moment as the main change does not shorten the lifetime of copies already cached under the prior TTL.

### 3. Preserve overlap

Where the protocol and provider allow it, keep both old and new paths valid during the cache window.

Examples include:

- Continue serving an old DKIM private key while old public-key references can be used
- Keep old and new MX destinations able to accept intended mail during a migration
- Maintain verification targets until dependent services confirm the new state

Avoid creating multiple SPF records. SPF overlap must be designed inside one valid policy rather than by publishing competing policies.

### 4. Publish and verify at the source

Confirm that the DNS provider accepted and published the intended value. Record the timestamp.

### 5. Compare recursive evidence

Use this checker with an expected value. Save the JSON report when the providers agree and when they differ.

### 6. Validate application behavior

For email authentication, send a controlled message and inspect:

- DKIM-Signature
- Authentication-Results
- SPF result and evaluated identity
- DKIM result and signing domain
- DMARC result and identifier alignment
- Received path
- Provider-specific feedback

DNS observation alone does not connect the record to an actual message.

### 7. Monitor before retiring the old path

Wait through relevant TTL and negative-cache windows. Monitor delivery, bounces, authentication, and service logs. Remove compatibility only after evidence shows the new path is stable.

### 8. Restore appropriate TTL

After the migration is stable, restore a TTL suitable for the zone's reliability and change frequency. A permanently tiny TTL can increase dependency on authoritative availability and query volume.

## Interpreting common result combinations

### Same answers, expected value observed

Both selected providers returned the same normalized answer, and both matched the expected state.

This is useful positive evidence. It is not global proof.

### Same answers, expected value missing

Both providers agree, but on a state different from the operator's expectation.

Possible causes include:

- The change was not published
- The expected owner name is wrong
- The expected type is wrong
- The value was entered differently
- Both providers still have an old cached answer
- The DNS control-panel change targeted another zone

### Different answers

The recursive observations differ.

Possible causes include:

- Valid old and new cache states
- Inconsistent authoritative servers
- Split-horizon DNS
- Different alias or dependency paths
- A recent delegation change
- Provider-specific policy
- A transient resolution failure

TTL and exact record evidence help narrow the possibilities but do not automatically choose one cause.

### NXDOMAIN and NOERROR/no data

One resolver says the name does not exist; another says the name exists without the requested type.

Investigate the zone cut, negative caching, recent name creation, aliases, and authoritative consistency.

### SERVFAIL

SERVFAIL is not equivalent to absence. It can reflect DNSSEC validation failure, authority timeouts, delegation problems, resolver policy, or another resolution error.

### One browser request fails

The comparison is incomplete. Review browser console and network controls, try another network if appropriate, and do not label the record missing.

## Exported evidence

The JSON export includes:

- Tool canonical URL
- Methodology statement
- Scope limitation
- Checked timestamp
- Exact owner name
- Record type
- Expected value and mode
- Match mode
- Provider name and endpoint
- DNS status
- Raw requested-type answers
- Authority records
- Normalized answer set
- DNSSEC AD state
- Recursive-availability flag
- Browser-observed request latency
- Browser or HTTP error text
- Expected-state result
- Nameserver context
- SOA context
- Plain-language summary
- Count of distinct observed answer sets

Latency is included for evidence, not as a DNS-provider performance benchmark. A single browser request includes local network, TLS, HTTP, routing, endpoint, and cache effects.

## Frequently asked questions

### Does agreement mean DNS is fully propagated?

No. It means the named providers returned the same normalized result to this browser at this time.

### How long does DNS propagation take?

There is no universal duration. Existing positive and negative cache entries, prior TTLs, resolver behavior, delegation caches, authoritative publication, local caches, and failures all affect observation.

### Can this tool flush a DNS cache?

No. The browser cannot force public resolvers, ISPs, enterprise networks, mailbox providers, or devices to discard valid cache entries.

### Why does TTL change between runs?

The provider may return remaining cache time. The next request can reach the same cache later, a refreshed cache, or a different service node.

### Why can two providers agree on the old value?

Both may still hold valid cached copies, or the new value may not be published at the authoritative source.

### Why can two providers agree on no data?

The record can be absent at the queried name, the type can be wrong, a negative response can be cached, or publication can have failed.

### Does the tool query local ISP DNS?

No. It sends HTTPS requests to the named provider endpoints. Local network behavior still affects reaching those endpoints.

### Is the domain sent to Email Bump?

The query runs in the browser directly against Google and Cloudflare. Email Bump does not proxy the DNS request. Standard page hosting and analytics behavior is separate from the DNS API requests.

### Why is Quad9 not included?

Quad9 retired its JSON-based DNS service in May 2025. Its standard DNS-over-HTTPS service uses DNS wire format. This browser implementation uses documented JSON interfaces and does not mislabel a retired or incompatible endpoint as a live provider.

### Can I check a DKIM CNAME?

Yes. Choose Custom, enter the selector owner name, and select CNAME. Use the dedicated DKIM checker to follow the alias and inspect the final key.

### Can I prove DMARC works with this page?

No. The page can observe the DMARC TXT record. A real message and its authentication results are required to inspect DMARC evaluation and alignment.

### Can I use an expected partial value?

Yes. Contains mode looks for a normalized substring within one normalized record. Use exact mode when the complete record is known.

### Does AD=no mean DNSSEC is broken?

Not necessarily. The data might be unsigned, the interface might not set AD for that response, validation can be disabled or unavailable, or another condition can apply. Perform a dedicated DNSSEC investigation before assigning a cause.

## Primary sources

- [Google Public DNS: JSON API for DNS over HTTPS](https://developers.google.com/speed/public-dns/docs/doh/json)
- [Cloudflare 1.1.1.1: Make JSON DNS-over-HTTPS requests](https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/make-api-requests/dns-json/)
- [IETF RFC 2308: Negative Caching of DNS Queries](https://www.rfc-editor.org/rfc/rfc2308)
- [IETF RFC 9520: Negative Caching of DNS Resolution Failures](https://www.rfc-editor.org/rfc/rfc9520)
- [IETF RFC 4035: Protocol Modifications for DNS Security Extensions](https://www.rfc-editor.org/rfc/rfc4035)
- [Quad9: JSON-based DNS service retirement notice](https://www.quad9.net/news/blog/quad9-json-based-dns-service-retires-5-may-2025/)

## Related tools and guidance

- [SPF lookup budget checker](https://emailbump.com/tools/spf-record-checker.md)
- [DKIM record checker](https://emailbump.com/tools/dkim-record-checker.md)
- [DMARC record builder](https://emailbump.com/tools/dmarc-record-builder.md)
- [MX routing inspector](https://emailbump.com/tools/mx-record-lookup.md)
- [BIMI record and logo checker](https://emailbump.com/tools/bimi-record-checker.md)
- [Email header analyzer](https://emailbump.com/tools/email-header-analyzer.md)
- [Domain RDAP lookup](https://emailbump.com/tools/domain-whois-lookup.md)
- [Email blacklist checker](https://emailbump.com/tools/email-blacklist-checker.md)
- [DKIM and Gmail's via label](https://emailbump.com/blog/dkim-and-via-label-in-gmail.md)
- [Reacting to Gmail reputation-based bounces](https://emailbump.com/blog/gmail-reputation-based-bounces.md)
- [Deliverability documentation](https://emailbump.com/docs/deliverability.md)