Gerador de políticas MTA-STS e registros DNS TLS-RPT

Gerador de políticas MTA-STS e registros DNS TLS-RPT

Documentação técnica completa e boas práticas para geração de arquivos de política RFC 8461 MTA-STS, registros DNS TXT _mta-sts e relatórios RFC 8460 TLS-RPT.

Predefinições:
Configuração de política e DNS

Host da política: mta-sts.example.com

Strict security: rejects unencrypted/invalid TLS delivery.

Nomes de host de troca de e-mail (MX) autorizados2
mx:mail.example.com
mx:mx2.example.com
7 days (1 week)

Atualize o ID ao editar o arquivo de política para que os remetentes recarreguem.

Relatórios de incidentes SMTP TLS-RPT (RFC 8460)
version: STSv1
mode: enforce
mx: mail.example.com
mx: mx2.example.com
max_age: 604800
Postura de imposição
enforceStrict TLS
Destinos de e-mail autorizados
2 MX Patterns
Vida útil do cache da política
7 days (1 week)

Compilação local de latência zero

Sintetiza arquivos de política RFC 8461 e registros DNS TXT instantaneamente na memória do navegador sem transmissões de rede.

Validação RFC 8461 e RFC 8460

Valida sintaxe de curinga MX, restrições de não-IP, limites alfanuméricos de ID de política e padrões de entrega HTTPS.

Pronto para implantação multiplataforma

Exporta snippets prontos para implantação em BIND, Cloudflare, Route 53, Nginx, Caddy, Apache e HashiCorp Terraform.

Referência técnica e guia de arquitetura

Guia do Desenvolvedor: Gerador de Políticas MTA-STS e Registros DNS TLS-RPT — Guia de referência

Documentação técnica completa e boas práticas para geração de arquivos de política RFC 8461 MTA-STS, registros DNS TXT _mta-sts e relatórios RFC 8460 TLS-RPT.

Parâmetros principais e controles

modestring (enforce | testing | none)

Determina o nível de imposição do MTA-STS para conexões SMTP de entrada. 'testing' solicita relatórios de falhas de TLS sem rejeitar mensagens; 'enforce' exige TLS válido e recusa conexões inseguras; 'none' desativa a política.

Padrão: testing
mxstring | string[]

Lista de padrões de hosts Mail Exchanger autorizados (FQDNs ou curingas de nível único como *.mail.example.com) contra os quais os remetentes devem validar certificados SAN via TLS.

Padrão: mail.example.com
max_ageinteger (segundos)

Tempo em segundos durante o qual o MTA remetente mantém a política armazenada em cache local. Valores recomendados em produção variam entre 604800 (1 semana) e 1209600 (2 semanas). Na fase inicial, indica-se 86400.

Padrão: 604800
policy_idstring

Identificador exclusivo definido no registro DNS TXT _mta-sts (geralmente um carimbo de data/hora ou hash de versão, ex: 2026101701). Sua alteração força os MTAs a invalidarem o cache e baixarem novamente o arquivo mta-sts.txt.

Padrão: 20261017000000
ruastring (mailto URI)

Endereço de e-mail especificado no registro _smtp._tls para onde MTAs remetentes compatíveis encaminham relatórios diários agregados em formato JSON sobre falhas de conexão TLS (TLS-RPT).

Padrão: mailto:[email protected]

Dicas profissionais e melhores práticas

Configure o registro _smtp._tls e

Configure o registro _smtp._tls e mantenha o MTA-STS no modo 'testing' por ao menos duas semanas antes de aplicar 'enforce'. Monitore os relatórios agregados diários para identificar incompatibilidades de cifras, certificados intermediários ausentes ou falhas de SNI sem perder mensagens legítimas.

O arquivo deve ser servido em https

O arquivo deve ser servido em https://mta-sts.<dominio>/.well-known/mta-sts.txt com status HTTP 200, Content-Type text/plain e certificado TLS emitido por autoridade pública confiável. Redirecionamentos entre hosts distintos e certificados inválidos anulam o carregamento da política.

As entradas 'mx

As entradas 'mx:' devem corresponder exatamente aos registros MX da zona DNS e aos nomes SAN contidos no certificado TLS do servidor de e-mail. Se o MX apontar para mail.example.com, o certificado precisa contemplar mail.example.com ou *.example.com.

Problemas comuns e solução de problemas

Falha na obtenção da política: MTAs relatam erro de conexão HTTPS ou certificado no subdomínio mta-sts

Verifique se os registros DNS A/AAAA para 'mta-sts.<seudominio>' estão corretos e se o servidor web possui certificado válido para esse subdomínio. Assegure que a porta 443 responda globalmente em menos de 10 segundos sem redirecionamentos externos.

Rejeição de e-mails legítimos após a ativação do modo 'enforce'

Verifique se o certificado TLS de algum servidor MX expirou ou se o comando STARTTLS está inoperante. Como contingência rápida, altere a diretiva para 'testing' e incremente o policy_id no registro DNS TXT para renovar imediatamente os caches dos servidores remotos.

Perguntas frequentes (FAQ)

Qual a principal diferença entre MTA-STS e DANE TLSA?▼

O MTA-STS (RFC 8461) utiliza a infraestrutura convencional de Web PKI (certificados HTTPS emitidos por CAs reconhecidas) combinada com registros DNS TXT. Já o DANE (RFC 7672) vincula as chaves criptográficas diretamente ao DNS através de registros TLSA, exigindo uma infraestrutura integralmente assinada com DNSSEC.

Por que o parâmetro policy_id no DNS é tão importante?▼

Os MTAs remetentes armazenam a política em cache pela duração de max_age. Para evitar requisições HTTPS desnecessárias a cada envio, os servidores verificam apenas o campo 'id=' no DNS TXT. Se este valor não for alterado, o novo arquivo de política não será baixado.

O que ocorre se o servidor de envio não suportar MTA-STS?▼

Servidores que não suportam a RFC 8461 ignoram os registros DNS e a política HTTPS, operando pelo mecanismo STARTTLS oportunista habitual. Caso a criptografia não esteja disponível, a mensagem será transmitida em texto simples.

Posso configurar múltiplos servidores MX em uma única política MTA-STS?▼

Sim. Você pode declarar múltiplas diretivas 'mx:' no mesmo arquivo (por exemplo, 'mx: mx1.example.com' e 'mx: mx2.example.com'). Todos os servidores MX públicos de sua zona devem ser contemplados.

Ferramentas e utilitários relacionados

Todas as ferramentas →