Como as organizações dependem cada vez mais do correio eletrónico como principal meio de comunicação, a importância de fortificar estes canais contra potenciais ameaças não pode ser exagerada. A segurança da camada de transporte(TLS) garante a confidencialidade e a integridade dos dados transmitidos através das redes.

O SMTP TLS Reporting (TLS-RPT) é um protocolo crítico que funciona em conjunto com o MTA-STS para garantir que os seus e-mails são entregues de forma segura. Ao fornecer feedback detalhado sobre problemas de entrega de emails, o TLS-RPT ajuda os proprietários de domínios a manter a integridade e a confidencialidade das suas comunicações. Neste guia abrangente, iremos explorar o que é o Relatório SMTP TLS, como funciona e porque é essencial para a sua estratégia de segurança de correio eletrónico."

Vários protocolos ajudam a encriptar os canais de mensagens SMTP para evitar que os ciber-atacantes interceptem as comunicações por correio eletrónico. Isto inclui STARTTLS, DANE e MTA-STS. No entanto, quando as tentativas de encriptação falham ao utilizar estes protocolos, o seu correio eletrónico pode não ser entregue. TLS-RPT (conforme descrito em RFC 8460) fornece um mecanismo de feedback para comunicar estas falhas de entrega.

Recomendamos vivamente a utilização do TLS-RPT em conjunto com o MTA-STS protocolo. Vamos entender como esses protocolos funcionam juntos para reforçar a segurança do correio eletrónico.

Takeaways de chaves

A segurança do correio eletrónico pode ser significativamente melhorada através da implementação de protocolos como o TLS-RPT e o MTA-STS.
O TLS-RPT fornece feedback essencial sobre questões de entrega de correio eletrónico relacionadas com a encriptação TLS, ajudando os proprietários de domínios a monitorizar eficazmente os seus canais de correio eletrónico.
Os protocolos STARTTLS, DANE e MTA-STS trabalham em conjunto para garantir uma comunicação segura por correio eletrónico, reduzindo o risco de ciberataques.
A configuração de um registo TLS-RPT implica a publicação de um registo TXT nas suas definições de DNS num subdomínio específico.
Reconhecer e resolver as falhas de encriptação TLS é fundamental para manter a capacidade de entrega e a segurança do correio eletrónico.

O que é o TLS-RPT?

O TLS-RPT (Transport Layer Security Reporting) é uma norma para comunicar problemas de entrega de correio eletrónico quando um correio eletrónico não está encriptado com TLS. A sua importância na autenticação de mensagens de correio eletrónico anda de mãos dadas com a razão para ativar a encriptação TLS para mensagens de correio eletrónico.

A encriptação TLS garante que todas as mensagens de correio eletrónico que lhe são enviadas são entregues em segurança. Se a ligação não for segura, muitas vezes as mensagens de correio eletrónico podem não ser entregues. O TLS-RPT permite aos proprietários de domínios monitorizar a entrega de correio eletrónico e as falhas de ligação. Os relatórios podem conter informações sobre:

Problemas de tratamento da política do MTA-STS
Motivo e tipo da falha de entrega
Endereço IP dos agentes de transferência de correio eletrónico de envio e receção
Contagem total de sessões de ligação TLS bem sucedidas e não bem sucedidas

Isto proporciona visibilidade dos seus canais de correio eletrónico e a capacidade de combater mais rapidamente os desafios de capacidade de entrega.

Simplifique os relatórios SMTP TLS com o PowerDMARC!

Teste grátis 15 dias Marcar demo

Como funciona o relatório TLS?

Na comunicação por correio eletrónico SMTP, a encriptação TLS é "oportunista". Isto significa que, se não for possível negociar um canal encriptado, o correio eletrónico continua a ser enviado num formato não encriptado (texto simples). De facto, há quase quatro décadas, os protocolos de correio eletrónico SMTP não suportavam a encriptação TLS. Teve de ser adaptada mais tarde sob a forma do comando STARTTLS.

