TLS-RPT Generator

Como usar este gerador TLS-RPT

Passo 1: Adicionar destinos de relatório

Indique onde pretende receber os relatórios de falhas de TLS:

Email (recomendado para começar)

mailto:tlsrpt@captaindns.com

Webhook HTTPS (para automação)

https://tlsrpt.captaindns.com/v1/report

Você pode adicionar vários destinos: os relatórios são enviados para todos.

Passo 2: Copiar o registro gerado

O gerador cria um registro RFC 8460 válido:

v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Passo 3: Publicar no DNS

Crie um registro TXT em _smtp._tls.captaindns.com com o valor gerado.

Exemplo para captaindns.com:

• Tipo: TXT
• Host: _smtp._tls
• Valor: v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Passo 4: Verificar a publicação

Use o nosso TLS-RPT Checker para confirmar que a configuração está correta.

O que o TLS-RPT realmente relata

O TLS-RPT é uma ferramenta de observabilidade pura: nunca altera o comportamento de um servidor, revela o que realmente aconteceu durante as conexões TLS de entrada para os seus MX.

Os operadores emissores informam a você, em especial:

• um downgrade ou stripping de STARTTLS, em que a sessão volta a texto claro
• um certificado expirado, não confiável ou autoassinado
• um certificado cujo hostname não corresponde ao MX esperado
• a falha na obtenção ou validação de uma política MTA-STS
• uma falha DANE: registro TLSA inválido ou cadeia DNSSEC quebrada

O TLS-RPT não aplica nenhuma regra. A recusa em entregar uma mensagem em texto claro vem do MTA-STS ou do DANE; o TLS-RPT limita-se a dizer para você quando e por que a criptografia falhou, para que você possa corrigir antes de passar a enforce.

Formato do registro TLS-RPT

Componentes obrigatórios

Esquemas de URI suportados

mailto: - Entrega por email

rua=mailto:equipe-seguranca@captaindns.com

Os relatórios chegam como anexos JSON comprimidos.

https: - Entrega por webhook

rua=https://api.captaindns.com/tlsrpt/ingest

Os relatórios são enviados via POST, em formato JSON, com o cabeçalho Content-Type: application/tlsrpt+gzip

Múltiplos destinos

Separe-os por vírgulas:

v=TLSRPTv1; rua=mailto:reports@captaindns.com,https://tlsrpt.captaindns.com/report

Enviar os relatórios para um domínio terceiro

Uma rua que aponta para um domínio diferente do seu funciona tal como está, sem qualquer registro de autorização do lado do destinatário.

Esta é uma diferença importante em relação ao DMARC. O DMARC exige um registro _report._dmarc no domínio terceiro antes de aceitar relatórios cross-domain. A RFC 8460 afastou deliberadamente esse mecanismo (seção 7): o risco de amplificação com o TLS-RPT é menor do que com o DMARC e a confiança é assegurada de outra forma. Os relatórios mailto: são assinados com DKIM pelo operador emissor, e os relatórios https: se apoiam na posse do DNS e do certificado do endpoint.

v=TLSRPTv1; rua=mailto:reports@tlsrpt-service.com

Não é necessária qualquer ação em tlsrpt-service.com para que esta rua seja válida.

Para manter a simplicidade, um endereço no seu próprio domínio é suficiente na maioria dos casos:

v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Exemplos por provedor de DNS

Cloudflare

1. Acesse as configurações de DNS do seu domínio
2. Adicione um registro:
   • Tipo: TXT
   • Nome: _smtp._tls
   • Conteúdo: o valor do registro gerado
   • TTL: Auto

AWS Route 53

1. Abra a zona hospedada do seu domínio
2. Crie um registro:
   • Nome do registro: _smtp._tls
   • Tipo de registro: TXT
   • Valor: "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"
   • TTL: 3600

OVH / Google Domains

1. Acesse a zona DNS
2. Adicione uma entrada:
   • Subdomínio: _smtp._tls
   • Tipo: TXT
   • Destino: o valor do registro gerado
   • TTL: 3600

Compreender os relatórios TLS-RPT

Um relatório TLS-RPT é um documento JSON agregado, comprimido com gzip, que resume as sessões TLS de um operador para o seu domínio ao longo de um dia.

