Ferramentas de Diagnóstico de Rede
Política de TLS obrigatório para e-mail de entrada
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 MTA-STS permite que um domínio exija que o e-mail de entrada seja entregue por TLS autenticado, defendendo contra ataques de downgrade e man-in-the-middle. O IPeek lê o registro TXT _mta-sts e busca o arquivo de política publicado em mta-sts.seu-dominio. Ele fecha a brecha deixada pelo STARTTLS oportunista, que um atacante pode remover silenciosamente.
O MTA-STS usa duas partes. Um registro TXT em _mta-sts.seu-dominio contém uma versão e um ID de política que diz aos servidores de envio que existe uma política e muda quando você a atualiza. A política em si fica em um arquivo de texto puro servido por HTTPS em https://mta-sts.seu-dominio/.well-known/mta-sts.txt. Esse arquivo lista a versão, o modo, os hostnames MX permitidos e um tempo de vida de cache max_age. Um remetente que suporta MTA-STS busca e armazena em cache a política, depois se recusa a entregar a qualquer MX cujo certificado não valide contra ela.
O IPeek mostra se o registro TXT _mta-sts existe e se o arquivo de política está acessível por HTTPS. O valor do modo é o que mais importa. none significa que nenhuma política está em vigor, testing significa que as falhas são reportadas mas o e-mail ainda flui, e enforce significa que um remetente deve abortar a entrega se a autenticação TLS falhar. Verifique se as entradas mx na política correspondem aos seus registros MX reais e se o certificado HTTPS no host da política é válido. Um max_age alto, frequentemente 604800 segundos, melhora a proteção porque políticas em cache resistem a adulteração ao vivo.
O erro mais comum é um registro TXT que existe enquanto o arquivo de política retorna um 404 ou um redirecionamento, o que torna a política inutilizável. O host da política deve servir HTTPS válido, então um certificado expirado ou incompatível em mta-sts.seu-dominio quebra a imposição por completo. Entradas MX que ficam fora de sincronia com seu DNS causam falhas de entrega assim que você muda para enforce. Implemente primeiro em testing, monitore os relatórios TLS-RPT em busca de falhas e só passe para enforce após confirmar que cada MX apresenta um certificado válido e correspondente.
No modo testing, os remetentes que detectam uma falha de TLS ainda entregam o e-mail mas reportam o problema, permitindo que você encontre falhas sem bloquear o tráfego. No modo enforce, um remetente deve abortar a entrega a qualquer MX cujo certificado falhe na validação. Comece em testing, acompanhe seus relatórios TLS-RPT e mude para enforce apenas quando nenhuma falha aparecer.
O arquivo de política é servido por HTTPS em https://mta-sts.seu-dominio/.well-known/mta-sts.txt, em um subdomínio chamado mta-sts. O registro TXT do DNS em _mta-sts.seu-dominio apenas anuncia que existe uma política e carrega um ID; as regras de fato, incluindo o modo e os hosts MX permitidos, ficam nesse arquivo HTTPS. Ambos precisam estar presentes e válidos para o MTA-STS funcionar.
O STARTTLS é oportunista: ele oferece criptografia, mas um atacante na rede pode remover o anúncio de STARTTLS e forçar a entrega em texto puro, sem ser detectado. O MTA-STS adiciona uma política publicada que diz aos remetentes que o TLS é obrigatório e em quais certificados MX confiar, então uma conexão TLS removida ou inválida faz a entrega falhar em vez de fazer um downgrade silencioso. Ele reforça o STARTTLS contra ataques de downgrade.
Não. O MTA-STS deliberadamente depende de HTTPS e da PKI da web para sua confiança, e não do DNSSEC, o que o torna mais fácil de implantar do que o DANE. O certificado HTTPS do arquivo de política fornece a autenticação. Se seu domínio já tem DNSSEC, você pode executar o DANE junto com o MTA-STS, já que os dois mecanismos se complementam em vez de entrar em conflito.
Publique primeiro o registro TXT e o arquivo de política no modo testing, depois habilite o TLS-RPT para que os servidores de envio enviem por e-mail relatórios de quaisquer falhas de TLS. Confirme que seus hostnames MX na política correspondem ao DNS e que cada MX apresenta um certificado válido. Quando os relatórios não mostrarem falhas durante um ciclo normal de relatório, mude o modo para enforce e atualize o ID da política.