STARTTLS, SSL/TLS e SMTP: qual criptografia para seus emails?

Por CaptainDNS
Publicado em 17 de fevereiro de 2026

Criptografia SMTP: STARTTLS, TLS 1.2, TLS 1.3, DANE e MTA-STS

TL;DR

SSL está obsoleto desde 2015 (RFC 7568): o termo correto é TLS. STARTTLS não é um protocolo de criptografia, é um comando que ativa o TLS em uma conexão existente
STARTTLS é vulnerável a ataques downgrade: um atacante na rede pode remover o anúncio STARTTLS e forçar a comunicação em texto claro. MTA-STS e DANE corrigem essa falha
TLS 1.3 é o padrão recomendado para SMTP em 2026: handshake mais rápido (1-RTT), cipher suites mais seguros, forward secrecy obrigatório
Configure seu MTA com TLS obrigatório na saída (smtp_tls_security_level = encrypt no Postfix) e implante MTA-STS para proteger os emails recebidos

Seus emails realmente transitam criptografados? Em 2024, o Google relata que mais de 95% dos emails recebidos pelo Gmail usam TLS. Mas esse número esconde uma realidade mais complexa: STARTTLS é oportunista por padrão, ataques downgrade são documentados e muitos servidores ainda aceitam TLS 1.0 ou cipher suites fracos.

Este guia vai além da simples comparação STARTTLS vs Implicit TLS. Ele explica como funciona a criptografia TLS no nível do handshake, por que o TLS 1.3 muda o cenário para SMTP, quais falhas os atacantes exploram e como configurar uma criptografia robusta nos MTAs mais comuns (Postfix, Exim, Exchange). Se você administra um servidor de email ou audita uma infraestrutura de email, sairá daqui com ações concretas.

SSL, TLS, STARTTLS: esclarecendo a terminologia

Os termos SSL, TLS e STARTTLS são usados de forma intercambiável na indústria de email. Isso gera uma grande confusão, pois designam coisas fundamentalmente diferentes.

SSL morreu, TLS o substituiu

SSL (Secure Sockets Layer) é o antecessor do TLS. A última versão, SSL 3.0, foi publicada em 1996 e oficialmente abandonada pela RFC 7568 em 2015 devido a vulnerabilidades críticas (POODLE, BEAST). Quando um provedor de email menciona "SSL" em 2026, está na verdade falando de TLS.

Protocolo	Ano	Status em 2026
SSL 2.0	1995	Proibido (RFC 6176)
SSL 3.0	1996	Proibido (RFC 7568)
TLS 1.0	1999	Obsoleto (RFC 8996)
TLS 1.1	2006	Obsoleto (RFC 8996)
TLS 1.2	2008	Aceitável
TLS 1.3	2018	Recomendado

Na prática: se seu servidor SMTP ainda aceita SSL 3.0 ou TLS 1.0, ele está vulnerável a ataques conhecidos. Desative esses protocolos.

STARTTLS não é um protocolo de criptografia

STARTTLS é um comando SMTP (definido na RFC 3207) que solicita ao servidor a troca de uma conexão em texto claro para uma conexão criptografada com TLS. Não é SSL, nem TLS, nem um protocolo autônomo: é um mecanismo de upgrade de uma conexão existente.

A confusão vem do nome: "STARTTLS" contém "TLS", mas não especifica qual versão de TLS será usada. A versão negociada depende da configuração do cliente e do servidor.

Implicit TLS vs Explicit TLS (STARTTLS)

Existem duas maneiras de estabelecer TLS em uma conexão SMTP:

Método	Porta típica	Funcionamento	Analogia web
Explicit TLS (STARTTLS)	25, 587	Conexão em texto claro, depois upgrade via comando STARTTLS	HTTP depois redirecionamento para HTTPS
Implicit TLS	465	Conexão TLS desde o primeiro byte	HTTPS nativo na porta 443

Com Explicit TLS, há sempre um momento em que a comunicação está em texto claro (a fase EHLO antes do STARTTLS). Com Implicit TLS, nunca há comunicação em texto claro. É essa diferença que tem consequências importantes em termos de segurança.

Como funciona a criptografia SMTP na prática?

Seja usando STARTTLS ou Implicit TLS, a criptografia se baseia em um handshake TLS. Esse processo de negociação determina a versão do protocolo, o cipher suite utilizado e a troca de chaves.

O handshake TLS passo a passo

Veja o que acontece quando um servidor SMTP negocia TLS (após o comando STARTTLS ou desde a conexão na porta 465):

