Seu MTA-STS pode não estar protegendo nada: como verificar
Publicado: 16 de outubro de 2026
Nesta semana o nosso próprio monitor detectou isso no nosso próprio domínio. O registro TXT _mta-sts estava publicado e qualquer verificador de DNS o dava como correto. Mas a política que ele anunciava não podia ser lida: o servidor por trás de mta-sts. respondia com um certificado autoassinado. Para qualquer servidor que nos enviasse e-mail, o nosso MTA-STS não existia.
É um erro fácil de deixar passar, porque nada quebra. O e-mail continua chegando. A única coisa que se perde é a proteção que você achava que tinha.
O que o MTA-STS precisa para funcionar
O MTA-STS (RFC 8461) diz aos outros servidores de e-mail: «entregue o meu e-mail só por uma conexão criptografada, e só para estes servidores». Ele tem duas peças, e as duas precisam estar certas:
- Um registro TXT em
_mta-sts.seudominio.comque anuncia a política, por exemplov=STSv1; id=20261016000000;. - Um arquivo de texto, a política em si, servido em
https://mta-sts.seudominio.com/.well-known/mta-sts.txt.
A segunda peça tem três requisitos rígidos: precisa ser servida por HTTPS, com um certificado válido para mta-sts.seudominio.com emitido por uma autoridade pública, e com uma resposta 200 direta. Quem envia não segue redirecionamentos.
Uma política típica é assim:
version: STSv1
mode: testing
mx: mx1.yourprovider.net
mx: mx2.yourprovider.net
max_age: 86400O que acontece quando a política não pode ser lida
Um remetente que suporta MTA-STS, como o Gmail ou o Microsoft 365, vê o registro TXT e tenta baixar a política. Se não consegue, por um certificado ruim, um redirecionamento ou um arquivo que falta, age como se o seu domínio não tivesse MTA-STS. Entrega a mensagem como antes: criptografada se puder e em texto puro se não.
Não há devolução nem aviso. O registro no DNS diz que você está protegido, e os remetentes que importam o estão ignorando.
Se você também publica TLS-RPT (_smtp._tls.seudominio.com), os relatórios diários dos remetentes vão mostrar isso como sts-policy-fetch-error ou sts-webpki-invalid. Sem TLS-RPT, ninguém avisa.
As causas habituais
O site mta-sts não existe no servidor web
O nome aponta para o seu servidor, mas não há nenhum site configurado para ele. O servidor responde com o site padrão, que costuma ter um certificado de outro nome ou um autoassinado. Era o nosso caso.
O certificado não cobre o nome
O certificado é válido, mas só para seudominio.com e www.seudominio.com. Um certificado curinga para *.seudominio.com cobre mta-sts.seudominio.com; um só do domínio, não.
Um redirecionamento no caminho
As regras que mandam tudo para https://www ou para a página inicial também pegam o arquivo da política. Para um navegador está tudo bem; para um servidor de e-mail é uma falha.
O certificado expirou
Funcionava quando foi montado. Noventa dias depois a renovação falhou para esse nome, e ninguém voltou a olhar.
Como verificar
Primeiro, o registro:
dig +short TXT _mta-sts.seudominio.comDepois, a política, do jeito que um remetente a pediria. Se o certificado não for válido, o curl vai recusar a conexão e dizer por quê:
curl -sS -D - https://mta-sts.seudominio.com/.well-known/mta-sts.txtO que você quer ver é um 200, Content-Type: text/plain e o texto da política. Para ver qual certificado o servidor apresenta de verdade:
openssl s_client -connect mta-sts.seudominio.com:443 -servername mta-sts.seudominio.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -ext subjectAltName -enddateO subjectAltName precisa incluir mta-sts.seudominio.com, e o emissor precisa ser uma autoridade pública, não o seu próprio servidor.
Por fim, compare as linhas mx: da política com os seus registros MX reais (dig +short MX seudominio.com). Um servidor que falte na política será recusado assim que você passar para enforce.
O nosso diagnóstico gratuito faz essas verificações de uma vez: o registro, a política, o certificado dela e a coincidência com os seus registros MX.
Como corrigir
- Crie um site para
mta-sts.seudominio.comno seu servidor web, ou em qualquer hospedagem estática, que sirva só o arquivo/.well-known/mta-sts.txtcomotext/plain. - Obtenha um certificado para esse nome exato. O Let's Encrypt é gratuito; com Apache e certbot é um comando:
certbot --apache -d mta-sts.seudominio.com. - Garanta que nenhum redirecionamento se aplica a esse site.
- Verifique de novo com o
curl. Se a resposta for o texto da política, sem erros, os remetentes já conseguem lê-la.
Não é preciso mudar o registro TXT para corrigir. Os remetentes que falharam vão tentar de novo e encontrar a política.
Depois: de testing para enforce
Comece com mode: testing. Os remetentes leem a política, informam os problemas por TLS-RPT e continuam entregando. Quando os relatórios estiverem limpos por umas duas semanas, passe para mode: enforce, suba o max_age para no mínimo uma semana (604800) e mude o id do registro TXT para que os remetentes baixem a versão nova.
Mais uma coisa: o certificado de mta-sts. é renovado como qualquer outro, e se uma renovação falhar, a proteção volta a desaparecer em silêncio. É o tipo de coisa que vale a pena vigiar de forma contínua, não verificar uma vez.