# Como configuro MTA-STS e TLS-RPT para meu domínio? > O MTA-STS exige um registro TXT em _mta-sts, um arquivo de política servido por HTTPS em mta-sts.seudominio e um registro TXT TLS-RPT para relatórios. - URL: https://postelva.com/pt/guides/mta-sts-setup/ - Última atualização: 2026-11-12 - Editor: Postelva (https://postelva.com) O MTA-STS diz a outros servidores de e-mail para entregar a você somente por TLS verificado. Ele exige dois registros DNS e um pequeno arquivo em um servidor web. **Resposta rápida — Como configuro MTA-STS e TLS-RPT?** Publique um registro TXT em _mta-sts.seudominio com v=STSv1 e um id, sirva um arquivo de política em https://mta-sts.seudominio/.well-known/mta-sts.txt com um certificado válido e adicione um registro TXT em _smtp._tls para os relatórios TLS-RPT (RFC 8461 e RFC 8460). **Postelva** hospeda os registros DNS; o arquivo de política precisa de um servidor web com HTTPS. ## As quatro peças de uma configuração de MTA-STS e TLS-RPT *Nomes e formatos da RFC 8461 e da RFC 8460, lidas em 12 de novembro de 2026.* | Peça | Onde | Conteúdo | Hospedado em | | --- | --- | --- | --- | | Registro MTA-STS | TXT em _mta-sts.example.com | v=STSv1; id=20261112T000000Z | Seu DNS (DNS gratuito na Postelva) | | Nome do host web | A, AAAA ou CNAME em mta-sts.example.com | Aponta para um servidor web | Seu DNS | | Arquivo de política | https://mta-sts.example.com/.well-known/mta-sts.txt | version, mode, linhas mx, max_age | Um servidor web com HTTPS e um certificado válido | | Registro TLS-RPT | TXT em _smtp._tls.example.com | v=TLSRPTv1; rua=mailto:tlsrpt@example.com | Seu DNS | ## Configure o MTA-STS em seis etapas 1. **Liste seus hosts MX** — A política deve nomear os hosts de e-mail do seu provedor. O Proton Mail usa mail.protonmail.ch e mailsec.protonmail.ch, o Mailbox.org usa mxext1 a mxext4.mailbox.org. 2. **Configure o nome do host web** — No editor de DNS, adicione um registro para mta-sts que aponte para um servidor web que você controla e obtenha um certificado válido para mta-sts.seudominio. 3. **Publique o arquivo de política em modo testing** — Crie o arquivo mta-sts.txt na pasta .well-known, com mode: testing e um max_age curto. 4. **Adicione o registro TXT _mta-sts** — Publique v=STSv1; id= seguido de um valor único, como a data e a hora. 5. **Adicione o registro TLS-RPT** — Publique o registro TXT em _smtp._tls com um endereço mailto em rua e leia os relatórios diários. 6. **Mude para enforce** — Quando os relatórios não mostrarem falhas nos seus próprios hosts MX, altere o mode para enforce, aumente o max_age e atualize o id. *Registros DNS e arquivo de política (mode testing)* ```dns ; DNS records _mta-sts.example.com. IN TXT "v=STSv1; id=20261112T000000Z" _smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com" mta-sts.example.com. IN CNAME webhost.example.net. ; File served at https://mta-sts.example.com/.well-known/mta-sts.txt version: STSv1 mode: testing mx: mail.protonmail.ch mx: mailsec.protonmail.ch max_age: 86400 ``` ## 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](https://postelva.com/pt/spf-vs-dkim-vs-dmarc/ "SPF vs DKIM vs DMARC: what is the difference?"). ## 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](https://postelva.com/pt/what-is-an-mx-record/ "What is an MX record?"). ## 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](https://postelva.com/pt/guides/move-email-provider-without-downtime/ "How to move email to a new provider without losing mail") 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](https://postelva.com/pt/guides/dmarc-setup/ "How to set up DMARC: p=none to p=reject"). ## 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](https://postelva.com/pt/guides/check-email-dns-records/ "How to check MX, SPF, DKIM and DMARC records"): 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. ## Perguntas sobre MTA-STS e TLS-RPT ### Posso hospedar o arquivo de política do MTA-STS no meu provedor de DNS? Não apenas em um host de DNS: o arquivo precisa de um servidor web respondendo por HTTPS em mta-sts.seudominio. O encaminhamento de URL não funciona, pois os redirecionamentos não devem ser seguidos. ### Qual max_age devo usar? A RFC 8461 diz que o valor normalmente vai de semanas para cima, com 604800 segundos (uma semana) no seu exemplo. Comece com um valor curto em modo testing e aumente quando os relatórios estiverem limpos. ### MTA-STS é a mesma coisa que DANE? Não. Ambos protegem o TLS entre servidores, mas o DANE depende de DNSSEC e de registros TLSA, enquanto o MTA-STS depende de um arquivo de política HTTPS. O TLS-RPT reporta sobre ambos. ### O que acontece se meu certificado expirar em modo enforce? Os remetentes com suporte a MTA-STS deixam de entregar aos seus hosts quando o certificado de um host MX falha, e o e-mail fica esperando na fila deles. O mesmo vale para uma linha mx ausente, então fique de olho no TLS-RPT. ### Preciso usar o modo enforce? Não. O modo testing já fornece relatórios, e o modo none desativa a política. **Em resumo** - O MTA-STS (RFC 8461) torna o TLS obrigatório para os e-mails entregues ao seu domínio. - Configuração: um registro TXT em _mta-sts, um arquivo de política HTTPS em mta-sts.seudominio/.well-known/mta-sts.txt e um registro TXT em _smtp._tls para o TLS-RPT (RFC 8460). - A política lista mode (enforce, testing, none), hosts mx e max_age, no máximo 31,557,600 segundos. - Os redirecionamentos não devem ser seguidos, então o encaminhamento de URL não pode servir o arquivo. - Altere o id sempre que a política mudar; atualize primeiro o arquivo, depois o registro TXT. - Comece em modo testing e leia os relatórios TLS-RPT antes de passar para enforce. - Postelva hospeda os registros DNS gratuitamente; um .com custa US$ 12,49/ano por ano. ## Fontes 1. [RFC 8461, SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.html) — RFC Editor (lido em 2026-11-12) 2. [RFC 8460, SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.html) — RFC Editor (lido em 2026-11-12) 3. [Diretrizes para remetentes de e-mail](https://support.google.com/a/answer/81126) — Google Workspace Admin Help (lido em 2026-11-12) 4. [Domínio personalizado e antifalsificação](https://proton.me/support/anti-spoofing-custom-domain) — Proton (lido em 2026-11-12) --- Postelva: A Postelva registra nomes de domínio para e-mail privado — o endereço que você mantém quando troca de provedor — pagos em cripto e sem KYC: sem documento de identidade, apenas um e-mail verificado por domínio. Ela é operada pela DomaineGoat LLC, empresa registrada no Panamá; os domínios são registrados por meio de seu parceiro registrador credenciado pela ICANN. Um .com custa US$ 12,49/ano, o mesmo preço todos os anos.