Com TLS 1.2 (4 trocas, 2-RTT):

ClientHello: o cliente envia as versões TLS e cipher suites que suporta
ServerHello: o servidor escolhe a versão TLS e o cipher suite, envia seu certificado
Troca de chaves: o cliente gera um segredo pré-mestre, criptografa-o com a chave pública do servidor
Finished: ambas as partes confirmam que o canal está criptografado

Com TLS 1.3 (2 trocas, 1-RTT):

ClientHello: o cliente envia as versões TLS, cipher suites e suas chaves Diffie-Hellman
ServerHello + Finished: o servidor escolhe os parâmetros, envia seu certificado e confirma a criptografia

O TLS 1.3 funde etapas: o handshake passa de 2-RTT para 1-RTT, o que reduz a latência de estabelecimento de conexão. Para um servidor MX que processa milhares de conexões por hora, essa otimização é significativa.

Comparação do handshake TLS 1.2 vs TLS 1.3 em uma conexão SMTP

TLS 1.2 vs TLS 1.3: quais diferenças para SMTP?

Critério	TLS 1.2	TLS 1.3
Handshake	2-RTT	1-RTT
Forward secrecy	Opcional (depende do cipher)	Obrigatório
Cipher suites	37 suites (incluindo fracos)	5 suites (todos robustos)
Compressão	Suportada (vulnerável ao CRIME)	Removida
Renegociação	Suportada (vetor de ataque)	Removida
0-RTT resumption	Não	Sim (com precauções)
RFC	RFC 5246	RFC 8446

O ponto-chave para SMTP: TLS 1.3 elimina os cipher suites fracos e torna a forward secrecy obrigatória. Com TLS 1.2, um servidor pode negociar RSA sem troca Diffie-Hellman, o que significa que um atacante que obtém a chave privada do servidor pode decifrar todas as comunicações passadas. Com TLS 1.3, cada sessão usa chaves efêmeras: mesmo se a chave privada vazar, as sessões passadas permanecem protegidas.

Cipher suites recomendados em 2026

Para SMTP, configure seu servidor com estes cipher suites, nesta ordem de preferência:

TLS 1.3 (nenhuma configuração necessária, os 5 suites são todos seguros):

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

TLS 1.2 (restringir aos suites com forward secrecy):

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256

Cipher suites a evitar: tudo que contenha RC4, DES, 3DES, MD5, NULL, EXPORT ou RSA sem ECDHE/DHE (sem forward secrecy).

As falhas do STARTTLS e como se proteger

STARTTLS é o mecanismo de criptografia mais utilizado para conexões SMTP entre servidores (porta 25). Mas seu design oportunista introduz falhas exploráveis.

O ataque downgrade STARTTLS

Quando um cliente SMTP se conecta a um servidor na porta 25, ele envia EHLO e aguarda a lista de extensões. Se o servidor anuncia 250-STARTTLS, o cliente sabe que pode mudar para TLS. O problema: essa troca ocorre em texto claro.

Um atacante posicionado entre o cliente e o servidor (man-in-the-middle) pode modificar a resposta EHLO para remover a linha 250-STARTTLS. O cliente, não vendo a extensão STARTTLS, continua em texto claro. O atacante pode então ler e modificar todos os emails em trânsito.

# Resposta legítima do servidor
250-mx1.captaindns.com
250-STARTTLS        <-- o atacante remove esta linha
250 OK

# O que o cliente vê após o ataque
250-mx1.captaindns.com
250 OK              <-- sem STARTTLS, conexão em texto claro

O ataque STRIPTLS

STRIPTLS é uma variante mais sofisticada. Em vez de remover o anúncio STARTTLS do servidor, o atacante intercepta o comando STARTTLS enviado pelo cliente e retorna um erro falso (por exemplo 454 TLS not available). O cliente abandona o TLS e continua em texto claro, acreditando ser um problema temporário.

Esses dois ataques são documentados e foram observados em escala nacional. Em 2014, pesquisadores demonstraram que vários países praticavam STRIPTLS nas conexões SMTP internacionais.

MTA-STS: forçar TLS nos emails recebidos

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) é a resposta da IETF aos ataques downgrade no SMTP. O princípio: o domínio destinatário publica uma política dizendo "todos os servidores que me enviam emails devem usar TLS com um certificado válido".

Como funciona:

