Todos os artigos

Como verificar o MTA-STS antes de mudar para enforce

··3 min de leitura

Antes de mudar o MTA-STS de testing para enforce, verifique quatro coisas: o registro _mta-sts, o arquivo de política, se todo host MX está coberto pela política e se os relatórios TLS-RPT não mostram falhas. Cole seus domínios no verificador de MTA-STS em massa para as três primeiras; os seus relatórios TLS-RPT cobrem a quarta.

Verificar o MTA-STS de uma lista de domínios →

Verifique em massa

  1. Abra o verificador de MTA-STS em massa.
  2. Cole os domínios, um por linha: até 100 por rodada, ou 500 depois de um login gratuito com o Google.
  3. Clique em Check MTA-STS (verificar MTA-STS). Os registros _mta-sts e _smtp._tls e os registros MX de cada domínio são lidos, e o arquivo de política é buscado uma vez via HTTPS.
  4. Leia cada linha: Enforced, Testing, Off, Broken ou Not set up, com o modo, o max_age, qualquer host MX que a política não cubra e o endereço do TLS-RPT.
  5. Qualquer domínio marcado como Broken, ou com um MX não coberto, não está pronto para o enforce.

Faça à mão

O registro e o arquivo de política, aqui para um domínio em modo testing:

dig +short txt _mta-sts.fastmail.com
# "v=STSv1; id=20260728T132000"

curl -s https://mta-sts.fastmail.com/.well-known/mta-sts.txt
# version: STSv1
# mode: testing
# mx: *.messagingengine.com
# max_age: 86400

Depois compare cada host MX com as linhas mx: da política (rode com bash):

d=fastmail.com
pol=$(curl -s https://mta-sts.$d/.well-known/mta-sts.txt | tr -d '\r')
for mx in $(dig +short mx $d | awk '{print $2}' | sed 's/\.$//'); do
  ok=no
  for p in $(echo "$pol" | awk '/^mx:/{print $2}'); do
    [ "$mx" = "$p" ] && ok=yes
    [ "${p#\*.}" != "$p" ] && [ "${mx#*.}" = "${p#\*.}" ] && ok=yes
  done
  echo "$mx covered=$ok"
done
# in2-smtp.messagingengine.com covered=yes
# in1-smtp.messagingengine.com covered=yes

E o certificado que cada MX apresenta, do qual a política depende:

openssl s_client -starttls smtp -connect in1-smtp.messagingengine.com:25 \
  -verify_hostname in1-smtp.messagingengine.com -verify_return_error -brief < /dev/null 2>&1 | grep -E "Verification|Peer certificate"
# Peer certificate: CN=*.messagingengine.com
# Verification: OK

Rodamos esses comandos em 9 de novembro de 2026. O teste do curinga segue a RFC 8461, seção 4.1: *.example.com corresponde a mail.example.com "but not example.com or foo.bar.example.com" (mas não a example.com nem a foo.bar.example.com). Muitas redes domésticas e de escritório bloqueiam a porta 25 de saída, então a etapa do openssl pode precisar rodar de um servidor. O verificador em massa não testa os certificados dos MX; este comando testa.

O que corrigir antes do enforce

  • Um MX não coberto. Adicione uma linha mx: para ele. A RFC 8461, seção 5 diz que, no modo enforce, os remetentes "MUST NOT deliver the message to hosts that fail MX matching or certificate validation or that do not support STARTTLS." (não podem entregar a mensagem a hosts que falham na correspondência de MX ou na validação do certificado, ou que não suportam STARTTLS). Isso pega quem adiciona um MX de backup ou troca de provedor de e-mail.
  • O arquivo de política não carrega. Ele precisa responder HTTP 200 em mta-sts.<domain> com um certificado válido para esse nome. A RFC diz que "HTTP 3xx redirects MUST NOT be followed" (redirecionamentos HTTP 3xx não podem ser seguidos), então um redirecionamento para www conta como nenhuma política.
  • Sem TLS-RPT. Publique _smtp._tls.<domain> com v=TLSRPTv1; rua=mailto:... (RFC 8460). No modo testing, os relatórios são a única forma de ver as falhas.
  • A troca. Mude primeiro mode: testing para mode: enforce no arquivo de política, depois altere o id no registro TXT para que os remetentes busquem a nova política. A seção 8.1 dá essa ordem, para que os remetentes nunca combinem um id novo com o arquivo antigo. O max_age pode ser no máximo 31557600 segundos (um ano); a RFC 8461 espera semanas ou mais quando você tiver confiança.

A maioria dos domínios nem publica MTA-STS; veja o nosso estudo sobre a adoção do MTA-STS. Para escrever os registros, use o gerador de MTA-STS.

Próximo passo: verifique os endereços para os quais você envia

O MTA-STS protege os e-mails que chegam ao seu domínio. Os bounces que prejudicam os seus envios vêm dos endereços da sua própria lista. Envie-a em /verify para checar cada caixa postal sem enviar nada. As primeiras 100 checagens são grátis com login do Google, sem cartão.

Pro, US$ 39 por mês: verificação de e-mails ilimitada.* Nunca medida, nunca cortada. Veja os preços.

*Uso justo: as primeiras 100.000 verificações do mês em velocidade máxima, depois mais devagar, nunca cortado.

Leia também: auditar a autenticação de e-mail do seu domínio, SPF, DKIM e DMARC explicados.

Perguntas frequentes

Como sei se o meu MTA-STS está pronto para o enforce?

O registro TXT _mta-sts existe uma única vez com um id válido, o arquivo de política carrega via HTTPS com certificado válido e HTTP 200, todo host MX corresponde a uma linha mx:, cada MX apresenta um certificado válido e os seus relatórios TLS-RPT não mostram falhas.

O que acontece se um host MX não estiver na minha política MTA-STS?

No modo testing, os remetentes que suportam TLS-RPT reportam uma falha e entregam mesmo assim. No modo enforce, a RFC 8461 diz que eles não podem entregar a esse host.

A URL da política mta-sts pode redirecionar?

Não. A RFC 8461 diz que redirecionamentos HTTP 3xx não podem ser seguidos e que só uma resposta 200 é uma política válida.

Preciso alterar o id quando mudar para enforce?

Sim. Os remetentes comparam o id do registro TXT com a política que guardaram em cache. Um id novo diz a eles para buscar a política atualizada.

Verifique e-mails por USD 39,00/mês, sem bloqueio

Checagem SMTP real da caixa postal. Sem créditos e sem cobrança por e-mail.

Começar agora

Leia o original em inglês