Gerador de Registro TLS-RPT

TLS-RPT: visibilidade sobre falhas de criptografia no SMTP de saída

O TLS-RPT (SMTP TLS Reporting) é o canal de relatórios que complementa o MTA-STS e o DANE, definido pela IETF na RFC 8460 em 2018. Enquanto o MTA-STS diz ao remetente "use TLS ou recuse a entrega", o TLS-RPT diz ao receptor "e aqui é onde quero receber um JSON diário sempre que algo der errado". Sem isso, você anuncia uma política de TLS e fica cego para falhas de certificado, tentativas de downgrade, mudanças de MX que quebraram a confiança ou remetente desconfigurado contra a sua política — normalmente até um cliente reclamar.

O registro DNS em si é minimalista:

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

A tag rua (Reporting URI of Aggregate reports) aceita endereços mailto: ou endpoints https://, separados por vírgula. MTAs remetentes que respeitam TLS-RPT vão fazer POST ou enviar e-mail com um relatório agregado diário para essas URIs.

O que vem dentro de um relatório TLS-RPT

Os relatórios são documentos JSON, geralmente comprimidos com gzip, que resumem um dia de tentativas de entrega ao seu domínio. Cada registro descreve a política aplicada (MTA-STS ou TLSA), a contagem de sessões com sucesso, a contagem de falhas e o detalhe por falha: tipo (starttls-not-supported, certificate-expired, certificate-host-mismatch, validation-failure etc.), o hostname do MX receptor e o IP de origem. Ler esse fluxo é como você descobre que um único hyperscaler parou de confiar no seu certificado ontem.

Para onde vão os relatórios e como processá-los

Parsear TLS-RPT na mão é chato, então a maioria dos times aponta o rua para um agregador SaaS: dmarcian, Valimail, Postmark TLS Reports, EasyDMARC e Mimecast ingerem os relatórios, normalizam os dados e expõem dashboards com tendência e breakdown de falhas. Existem parsers open-source (o pacote Python tls-rpt, o parsedmarc) para times que preferem manter os dados in-house.

Onde TLS-RPT encaixa na stack de segurança de e-mail

A stack clássica hoje é SPF + DKIM + DMARC para autenticação, BIMI para branding na caixa de entrada, e MTA-STS + TLS-RPT para criptografia do transporte. O TLS-RPT copia o padrão do DMARC quase em cima — um registrinho DNS apontando para onde mandar o relatório — o que facilita rolar em paralelo a um DMARC já existente. Grandes empresas (Google, Microsoft, os maiores bancos americanos e europeus, e bancos brasileiros como Itaú, Bradesco e Santander) estão cada vez mais exigindo MTA-STS+TLS-RPT como pré-requisito para fornecedores B2B.

Perguntas frequentes

O TLS-RPT substitui os relatórios DMARC? Não — eles se complementam. DMARC cobre autenticação (alinhamento SPF/DKIM); TLS-RPT cobre a camada de transporte (a conexão foi realmente criptografada e o certificado foi confiável).

É obrigatório? Formalmente, não. Mas se você já implantou MTA-STS em modo testing sem TLS-RPT, está jogando fora o único canal de feedback que diz se é seguro virar para enforce.

Minha plataforma de marketing suporta? As que roteiam pelo MX próprio sim — SendGrid, Mailgun, AWS SES, Postmark e Mailchimp/Mandrill. Klaviyo e similares que enviam pelo seu domínio herdam a configuração de DNS de qualquer jeito.

Como verifico o registro? dig +short TXT _smtp._tls.example.com num shell, ou o validador em mxtoolbox.com/tls-rpt-record-lookup.aspx.