O comando STARTTLS só é emitido nas comunicações SMTP se ambas as partes suportarem a encriptação TLS. Caso contrário, a mensagem de correio eletrónico continuará a ser enviada em texto simples.

Para eliminar a encriptação oportunista no SMTP, foi introduzido o MTA-STS (RFC 8461). O protocolo MTA-STS garante que as mensagens de correio eletrónico são encriptadas antes de serem entregues. O servidor de correio eletrónico ou o agente de transferência de correio (MTA) negoceia com o servidor recetor para ver se este suporta o comando STARTTLS. Se for compatível, a mensagem de correio eletrónico é encriptada com TLS e é entregue. Caso contrário, a entrega falha.

Explicação passo a passo de como funciona o TLS-RPT

1. Entendendo o processo de handshake do TLS

O aperto de mão Transport Layer Security (aperto de mão TLS) é o processo de estabelecimento de uma ligação segura entre dois agentes de transferência de correio (MTA) em comunicação. Este processo envolve os seguintes passos:

O MTA que envia o correio eletrónico envia uma mensagem "Client Hello" para o MTA que o recebe. Esta mensagem contém parâmetros úteis, como as versões TLS e os conjuntos de cifras.
O MTA que recebe o correio eletrónico recebe esta mensagem e responde com uma mensagem "Server Hello". Esta contém a versão TLS e o conjunto de cifras selecionados.
Após o início do aperto de mão TLS, o MTA recetor envia o seu certificado SSL/TLS que é emitido por uma CA (Autoridade de Certificação) de confiança. Este certificado contém a chave pública.
Ambos os MTAs comunicantes trocam de forma segura as suas chaves criptográficas e estabelecem uma ligação encriptada por TLS. Isto garante uma comunicação segura por correio eletrónico entre ambas as partes.

2. Cenários de handshake TLS com falha

Os TLS Handshakes podem falhar devido a uma variedade de razões:

Erros de certificação: Certificados expirados ou certificados emitidos por Autoridades de Certificação não confiáveis podem levar a falhas no handshake do TLS.
Incompatibilidades de versões: Se houver uma incompatibilidade entre as versões TLS suportadas pelos MTAs emissores e receptores, pode ocorrer uma falha no aperto de mão.
Falhas no STARTTLS: Se o comando STARTTLS não for corretamente implementado, pode conduzir novamente a uma falha na encriptação TLS.
Aplicação do MTA-STS: No caso de o destinatário do correio eletrónico ter definido o seu modo de política MTA-STS para "impor", um aperto de mão TLS falhado pode levar à rejeição da mensagem.

3. Geração e entrega de relatórios

Sempre que ocorrem falhas na encriptação TLS, o servidor de envio gera um relatório TLS-RPT e envia-o ao proprietário do domínio para avaliação e resolução de problemas adicionais.

Conteúdo do relatório

Detalhes do servidor de envio: Endereço IP e nome de domínio do remetente.

Detalhes do servidor de receção: O domínio do destinatário e as informações do servidor de correio eletrónico.

Descrição do erro: Tipo e pormenores da falha (por exemplo, erro de certificado, incompatibilidade de protocolo).

Tempo de fracasso: Registo de data e hora em que o problema ocorreu.

Modo de política: Se o domínio está em modo de "teste" ou de "aplicação".

Entrega de relatórios

Estes relatórios TLS são enviados em formato JSON para o endereço de correio eletrónico especificado no registo TXT do DNS TLS-RPT do proprietário do domínio.

Papel da encriptação oportunista no SMTP

O SMTP utiliza tradicionalmente a encriptação oportunista. Isto significa que tenta utilizar o TLS mas recorre à entrega não encriptada se o MTA recetor não suportar o TLS.

No entanto, a encriptação oportunista tem uma grande limitação. Neste tipo de encriptação que não estabelece qualquer mandato, as mensagens de correio eletrónico podem ser enviadas em texto simples ou em texto claro (num formato não encriptado) se a encriptação TLS falhar. Essas mensagens não encriptadas são vulneráveis à interceção.

Como funcionam em conjunto o MTA-STS e o TLS-RPT

