Ferramentas de Diagnóstico de Rede
Política de relatórios de TLS do SMTP
DNS e Registros
Consulta DNS Todos os registros DNS de qualquer domínio Consulta de Registro A Endereços IPv4 de um domínio Consulta de Registro AAAA Endereços IPv6 de um domínio Consulta MX Servidores de e-mail de um domínio Consulta NS Servidores de nomes autoritativos Consulta TXT Registros TXT, SPF, verificação Consulta CNAME Registros de nome canônico (alias) Consulta SOA Registro Start of Authority Consulta SRV Registros de localização de serviço Consulta CAA Quais ACs podem emitir certificados DNS Reverso (PTR) Endereço IP para hostname Verificação DNSSEC O domínio está assinado e validado? Diagnóstico de DNS Um relatório completo de delegação e DNSEntregabilidade de E-mail
Verificação SPF Valide seu registro Sender Policy Framework Verificação DMARC Inspecione e avalie sua política DMARC Verificação DKIM Encontre e valide sua chave pública DKIM Verificação de Blacklist Verifique um IP em listas de bloqueio de e-mail (DNSBLs) Teste SMTP Conecte-se a um servidor de e-mail e verifique o STARTTLS Verificação MTA-STS Política de TLS obrigatório para e-mail de entrada Verificação BIMI Registro de logotipo da marca para e-mail Verificação TLS-RPT Política de relatórios de TLS do SMTPRede e Web
Verificação de Certificado SSL Inspecione o certificado TLS e a validade de um site Verificação de Cabeçalhos HTTP Inspecione cabeçalhos de resposta, redirecionamentos e segurança Ping (TCP) Acessibilidade e latência por TCP Verificação de Portas Quais portas comuns estão abertasDomínio
Consulta WHOIS Dados de registro de domínios, IPs e ASNsO TLS-RPT (SMTP TLS Reporting) permite que um domínio receba relatórios diários sobre falhas de conexão TLS dos servidores de envio, para que você detecte e-mails sendo entregues de forma insegura. O IPeek lê o registro TXT _smtp._tls e mostra os destinos dos relatórios. Ele complementa o MTA-STS e o DANE dando visibilidade sobre como essas políticas se comportam na prática.
O TLS-RPT é publicado como um único registro TXT do DNS em _smtp._tls.seu-dominio. O registro contém uma tag de versão e uma tag rua= que lista para onde os relatórios devem ser enviados, seja um endereço mailto ou um endpoint HTTPS. Os servidores de envio que suportam o padrão agregam os resultados de suas negociações TLS com seus hosts MX ao longo de um dia e entregam um relatório JSON a esses destinos. Cada relatório conta sessões bem-sucedidas e falhas e categoriza as falhas, como erros de validação de certificado ou indisponibilidade de STARTTLS, dando a você um ciclo de feedback sobre a entrega real.
O IPeek confirma se o registro TXT _smtp._tls existe e mostra os destinos rua que ele analisa. Verifique se a versão é TLSRPTv1 e se cada alvo rua é uma caixa de correio ou URL HTTPS válida que você realmente monitora. O registro em si não impõe nada; ele apenas solicita relatórios, então sua presença significa que os remetentes sabem para onde enviar os dados de falha de TLS. Quando os relatórios chegarem, observe os tipos de falha: certificate-expired, falhas de validação e starttls-not-supported apontam cada um para uma correção específica na sua infraestrutura de recebimento antes que causem problemas silenciosos de entrega.
O MTA-STS e o DANE impõem TLS no e-mail de entrada, mas a imposição só é segura se você puder ver o que ela faz com o tráfego real. O TLS-RPT fornece essa visibilidade: quando você implanta o MTA-STS no modo testing, os relatórios revelam quais remetentes encontram falhas de TLS antes de você mudar para enforce. O mesmo vale para incompatibilidades de TLSA do DANE. Trate o TLS-RPT como a camada de monitoramento da sua postura de TLS, implantada junto com, e não no lugar de, os mecanismos de imposição, para que você detecte problemas de certificado e configuração cedo.
É um registro TXT publicado em _smtp._tls.seu-dominio que solicita relatórios de falhas de TLS. O registro contém uma tag de versão v=TLSRPTv1 e uma tag rua= especificando para onde os relatórios vão, como um endereço mailto ou uma URL HTTPS. Os servidores de envio que suportam TLS-RPT o usam para saber para onde entregar seus relatórios agregados diários sobre conexões TLS com seu domínio.
Um relatório TLS-RPT é um documento JSON que resume um dia de negociações TLS entre um servidor de envio e seus hosts MX. Ele conta sessões bem-sucedidas e falhas e detalha as falhas por tipo, como certificados expirados, erros de validação de certificado ou indisponibilidade de STARTTLS. Isso permite identificar quais hosts de recebimento ou certificados estão causando entregas inseguras ou com falha.
Não. O TLS-RPT é puramente um mecanismo de relatório e não impõe nada por si só. A imposição vem do MTA-STS ou do DANE, que exigem TLS e podem bloquear a entrega insegura. O TLS-RPT fica ao lado dessas políticas como uma camada de monitoramento, dando visibilidade sobre com que frequência o TLS tem sucesso ou falha para que você implante a imposição com confiança.
Publique um registro TXT em _smtp._tls.seu-dominio contendo v=TLSRPTv1 e uma tag rua= apontando para uma caixa de correio ou endpoint HTTPS que você monitora, por exemplo rua=mailto:tlsrpt@seu-dominio. Escolha um destino que você realmente acompanhe, já que os relatórios chegam diariamente em JSON. Combine-o com MTA-STS ou DANE para que os relatórios descrevam como sua política de TLS imposta está se comportando.
O TLS-RPT fornece a visibilidade que torna seguro implantar o MTA-STS. Quando você publica uma política MTA-STS no modo testing, os servidores de envio reportam quaisquer falhas de TLS pelo TLS-RPT, então você vê quais remetentes seriam bloqueados antes de mudar para enforce. Os dois foram projetados para trabalhar juntos: o MTA-STS define a política e o TLS-RPT informa como ela está se comportando na prática.