As long as resolvers may keep their old copy, and that is set by a number you can see: the TTL (time to live) of the record. A resolver that looked the record up before your change may reuse its copy until that TTL runs out, and only then asks your DNS servers again. So the longest wait is:

With a TTL of 300 seconds, a resolver may keep the old value for up to five minutes after your DNS provider publishes the change; with a TTL of one day, for up to a day. The TTL is an upper limit: a resolver may drop its copy sooner, and Google says the TTLs in its Public DNS cache are generally limited to six hours even when the record's TTL is longer. Providers put it the same way: Namecheap says that with its default TTL, DNS servers can still show the old value for up to 30 minutes after a change.

The word suggests that a change travels from server to server, but nothing is pushed to resolvers. When you save a record, your DNS provider updates its own DNS servers, and they start giving the new answer. Everyone else asks through a recursive resolver: their internet provider's, their company's, or a public one such as Google's 8.8.8.8 or Cloudflare's 1.1.1.1. Each resolver keeps the answers it fetched for the time the TTL allows (RFC 1035 §3.2.1). “Propagation” is those stored copies running out one by one, at different moments, because each resolver fetched the record at a different time. Until the last one has run out, some people get the new answer and some the old one.

What this DNS propagation checker does

It sends the same question, for one name and one record type, to 9 public resolvers run by 9 different operators, all at the same moment and directly from our server, and compares their answers. Records count as the same answer when they hold the same values, in any order and with any TTL, because every resolver counts its TTL down from the moment it fetched the record. A resolver that does not answer, or answers with an error, is left out and listed with the reason. The table of all 9 is in the resolvers we ask.

It shows what those resolvers hold, not your internet provider's resolver or your own computer's cache. It does not ask your domain's own DNS servers either, so it cannot say which of two answers is the new one: compare them with what you saved at your DNS provider.

Choose the record type you changed in the menu; A is the default. For a website that is usually A, AAAA or CNAME, for mail servers MX, for SPF, DMARC and most DKIM keys TXT, and for a move to another DNS provider NS. SOA shows the zone's serial number, the version of the zone (RFC 1035 §3.3.13): if your provider raises it with every change, different serials show which resolvers still hold an older copy of the SOA record. An IP address is checked as its reverse DNS (PTR) record.

The panel at the top of the result is the verdict: a colored icon and a short label. Under it the result lists every different answer, which resolvers gave it, and one row per resolver with its answer, the TTL it has left and how long it took. There are three possible verdicts: Pass, Warning and Could not check. It never shows Fail: different answers are not an error by themselves.

Warning: no resolver sees the record

Every resolver that answered says there are no records of this type at this name: the name exists without them (shown as NODATA) or does not exist at all (NXDOMAIN). The result treats both the same, because some DNS providers give an empty answer for names that do not exist. The usual reasons:

• a typo in the name, or the record added at another name, for example www instead of the domain itself;
• the record added at a DNS provider that is not the one your domain uses; check the ns: records of the domain;
• the record is new and resolvers still remember the earlier “no such record” answer. That is negative caching: the answer carries the zone's SOA record, and resolvers may keep it for the lower of the SOA's TTL and its last field, the minimum (RFC 2308 §5). For example.com that was 1,800 seconds on September 26, 2026. The TTL column shows how much longer each resolver may keep it, an upper limit only. A check here before you added the record counts too: it asked the same resolvers.

Warning: the name is an alias to a name that does not exist

The name has a CNAME record, so resolvers follow it to another name, and every resolver that answered said that other name does not exist. Nobody gets an address or any other record back. This is common after a service is canceled: the CNAME still points to the provider's old host. Point the CNAME to the name your provider gives you now, or delete it if the service is gone.

Could not check: two or more resolvers report a server failure

2 or more resolvers of different operators answered SERVFAIL. Resolvers do that when they cannot reach the domain's DNS servers, and resolvers that check DNSSEC do it when the domain's signatures do not validate. When independent operators fail the same way, the cause is more likely on the domain's side. The resolvers that did answer do not outvote them: a resolver that does not check DNSSEC answers even for a domain whose signatures are broken. This check does not validate DNSSEC itself, so it cannot say which of the two it is. On September 26, 2026, dnssec-failed.org got SERVFAIL from 7 of our 9 resolvers, and Gcore and CIRA answered, with an address. Both also gave SERVFAIL when the question carried the AD flag (dig sets it by default) or asked for DNSSEC records; this check does neither, so it shows what these two resolvers give a device that does not ask for DNSSEC. With DNSSEC checking switched off (dig +cd), 1.1.1.1 answered too, so the domain's DNS servers could be reached and it was the DNSSEC check that failed. Check that every nameserver of the domain answers, and if DNSSEC is on, that the DS record at your registrar matches a key your DNS provider publishes now.

