You switched mail providers, updated the MX records and added the new provider to SPF, and now half your colleagues say mail works and the other half see bounces. Or you published a DMARC record and a lookup tool cannot find it yet. Email DNS changes are not visible everywhere at once: every recursive resolver serves its cached copy until the old record's TTL runs out.
The Email DNS Propagation checker asks eight public resolvers for one email-related record (MX, SPF, DMARC, MTA-STS or TLS-RPT) and shows their answers side by side, with a summary of whether they agree. Use it right after a change to see whether the new record is out, and during a migration to understand why some senders still behave as before.
What is email DNS propagation?
In simple terms
When you change a DNS record, the authoritative name servers have the new value immediately. But most mail servers do not ask your name servers directly: they ask a resolver, which keeps answers in a cache for a while. "Propagation" is the time it takes until those caches have expired and everyone gets the new answer.
Technical background
DNS has no push mechanism. A recursive resolver caches each answer for the TTL (time to live) that the authoritative server attached to it, as described in RFC 1035 and RFC 2181. Negative answers (NXDOMAIN or no data) are also cached, for the SOA minimum TTL (RFC 2308), which is why a record that was queried just before you created it may stay invisible for a while.
The email records the tool compares:
| Record | DNS name and type | Used by |
|---|---|---|
| MX | <domain> MX | Senders to find your mail servers |
| SPF | <domain> TXT starting with v=spf1 | Receivers checking your outbound mail |
| DMARC | _dmarc.<domain> TXT starting with v=DMARC1 | Receivers applying your policy |
| MTA-STS | _mta-sts.<domain> TXT starting with v=STSv1 | Senders discovering your TLS policy |
| TLS-RPT | _smtp._tls.<domain> TXT starting with v=TLSRPTv1 | Senders sending TLS reports |
Large public resolvers are anycast networks with many sites and often several independent caches per site, so even one resolver address can return the old and the new answer on consecutive queries during the transition.
Why use Email DNS Propagation?
- Migration timing: know when the new MX is visible on major resolvers before you shut down the old mail server.
- Explain inconsistent behavior: some receivers apply the new SPF or DMARC record while others still use the old one.
- Verify a new record exists before you test with tools that rely on a single resolver.
- Catch partial publishing: if no resolver returns the record long after the change, the problem is in your zone, not in caching.
Who should use it?
- Administrators migrating mail between providers.
- Anyone who has just published or changed SPF, DMARC, MTA-STS or TLS-RPT.
- Support staff explaining why mail delivery changed for some senders but not others.
- MSPs confirming a client's DNS change has been applied.
How Email DNS Propagation works
The tool translates your choice into a DNS name and type: MX queries the domain's MX records; SPF queries the domain's TXT records; DMARC, MTA-STS and TLS-RPT query TXT at _dmarc, _mta-sts and _smtp._tls under the domain.
The NetTools.tech server then sends that query in parallel to eight public resolvers: Google Public DNS (8.8.8.8 and 8.8.4.4), Cloudflare DNS (1.1.1.1 and 1.0.0.1), Quad9 (9.9.9.9 and 149.112.112.112), OpenDNS (208.67.222.222) and AdGuard DNS (non-filtering, 94.140.14.140). Each resolver gets one try with a 3-second timeout, and the response time is measured.
In your browser, the answers are filtered to the record you asked for: for SPF only strings starting with v=spf1, for the other TXT records only strings starting with v=DMARC1, v=STSv1 or v=TLSRPTv1. Other TXT records at the same name, such as site-verification strings, are ignored. The distinct answers are counted to produce the summary. The operation has a 25-second time limit and counts against a per-client rate limit, with a higher cost than a single lookup because it sends eight queries.
How to use the NetTools.tech Email DNS Propagation checker
- Open Email DNS Propagation.
- Enter the Domain, for example
example.com. - Choose the Record: MX (default), SPF, DMARC, MTA-STS or TLS-RPT.
- Press Run Email DNS Propagation. In the terminal the same check is
/email-propagation example.com --record DMARC. - Read the summary line, then compare the rows.
- Repeat after a few minutes while a change is propagating; use Copy to keep a text version.
Understanding the results
| Result | Meaning | What to look for |
|---|---|---|
| Queried | The DNS name and type actually asked, such as _dmarc.example.com TXT | Confirms the right name was built |
| Resolver | The provider and the address asked, such as Google Public DNS (8.8.8.8) | Google, Cloudflare and Quad9 each appear with two addresses |
| Record | The matching record(s) returned, or — | Compare the values across rows |
| Result: answer | The resolver returned data for the name | The record column may still be — if none of the TXT strings matched the record type |
| Result: no records | The name exists but has no data of this type | Normal before a new record is created or cached |
| Result: NXDOMAIN | The name does not exist for this resolver | Expected for _dmarc etc. until the record is published |
| Result: timed out / SERVFAIL / refused / error | The resolver did not give a usable answer | SERVFAIL on every resolver often points to a DNSSEC or name server problem |
| Time | Response time from the NetTools.tech server | A noticeably higher time often means the resolver had to fetch the record instead of answering from cache |
| Summary: all resolvers that answered return the same record | One distinct value | Rows without a record are not counted as a different answer |
| Summary: no resolver returned this record | Nothing found anywhere | Check that the record is published under the right name |
| Summary: N different answers | Old and new values are both cached | Wait for the old TTL to expire |
Example: moving MX to a new provider
example.com changed its MX from mail.example.com to mx1.example.net and mx2.example.net ten minutes ago; the old MX had a TTL of one hour. Checking MX shows:
Queried example.com MX
Resolver Record Result Time
Google Public DNS (8.8.8.8) 10 mx1.example.net / 20 mx2.example.net answer 18 ms
Cloudflare DNS (1.1.1.1) 10 mail.example.com answer 4 ms
Quad9 (9.9.9.9) 10 mx1.example.net / 20 mx2.example.net answer 21 ms
...
2 different answers — a recent change may still be propagating.(In the tool, multiple records in one row are shown on separate lines.) Some resolvers have fetched the new MX, Cloudflare still serves the cached old one. Keep the old server accepting mail until the old TTL has elapsed on all resolvers and the summary shows one answer. To query one resolver yourself:
dig @1.1.1.1 +noall +answer MX example.com
dig @8.8.8.8 +noall +answer MX example.comThe TTL column in dig output counts down to the moment that resolver will re-fetch.
Common use cases
- Mail provider migrations: watch MX and SPF until all resolvers agree.
- DMARC policy changes: confirm the new
p=value is visible before you judge its effect in reports. - MTA-STS id changes: check the new
idis visible after updating the policy file. - New TLS-RPT record: confirm it is published before waiting a day for reports.
- Post-change verification after another team edited your zone.
Troubleshooting
No resolver returns the record
Propagation is not the problem: the record is not published where the tool looks. Check the host name (_dmarc, _mta-sts, _smtp._tls), that your DNS panel did not append the domain twice, and that the change was saved in the zone your domain's NS records actually point to. DNS Lookup shows the NS records.
The Result is "answer" but the Record column is empty
The resolver returned TXT data at that name, but none starting with the expected tag. Typical causes: a typo such as v=spf or v=DMARC 1, quotes typed into the value, or a leading space.
Answers keep flipping between old and new
Anycast resolvers have many caches. During the old TTL window, consecutive queries can hit different caches. This settles once the old TTL has expired everywhere.
Some resolvers time out or return SERVFAIL
Isolated timeouts are normal on busy networks; repeat the check. SERVFAIL from validating resolvers but not others can indicate a DNSSEC problem with the zone.
Common mistakes
- Expecting a change to be visible instantly after saving it in the DNS panel.
- Lowering the TTL at the same time as the change; that only helps for the next change.
- Treating agreement among eight public resolvers as proof that every ISP and corporate resolver has the new data.
- Checking DMARC on the domain instead of
_dmarc; the tool builds the name for you, so enter only the domain. - Shutting down the old mail server as soon as one resolver shows the new MX.
Limitations
- Only eight IPv4 public resolvers are queried, all from the NetTools.tech server; anycast resolvers answer from the site nearest to that server, not from your users' locations.
- The tool does not show TTL values. Use
digagainst a resolver or DNS Lookup if you need them. - DKIM is not included because it needs a selector; use DNS Propagation with the TXT type for
selector._domainkey.<domain>. - TXT values are shortened to 1,024 characters per record in the results.
- The tool shows what resolvers return, not whether the record is correct. Validate the content with SPF Lookup, DMARC Lookup, MTA-STS Lookup or MX Lookup.
Security & privacy
Only a public domain name is sent to the NetTools.tech server; internal names such as .local or .internal are rejected. The server queries public resolvers only, never internal DNS, and those resolver operators see the queries as coming from the NetTools.tech server, not from you. No email is sent and your mail servers are not contacted. The records queried are public. No credentials are needed.
Related tools
- DNS Propagation – any record type and name, more resolvers (guide).
- MX Lookup – validate MX hosts, addresses and reverse DNS (guide).
- SPF Lookup – check the SPF record's syntax and lookup count (guide).
- DMARC Lookup – explain the policy and reporting setup (guide).
- DNS Lookup – query a single record type, including NS and TTLs (guide).
Summary
Email DNS changes reach senders and receivers only when resolver caches expire, so the old and new records coexist for up to one TTL. The NetTools.tech Email DNS Propagation checker queries eight public resolvers for MX, SPF, DMARC, MTA-STS or TLS-RPT and shows whether their answers agree. Use it to time migrations, and validate the record content with the dedicated lookup tools.
Frequently asked questions
Why do resolvers show different answers after a DNS change?
Recursive resolvers cache records for the TTL that was set when they last fetched them. Until that TTL expires, a resolver keeps returning the old answer, so some resolvers show the new record while others still show the old one.
How long does email DNS propagation take?
It depends on the TTL of the old record and on when each resolver last cached it. With a TTL of 3600 seconds, all caches normally hold the new answer within about an hour of the change; with a TTL of a day, it can take up to a day.
How can I speed up propagation?
Lower the TTL of the record well before a planned change, at least one old TTL in advance, so caches pick up the short TTL first. After the change has been made, you can only wait for existing caches to expire.
Which records can the Email DNS Propagation tool compare?
MX, SPF, DMARC, MTA-STS and TLS-RPT. SPF is the v=spf1 TXT record on the domain, DMARC is read at _dmarc, MTA-STS at _mta-sts and TLS-RPT at _smtp._tls.
Can I check DKIM propagation with this tool?
Not directly, because DKIM keys live under a selector name that the tool does not ask for. Use the general DNS Propagation tool with the TXT type and the name selector._domainkey.example.com, or DKIM Lookup to check the key itself.
Which resolvers are queried?
Eight public IPv4 resolvers: Google (8.8.8.8 and 8.8.4.4), Cloudflare (1.1.1.1 and 1.0.0.1), Quad9 (9.9.9.9 and 149.112.112.112), OpenDNS (208.67.222.222) and AdGuard (94.140.14.140). They are queried from the NetTools.tech server.
Does "all resolvers return the same record" mean the change is live everywhere?
It means all eight resolvers that answered agree at that moment. Other resolvers, such as ISP or corporate resolvers, have their own caches, and anycast resolvers answer from the site nearest to the NetTools.tech server, so different locations can still see an older answer briefly.