Porque monitorizar os relatórios TLS-RPT?
A monitorização TLS-RPT torna visíveis as falhas de encriptação SMTP que o seu servidor nunca regista. É o único canal definido por uma norma (RFC 8460) pelo qual os remetentes informam o que quebrou no transporte. Sem ele, um e-mail recusado por um problema de TLS não deixa nenhum rasto do lado do destinatário. A sua reputação degrada-se. Os seus utilizadores não esperam nada porque ignoram que uma mensagem existia.
Três panes voltam em quase todos os relatórios.
Um certificado expirado no MX faz a negociação encriptada falhar, e os remetentes em modo estrito rejeitam a mensagem em vez de entregá-la em texto simples. Uma política MTA-STS que aponta para um MX que sumiu produz o mesmo resultado: ligação recusada, e-mail que nunca chegou. E o pior continua a ser o downgrade de STARTTLS, quando um equipamento de rede retira o anúncio STARTTLS do diálogo SMTP. O correio passa então em texto simples. Ninguém sabe. O relatório TLS-RPT, esse sim, vê.
Como configurar a monitorização TLS-RPT em 3 passos
Passo 1: Adicione o seu domínio
Inicie sessão e adicione o domínio. O CaptainDNS fornece um endereço de email para receber os relatórios do monitor e um URL HTTPS alternativo.
Passo 2: Verifique a propriedade do domínio
Adicione o TXT de verificação do CaptainDNS para comprovar a propriedade do domínio. A verificação do domínio e a ativação não confirmam a receção de relatórios.
Passo 3: Publique o registo TLS-RPT
Consulte a configuração do monitor para publicar o TXT _smtp._tls recomendado com o destino mailto. Verifique os destinatários mantidos antes de substituir um TXT existente. Se a leitura DNS falhar, adicione apenas o fragmento a rua= sem remover outros destinatários, ou tente novamente para obter o valor completo.
O que é TLS-RPT?
O TLS-RPT (SMTP TLS Reporting), definido pela RFC 8460, permite aos remetentes participantes comunicar os resultados das ligações TLS. O TXT indica o destino dos relatórios, sem garantir o envio.
Exemplo de registo DNS:
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt-TOKEN@mailsrv1.captaindns.com"
Exemplo ilustrativo: substitua TOKEN pelo token indicado na configuração do monitor. Para um TXT existente, consulte a recomendação do monitor para verificar os destinatários a manter. O fragmento mailto, por si só, não é um TXT completo.
O que contém um relatório TLS-RPT?
Um relatório TLS-RPT é um documento JSON que agrega, numa janela de 24 horas, todas as tentativas de ligação TLS de um remetente para o seu domínio. Ele conta as sessões bem-sucedidas e as que falharam, e detalha cada falha por tipo. O CaptainDNS descodifica esse JSON e exibe-o de forma legível.
| Campo | Descrição |
|---|---|
| Organização remetente | O fornecedor de e-mail que enviou o relatório |
| Período | Timestamps de início e fim da janela de relatório |
| Políticas aplicadas | Políticas MTA-STS, DANE ou STARTTLS detetadas |
| Sessões bem-sucedidas | Número de ligações TLS estabelecidas com sucesso |
| Sessões com falha | Número de falhas de negociação TLS com detalhes do erro |
Os 11 tipos de falha TLS-RPT (RFC 8460)
O §4.3 da RFC 8460 define 11 valores de result-type, e a monitorização reporta-os todos. Alguns remetentes emitem ainda starttls-not-offered, uma variante de starttls-not-supported alheia à RFC: é tratada da mesma forma.
| Tipo de falha | Descrição |
|---|---|
starttls-not-supported | O servidor destinatário não suporta STARTTLS |
certificate-expired | O certificado TLS apresentado pelo MX expirou |
certificate-host-mismatch | O certificado não corresponde ao nome de host do MX |
certificate-not-trusted | A cadeia de certificados não é fiável para o remetente |
validation-failure | Falha de validação TLS genérica |
tlsa-invalid | O registo DANE TLSA é inválido ou não corresponde |
dnssec-invalid | A cadeia DNSSEC necessária ao DANE está quebrada ou em falta |
dane-required | DANE é necessário, mas não pôde ser validado |
sts-policy-fetch-error | Impossível obter a política MTA-STS (HTTPS ou DNS) |
sts-policy-invalid | A política MTA-STS não pôde ser validada |
sts-webpki-invalid | O host da política MTA-STS tem um certificado Web PKI inválido |
TLS-RPT vs DMARC
| TLS-RPT | DMARC | |
|---|---|---|
| Protege | Encriptação do transporte (SMTP TLS) | Autenticação do remetente (SPF/DKIM) |
| Reporta | Falhas de ligação TLS, erros de certificado | Falhas de alinhamento de autenticação |
| RFC | RFC 8460 | RFC 7489 |
| Registo DNS | _smtp._tls TXT | _dmarc TXT |
| Ameaças detetadas | Certificados expirados, remoção STARTTLS, erros DANE/MTA-STS | Falsificação, phishing, usurpação de domínio |
Os dois protocolos são complementares. Implemente a monitorização DMARC junto com TLS-RPT para visibilidade completa sobre a segurança do e-mail.
Quem envia relatórios TLS-RPT?
Os relatórios provêm de remetentes que suportam TLS-RPT e tentam entregar correio ao domínio. A disponibilidade e a frequência dependem do tráfego e da implementação de cada remetente. Publicar o TXT não garante relatórios de um fornecedor específico.
Casos de uso concretos
A maioria dos incidentes TLS resolve-se numa hora quando os vê, e se arrasta por semanas quando não vê. Veja duas panes reais que a monitorização TLS-RPT trouxe à tona.
Incidente 1: Certificado expirado não detetado
Sintoma: Grandes remetentes (Google, Microsoft) reportam falhas certificate-expired nos seus relatórios TLS-RPT.
Diagnóstico: O painel do CaptainDNS mostra um pico de falhas nas últimas 24h, todas relacionadas a um certificado Let's Encrypt expirado no MX principal. Sem TLS-RPT, o problema teria ficado invisível por semanas.
Ação: Renovar o certificado TLS do servidor de e-mail. Os relatórios seguintes confirmam a resolução.
Incidente 2: Política MTA-STS dessincronizada
Sintoma: Relatórios indicam falhas sts-policy-invalid apesar de uma política MTA-STS publicada.
Diagnóstico: Os relatórios TLS-RPT revelam que a política MTA-STS referencia um servidor MX que já não existe. Remetentes estritos abandonam a entrega sem notificar o destinatário.
Ação: Atualizar a política MTA-STS para refletir os MX atuais.
O CaptainDNS analisa os relatórios recebidos sem servidores para gerir nem JSON para descodificar. O envio depende dos remetentes e do tráfego para o domínio.
FAQ - Perguntas frequentes
P: O que é um registo TLS-RPT?
R: Um registo TLS-RPT é um registo DNS TXT colocado em _smtp._tls.seudominio.com. Ele contém uma diretiva rua= que indica aos servidores remetentes para onde enviar os relatórios de falha TLS (RFC 8460).
P: A monitorização TLS-RPT do CaptainDNS é gratuita?
R: A primeira ferramenta da conta é gratuita. Cada domínio TLS-RPT conta como uma ferramenta: depois, 3 €/mês sem IVA. Sem custos ocultos, sem período experimental.
P: Como configuro o meu domínio para enviar os relatórios para cá?
R: Consulte a configuração do monitor para publicar o TXT _smtp._tls recomendado com o destino mailto. Verifique os destinatários mantidos antes de substituir um TXT existente. Se a leitura DNS falhar, adicione apenas o fragmento a rua= sem remover outros destinatários, ou tente novamente para obter o valor completo.
P: Quais formatos de relatório são aceites?
R: Aceitamos relatórios TLS-RPT JSON definidos pela RFC 8460, com ou sem compressão gzip, por email e HTTPS POST. O email é o destino recomendado; HTTPS continua a ser suportado.
P: Como funciona a verificação de domínio?
R: Adicione o TXT de verificação do CaptainDNS para comprovar a propriedade do domínio. A verificação do domínio e a ativação não confirmam a receção de relatórios.
P: Preciso de MTA-STS para usar TLS-RPT?
R: Não, o TLS-RPT funciona de forma independente. No entanto, combinar MTA-STS com TLS-RPT é recomendado: o MTA-STS impõe a encriptação, e o TLS-RPT informa quando os remetentes não conseguem cumpri-la.
P: Quais os riscos sem TLS-RPT?
R: Sem TLS-RPT, falhas de entrega TLS são completamente invisíveis. Um certificado expirado pode bloquear e-mails de Google e Microsoft por dias. Uma política MTA-STS desatualizada faz remetentes rejeitarem as suas ligações em silêncio. Só descobre o problema quando alguém reclama, tarde demais.
P: Com que frequência os relatórios chegam?
R: Os remetentes que suportam TLS-RPT enviam geralmente relatórios por períodos de 24 horas. A receção depende desses remetentes e do tráfego. Não há um prazo garantido para o primeiro relatório; os relatórios recebidos são depois analisados no painel.
P: Quais tipos de falha TLS o TLS-RPT reporta?
R: O TLS-RPT cobre os 11 tipos de falha definidos na RFC 8460: starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, tlsa-invalid, dnssec-invalid, dane-required, sts-policy-fetch-error, sts-policy-invalid e sts-webpki-invalid. Cada tipo indica um problema específico na cadeia de negociação TLS ou validação de política.
P: Qual é a diferença entre TLS-RPT e DMARC?
R: TLS-RPT e DMARC protegem camadas diferentes. DMARC (RFC 7489) verifica a autenticação do remetente por alinhamento SPF e DKIM e combate falsificação e phishing. TLS-RPT (RFC 8460) monitoriza a encriptação do transporte e reporta quando ligações SMTP TLS falham, certificados expiram ou STARTTLS é rebaixado. Ambos são essenciais.
Ferramentas complementares
| Ferramenta | Utilidade |
|---|---|
| Verificação de sintaxe TLS-RPT | Validar a sintaxe de um registo TLS-RPT |
| Verificação de registo TLS-RPT | Verificar o registo TLS-RPT DNS do seu domínio |
| Gerador TLS-RPT | Gerar um registo DNS TLS-RPT |
| Leitor de relatórios TLS-RPT | Analisar manualmente um relatório JSON TLS-RPT |
| Alojamento MTA-STS | Alojar a sua política MTA-STS (primeira ferramenta gratuita, depois 3 €/mês sem IVA) |
| Monitorização DMARC | Monitorizar e analisar relatórios agregados DMARC |
Recursos úteis
- RFC 8460 - SMTP TLS Reporting: Especificação oficial TLS-RPT
- RFC 8461 - MTA-STS: Padrão complementar para impor encriptação SMTP
- Google: Configurar relatórios TLS: Guia do Google Workspace para TLS-RPT