Domain Stabilizer
Entrar

Seu MTA-STS pode não estar protegendo nada: como verificar

Publicado: 16 de outubro de 2026

ESENPT

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:

  1. Um registro TXT em _mta-sts.seudominio.com que anuncia a política, por exemplo v=STSv1; id=20261016000000;.
  2. 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: 86400

O 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.com

Depois, 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.txt

O 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 -enddate

O 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

  1. Crie um site para mta-sts.seudominio.com no seu servidor web, ou em qualquer hospedagem estática, que sirva só o arquivo /.well-known/mta-sts.txt como text/plain.
  2. 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.
  3. Garanta que nenhum redirecionamento se aplica a esse site.
  4. 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.

Verifique o seu domínio

O diagnóstico gratuito verifica SPF, DKIM, DMARC, MTA-STS, SSL, DNS e listas de bloqueio em menos de um minuto. Somente leitura e sem conta.

Diagnóstico gratuito

Se você gerencia os domínios dos seus clientes, o Domain Stabilizer os vigia de forma contínua e avisa quando algo piora. Como funciona

Domain Stabilizer

Estabilização de domínios: DMARC, SSL, DNS, MX, blacklists e uptime — correções exatas e evidência do trabalho.

Conexão segura (TLS)
Práticas alinhadas ao RGPD
Suporte útil
Produto
PreçosDiagnóstico gratuito do domínio

© 2026 Domain Stabilizer. Todos os direitos reservados.

Feito com ❤️ para equipes que se importam com entrega confiável.