Could not check: not enough resolvers answered

More than half of the resolvers gave no usable answer, or fewer than 2 answered, so there is not enough to compare. We never turn a missing answer into a pass or a warning. If 2 or more of them answered SERVFAIL, the result says so, and the cause is more likely on the domain's side: see server failures above. If they timed out or could not be reached, this says nothing about your records, and if it stays like this, the problem is more likely between our server and the resolvers. A result that could not be checked is not reused, so you can try again right away.

Resolvers left out of the comparison

A resolver that timed out, refused the query, answered SERVFAIL or sent an answer we could not decode safely is listed with the reason and left out: it counts neither as agreeing nor as disagreeing, and the verdict comes from the others. The one exception is SERVFAIL from 2 or more resolvers: then the verdict is Could not check, see above. A timeout tells us nothing about your records; a single SERVFAIL can be that resolver's own problem. If our limit on DNS queries per check ever stops a resolver from being asked, the result says so too.

Could not check: a fault on our side

Rarely, the result says the check could not be completed because of an internal error. That is a fault in our software, not a finding about your domain and not a network problem, so trying again will most likely give the same result. Please write to support@mxverdict.com with the address of the result page, and we will fix it.

TTL left

Each row shows the TTL that resolver has left for its copy, counted from when that resolver fetched it. That is why the numbers differ even when the records are the same: on September 26, 2026, Cloudflare's 1.1.1.1 had 243 seconds left for example.com A, Google's 8.8.8.8 had 300 and Quad9 had 141. So it can be lower than the TTL you set. For a “no records” answer it is how long that resolver may keep the empty answer.

Why this is not a check from different countries

Google Public DNS uses anycast: one address is served from many places, and a question goes to the site nearest to whoever asks. Where an operator works like that, our questions, which all come from our server, reach its site near our server, whatever country its description names. Google also passes part of the asker's address to the domain's DNS servers, so services that answer by location answer for where our server is. What we compare is 9 independent caches, which is what propagation is about.

You cannot push a new record into other people's resolvers. You can make their copies short-lived before you change something, and you can clear the caches you control.

Lower the TTL before the change

1. Well before the change, lower the TTL of the record you will change, for example to 300 seconds (five minutes). Leave the value as it is.
2. Wait at least as long as the old TTL. Resolvers that stored the record before you lowered it keep the old TTL until it runs out; this is the step people skip.
3. Make the change. Resolvers now keep the old value for at most the short TTL. Check the name here until every resolver gives the new answer.
4. Raise the TTL again, for example to an hour, so resolvers ask your DNS servers less often.

A record you are adding for the first time has no TTL of its own yet: what counts is how long resolvers keep the “no such record” answer, set by the SOA record of the zone (see no resolver sees the record). Add the record before you need it, and do not look it up just before adding it: a lookup of a missing record is what puts the empty answer into a cache. A check on this page is such a lookup at the 9 resolvers we ask: each of them may then keep the empty answer for as long as the TTL column of that result shows.

Changing nameservers takes longer

Your nameservers are listed twice: in the zone above yours (for example.com, the .com zone, where you change them through your registrar) and as NS records in your own zone. Each copy has its own TTL, and the TTL settings in your DNS dashboard do not touch the one in the zone above. A resolver may keep either copy: RFC 2181 §5.4.1 ranks the answer of your own DNS servers above the referral from the zone above. So the longest wait depends on the resolver, and some keep NS records for less than their TTL.

On September 26, 2026, the .com servers gave the nameservers of example.com and gmail.com a TTL of 172,800 seconds; the domains' own servers gave 86,400 and 345,600 seconds. Our 9 public resolvers had between 10,649 and 86,400 seconds left on the NS records of example.com, and up to 339,809 on those of gmail.com; Google had at most 21,600 on both, its six-hour limit. A resolver that still holds the old nameservers keeps asking them until its copy runs out.

• Before you switch, copy every record to the new DNS provider, so both give the same answers. Then it does not matter which one a resolver asks.
• Keep the zone at the old provider unchanged for at least as long as the longer of the two NS TTLs (for example.com, the 172,800 seconds of the .com zone when we measured).
• Check the ns: records of the domain here, and the delegation itself with the dig command in How to check DNS propagation.

Flush the caches on your own computer

If this page shows the new answer everywhere but your computer does not, the old answer is in a cache near you. These clear it on your side only:

• macOS: in Terminal, run sudo killall -HUP mDNSResponder. Apple gives this command for OS X Yosemite v10.10.4 and later in its archived article “Reset the DNS cache in OS X”.
• Windows: in Command Prompt, run ipconfig /flushdns. Microsoft's description: “Flushes and resets the contents of the DNS client resolver cache.”
• Chrome: open chrome://net-internals/#dns and select Clear host cache under Host resolver cache. Chrome keeps its own cache in addition to the operating system's.

