A alteração dos provedores de e-mail altera os nomes de host de recebimento, a propriedade do certificado e, às vezes, o comportamento de fallback. MTA-STS pode expor uma ordem de migração insegura: DNS começa a anunciar um novo provedor enquanto alguns remetentes ainda impõem uma política que permite apenas o antigo.
Faça um inventário de ambos os lados da migração
Referências: RFC 8461 §4, RFC 8461 §8.2.
Registre os nomes MX antigos e propostos, prioridades, endereços, STARTTLS comportamento e identidades de certificados. Obtenha o roteamento atual do novo provedor e a orientação MTA-STS e, em seguida, verifique os nomes exatos em sua própria alteração planejada DNS . A marca de um provedor ou um curinga adivinhado não é um inventário oficial de nomes de host.
Revise se a política de hospedagem HTTPS ou DNS de descoberta também está vinculada ao provedor de saída. Mover o recebimento de mensagens ao cancelar acidentalmente o host da política cria uma segunda falha. Mantenha a publicação de políticas, a renovação de certificados e os destinos de relatórios de propriedade explícita durante a mudança.
Publique uma política de compatibilidade primeiro
Referências: RFC 8461 §3.2, RFC 8461 §4, RFC 8461 §8.1.
Prepare uma política que permita os hosts de recebimento antigos e novos necessários sem alterar ainda o roteamento de mensagens. Teste se ambos os grupos correspondem e se o novo grupo passa no certificado SMTP e nas verificações STARTTLS . Publique o corpo HTTPS antes de alterar o ID de descoberta.
Permita um intervalo de transição com base na política max_age publicada anteriormente, no TTL DNS e no comportamento de atualização observado. A redução de max_age no momento da migração não encurta uma política obtida anteriormente. Sempre que possível, mantenha uma rota antiga em funcionamento que satisfaça as políticas antigas em cache enquanto a nova política é distribuída. Não prometa que a alteração do ID atualizará instantaneamente todos os remetentes.
Ensaie os três estados políticos
Referências: RFC 8461 §4.1.
Use dois nomes sintéticos, mx.old.example e mx.new.example . A Política A permite apenas antigos; a política B permite ambos; a política C permite apenas novos. A matriz de compatibilidade esperada é A: antigo verdadeiro, novo falso; B: ambos verdadeiros; C: antigo falso, novo verdadeiro. O jogo off-line local fornecido foi executado novamente para esta revisão e registra essas comparações de nomes, não de entrega.
Esta matriz prova apenas a relação de adesão à política nomeada. Um ensaio realista também precisa de respostas DNS , certificados válidos, STARTTLS , aceitação do destinatário e entrega real da mensagem de teste. Esses testes de migração ao vivo não foram realizados para este artigo. Preservar os seus resultados futuros separadamente, em vez de tratar a matriz local como uma transição bem-sucedida de fornecedores.
Mova a rota e retire-se deliberadamente
Referências: RFC 8461 §5.1, RFC 8461 §8.1.
Após o estágio de compatibilidade, alterne o roteamento MX por meio do processo de alteração aprovado. Observe a entrega em ambos os provedores, erros do remetente, filas e relatórios TLS . Confirme destinatários comerciais e rotas de recuperação, incluindo endereços de baixo volume que um único teste de caixa de entrada deixaria passar. Mantenha o serviço antigo disponível durante a sobreposição planejada.
Só então restrinja a política ao novo conjunto pretendido e anuncie outro ID. Preserve o corpo anterior e considere como a reversão funcionaria com os remetentes armazenando em cache a política somente nova. Adicionar novamente o MX antigo apenas no DNS pode não restaurar a entrega para esse coorte. Feche a migração quando a rota, a política e as evidências operacionais apoiarem a desativação, e não apenas quando o editor DNS mostrar o novo provedor.
Evidências históricas retidas e escopo restante
O seguinte descreve observações preservadas de 7 de novembro de 2026, não um experimento de rede reexecutado para esta revisão. As verificações off-line recentemente executadas são registradas separadamente.
O ensaio estendido vincula a matriz de membros à publicação e ao estado vitalício. A1 permite apenas o antigo e pode permanecer válido até o tempo lógico 1086700, quando sua última busca modelada é considerada. B2 permite ambos os provedores; seu corpo é buscado por meio do endpoint HTTPS do laboratório após a alteração do ID DNS . C3 permite apenas novos. Os tempos de expiração B2 e C3 modelados, 1004200 e 1004500, ocorrem antes do limite A1 mais antigo porque A1 usou uma vida útil mais longa. Assim, promover o C3 ou mudar DNS apenas no momento da publicação do B2 não é evidência de que todos os remetentes antigos estejam prontos. O rastreamento demonstra DNS /HTTPS local real, além da aritmética explícita do estado da política. Ele não testa a aceitação do destinatário do provedor, caches DNS públicos, entrega de correspondência ou cobertura de endereço comercial; estes continuam sendo o portão de transição.