O que é MTA-STS?
MTA-STS (Mail Transfer Agent Strict Transport Security) permite que um domínio declare que as conexões SMTP de entrada devem usar TLS com um certificado válido. Ele combina um registro DNS TXT em _mta-sts.seudominio.com com um arquivo de política servido por HTTPS em mta-sts.seudominio.com/.well-known/mta-sts.txt. O registro DNS anuncia que existe uma política e carrega um ID que muda sempre que a política é atualizada.
Sem o MTA-STS, o TLS oportunista do SMTP pode ser eliminado silenciosamente por um invasor no caminho, forçando a entrega do correio em texto simples. O MTA-STS preenche essa lacuna instruindo os servidores de envio a recusarem a entrega se o TLS não puder ser negociado. Ele emparelha naturalmente com o TLS-RPT, que envia relatórios por e-mail quando um remetente não consegue honrar a política. O padrão é definido na RFC 8461.
Por que verificar seu registro MTA-STS?
1Confirme se a política pode ser descoberta
Se o registro DNS estiver ausente ou malformado, os remetentes nunca procurarão seu arquivo de política – verifique se ele resolve
2Pegue um ID que nunca muda
O ID deve ser atualizado a cada mudança de política ou os caches atendem a uma política obsoleta – um verificador revela o valor atual
3Evite downgrades silenciosos de TLS
Um registro funcional sinaliza aos remetentes para exigir criptografia, protegendo o correio em trânsito contra interceptação
4Validar antes do modo de aplicação
Confirme o alinhamento do registro e da política durante o modo de teste, para que a mudança para aplicação não devolva e-mails legítimos
Como funciona o MTA-STS – passo a passo
Você hospeda um arquivo de política em https://mta-sts.yourdomain.com/.well-known/mta-sts.txt descrevendo o modo, hosts MX e max_age.
Você publica um registro TXT em _mta-sts.seudominio.com contendo a versão e um ID exclusivo.
Um servidor de envio prestes a entregar consultas de correio que registram TXT e vê uma política é anunciado.
Ele busca o arquivo de política HTTPS e valida o MX receptor e seu certificado TLS.
Se a política estiver no modo de aplicação e o TLS não puder ser validado, o remetente se recusará a entregar, em vez de recorrer ao texto simples.
Sintaxe do registro MTA-STS
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20240118T120000Z"
# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800Detalhamento de tags DNS
v=STSv1— versão do protocolo, sempre primeiroidentificação =— token exclusivo, alterações a cada atualização de políticaCampos do arquivo de política
Falhas e correções comuns do MTA-STS
Arquivo de política inacessível
O arquivo .well-known deve ser carregado por HTTPS com um certificado válido – corrija o host antes que os remetentes possam aplicá-lo
ID desatualizado
Esquecer de alterar o ID após editar a política faz com que os remetentes mantenham o antigo – altere-o a cada atualização
Incompatibilidade de MX
Se as entradas mx não corresponderem aos seus registros MX reais, o modo de aplicação bloqueará e-mails legítimos — mantenha-os sincronizados
Pulando direto para impor
Comece a testar com TLS-RPT para detectar problemas antes que o modo de aplicação possa devolver mensagens
Perguntas Frequentes
MTA-STS (Mail Transfer Agent Strict Transport Security) permite que seu domínio informe aos servidores de envio que o correio deve ser entregue por TLS com um certificado válido. Ele combina um registro DNS TXT em _mta-sts.yourdomain.com com um arquivo de política hospedado em HTTPS. Sem ele, a criptografia oportunista do SMTP pode ser eliminada por um invasor no caminho da rede, forçando seu e-mail a viajar em texto simples.
O registro TXT em _mta-sts.seudominio.com contém duas coisas: a versão (v=STSv1) e um id — um token exclusivo que você deve alterar sempre que atualizar o arquivo de política. O registro não contém a política em si; simplesmente anuncia que existe uma política e sinaliza, por meio de um ID alterado, quando os remetentes devem recuperá-la.
O modo é definido no arquivo de política HTTPS, não no registro DNS. No modo de teste, os remetentes relatam falhas de TLS (via TLS-RPT), mas ainda entregam mensagens, permitindo que você encontre problemas com segurança. No modo de aplicação, os remetentes recusam-se a entregar se o TLS não puder ser validado. A prática recomendada é executar testes com os relatórios ativados primeiro e, em seguida, mudar para aplicar assim que confirmar que tudo funciona.
Ambos exigem TLS para mensagens recebidas, mas ancoram a confiança de maneira diferente. DANE usa registros DNSSEC e TLSA para fixar certificados, portanto, depende da implantação do DNSSEC. O MTA-STS usa a PKI da web pública e uma política hospedada em HTTPS, portanto funciona sem DNSSEC. Muitos domínios adotam o MTA-STS primeiro porque é mais simples de implantar na infraestrutura existente.
Os motivos comuns são um registro TXT ausente ou malformado, um ID que não foi atualizado após uma alteração de política ou um arquivo de política que não é carregado por HTTPS com um certificado válido. Este verificador verifica o registro DNS; confirme também se o arquivo em /.well-known/mta-sts.txt está acessível e se suas entradas mx correspondem aos seus registros MX reais.