Um verificador de transporte pode descobrir um problema real sem provar a segurança de cada mensagem que sua organização envia ou recebe. A maioria das verificações observa um endpoint selecionado em um determinado momento usando um determinado resolvedor e método de validação. Um resultado defensável inclui, portanto, escopo e cobertura ausente, e não apenas um crachá de aprovação.
Definir a rota de entrega do estoque
Referências: RFC 8461 §3.4, RFC 8461 §5.1, RFC 7672 §2.2.
Liste os domínios de destinatários, nomes de host MX , prioridades, endereços IPv4 e IPv6 , gateways hospedados e rotas de failover. Observe se o teste segue o roteamento MX comum ou um host inteligente configurado explicitamente. Registre a implementação do remetente e se ela suporta MTA-STS, DANE ou uma política local de TLS obrigatório. Diferentes sistemas de envio podem tomar decisões diferentes para o mesmo domínio de recebimento.
Em seguida, defina a afirmação que cada verificação pode suportar. Uma solicitação HTTPS pública pode estabelecer a disponibilidade da política a partir desse ponto de vista. Uma investigação TLS pode observar um certificado apresentado em um endereço escolhido. Uma consulta DNS de validação pode fornecer evidências sobre DNSSEC status sob um modelo de confiança do resolvedor especificado. Ninguém por si só prova que um verdadeiro envio MTA usou os mesmos dados e aplicou a política de entrega esperada.
Capture o estado em vez de apenas resultados
Referências: RFC 8461 §3.3, RFC 8461 §4, RFC 7672 §3.
Para MTA-STS , retenha o registro de descoberta, os bytes exatos da política HTTPS, o tempo de recuperação, o modo, o tempo de vida e o estado do cache do remetente. Para DANE , mantenha o MX e TLSA respostas, estado de validação e comparação de associação. Para cada conexão SMTP , capture o host e o IP selecionados, STARTTLS negociação, resultado da verificação por pares e decisão de entrega. Seções 3–5 RFC 8461, Seções 2–3 RFC 7672.
Uma análise com falha deve registrar seu estágio de falha. Tempo limite DNS , tempo limite de TCP, ausência STARTTLS , falha de handshake e incompatibilidade de certificado não são descobertas intercambiáveis. Um handshake bem-sucedido também não estabelece que o remetente recusaria uma conexão futura com downgrade. Incluir casos negativos controlados quando autorizado, especialmente antes de permitir uma exigência estrita de transporte.
Supere uma lacuna de cobertura
Neste exemplo de inventário sintético, mx1.example.net possui rotas IPv4 e IPv6 e mx2.example.net é um backup. Uma observação de amostra cobre apenas o endereço IPv4 do mx1. O inventário deve marcar o IPv6 e as rotas de backup como não testadas, em vez de propagar o sucesso em todas as três. A observação é explicitamente sintética e não pretende ter uma conexão real.
Adicione uma linha de aceitação do lado do remetente para um MTA de suporte usando uma política de aplicação válida, outra com um cache vazio e um remetente compatível com DANE com TLSA validado. Essas linhas permanecem pendentes até que os logs reais sejam capturados. Isto torna o plano de aceitação útil sem apresentar os resultados esperados como medições. Ele também permite que um respondente de incidentes veja se a rota com falha já foi exercida.
Reconciliar relatórios e evidências operacionais
Referências: RFC 8460 §4.1, RFC 8460 §4.2.
TLS-RPT os relatórios podem revelar falhas observadas pelos remetentes participantes durante um período de relatório, complementando as investigações pontuais. Suas contagens de sessões não são contagens de mensagens únicas e sua cobertura não é universal. Um período de relatório tranquilo não prova que todas as rotas foram bem-sucedidas, e repetidas tentativas podem complicar as estimativas de impacto nos negócios. Seção 4.4 RFC 8460.
Mantenha o resultado bruto, carimbo de data/hora, versão da ferramenta ou comando e a conclusão mais restrita que você tirou dele. Teste novamente após renovação de certificado, migração MX , alterações DNSSEC e atualizações de políticas. O pacote de revisão inclui sete transcrições de loopback retidas de 7 de novembro de 2026, com bytes de certificado de mesmo nível para as quatro sessões que alcançaram a captura do certificado. Eles cobrem um cliente/servidor Python IPv4 local em portas geradas com confiança explicitamente configurada e entradas de política, não Internet SMTP , uma cadeia de validação DNSSEC , filas de produção MTA ou conformidade total com perfil de certificado MTA-STS . As sessões históricas foram inspecionadas, mas não reproduzidas aqui. Os exemplos de caminhos de Internet IPv4 , IPv6 e de backup permanecem não testados; nenhum herda um passe local. O modelo de cobertura offline recém-executado apenas verifica se uma rota sintética observada deixa as outras rotas listadas não testadas. Capture o MTA pretendido e as observações de roteamento antes de reivindicar a garantia de implantação.