Migration to Google Workspace
- Input
- MX antigo: mail.provedor-antigo.com
- Expected output
- MX novo: smtp.google.com (aspmx.l.google.com)
Keep the old server on until all three resolvers agree.
Carregando ferramenta… / Loading tool…
MX record propagation
Switching email providers is the DNS change with the highest real risk: if the old MX record is still cached at some resolver when the old server is turned off, messages sent during that window can simply fail to arrive.
Keep the old server on until all three resolvers agree.
Multiple MX entries with different priorities are normal for redundancy.
It's the time a DNS record change takes to be reflected across every recursive resolver in the world. There is no mechanism to "push" the change, each resolver only fetches the new value after the old cached value's TTL expires.
Not recommended. Keep it active for at least the old MX record's TTL, and ideally 48 to 72 hours, so you don't lose messages sent by servers that still have the old value cached.
It is a number where the lowest value wins preference. Servers try the lowest-priority MX first and fall back to the next ones only if the first doesn't respond, it is the standard email redundancy mechanism.
The divergence window depends only on the configured TTL, not on the record type. But because the cost of getting it wrong is higher (lost email, not just a stale page), it is worth using a lower TTL on the MX before any planned migration.
The check queries 3 public resolvers (Cloudflare, Google Public DNS and DNS.SB) in parallel, straight from your browser, without touching our server. If all of them agree, propagation is complete.
For safety, the browser talks directly to fixed public resolvers, passing only the queried name, the J-Kit server is never used as an intermediary, avoiding IP exposure and SSRF. A DNS query is public by nature, like any name resolution.