O domínio captaindns.com publica um registro DNS TXT _mta-sts.captaindns.com com um identificador de política
O domínio hospeda um arquivo https://mta-sts.captaindns.com/.well-known/mta-sts.txt contendo a política
O servidor remetente consulta essa política antes de se conectar ao MX
Se a política está no modo enforce, o servidor remetente recusa entregar em texto claro

# Registro DNS
_mta-sts.captaindns.com.  TXT  "v=STSv1; id=20260217"

# Arquivo de política (HTTPS obrigatório)
version: STSv1
mode: enforce
mx: mx1.captaindns.com
mx: mx2.captaindns.com
max_age: 604800

Limitação: MTA-STS depende de HTTPS para distribuir a política. Se o atacante bloquear o acesso HTTPS ao arquivo de política, o servidor remetente não consegue recuperar a política e pode voltar ao texto claro. É um problema de TOFU (Trust On First Use): a política é segura apenas após a primeira recuperação bem-sucedida.

DANE (TLSA): autenticar o certificado via DNS

DANE (DNS-based Authentication of Named Entities, RFC 7672 para SMTP) resolve o problema de forma diferente. Em vez de publicar uma política via HTTPS, o domínio publica um registro TLSA no DNS que contém a impressão digital do certificado TLS esperado.

# Registro TLSA para o MX (porta 25)
_25._tcp.mx1.captaindns.com.  TLSA  3 1 1 a0b1c2d3e4f5...

Vantagens do DANE:

Sem dependência de HTTPS (ao contrário do MTA-STS)
Autentica o certificado do servidor via DNSSEC (não apenas "TLS obrigatório", mas "TLS com este certificado")
Protege contra ataques downgrade e certificados falsos

Pré-requisito: DANE exige DNSSEC no domínio. Sem DNSSEC, os registros TLSA não são autenticados e o DANE é ineficaz. É o principal obstáculo para a adoção: apenas ~5% dos domínios usam DNSSEC em 2026.

Mecanismo	Protege contra downgrade	Autentica o certificado	Pré-requisitos
STARTTLS sozinho	Não	Não	Nenhum
MTA-STS	Sim (após primeiro fetch)	Sim (CA pública)	HTTPS + DNS TXT
DANE	Sim	Sim (impressão digital exata)	DNSSEC + DNS TLSA
MTA-STS + DANE	Sim (dupla proteção)	Sim (CA + impressão digital)	DNSSEC + HTTPS

Mecanismos de proteção contra ataques STARTTLS downgrade

Configurar a criptografia TLS no seu servidor SMTP

A teoria está clara. Vamos à configuração concreta nos três MTAs mais utilizados.

Postfix: ativar e reforçar TLS

Postfix é o MTA mais implantado em servidores Linux. A configuração TLS é feita no main.cf.

TLS de entrada (servidor, recebimento de emails):

# Ativar TLS para conexões de entrada
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.captaindns.com/privkey.pem
smtpd_tls_security_level = may

# Forçar TLS 1.2 no mínimo
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_protocols = >=TLSv1.2

# Cipher suites (TLS 1.2)
smtpd_tls_mandatory_ciphers = high
smtpd_tls_exclude_ciphers = aNULL, MD5, DES, 3DES, RC4

TLS de saída (cliente, envio de emails):

# Ativar TLS para conexões de saída
smtp_tls_security_level = may
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

# Forçar TLS 1.2 no mínimo na saída
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_protocols = >=TLSv1.2

# Registrar conexões TLS em log (útil para auditoria)
smtp_tls_loglevel = 1

Reforçar ainda mais: substitua smtp_tls_security_level = may por encrypt para recusar qualquer conexão em texto claro na saída. Atenção: alguns servidores pequenos não têm TLS, seus emails para esses servidores serão bloqueados. Use dane se DNSSEC estiver disponível.

Valor `security_level`	Comportamento
`none`	Sem TLS (não recomendado)
`may`	TLS oportunista (padrão, aceita texto claro)
`encrypt`	TLS obrigatório (recusa texto claro)
`dane`	TLS + verificação DANE via DNSSEC
`verify`	TLS + verificação do hostname do certificado

Exim: configuração TLS

Exim usa uma configuração modular. As diretivas TLS ficam no bloco principal.

# Certificado e chave
tls_certificate = /etc/letsencrypt/live/mx1.captaindns.com/fullchain.pem
tls_privatekey = /etc/letsencrypt/live/mx1.captaindns.com/privkey.pem

# Anunciar STARTTLS
tls_advertise_hosts = *

# Forçar TLS 1.2 no mínimo
openssl_options = +no_sslv2 +no_sslv3 +no_tlsv1 +no_tlsv1_1

