Ir para o conteúdo principal

Monitorização TLS-RPT: 1 domínio grátis, monitorização contínua a partir de 3 €/mês

Detete falhas TLS e analise os seus relatórios de encriptação SMTP automaticamente

Todos os dias, e-mails desaparecem silenciosamente: certificado TLS expirado, extensão STARTTLS removida, política MTA-STS mal configurada. Sem alertas, sem rasto. TLS-RPT (RFC 8460) foi criado para tornar visíveis essas falhas invisíveis. O CaptainDNS recebe os seus relatórios SMTP TLS automaticamente, analisa e apresenta os resultados de forma clara. Adicione o seu domínio e nós cuidamos do resto.

Principais funcionalidades da ferramenta

Receção automática

Os relatórios são recebidos e analisados automaticamente. Nenhum servidor para gerir, nenhum JSON para descodificar. Adicione o registo DNS e pronto.

Verificação de domínio

Um registo TXT de verificação comprova a propriedade do domínio. Adicione-o ao seu DNS e a validação é automática.

Análise detalhada

Consulte os contadores de sucesso e falha TLS, os detalhes de política e os endereços IP de origem para cada período de relatório.

Coletor de relatórios dedicado

Cada domínio recebe um endpoint HTTPS exclusivo. O registo DNS TLS-RPT é gerado automaticamente com a URL rua= correta.

Múltiplos domínios

Monitorize os relatórios TLS-RPT de vários domínios a partir de uma única conta. Cada domínio possui o seu próprio coletor de relatórios verificado.

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

Faça login e registe o domínio a ser monitorizado. O CaptainDNS gera um coletor de relatórios HTTPS exclusivo e o registo DNS TLS-RPT correspondente.

Passo 2: Verifique a propriedade do domínio

Adicione o registo TXT de verificação ao seu DNS. A validação é automática assim que o registo for detetado.

Passo 3: Publique o registo TLS-RPT

Adicione o registo TXT _smtp._tls fornecido ao seu DNS. Os servidores remetentes começarão a enviar relatórios de falha TLS para o seu endpoint CaptainDNS.


O que é TLS-RPT?

TLS-RPT (SMTP TLS Reporting) é um padrão definido pela RFC 8460 que faz os remetentes reportarem ao domínio destinatário cada negociação TLS que falha. Os servidores remetentes sinalizam toda a ligação encriptada que não se completa. Um único registo DNS basta para acioná-los.

Exemplo de registo DNS:

_smtp._tls.captaindns.com.  IN  TXT  "v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/abc123"

O registo _smtp._tls indica aos servidores remetentes para onde enviar os seus relatórios JSON quando uma ligação TLS falha com o seu domínio.


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.

CampoDescrição
Organização remetenteO fornecedor de e-mail que enviou o relatório
PeríodoTimestamps de início e fim da janela de relatório
Políticas aplicadasPolíticas MTA-STS, DANE ou STARTTLS detetadas
Sessões bem-sucedidasNúmero de ligações TLS estabelecidas com sucesso
Sessões com falhaNú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 falhaDescrição
starttls-not-supportedO servidor destinatário não suporta STARTTLS
certificate-expiredO certificado TLS apresentado pelo MX expirou
certificate-host-mismatchO certificado não corresponde ao nome de host do MX
certificate-not-trustedA cadeia de certificados não é fiável para o remetente
validation-failureFalha de validação TLS genérica
tlsa-invalidO registo DANE TLSA é inválido ou não corresponde
dnssec-invalidA cadeia DNSSEC necessária ao DANE está quebrada ou em falta
dane-requiredDANE é necessário, mas não pôde ser validado
sts-policy-fetch-errorImpossível obter a política MTA-STS (HTTPS ou DNS)
sts-policy-invalidA política MTA-STS não pôde ser validada
sts-webpki-invalidO host da política MTA-STS tem um certificado Web PKI inválido

TLS-RPT vs DMARC

TLS-RPTDMARC
ProtegeEncriptação do transporte (SMTP TLS)Autenticação do remetente (SPF/DKIM)
ReportaFalhas de ligação TLS, erros de certificadoFalhas de alinhamento de autenticação
RFCRFC 8460RFC 7489
Registo DNS_smtp._tls TXT_dmarc TXT
Ameaças detetadasCertificados expirados, remoção STARTTLS, erros DANE/MTA-STSFalsificaçã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 grandes fornecedores de e-mail emitem relatórios TLS-RPT assim que tentam uma ligação TLS para o seu domínio. Sozinhos, Google e Microsoft entregam a maior parte do correio recebido por um domínio profissional típico. Recebe e-mail de algum deles? Então um registo TLS-RPT publicado já lhe dá uma cobertura útil.

  • Google (Gmail, Workspace): Envia relatórios agregados diários cobrindo todas as tentativas de ligação
  • Microsoft (Outlook, Exchange Online): Reporta falhas de negociação TLS para os clientes Microsoft 365
  • Yahoo: Fornece dados TLS-RPT para a infraestrutura Yahoo Mail e AOL
  • Apple (iCloud Mail): Reporta falhas TLS para a entrega do iCloud Mail
  • Comcast: Um dos primeiros ISPs a implementar o reporting TLS-RPT

Publique um registo TLS-RPT e esses fornecedores começam a reportar automaticamente. Não é preciso inscrever-se junto de cada fornecedor.


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.

Nos dois casos, o gatilho é o mesmo: um relatório TLS-RPT lido na hora certa. Adicione o seu domínio ao CaptainDNS, publique o registo _smtp._tls, e esses sinais chegam ao seu painel sem nenhum servidor para gerir.


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: Adicione um registo TXT em _smtp._tls.seudominio.com com o valor v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/{seu-token}. O registo exato é fornecido quando adiciona o seu domínio.


P: Quais formatos de relatório são aceites?

R: Aceitamos relatórios TLS-RPT no formato JSON conforme definido pela RFC 8460, comprimidos (gzip) ou não. Os relatórios são aceites via HTTPS POST.


P: Como funciona a verificação de domínio?

R: Adiciona um registo TXT de verificação fornecido pelo CaptainDNS ao seu DNS. Assim que for detetado, a propriedade do domínio é confirmada e a monitorização dos relatórios é ativada.


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 relatórios são analisados e disponibilizados no seu painel em poucos segundos após a receção. A maioria dos fornecedores de e-mail envia relatórios diariamente.


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

FerramentaUtilidade
Verificação de sintaxe TLS-RPTValidar a sintaxe de um registo TLS-RPT
Verificação de registo TLS-RPTVerificar o registo TLS-RPT DNS do seu domínio
Gerador TLS-RPTGerar um registo DNS TLS-RPT
Leitor de relatórios TLS-RPTAnalisar manualmente um relatório JSON TLS-RPT
Alojamento MTA-STSAlojar a sua política MTA-STS (primeira ferramenta gratuita, depois 3 €/mês sem IVA)
Monitorização DMARCMonitorizar e analisar relatórios agregados DMARC

Recursos úteis