O Mail Transfer Agent Strict Transport Security (MTA-STS) e o TLS-RPT são protocolos complementares no ecossistema de autenticação de correio eletrónico. Enquanto o MTA-STS garante que o MTA de envio tem de utilizar o TLS para a entrega e rejeitar as mensagens de correio eletrónico se a encriptação falhar,

O TLS-RPT permite que os proprietários de domínios monitorizem os handshakes TLS falhados e resolvam os problemas. Quando implementados em conjunto, podem evitar a interceção de mensagens em trânsito e minimizar os problemas de entrega de correio eletrónico.

Relação entre DANE e TLS-RPT

O DNS-based Authentication of Named Entities (DANE) é um protocolo que permite aos proprietários de domínios especificar certificados TLS verificados através de DNSSEC para evitar ataques man-in-the-middle. Enquanto o TLS-RPT monitoriza as falhas de TLS, o DANE garante que apenas são utilizados certificados fiáveis. Ao fazê-lo, o DANE impede ativamente que os atacantes realizem ataques de downgrade de TLS e de falsificação de certificados, mantendo assim a integridade das comunicações por correio eletrónico.

Porque precisa de relatórios SMTP TLS?

Os proprietários de domínios precisam de se manter informados sobre os problemas de entrega de correio eletrónico devido a falhas na encriptação TLS de mensagens enviadas a partir de um domínio com MTA-STS. O relatório TLS torna isso possível ao fornecer essas informações.

Segurança do correio eletrónico: Destacar os riscos da comunicação por correio eletrónico não encriptado (por exemplo, interceção, ataques do tipo "man-in-the-middle").
Conformidade: Mencione como o TLS-RPT ajuda as organizações a cumprir os requisitos regulamentares de proteção de dados.
Capacidade de entrega: Explicar como o TLS-RPT melhora a capacidade de entrega de correio eletrónico através da identificação e resolução de problemas de encriptação.

Passos para configurar o TLS-RPT

Pode ativar o relatório TLS para o seu domínio criando um registo TXT para TLS-RPT e publicando-o no seu DNS. Este registo deve ser publicado no subdomínio smtp.tls.yourdomain.com

Passo 1: Gerar um registo TLS-RPT (utilizando um gerador de registos TLS-RPT)

Pode inscrever-se no PowerDMARC gratuitamente e utilizar o nosso gerador de registos TLS-RPT para criar o seu registo.

Passo 2: Introduza o seu endereço de correio eletrónico de comunicação

Introduza um endereço de correio eletrónico no qual pretende receber os seus relatórios SMTP TLS.

Passo 3: Publique o registo TLS no seu DNS

Pode contactar o seu fornecedor de serviços de registo de domínios para criar um novo registo TXT para TLS-RPT. Se gerir o seu próprio DNS, edite as suas definições de DNS para incluir o registo.

Sintaxe e exemplo de registo TLS-RPT

Sintaxe: v=TLSRPTv1; rua=mailto:[email protected];

Vamos analisar os 2 componentes do registo de comunicação TLS fornecido:

v=TLSRPTv1: Esta etiqueta especifica a versão do protocolo TLS-RPT que está a ser utilizada. Neste caso, "TLSRPTv1" indica a primeira versão do protocolo.
rua=mailto:[email protected]: rua significa "Reporting URI(s) for Aggregate Data". Esta etiqueta especifica para onde o servidor de correio do destinatário deve enviar os relatórios TLS agregados.

Pode configurar mais do que um destino para receber os seus relatórios. Para vários destinos, separe cada entrada com uma vírgula (,). Pode utilizar "mailto:" para especificar um endereço de correio eletrónico para este passo, ou dar instruções ao MTA para enviar relatórios através de POST para URLs de ponto final, utilizando "https:" no campo rua=. Se estiver a utilizar "https:" certifique-se de que o campo define o URL para um servidor Web ativado por HTTPS com um certificado válido. Tanto "mailto:" como "https:" também podem ser utilizados num único registo, separados por uma vírgula.

