Skip to content
Comece com 100 créditos de verificação grátis
Qualisend
Ferramenta gratuita

Gerador de MTA-STS e TLS-RPT.

Exija a entrega criptografada dos seus e-mails de entrada. Informe seu domínio e seus hosts MX e receba as três peças — o registro _mta-sts, o arquivo de política e o registro TLS-RPT _smtp._tls — geradas ao vivo no seu navegador. Sem conta, sem cartão.

Um por linha — seus nomes de host MX exatos (um curinga como *.yourprovider.com é permitido). Eles precisam corresponder aos certificados que seus servidores MX apresentam.

Por quanto tempo os destinatários mantêm a política em cache. 604800 (1 semana) é o comum; comece com um valor menor durante os testes.

Para onde os relatórios diários de TLS-RPT (JSON) são enviados — é assim que você verá as falhas de entrega.

1. Registro DNS de MTA-STS (TXT)
v=STSv1; id=…

Publique como registro TXT em _mta-sts.yourdomain.com.

2. Arquivo de política
version: STSv1 mode: testing mx: mail.yourdomain.com max_age: 604800

Sirva isto via HTTPS em https://mta-sts.yourdomain.com/.well-known/mta-sts.txt (certificado válido, content-type text/plain).

3. Registro DNS de TLS-RPT (TXT)
v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com

Publique como registro TXT em _smtp._tls.yourdomain.com.

Comece no modo testing. Execute primeiro mode: testing e acompanhe os relatórios de TLS-RPT — só mude para enforce quando eles confirmarem que todo destinatário alcança seu MX por TLS válido, ou você corre o risco de bloquear seu próprio e-mail de entrada.

Como implementar com segurança

O MTA-STS protege os e-mails que chegam até você; SPF, DKIM e DMARC autenticam os e-mails que saem. O guia de MTA-STS e TLS-RPT cobre toda a implementação, e a verificação de saúde do domínio confirma que os registros resolvem assim que forem publicados.

Publique as três, em modo de teste
Adicione os dois registros TXT, hospede o arquivo de política via HTTPS no subdomínio mta-sts e mantenha mode: testing para que nada seja bloqueado ainda.
Acompanhe o TLS-RPT, depois aplique enforce
Assim que os relatórios diários confirmarem que todo remetente alcança seu MX por TLS válido, mude para mode: enforce e incremente o id da política.

Por que exigir TLS no e-mail de entrada

A criptografia SMTP é oportunista por padrão, o que significa que pode ser removida silenciosamente entre servidores. MTA-STS e TLS-RPT fecham essa brecha e dão visibilidade sobre a entrega — um complemento à autenticação que impede a falsificação. Configure corretamente SPF, DKIM e DMARC para o envio, e MTA-STS para o recebimento.

Gerador de MTA-STS e TLS-RPT — Perguntas frequentes

O MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) permite que seu domínio informe aos servidores de envio que o e-mail de entrada deve ser entregue por TLS aos seus hosts MX autenticados. Sem ele, a criptografia SMTP é oportunista e pode ser removida por um invasor no meio do caminho; o MTA-STS fecha essa brecha de rebaixamento. É um registro DNS TXT que aponta para um arquivo de política servido por HTTPS.

No modo testing, os destinatários que oferecem suporte a MTA-STS ainda entregam o e-mail mesmo que a verificação da sua política falhe, mas relatam a falha via TLS-RPT — assim você vê os problemas sem arriscar a entrega. No modo enforce, um destinatário se recusa a entregar a um MX que não corresponde à política ou apresenta um certificado inválido. Comece sempre em testing, confirme que os relatórios estão limpos e depois passe para enforce.

O TLS-RPT (RFC 8460) é o registro complementar em _smtp._tls.seudominio. Ele pede aos servidores de recebimento que enviem um relatório JSON diário dos sucessos e falhas do handshake TLS quando entregam ao seu MX. Esses relatórios são como você confirma que todo remetente consegue alcançá-lo por TLS válido antes de mudar o MTA-STS para enforce — e como você detecta problemas de certificado depois.

Três coisas, todas geradas aqui: (1) um registro TXT em _mta-sts.seudominio contendo v=STSv1 e um id que você incrementa sempre que a política mudar; (2) o próprio arquivo de política, servido via HTTPS em https://mta-sts.seudominio/.well-known/mta-sts.txt com um certificado válido; e (3) o registro TXT de TLS-RPT em _smtp._tls.seudominio. Os registros DNS sozinhos não bastam — o arquivo de política precisa estar acessível por HTTPS.

Ambos exigem TLS para o SMTP de entrada, mas diferem na âncora de confiança. O DANE publica registros TLSA protegidos por DNSSEC; o MTA-STS usa uma política hospedada via HTTPS mais DNS e não exige DNSSEC, o que facilita a implementação na maioria dos domínios. Gmail, Outlook e Yahoo todos respeitam o MTA-STS, então hoje é a opção com maior suporte.

Proteja o transporte — depois limpe a lista

O MTA-STS protege a entrega; verificar sua lista protege sua reputação. Comece grátis com 100 créditos, sem cartão.

Comece a verificar