Anatomia de um relatório

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2024-01-15T00:00:00Z",
    "end-datetime": "2024-01-16T00:00:00Z"
  },
  "contact-info": "postmaster@google.com",
  "report-id": "2024011512345",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce", "mx: mail.captaindns.com", "max_age: 604800"],
      "policy-domain": "captaindns.com"
    },
    "summary": {
      "total-successful-session-count": 8432,
      "total-failure-session-count": 3
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "198.51.100.1",
      "receiving-mx-hostname": "mail.captaindns.com",
      "failed-session-count": 3
    }]
  }]
}

Os tipos de falha (result-type)

O registro IANA define 11 valores possíveis para result-type:

Os tipos de política (policy-type)

Cada sessão está associada a um dos 3 policy-type:

Transporte e cadência

Todos os relatórios são comprimidos com gzip. Existem dois canais de entrega, conforme o esquema da sua rua:

• HTTPS: o relatório é enviado via POST com o cabeçalho Content-Type: application/tlsrpt+gzip (ou application/tlsrpt+json). O endpoint confirma a recepção com um estado 2xx.
• Email: a mensagem é um multipart/report; report-type="tlsrpt" com um anexo application/tlsrpt+gzip. Inclui os cabeçalhos TLS-Report-Domain e TLS-Report-Submitter, um assunto da forma Report Domain: captaindns.com Submitter: google.com Report-ID: 2024011512345, e é assinada com DKIM com o seletor s=tlsrpt.

Cadência: cada operador emissor envia um relatório agregado por dia, cobrindo a janela das 00:00 às 24:00 UTC. Em caso de falha de entrega, tenta de novo até 24 horas.

Quem envia os relatórios

Os grandes operadores emitem relatórios TLS-RPT: o Google, a Microsoft e o Yahoo fazem isso sistematicamente; a Apple e a Comcast também já foram reportadas. Cada operador produz o seu próprio relatório independente, portanto você pode receber vários por dia, um por emissor.

TLS-RPT com MTA-STS e DANE

O TLS-RPT é o ciclo de observabilidade do MTA-STS e do DANE. Estes protocolos impõem a criptografia; o TLS-RPT mostra a você o efeito dessa imposição, antes e depois da entrada em produção.

Ordem de implementação recomendada

1. Publicar o TLS-RPT, e o MTA-STS em mode: testing
2. Analisar os relatórios durante 2 a 4 semanas
3. Passar o MTA-STS para mode: enforce
4. Continuar o monitoramento via TLS-RPT

Passar a enforce sem TLS-RPT é avançar às cegas: se uma política quebrar a entregabilidade, você só saberá pelas queixas dos usuários.

Ferramentas relacionadas

• Gerar uma política MTA-STS
• Verificar o estado MTA-STS
• Verificar o estado TLS-RPT
• Verificar os registros DANE TLSA

Boas práticas e armadilhas comuns

Boas práticas

• Aponte a rua para uma caixa ou endpoint dedicado, capaz de absorver o volume e de analisar o JSON. Nunca uma caixa humana: os relatórios chegam todos os dias, em JSON comprimido com gzip, de cada operador.
• Use uma ferramenta de agregação para transformar estes relatórios em tendências acionáveis, em vez de abri-los um a um.

Armadilhas a evitar

• Dois registros TXT em _smtp._tls tornam a configuração inválida. Mantenha um único registro com um único valor.
• Aplique percent-encoding aos caracteres ,, ! e ; quando aparecem numa URI (por exemplo num mailto: com parâmetros), caso contrário o parsing do registro quebra.

Casos de uso concretos

Cada cenário abaixo traduz-se num result-type preciso nos seus relatórios:

• Um MX de backup nunca configurado para TLS: starttls-not-supported. Detecte-o antes que um atacante tire proveito disso.
• O certificado de um parceiro expirou: certificate-expired nas sessões em causa.
• Um MX apresenta um certificado emitido para o hostname errado: certificate-host-mismatch.
• Um downgrade ativo de STARTTLS (ataque na rede) faz cair as sessões criptografadas: pico de starttls-not-supported.
• A sua própria política MTA-STS está quebrada ou inacessível: sts-policy-fetch-error ou sts-policy-invalid, antes que bloqueie e-mails legítimos.
• Um DANE mal configurado: tlsa-invalid (TLSA que deixou de corresponder após uma rotação de certificado) ou dnssec-invalid (cadeia DNSSEC quebrada).

Ferramentas complementares

Recursos úteis

• RFC 8460 - SMTP TLS Reporting (especificação oficial)
• RFC 8461 - MTA-STS (protocolo complementar)
• Google - Configurar TLS reporting
• Postfix - Documentação TLS