SPF, DKIM e DMARC provam quem enviou uma mensagem. MTA-STS e TLS-RPT protegem a mensagem enquanto ela está em movimento — eles garantem que a conexão que carrega seu e-mail está genuinamente criptografada e avisam você quando não está. O MTA-STS (SMTP MTA Strict Transport Security, definido na RFC 8461) permite que um domínio declare que os e-mails destinados aos seus servidores devem chegar por TLS com um certificado válido. O TLS-RPT (SMTP TLS Reporting, RFC 8460) pede aos servidores remetentes que enviem um relatório diário informando se essa criptografia teve sucesso ou falhou. Nenhum dos dois autentica o conteúdo — juntos, eles fecham uma lacuna diferente, aquela que o TLS oportunista puro deixa completamente aberta. Veja o que cada um faz e como implantá-los sem quebrar o seu e-mail de entrada.
A resposta curta#
O MTA-STS é uma política que você publica para que os servidores de e-mail de
outras pessoas criptografem os e-mails que enviam para você. Ele tem duas partes
móveis: um registro TXT no DNS em _mta-sts.yourdomain.com que sinaliza que a
política existe, e um arquivo de política hospedado por HTTPS em
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt que lista os nomes de host
dos seus MX, um modo (none, testing ou enforce) e por quanto tempo armazená-lo
em cache. O TLS-RPT é um segundo registro TXT em _smtp._tls.yourdomain.com que
indica um endereço para receber relatórios diários sobre como essas conexões TLS se
saíram. A implantação segura espelha o DMARC: publique primeiro no modo testing,
leia os relatórios do TLS-RPT até ter certeza de que toda conexão negocia o TLS
corretamente e, então, mude para enforce.
A lacuna que o MTA-STS fecha#
O SMTP moderno já criptografa a maior parte dos e-mails em trânsito usando o STARTTLS — o servidor remetente pergunta "você suporta TLS?", o destinatário responde que sim, e os dois negociam um canal criptografado. O problema é que esse handshake é oportunista e não autenticado. Se algum dos lados não oferecer TLS, o e-mail recorre ao texto puro em vez de falhar. Pior ainda, um atacante posicionado entre os dois servidores pode retirar a oferta de STARTTLS da conversa — um ataque de downgrade — e o servidor remetente, sem ver TLS disponível, entrega a mensagem silenciosamente em texto aberto. O certificado também não é verificado, então um homem-no-meio pode apresentar o seu próprio e interceptar a conexão.
O MTA-STS corrige as duas fraquezas. Ao publicar uma política, você diz aos remetentes compatíveis: o e-mail para este domínio deve trafegar por TLS, o servidor de recebimento deve apresentar um certificado que seja válido e corresponda a um dos nomes de host MX que listei e, se essas condições não forem atendidas, não entregue — adie e tente novamente em vez de recorrer ao texto puro. Como a política é obtida por HTTPS, o próprio certificado dela atua como âncora de confiança, e é isso que impede um atacante de forjá-la ou removê-la. O resultado é que um espião passivo ou um atacante ativo de downgrade não consegue mais forçar o seu e-mail de entrada a trafegar em aberto.
O que o TLS-RPT acrescenta#
O MTA-STS sozinho é imposição sem visibilidade — você estaria dizendo aos remetentes para recusarem conexões inseguras, mas não teria como ver com que frequência isso de fato acontece ou quais remetentes estão falhando. O TLS-RPT é o canal de feedback. Ele funciona exatamente como o relatório agregado do DMARC e combina naturalmente com o hábito de ler relatórios DMARC.
Quando você publica um registro TLS-RPT, os remetentes participantes enviam a você um
relatório JSON diário resumindo cada sessão TLS que abriram com os seus hosts MX:
quantas tiveram sucesso, quantas falharam e — o mais importante — por que falharam.
Um relatório pode mostrar um certificado expirado em um dos seus servidores MX, uma
divergência de nome de host, uma negociação de STARTTLS interrompida ou um problema
na obtenção da política. É exatamente essa a informação de que você precisa antes de
se atrever a colocar o MTA-STS em enforce, porque uma falha no modo enforce
significa e-mail de entrada adiado ou rejeitado. O TLS-RPT é o que torna a implantação
segura em vez de um salto de fé.
Configurando o MTA-STS: o registro DNS e o arquivo de política#
O MTA-STS precisa de três coisas no lugar: um registro DNS, um arquivo de política e um subdomínio para hospedar o arquivo por HTTPS.
1. O registro TXT no DNS. Publique um registro TXT em _mta-sts.yourdomain.com.
Sua função é pequena — ele anuncia que uma política existe e carrega um id que os
remetentes usam para perceber quando a política muda.
_mta-sts.example.com. TXT "v=STSv1; id=20260725090000"
O id é uma string arbitrária de até 32 caracteres alfanuméricos. Um timestamp é a
convenção comum. A única regra que importa: sempre que você editar o arquivo de
política, mude o id. Os remetentes armazenam sua política em cache, e um novo id
é o sinal que os avisa para buscá-la novamente. Esqueça de incrementá-lo e suas
alterações podem passar despercebidas por todo o período do seu max_age.
2. O arquivo de política. Hospede um arquivo de texto puro no caminho fixo
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Ele lista o modo, cada nome
de host MX válido e um tempo de vida do cache:
version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.com
max_age: 86400
Cada linha mx deve corresponder a um nome de host dos registros MX do seu domínio,
e a forma curinga (*.example.com) corresponde a um único rótulo mais à esquerda.
Cada host MX que você lista precisa servir um certificado que esteja atualmente
válido, encadeie até uma CA pública e corresponda ao seu nome de host — caso
contrário, um remetente em modo enforce o recusará. O max_age é o tempo de vida do
cache em segundos; a RFC 8461 permite valores de até 31557600 (cerca de um ano).
Mantenha-o curto (um dia ou algo assim) enquanto estiver testando, para que as
mudanças se propaguem rapidamente, e depois aumente-o quando estiver confiante no
enforce — destinatários como o Google recomendam um max_age longo em produção,
embora o valor exato fique a seu critério.
3. O subdomínio mta-sts por HTTPS. O arquivo de política deve estar acessível
por HTTPS no subdomínio mta-sts com um certificado válido para
mta-sts.yourdomain.com. Na prática, você aponta esse subdomínio (via A/AAAA ou
CNAME) para o que quer que sirva o arquivo — um pequeno host estático ou uma CDN são o
comum — e garante que ele responda com Content-Type: text/plain. Muitos provedores
de DNS e de hospedagem agora oferecem uma opção gerenciada de MTA-STS que cuida do
arquivo e do certificado por você.
Configurando o TLS-RPT#
O TLS-RPT é de longe o mais simples dos dois: um único registro TXT, sem arquivo de política.
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
A tag rua indica para onde os relatórios vão. Ela aceita um endereço mailto:, um
endpoint https: que recebe relatórios via POST ou uma lista de ambos separada por
vírgulas. O JSON puro do TLS-RPT é denso, então a maioria das equipes aponta o rua
para um serviço de monitoramento que interpreta os relatórios em um painel legível — da
mesma forma que os relatórios DMARC geralmente fluem para um parser em vez de uma
caixa de entrada humana. Você pode publicar o TLS-RPT por conta própria, e vale a pena
fazê-lo antes do MTA-STS: ele lhe dá um retrato da saúde atual do seu TLS com zero
risco para o fluxo de e-mails.
Implantando o MTA-STS e o TLS-RPT com segurança#
A ordem das operações para o MTA-STS e o TLS-RPT importa mais do que os próprios registros — erre-a e você pode adiar o seu próprio e-mail de entrada. Siga a mesma disciplina de monitorar-depois-impor que rege uma boa implantação de DMARC.
1. Publique o TLS-RPT primeiro. Sem nenhuma política MTA-STS ainda, os relatórios simplesmente informam quanto do seu e-mail de entrada já usa TLS e se algum dos seus certificados MX está mal configurado. Corrija aqui qualquer coisa óbvia.
2. Publique o MTA-STS no modo testing. Adicione o registro DNS e o arquivo de
política com mode: testing. Nesse modo, os remetentes avaliam sua política e
reportam as falhas via TLS-RPT, mas ainda entregam os e-mails normalmente. Nada no
seu fluxo de e-mails muda — você está apenas coletando dados. Deixe-o aqui tempo
suficiente para capturar um ciclo completo dos seus correspondentes habituais, o ideal
sendo algumas semanas.
3. Leia os relatórios do TLS-RPT e corrija as falhas. Fique atento a problemas de
certificado, divergências de nome de host e hosts MX que você esqueceu de listar. Cada
falha no modo testing é uma falha que você teria causado no modo enforce. Continue
ajustando seus certificados e o arquivo de política até que os relatórios estejam
limpos.
4. Mude para mode: enforce. Assim que as falhas cessarem, edite o arquivo de
política para enforce e incremente o id no registro DNS para que os remetentes
o busquem novamente. A partir desse ponto, os remetentes compatíveis se recusarão a
entregar por uma conexão não autenticada ou rebaixada. Considere aumentar o max_age
agora, para uma proteção mais forte contra tentativas de downgrade.
Onde isso se encaixa junto ao SPF, DKIM e DMARC#
Vale a pena ser preciso sobre o que o MTA-STS e o TLS-RPT fazem e não fazem, porque é fácil arquivá-los sob "entregabilidade" e esperar a coisa errada.
SPF, DKIM e DMARC respondem à pergunta esta mensagem é mesmo de quem afirma ser? — eles autenticam a identidade e o conteúdo. MTA-STS e TLS-RPT respondem a uma pergunta diferente: a conexão que carregou esta mensagem estava de fato criptografada e verificada? — eles protegem a confidencialidade em trânsito. As duas camadas são complementares e independentes. Uma mensagem pode passar no DMARC enquanto trafega em texto puro, e pode trafegar por TLS imposto enquanto falha no DMARC. Uma configuração completa quer as duas.
Duas ressalvas honestas. Primeira, o MTA-STS e o TLS-RPT não fazem parte dos requisitos para remetentes em massa do Google e do Yahoo que entraram em vigor em 2024 — esses exigem SPF, DKIM, DMARC, cancelamento de inscrição com um clique e uma baixa taxa de spam, não políticas de segurança de transporte. Dito isso, os grandes provedores de fato publicam e honram o MTA-STS como destinatários, de modo que uma política que você publica é realmente imposta pelo Gmail e por outros quando eles entregam para você. Segunda, o MTA-STS não é uma solução para o problema da pasta de spam. Ele reforça a segurança do transporte de entrada; ele não melhora, por si só, onde o seu marketing de saída cai. A entrega na caixa de entrada ainda é decidida pela reputação do remetente, pelo engajamento e pela higiene da lista, e se o seu e-mail está indo para o spam, os motivos vivem nesses sinais, não na sua configuração de TLS. Trate o MTA-STS e o TLS-RPT como o capítulo de segurança de transporte de um domínio de envio maduro — vale a pena fazer, mas distinto das alavancas no guia de entregabilidade que de fato movem a entrega na caixa de entrada.
Se você quiser uma analogia, o MTA-STS é primo próximo do DANE, a forma mais antiga, baseada em DNSSEC, de impor TLS no SMTP. Ambos miram o mesmo problema de downgrade; o MTA-STS foi projetado para que domínios sem DNSSEC ainda pudessem obter a maior parte da proteção, usando o sistema de certificados web em vez disso. Se você já roda o DANE, talvez não precise do MTA-STS, mas os dois podem coexistir.
Perguntas frequentes#
O MTA-STS substitui o SPF, o DKIM ou o DMARC?#
Não — eles operam em camadas diferentes e você quer ambos. SPF, DKIM e DMARC autenticam o remetente e o conteúdo de uma mensagem, provando que ela realmente vem do seu domínio e não foi alterada. MTA-STS e TLS-RPT protegem o transporte: eles forçam a conexão que carrega a mensagem a usar TLS verificado e reportam quando isso não acontece. Uma mensagem precisa de autenticação e de entrega criptografada, então o MTA-STS fica ao lado do DMARC, sem substituir nenhum deles.
O MTA-STS e o TLS-RPT são exigidos pelo Google e pelo Yahoo?#
Não como parte dos requisitos para remetentes em massa de 2024, que exigem SPF, DKIM, DMARC, cancelamento de inscrição com um clique e uma taxa de spam abaixo de 0,3% — o MTA-STS não está nessa lista. Mas os grandes provedores publicam suas próprias políticas de MTA-STS e honram a sua como destinatários, de modo que uma política que você publica é de fato imposta pelo Gmail e por outros. É uma boa prática recomendada para um domínio de envio maduro, apenas não é uma exigência formal para chegar à caixa de entrada.
Qual é a diferença entre MTA-STS e DANE?#
Ambos impõem TLS no SMTP de entrada e defendem contra ataques de downgrade; eles diferem em como estabelecem a confiança. O DANE publica informações de certificado no DNS e depende do DNSSEC para tornar esses registros invioláveis. O MTA-STS evita a exigência do DNSSEC servindo sua política por HTTPS, usando o sistema comum de certificados web como âncora de confiança. O MTA-STS costuma ser mais fácil de implantar em domínios sem DNSSEC; os dois também podem funcionar em conjunto.
O MTA-STS vai melhorar minha entrega na caixa de entrada?#
Não diretamente. O MTA-STS é um controle de segurança de transporte para os e-mails que chegam ao seu domínio — ele não muda como o seu marketing de saída é filtrado. A entrega na caixa de entrada é determinada pela reputação do remetente, pelo engajamento, pelas taxas de reclamação e pela qualidade da lista. Vale a pena configurar o MTA-STS por segurança e completude, mas se seus e-mails estão caindo no spam, a solução está na higiene da sua lista e na reputação, não na sua política de TLS.
MTA-STS e TLS-RPT reforçam os canos por onde seus e-mails trafegam, mas a caixa de entrada se conquista na qualidade da lista. O verificador de e-mails gratuito detecta domínios mortos e erros de digitação antes que resultem em rejeições, e o plano gratuito roda o pipeline completo de verificação na sua lista — porque um domínio seguro e bem autenticado só conquista a entrega quando a lista por trás dele está limpa.