Your internet provider's resolver keeps copies too, and only its operator can clear them. Until they run out you can compare with a public resolver from the command line (see below).

Ask Google Public DNS and Cloudflare to refresh

Google Public DNS and Cloudflare's 1.1.1.1 each have a public page that drops a cached answer, one name at a time:

• Google Public DNS: the Flush Cache page (developers.google.com/speed/public-dns/cache). No proof of ownership is needed, but you solve a reCAPTCHA, and each record type is flushed separately. After a nameserver change, Google asks you to flush the domain itself first and subdomains such as www after it. Domains that answer by the asker's location cannot be flushed there, and names with non-ASCII letters must be entered in their xn-- form.
• Cloudflare 1.1.1.1: the Purge Cache page (one.one.one.one/purge-cache/). Enter the domain, pick the record type and select Purge Cache. SOA is not in its list of types.

This refreshes only that operator's cache. Every other resolver keeps its copy until the TTL runs out.

TTL at Cloudflare

1. In the Cloudflare dashboard, go to the DNS Records page.
2. Select Edit on the record, change TTL and select Save.

Auto means 300 seconds. Proxied records always have Auto, and their TTL cannot be edited. For DNS-only records you can choose from 60 seconds (30 seconds on Enterprise plans) up to one day.

TTL at GoDaddy

1. Sign in to your GoDaddy Domain Portfolio and select the domain to open its Domain Settings.
2. Select DNS, then Edit next to the record.
3. Change TTL and select Save. The default is 1 hour.

TTL at Namecheap

1. Open Domain List and select Manage next to the domain.
2. Open the Advanced DNS tab. The records are under Host Records.
3. Choose a value in the record's TTL menu and save the change. Automatic is 30 minutes (5 minutes for ALIAS records).

Moving email to another provider

When you move mail to Google Workspace, Microsoft 365, Zoho or another provider, the MX records change, and senders whose resolvers still hold the old ones deliver to the old provider. Lower the TTL of the MX records first, as above. After the change, keep the old mailboxes receiving for at least as long as the old TTL of the MX records, and until the MX check of your domain here (for example mx:example.com) shows the new records at every resolver: senders ask their own resolvers, not only the ones we check. The MX lookup then shows the new mail servers with their addresses.

When a sending service such as SendGrid, Mailgun or Amazon SES says it cannot find a DNS record you added, look the record up here with the type and the name the service lists, for example txt: or cname: in front of the name. If every resolver shows it, the record is published, and the service may still be holding an older answer: ask it to verify again later.

1. Enter the name as it appears in the record, for example www.example.com or _dmarc.example.com, and choose the record type you changed.
2. Compare the answers with the value you saved at your DNS provider. Answer 1 is only the most common one, not necessarily the new one.
3. For resolvers that still give another answer, the TTL column says how long they may keep it. Check again after that. This page reuses a result for 60 seconds, so wait at least that long between checks.

From your own computer you can ask one resolver at a time. On macOS and Linux, dig with @ and an address asks that resolver instead of your network's own:

dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer

On September 26, 2026, they returned the same two addresses with different TTLs left:

example.com.		241	IN	A	104.20.23.154
example.com.		241	IN	A	172.66.147.243

example.com.		300	IN	A	104.20.23.154
example.com.		300	IN	A	172.66.147.243

Each line of the answer shows the name, the TTL that resolver has left in seconds, IN, the record type and the value. Compare the values; the TTLs usually differ, because each resolver counts down from its own fetch.

nslookup works on Windows, macOS and Linux; the resolver's address goes last. In Windows PowerShell, Resolve-DnsName takes it with -Server:

nslookup -type=A example.com 8.8.8.8
Resolve-DnsName -Name example.com -Type A -Server 8.8.8.8

To see the nameservers the zone above yours hands out, and their TTL, ask one of its servers directly. For a .com domain:

dig @a.gtld-servers.net example.com NS +norecurse +noall +authority

On September 26, 2026, this returned:

example.com.		172800	IN	NS	hera.ns.cloudflare.com.
example.com.		172800	IN	NS	elliott.ns.cloudflare.com.

One address per operator, because a second address of the same operator reaches the same network. For most operators it is their address without filtering; the last column says what each operator states about blocking. The locations are what each operator says about itself, read on its own pages on September 26, 2026, and for CIRA on September 22, 2026; “not verified” marks what its pages do not say. The list itself and whether every address answers were last checked on September 26, 2026.

We ask their IPv4 addresses over plain DNS. Each operator sees the name and type you check, asked by our server; none of them sees your address. The dig commands above work with any address in this table.