Migração para Google Workspace
- Entrada
- MX antigo: mail.provedor-antigo.com
- Saída esperada
- MX novo: smtp.google.com (aspmx.l.google.com)
Mantenha o servidor antigo ligado até os três resolvers concordarem.
Carregando ferramenta… / Loading tool…
propagação do registro MX
Migrar de provedor de e-mail é a mudança de DNS com maior risco real: se o registro MX antigo ainda estiver em cache em algum resolver quando o servidor antigo for desligado, mensagens enviadas nesse intervalo podem simplesmente não chegar.
Mantenha o servidor antigo ligado até os três resolvers concordarem.
Vários MX com prioridades diferentes são normais para redundância.
É o tempo que uma alteração em um registro DNS leva para ser refletida em todos os resolvers recursivos do mundo. Não existe um mecanismo de "empurrar" a mudança, cada resolver só busca o valor novo depois que o TTL do valor antigo em cache expira.
Não é recomendado. Mantenha-o ativo por pelo menos o TTL antigo do registro MX, e idealmente por 48 a 72 horas, para não perder mensagens enviadas por servidores que ainda têm o valor antigo em cache.
É um número onde o menor valor tem preferência. Servidores tentam primeiro o MX de menor prioridade e caem para os seguintes só se o primeiro não responder, é o mecanismo padrão de redundância de e-mail.
O tempo de divergência depende só do TTL configurado, não do tipo de registro. Mas como o custo de errar é maior (e-mail perdido, não só uma página desatualizada), vale usar um TTL mais baixo no MX antes de qualquer migração planejada.
A verificação consulta 3 resolvers públicos (Cloudflare, Google Public DNS e DNS.SB) em paralelo, direto do seu navegador, sem passar pelo nosso servidor. Se todos concordarem, a propagação está completa.
Por segurança, o navegador fala diretamente com resolvers públicos fixos, passando apenas o nome consultado, o servidor do J-Kit nunca é usado como intermediário, evitando exposição de IP e SSRF. A consulta é pública por natureza, como qualquer resolução de DNS.