Exemplo: v=TLSRPTv1; rua=mailto:[email protected],https://tlsreport.example.com;

Nota: Na prática, substitui-se "seudomínio.com" pelo nome de domínio real onde pretende receber estes relatórios.

Compreender os relatórios JSON do TLS-RPT

Estrutura de um relatório JSON TLS-RPT

Os relatórios TLS são enviados no formato JSON. Abaixo está um exemplo de como pode ser um relatório JSON TLS:

{

"organization-name": "Organização Inc.",

“date-range”: {

"start-datetime": “2020-10-22T00:00:00Z”,

"end-datetime": “2020-10-22T23:59:59Z”

"contacto-info": "[email protected]",

"report-id": “2020-10-22T00:00:00Z_domain.com”,

"políticas": [

{

“policy”: {

"tipo de política": "sts",

"policy-string": [

"versão: STSv1",

"mode: testing",

"mx: mx.domain.com",

"mx: mx2.domain.com",

"mx: mx3.domain.com",

"max_age: 604800"

"domínio da política": "domínio.com"

“summary”: {

"total-successful-session-count": 15,

"total-failure-session-count": 0

}

Campos-chave e o seu significado

Eis a repartição dos principais campos deste relatório JSON TLS:

Campos	Descrição
organização	A organização do domínio que possui o registo TLS-RPT.
correio eletrónico	O endereço de correio eletrónico para onde são enviados os relatórios agregados.
data_inicial	A data de início do período de referência.
data_final	A data final do período de referência.
políticas	Um conjunto de objectos de política que descrevem as políticas aplicadas durante o período de referência.
política	Contém informações sobre a política aplicada.
tipo de política	Especifica o tipo de política
cadeia_de_políticas	Especifica a cadeia de políticas associada à política
modo	Especifica o modo de política MTA-STS (Aplicar/Testar)
resumo	Contém informações resumidas sobre as sessões que foram tentadas.
total_successful_session_count	O número total de sessões TLS estabelecidas com êxito.
total_failure_session_count	A contagem total de falhas de sessão TLS.
detalhes_da_falta	Um conjunto de objectos que fornecem detalhes sobre falhas específicas.
razão	Uma cadeia de caracteres que indica o motivo da falha (por exemplo, "certificate_expired").
contagem	A contagem de sessões que falharam por um motivo específico.

Formato de relatório TLS-RPT JSON e interpretação de dados

Metadados do relatório

{

"organization-name": "Organização do MTA remetente",

“date-range”: {

"start-datetime": “2025-02-25T00:00:00Z”,

"end-datetime": “2025-02-25T23:59:59Z”

"report-id": “unique-report-id-12345”

}

Esta secção do relatório JSON apresenta informações básicas, como o nome da organização do remetente do email, a data e hora de início, a data e hora de fim e o ID exclusivo do relatório TLS gerado.

Detalhes da política

“policy”: {

"tipo de política": "sts",

"policy-string": "mode: enforce; mx: mail.example.com; max_age: 604800;"

}

Esta secção descreve o modo de política MTA-STS implementado, que neste caso é o modo Enforce, mas também pode ser definido para o modo Testing (Teste).

Detalhes da falha

"failure-details": [

{

"result-type": "certificate-expired",

"sending-mta": "smtp.example.org",

"receiving-mta": "mail.example.com",

"failure-reason": "O aperto de mão TLS falhou devido a um certificado expirado"

}

]

Esta secção é a parte mais crucial do seu relatório TLS, detalhando a lógica da encriptação e potenciais falhas de entrega. Neste caso, o exemplo indica que um certificado expirado é a causa da falha do handshake TLS. Isto desempenha um papel significativo na deteção de erros durante os handshakes TLS falhados e promove uma rápida resolução de problemas para comunicações TLS seguras.

Razões e resolução de problemas de falhas de encriptação TLS

Pode haver várias razões para as falhas de encriptação TLS. Para além da falta de suporte para encriptação em ambos os lados, razões mais sinistras, como um ataque de downgrade SMTP, podem levar à falha da ligação TLS. Mas os proprietários de domínios gostariam de saber que a entrega falhou. O relatório TLS (TLS-RPT) é um protocolo que o notificará. Em caso de falhas de entrega, receberá o seu relatório TLS num formato de ficheiro JSON para o endereço de correio eletrónico definido no seu registo TLS-RPT. Seguem-se alguns motivos comuns para falhas de encriptação e sugestões de resolução de problemas:

1. Questões relativas ao certificado

certificado_expirado

O certificado apresentado pelo servidor remoto ultrapassou a data de expiração. Isto torna-o não fiável para a encriptação. Neste caso, é necessário renovar o certificado.

certificate_not_valid_yet

O certificado apresentado pelo servidor remoto ainda não é válido. Isto pode dever-se a uma hora incorrecta do servidor ou à utilização prematura do certificado. Neste caso, é melhor contactar o fornecedor do certificado.

certificado_revogado

O certificado apresentado pelo servidor remoto foi revogado pela autoridade de certificação devido a questões de segurança. Neste caso, é melhor contactar o fornecedor do certificado.

assinatura_não_válida

A cadeia de certificados apresentada pelo servidor remoto não é de confiança para o servidor ou cliente de correio do remetente, indicando um potencial risco de segurança. Neste caso, é melhor contactar o fornecedor de certificados.

certificado não suportado

O certificado apresentado pelo servidor remoto utiliza algoritmos de encriptação ou comprimentos de chave que não são suportados pelo servidor de correio do remetente, impedindo uma ligação segura. Neste caso, é melhor contactar o seu fornecedor de certificados.

2. Incompatibilidade entre nome de anfitrião e identidade

incompatibilidade de nome de anfitrião

O nome de anfitrião especificado no certificado do servidor não corresponde ao nome de anfitrião do servidor ao qual o servidor de correio do remetente está a tentar ligar. Isto indica um possível ataque man-in-the-middle ou um problema de configuração.

Pode verificar os registos MX no seu ficheiro de política MTA-STS para se certificar de que correspondem ao registo MX do domínio.

3. Questões de handshake e protocolo

handshake_failure

Ocorreu um problema durante o processo inicial de aperto de mão TLS entre o servidor de correio do remetente e o servidor de correio do destinatário, impedindo o estabelecimento do canal seguro. Verifique novamente se a ligação SMTP STARTTLS foi estabelecida. Podem existir várias razões que contribuem para as falhas de encriptação, como a falta de suporte para STARTTLS ou um ataque de downgrade de TLS.

4. Questões políticas do MTA-STS

mta_sts_policy_not_found

Esta falha ocorre quando o servidor de correio do remetente não consegue encontrar uma política MTA-STS para o domínio do destinatário. Reveja o seu ficheiro de política MTA-STS. Deve verificar o seu registo MTA-STS para se certificar de que foi publicado corretamente.

mta_sts_policy_invalid

Esta falha ocorre quando a política MTA-STS encontrada no DNS para o domínio do destinatário é inválida, contém erros ou não cumpre a especificação MTA-STS. Reveja o seu ficheiro de política MTA-STS. Especifique um modo de política MTA-STS adequado. Pode ser Nenhum, Aplicar ou Testar. Isto instrui os servidores de envio sobre como lidar com os emails que sofrem falhas de validação da política MTA-STS.

mta_sts_policy_fetch_error

Esta falha ocorre quando o servidor de correio do remetente encontra um erro ao tentar recuperar a política MTA-STS dos registos DNS do domínio do destinatário. Deve validar os registos MTA-STS no seu DNS para se certificar de que a sintaxe do registo está correta.

mta_sts_connection_failure

Esta falha ocorre quando o servidor de correio do remetente tenta estabelecer uma ligação segura utilizando o MTA-STS, mas falha devido a razões como certificados não fiáveis, conjuntos de cifras não suportados ou outros problemas de TLS. Deve verificar a validade do seu certificado e certificar-se de que o certificado está atualizado com a norma TLS mais recente.

mta_sts_invalid_hostname

Esta falha ocorre quando o nome de anfitrião do servidor de correio do destinatário, conforme especificado na política MTA-STS, não corresponde ao nome de anfitrião real do servidor. Deve verificar os registos MX no seu ficheiro de política MTA-STS para se certificar de que correspondem ao registo MX do domínio.

Melhores práticas para a implementação do TLS-RPT

Monitorizar regularmente os relatórios TLS

Os relatórios TLS devem ser monitorizados regularmente para garantir que não perde mensagens não entregues. Pode fazê-lo monitorizando manualmente a sua caixa de correio para os relatórios JSON ou utilizando uma ferramenta de análise de relatórios como o PowerTLS-RPT.

Garantir que a política MTA-STS está corretamente configurada

Para garantir a implementação correta do TLS-RPT, a sua política MTA-STS deve ser configurada corretamente e sem erros de sintaxe. Pode verificar o seu registo utilizando o nosso verificador de MTA-STS para esta etapa.

Resolver prontamente as falhas de encriptação

Assim que detetar falhas de encriptação descritas no seu relatório TLS, é importante tomar medidas rapidamente para evitar problemas de entrega de correio eletrónico no futuro.

Utilizar versões seguras do protocolo TLS

Utilizar apenas as versões mais recentes e suportadas do protocolo TLS é essencial para evitar falhas de encriptação indesejadas.

Relatórios SMTP TLS simplificados com o PowerDMARC

A experiência de relatório SMTP TLS do PowerDMARC visa melhorar sua segurança e facilitar sua vida com um serviço hospedado.

Relatórios traduzidos de TLS

Os seus complexos relatórios TLS-RPT JSON são convertidos em informações simplificadas que pode consultar em segundos ou ler em pormenor.

Questões de auto-detecção

A plataforma PowerDMARC identifica e destaca o problema que está a enfrentar para que possa resolvê-lo sem perder tempo.

Não há nada que me agrade na plataforma PowerDMARC, que tem um layout fácil de utilizar e compreender, com o que eu chamaria de funcionalidades completas que permitem o controlo DMARC alojado, nivelamento de SPFpodendo facilmente expandir o SPF inclui para inspecionar as especificidades do registo e até suporte completo para MTA-STS e TLS-RPT!

Dylan B (Proprietário da empresa)

Perguntas frequentes sobre a segurança da camada de transporte

O que significa TLS?

TLS significa Transport Layer Security (Segurança da Camada de Transporte).

Quem emite os certificados TLS?

As Autoridades de Certificação (CAs) podem emitir certificados TLS. O processo de emissão do certificado inclui a verificação da identidade do titular do certificado. Se a identificação for bem sucedida, o certificado é emitido.

Porque é que preciso de um certificado TLS?

Os certificados TLS desempenham um papel fundamental na segurança das comunicações através da Internet. Ajudam a encriptar informações sensíveis trocadas entre servidores Web em comunicação. Algumas das suas utilizações mais comuns incluem a segurança das comunicações por correio eletrónico e HTTPS.

Qual é a norma TLS atual?

O TLS 1.3 é a versão mais recente do Transport Layer Security. O TLS-RPT pode ser implementado utilizando qualquer versão do TLS. Isto pode incluir versões mais antigas do protocolo ou versões futuras. A versão é normalmente determinada por critérios como as capacidades dos servidores em comunicação.

Yunes Tarada

Especialista em segurança de domínios e e-mails da PowerDMARC

Yunes é um Operations Team Lead na PowerDMARC com conhecimentos especializados em autenticação e segurança de correio eletrónico. Yunes é um Microsoft-certified Azure Administrator Associate com certificações em CompTIA A+ e muito mais.

Últimas mensagens de Yunes Tarada (ver todas)

Ataques de salting de correio eletrónico: Como o texto oculto contorna a segurança - 26 de fevereiro de 2025
Alisamento do SPF: O que é e porque é que precisa dele? - 26 de fevereiro de 2025
DMARC vs DKIM: Principais diferenças e como funcionam em conjunto - 16 de fevereiro de 2025

O que é o relatório SMTP TLS (TLS-RPT)?