MTA-STS as falhas dizem respeito à segurança do transporte do correio de entrada. Eles não são reparados alterando SPF ou DKIM. Diagnosticar a cadeia na ordem: descoberta de políticas em DNS , recuperação de políticas em HTTPS, os nomes MX permitidos e o comportamento TLS dos servidores de recebimento.
Identifique a observação de envio afetada
Colete o erro de entrega do remetente, a hora, o domínio de destino e o relatório TLS disponível. Separe o resultado de um único remetente de uma interrupção universal. Os remetentes podem ter armazenado em cache diferentes versões de políticas e as implementações diferem em seu suporte. Registre o identificador da política atual, corpo, modo e max_age junto com qualquer política anteriormente ativa que você possa recuperar.
RFC 8461 define a descoberta em _mta-sts para o domínio de recebimento e a recuperação HTTPS em https://mta-sts.<domain>/.well-known/mta-sts.txt. Confira o publicado Registro TXT e o URL exato do domínio real. Certifique-se de que o endpoint HTTPS apresente um certificado confiável para seu nome de host e atenda a uma política válida. RFC 8461 Seção 3.3 requer HTTP 200 e proíbe seguir redirecionamentos HTTP 3xx ao buscar a política. Uma visita bem-sucedida do navegador à página inicial não estabelece esse comportamento do endpoint.
Compare a política com o roteamento MX real
Inspecione o público do domínio de destino Registros MX e compare seus nomes de host com os padrões mx da política. Teste cada host receptor ativo, incluindo um backup que normalmente recebe pouco tráfego. Um backup recém-adicionado fora do padrão permitido pode criar falhas intermitentes em vez de uma interrupção total limpa.
Para cada host MX , verifique SMTP STARTTLS, validade do certificado, cadeia de confiança e correspondência de identidade para o nome do host MX . Mantenha o certificado de política da web e os certificados do servidor SMTP separados na investigação: reparar um não repara o outro. Use uma ferramenta de diagnóstico TLS adequada de um local de teste autorizado e retenha os detalhes da conexão sem transmitir mensagens ou credenciais reais desnecessariamente.
Interpretar o modo e o cache corretamente
O modo de teste não exige rejeição em caso de falha de validação MTA-STS ; outros controles de entrega ainda podem recusar a mensagem. O modo de aplicação aplica seu requisito de validação quando o remetente possui uma política aplicável. Um remetente obrigatório com uma política em cache aplicável pode continuar a exigir essa política mesmo que o registro de descoberta DNS seja removido posteriormente. A remoção de um site quebrado não é, portanto, uma reversão instantânea confiável.
Quando uma política for alterada, atualize o identificador de descoberta para que os remetentes de suporte possam detectar a alteração. Planeje alterações em torno do tempo de vida do cache publicado. Para uma retirada planejada, use o procedimento modo nenhum da RFC e permita políticas em cache em vez de tratar a exclusão DNS como cancelamento imediato. Mantenha o ponto final da política disponível durante as transições onde os remetentes ainda precisam dele.
Trabalhe uma falha através da cadeia
Caso ilustrativo: example.org anuncia primary.example.org e backup.example.net como hosts MX , mas a política MTA-STS permite apenas primary.example.org . O correio normalmente é bem-sucedido até que o backup seja selecionado. A primeira correção a ser investigada é a incompatibilidade entre a rota de recebimento pretendida e a política, e não o remetente Registro SPF. Verifique se o backup está autorizado e compatível com TLS antes de adicioná-lo. Este é um cenário sintético, não um teste de domínio ativo.
Crie uma linha de diagnóstico contendo tempo de observação, fonte de envio, versão da política, se conhecida, MX selecionado, erro TLS , alteração pretendida e resultado da verificação. Os relatórios TLS podem revelar categorias e padrões, mas a sua cobertura não é completa e a ausência de relatórios não é prova de que todos os remetentes tenham sucesso.
Restaure o serviço sem esconder a causa
Prefira reparar o certificado real, o endpoint ou a incompatibilidade de roteamento. Se for necessária uma flexibilização da política, obtenha a aprovação da alteração relevante, documente a exposição temporária e leve em conta os caches. Após o reparo, verifique cada caminho MX e examine as observações subsequentes do remetente e os relatórios TLS . Mantenha o monitoramento de expiração de certificados HTTPS e SMTP e inclua a política MTA-STS em todas as listas de verificação de migração de provedores de e-mail.
Mantenha o histórico do cache na decisão de retirada
RFC 8461 Seção 8.3 descreve o modo de publicação nenhum com uma vida útil curta e um registro de descoberta alterado, mantendo então os endpoints até que todas as políticas atendidas anteriormente expirem. Inclui políticas mais antigas cujo max_age mais longo pode sobreviver à versão imediatamente anterior. A exclusão DNS não apaga esses caches. A Seção 3.3 distingue uma busca recente com falha sem cache utilizável de uma busca com falha com uma política de cache válida. RFC 8460 Seções 4.2 e 4.3 descreve sessões relatadas e tipos de falha, não um registro completo de entrega por mensagem. Nenhuma conexão, pesquisa ou migração TLS foi executada para este cenário de ensino.