Como verificar o MTA-STS antes de mudar para enforce
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
- Abra o verificador de MTA-STS em massa.
- Cole os domínios, um por linha: até 100 por rodada, ou 500 depois de um login gratuito com o Google.
- Clique em Check MTA-STS (verificar MTA-STS). Os registros
_mta-stse_smtp._tlse os registros MX de cada domínio são lidos, e o arquivo de política é buscado uma vez via HTTPS. - 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. - 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 parawwwconta como nenhuma política. - Sem TLS-RPT. Publique
_smtp._tls.<domain>comv=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: testingparamode: enforceno arquivo de política, depois altere oidno 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. Omax_agepode 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