Como configuro MTA-STS e TLS-RPT para meu domínio?

O que o MTA-STS protege?

O MTA-STS permite que um domínio de e-mail declare que oferece suporte a TLS e que os remetentes devem se recusar a entregar a qualquer um de seus hosts MX que não consiga apresentar um certificado válido. A RFC 8461, um Proposed Standard de setembro de 2018, o define. Sem ele, a criptografia entre servidores é oportunista: o remetente tenta STARTTLS e, se um atacante o remove, envia a mensagem em texto claro.

Com uma política em modo enforce, um remetente com suporte a MTA-STS busca sua política, verifica se o host MX aparece na lista mx e exige uma conexão TLS válida com um certificado correspondente. Se qualquer verificação falhar, a mensagem aguarda e não é entregue por um canal mais fraco. Ele protege apenas os e-mails recebidos e funciona somente para remetentes que o implementam. Ele não autentica mensagens: essa é a função dos registros em SPF vs DKIM vs DMARC.

O que vai no arquivo de política?

O arquivo de política é um arquivo de texto simples com linhas chave: valor, contendo a versão, o modo, os padrões MX permitidos e uma duração em segundos. A RFC 8461 define esses campos. version deve ser STSv1. mode é enforce (os remetentes não devem entregar a hosts que falhem nas verificações), testing (a entrega pode prosseguir, e os remetentes com suporte a TLS-RPT enviam relatórios de falha) ou none (como se não existisse política). Cada linha mx nomeia um host por extenso, por exemplo mail.protonmail.ch, ou usa um curinga no rótulo mais à esquerda, como *.example.net. max_age é um número de segundos, no máximo 31,557,600, e a RFC diz que normalmente deve ser de semanas ou mais. Seu exemplo usa 604800, uma semana.

O arquivo deve ser servido por HTTPS em mta-sts.seudominio com um certificado válido para esse nome. Somente uma resposta HTTP 200 conta e os redirecionamentos não devem ser seguidos, o que exclui o encaminhamento de URL, um serviço que responde com um redirecionamento. O arquivo deve ser enviado como text/plain. Use um pequeno servidor web ou uma hospedagem de páginas estáticas que você controle. As linhas mx devem corresponder aos registros do seu provedor, conforme listados em o que é um registro MX.

O que são o id e a ordem de atualização?

O id no registro TXT é um rótulo de 1 a 32 letras e dígitos que deve mudar sempre que a política mudar, para que os remetentes saibam que devem buscar o arquivo de novo. A RFC 8461 diz que ele identifica uma instância de uma política e que não há ordenação entre ids, então um carimbo de data e hora funciona bem.

Atualize nesta ordem: publique primeiro o novo arquivo de política e depois altere o id. Um remetente que visse o novo id antes do novo arquivo armazenaria em cache a política antiga novamente. Quando você troca de provedor de e-mail, os hosts MX também mudam, então edite as linhas mx antes de alterar os registros MX, mantenha os hosts antigos na lista durante a troca e incremente o id. Uma linha mx esquecida em modo enforce impede a chegada de e-mails, e o guia de migração como mover o e-mail para um novo provedor dá a ordem segura do restante.

O que é o TLS-RPT e o que os relatórios contêm?

O TLS-RPT é um formato de relatórios, a RFC 8460, no qual os servidores remetentes informam todos os dias quantas conexões TLS com seu domínio tiveram sucesso ou falharam. Você publica um registro TXT em _smtp._tls.seudominio com v=TLSRPTv1 e um campo rua contendo um endereço mailto: ou https:. Os relatórios por mailto devem ter uma assinatura DKIM válida do domínio que reporta.

Cada relatório é um documento JSON que cobre um dia UTC. Ele nomeia a política aplicada (MTA-STS, DANE ou nenhuma), conta as sessões bem-sucedidas e as que falharam e informa o tipo de falha, como certificate-expired ou starttls-not-supported, com os endereços IP de envio e de recebimento. É assim que você descobre que um certificado expirou ou que uma linha mx tem um erro de digitação, antes de passar para enforce. Trate as primeiras semanas como o período de teste recomendado para o DMARC.

Preciso de MTA-STS para um domínio de e-mail pessoal?

Não: o MTA-STS é um reforço opcional, e as regras dos grandes remetentes não o exigem. Google, Yahoo e Microsoft pedem SPF, DKIM e DMARC aos remetentes em massa e não listam o MTA-STS. Para um domínio pessoal no Proton Mail, Fastmail ou Mailbox.org, a configuração só vale a pena se você aceitar a manutenção de um servidor web e de um certificado.

Os provedores diferem. Segundo a leitura de Postelva de 12 de novembro de 2026 das listas de configuração de DNS de 4 provedores (Proton Mail, Tuta, Mailbox.org e Fastmail), 1 lista um registro MTA-STS em sua própria configuração (Tuta, um CNAME), e as páginas de ajuda lidas dos outros três não documentam nenhum. A configuração completa são 3 registros DNS e 1 arquivo. Verifique cada um com os comandos de como verificar registros MX, SPF, DKIM e DMARC: dig TXT _mta-sts.example.com +short e dig TXT _smtp._tls.example.com +short.

Uma definição citável: o MTA-STS é a política que torna o TLS obrigatório quando outros servidores entregam e-mails ao seu domínio, e o TLS-RPT é o relatório diário que avisa quando isso falha.