Uma reversão altera as observações futuras; ele não pode acessar todos os remetentes e apagar uma política em cache. Quando uma política imposta começar a atrasar mensagens legítimas, preserve a revisão exata quebrada e encontre a maneira mais rápida de fazer com que um caminho de recebimento satisfaça a política que os remetentes já possuem.
Estabilize a entrega antes de remover os controles
Referências: RFC 8461 §4, RFC 8461 §5.1.
Identifique se a falha é um MX omitido, um problema de certificado, perdido STARTTLS problemas de suporte ou busca de políticas. Restaurar um MX anteriormente compatível ou reparar seu certificado pode ajudar os remetentes com políticas antigas e novas em cache de forma mais direta do que tentar uma retirada emergencial da política global.
Verifique os registros do remetente afetado, quando disponíveis, e teste todos os candidatos pretendidos. Se um MX compatível permanecer, os remetentes poderão usá-lo. Não presuma que um backup é seguro apenas porque sua preferência DNS tem prioridade mais baixa; ele ainda precisa corresponder à política e passar na validação de transporte.
Escolha reparo ou retirada deliberada
Referências: RFC 8461 §3.2, RFC 8461 §8.1, RFC 8461 §8.3.
Para uma correção, publique o corpo HTTPS corrigido antes de alterar o ID TXT . Mantenha cópias de políticas anteriores e valores max_age disponíveis para calcular o risco de transição. Um corpo atual corrigido não prova que um remetente o obteve.
Para remoção deliberada, a seção 8.3 RFC 8461 recomenda o modo de serviço nenhum com um max_age pequeno (por exemplo, um dia) e a atualização do registro de descoberta, mantendo então a infraestrutura de política relevante até que todas as políticas servidas anteriormente tenham expirado antes de removê-la. Calcule o último horário de exibição de cada versão mais seu próprio max_age e, em seguida, use a última expiração em cada versão. Uma versão mais antiga com vida útil mais longa pode durar mais que a versão imediatamente anterior. Uma política none ainda precisa de version e max_age; linhas mx não são necessárias nesse modo. Use um novo ID válido para anunciar a mudança.
Reproduzir o caso de aplicação obsoleta
Referências: RFC 8461 §3.3, RFC 8461 §5.
Em um remetente controlado, armazene em cache uma política de aplicação que permita apenas mx1.example.net com max_age 86400. Altere DNS público e o HTTPS para uma política none, mas inicialmente impeça que o remetente obtenha a atualização. Tente entregar para mx2.example.net . A antiga política de aplicação válida ainda exclui mx2, apesar do novo corpo none do operador.
Em seguida, permita a atualização e capture o remetente sem aplicar nada ou avance o relógio de teste controlado através do tempo de vida do cache original em um ambiente isolado e seguro. Não altere os relógios na infraestrutura de correio de produção para este teste. Este é um procedimento de laboratório, não executado MTA teste; o novo dispositivo off-line demonstra apenas a aritmética do estado e da última vida útil, não um cache de remetente real.
Fechar com evidências para ambas as coortes
Referências: RFC 8461 §8.3, RFC 8460 §4.1.
Verifique o comportamento de um novo remetente sem política em cache e de um remetente conhecido por manter a revisão obrigatória anterior. Preserve os resultados da fila, busque resultados e metadados de políticas. TLS-RPT pode ajudar a identificar falhas remanescentes, mas a cobertura está incompleta e os relatórios estão atrasados.
Mantenha o host HTTPS e a descoberta disponíveis durante a janela de retirada planejada, monitore o caminho de entrega real e documente a decisão final de remoção. A exclusão de _mta-sts por si só não é uma reversão imediata nem uma estratégia confiável de recuperação de incidentes.
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 cálculo de retirada agora inclui todas as versões veiculadas anteriormente, em vez de apenas a última max_age. No razão lógico executado, A1 foi atendido pela última vez em 1000300 com tempo de vida 86400, B2 em 1000600 com tempo de vida 3600 e C3 em 1000900 com tempo de vida 3600. Seus limites de expiração são 1086700, 1004200 e 1004500, respectivamente. O limite de remoção calculado é, portanto, 1086700. O antigo instantâneo do remetente A1 ainda rejeita o novo nome de host mesmo depois que o laboratório anuncia e busca B2. A restauração da antiga rota compatível permanece significativa para esse instantâneo. Este é um cálculo rotulado de estado e rota, não uma retirada de cache remota observada ou recuperação de mensagem em fila. Uma retirada de produção deve usar os últimos horários reais e todas as versões anteriores.