# Exigir TLS para conexões de saída (opcional)
tls_require_ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:\
  ECDHE-RSA-AES256-GCM-SHA384:\
  ECDHE-ECDSA-AES128-GCM-SHA256:\
  ECDHE-RSA-AES128-GCM-SHA256

Para verificar a configuração: exim -bV exibe as capacidades TLS compiladas.

Microsoft Exchange: impor TLS

No Exchange (2019+), a configuração TLS é feita pelos conectores de recebimento e envio.

Conector de recebimento (emails de entrada):

# Forçar TLS no conector de recebimento
Set-ReceiveConnector "Default Frontend" -RequireTLS $true

# Desativar protocolos obsoletos (via registro do Windows)
# HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
# Desativar SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1

Conector de envio (emails de saída para um parceiro específico):

# Criar um conector de envio com TLS obrigatório
New-SendConnector -Name "Para captaindns.com (TLS)" `
  -AddressSpaces "captaindns.com" `
  -RequireTLS $true `
  -TlsAuthLevel DomainValidation

Nota: RequireTLS $true em um conector de envio significa que o Exchange recusa enviar em texto claro para esse destino. Use-o para domínios parceiros que suportam TLS, não para um conector catch-all (mensagens seriam bloqueadas).

Verificar a criptografia dos seus emails

Configurar TLS não basta: é preciso verificar se a criptografia está realmente funcionando.

No Gmail: indicador de criptografia

O Gmail exibe um cadeado no cabeçalho dos emails. Um cadeado cinza significa que o email transitou em TLS (padrão). Um cadeado vermelho com um ponto de exclamação significa que o email não foi criptografado em trânsito.

Para os detalhes técnicos, clique em "Mostrar original" no Gmail: o cabeçalho Received contém a versão TLS e o cipher suite utilizados.

Received: from mx1.captaindns.com (mx1.captaindns.com [203.0.113.10])
  by mx.google.com with ESMTPS id abc123
  (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384)

Na linha de comando: openssl s_client

Para testar a criptografia de um servidor MX a partir de um terminal:

# Teste STARTTLS na porta 25
openssl s_client -connect mx1.captaindns.com:25 -starttls smtp \
  -servername mx1.captaindns.com 2>/dev/null | \
  grep -E "Protocol|Cipher|Verify"

# Resultado esperado
Protocol  : TLSv1.3
Cipher    : TLS_AES_256_GCM_SHA384
Verify return code: 0 (ok)

Se Protocol exibir TLSv1 ou TLSv1.1, seu servidor está usando um protocolo obsoleto. Se Verify return code for diferente de 0, o certificado tem um problema.

Com a ferramenta CaptainDNS

O SMTP/MX Connectivity Tester do CaptainDNS testa automaticamente todos os MX de um domínio e verifica para cada um: a versão TLS negociada, o cipher suite, a validade do certificado (expiração, SAN, cadeia de confiança) e o suporte a STARTTLS. O resultado inclui uma pontuação por servidor MX com códigos de diagnóstico explícitos.

🎯 Plano de ação recomendado

Audite sua configuração atual: verifique a versão TLS e os cipher suites de cada MX com openssl s_client ou o SMTP/MX Connectivity Tester
Desative SSL 3.0, TLS 1.0 e TLS 1.1: esses protocolos são obsoletos (RFC 8996) e vulneráveis. TLS 1.2 é o mínimo, TLS 1.3 é o recomendado
Restrinja os cipher suites: remova RC4, DES, 3DES, MD5 e os suites sem forward secrecy (ECDHE/DHE obrigatório)
Implante MTA-STS: publique uma política enforce para proteger seus emails recebidos contra ataques downgrade
Ative DANE se DNSSEC estiver disponível: publique registros TLSA para autenticar os certificados dos seus MX via DNS

FAQ

Qual é a diferença entre STARTTLS e SSL/TLS?

SSL e TLS são protocolos de criptografia (SSL sendo o antecessor obsoleto do TLS). STARTTLS não é SSL nem TLS: é um comando SMTP que ativa a criptografia TLS em uma conexão inicialmente em texto claro. Após o STARTTLS, a conexão usa TLS (1.2 ou 1.3), mas a fase inicial antes do comando permanece vulnerável a ataques downgrade.

Ainda é necessário usar SSL para SMTP?

Não. SSL 2.0 e 3.0 são proibidos pelas RFC 6176 e 7568. TLS 1.0 e 1.1 estão obsoletos desde a RFC 8996. Todo servidor SMTP deve usar TLS 1.2 no mínimo, e TLS 1.3 de preferência. Se um provedor menciona "SSL", na verdade está se referindo a TLS.

Como forçar a criptografia TLS nos emails de saída?

No Postfix, configure smtp_tls_security_level = encrypt no main.cf para recusar qualquer conexão em texto claro na saída. No Exchange, ative RequireTLS no conector de envio. Atenção: os emails para servidores sem TLS serão bloqueados. Use o modo dane ou may se precisar entregar a todos os destinatários.

O que é DANE e como ele protege o SMTP?

DANE (DNS-based Authentication of Named Entities) permite publicar a impressão digital do certificado TLS de um servidor MX em um registro DNS TLSA. O servidor remetente verifica se o certificado apresentado corresponde à impressão digital publicada, o que impede ataques por certificado falso e downgrades. DANE exige DNSSEC para garantir a autenticidade dos registros DNS.

Como verificar se meus emails transitam em TLS?

Três métodos: (1) no Gmail, clique em "Mostrar original" e procure os cabeçalhos Received com a versão TLS, (2) na linha de comando, use openssl s_client -connect mx:25 -starttls smtp para testar a negociação, (3) use o SMTP/MX Connectivity Tester do CaptainDNS para um diagnóstico automatizado de todos os seus MX.

Quais cipher suites usar para SMTP em 2026?

Para TLS 1.3: todos os suites são seguros (AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305). Para TLS 1.2: use apenas os suites ECDHE com AES-GCM (forward secrecy obrigatório). Elimine RC4, DES, 3DES, MD5, os suites NULL, EXPORT e as trocas RSA sem ECDHE/DHE.

Qual é a diferença entre MTA-STS e DANE?

MTA-STS publica uma política TLS via HTTPS (arquivo .well-known/mta-sts.txt) que indica que o domínio exige TLS. DANE publica a impressão digital do certificado via um registro DNS TLSA protegido por DNSSEC. MTA-STS é mais fácil de implantar (não precisa de DNSSEC), mas sofre do problema TOFU (Trust On First Use). DANE oferece uma autenticação mais forte, mas exige DNSSEC. Ambos podem ser implantados simultaneamente.

Baixe as tabelas comparativas

Assistentes conseguem reutilizar os números consultando os ficheiros JSON ou CSV abaixo.

📖 Glossário

TLS (Transport Layer Security): Protocolo de criptografia de comunicações de rede. Sucessor do SSL, versões atuais: TLS 1.2 e TLS 1.3 (RFC 8446).
STARTTLS: Comando SMTP (RFC 3207) que solicita o upgrade de uma conexão em texto claro para TLS. Não é um protocolo de criptografia em si.
Implicit TLS: Modo de conexão onde o TLS é estabelecido desde o primeiro byte, sem fase em texto claro. Usado na porta 465 (SMTP) e na porta 443 (HTTPS).
Forward secrecy: Propriedade criptográfica que garante que a comprometimento de uma chave privada não permite decifrar as sessões passadas. Assegurada pelas trocas de chaves ECDHE/DHE.
Cipher suite: Combinação de algoritmos usados para uma sessão TLS: troca de chaves (ECDHE), autenticação (RSA/ECDSA), criptografia (AES-GCM) e hash (SHA384).
DANE: DNS-based Authentication of Named Entities (RFC 7672 para SMTP). Permite autenticar o certificado TLS de um servidor via um registro DNS TLSA protegido por DNSSEC.
MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Política publicada via HTTPS que força os servidores remetentes a usar TLS com um certificado válido.
Ataque downgrade: Ataque de rede que força uma conexão a usar um protocolo menos seguro, tipicamente removendo o anúncio STARTTLS ou modificando a negociação TLS.
TOFU: Trust On First Use. Modelo de segurança onde a confiança é estabelecida na primeira interação. MTA-STS sofre desse problema: a primeira recuperação da política é vulnerável.

Verifique a criptografia TLS dos seus servidores MX: Use nosso SMTP/MX Connectivity Tester para testar a versão TLS, os cipher suites e a validade do certificado de cada MX, em poucos segundos.

📚 Guias de SMTP e conectividade email relacionados

As portas SMTP explicadas: 25, 465, 587, 2525: função, criptografia e casos de uso de cada porta SMTP
Como testar a conectividade SMTP dos seus servidores MX: guia passo a passo com telnet e openssl
Porta 25 bloqueada: diagnóstico e soluções por provedor de hospedagem (em breve)