O que o verificador MTA-STS valida?

O verificador realiza uma validação completa: registro DNS TXT em _mta-sts.domain.com, arquivo de política HTTPS em mta-sts.domain.com/.well-known/mta-sts.txt, validade do certificado TLS e validação cruzada de registros MX com padrões da política.

Por que minha política MTA-STS não está sendo buscada?

Causas comuns: o subdomínio mta-sts não existe, HTTPS não está configurado, o certificado é inválido, o caminho do arquivo de política está errado, ou o servidor retorna redirecionamentos (não permitidos). O verificador relatará o erro específico.

O que significa 'MX não coberto pela política'?

Este aviso significa que um ou mais registros MX do seu domínio não correspondem a nenhum padrão na sua política MTA-STS. Esta é uma falha de segurança : adicione os padrões MX ausentes ao seu arquivo de política.

Por que o verificador mostra erros TLS?

MTA-STS exige que o arquivo de política seja servido via HTTPS com um certificado válido. Erros TLS podem significar: certificado expirado, certificado autoassinado, incompatibilidade de nome de host ou versão TLS desatualizada.

Qual é a diferença entre os modos testing e enforce?

No modo 'testing', os servidores remetentes relatam falhas TLS mas ainda entregam email. No modo 'enforce', a entrega é rejeitada se TLS falhar. Use testing primeiro para identificar problemas.

Com que frequência devo verificar minha configuração MTA-STS?

Verifique após qualquer alteração no DNS, registros MX ou configuração do servidor de email. Verifique também após renovações de certificado para o subdomínio mta-sts. Verificações mensais regulares ajudam a detectar problemas.

Como verifico MTA-STS para Microsoft 365 / Office 365?

Digite seu domínio em nosso MTA-STS Checker. Domínios Microsoft 365 com domínios personalizados precisam de configuração MTA-STS separada : a Microsoft não configura automaticamente. Você precisa criar o registro DNS TXT e hospedar o arquivo de política você mesmo ou usar um serviço de terceiros.

Como verifico MTA-STS para Google Workspace?

Use nossa ferramenta de consulta MTA-STS com seu domínio Google Workspace. Google Workspace suporta MTA-STS mas você precisa configurar você mesmo para domínios personalizados. O verificador valida seu registro DNS _mta-sts, busca a política e verifica que os padrões MX correspondam aos servidores de email do Google (ex: *.google.com ou aspmx.l.google.com).

MTA-STS Checker Grátis - Consulta e Validação Online

Por que verificar o seu MTA-STS

O transporte SMTP usa TLS de forma oportunista: se a cifragem falha, a ligação cai para texto plano sem qualquer alerta. Um atacante em posição de man-in-the-middle pode então remover o banner STARTTLS e forçar o envio dos seus emails em texto legível.

MTA-STS (RFC 8461) fecha esta lacuna. Publica uma política servida por HTTPS apoiada em PKI pública que ordena aos MTAs remetentes que recusem qualquer ligação sem TLS válido. É a camada que faltava para fechar a porta aos ataques de downgrade e ao spoofing TLS.

Verificar a sua configuração antes de passar para enforce é crítico:

Política avariada → os emails legítimos podem ser bloqueados
Padrões MX incompletos → alguns servidores permanecem vulneráveis
Certificado expirado → a política torna-se inválida, os MTAs remetentes voltam ao TLS oportunista

Casos de uso comuns:

Após a publicação → confirmar que DNS, política HTTPS e TLS são coerentes
Antes de mode: enforce → garantir que nenhum MX legítimo é excluído
Auditoria de segurança → validar a proteção contra downgrade TLS

Como usar este verificador em 3 passos

Passo 1: introduzir o domínio a analisar

Digite o domínio exatamente como aparece nos seus endereços de email:

captaindns.com (domínio principal)
marketing.captaindns.com (subdomínio se você envia a partir de um subdomínio)

A ferramenta consulta automaticamente _mta-sts.dominio, busca https://mta-sts.dominio/.well-known/mta-sts.txt e compara os padrões com os registros MX.

Passo 2: analisar os resultados

O verificador exibe:

Elemento	Descrição
Registro TXT	Versão `STSv1` e ID único da política
Política HTTPS	Conteúdo do arquivo `.well-known/mta-sts.txt`
Modo	`none`, `testing` ou `enforce`
Padrões MX	Lista de hosts autorizados pela política
max_age	Duração de cache da política em segundos
Certificado TLS	Validade, expiração, versão TLS do subdomínio `mta-sts`
Cobertura MX	Todos os MX resolvidos correspondem a um padrão

Passo 3: corrigir os problemas sinalizados

Os resultados são classificados por gravidade:

Crítico → a política é inutilizável, os MTAs remetentes ignoram-na
Aviso → funciona mas expõe a um risco ou proteção parcial
Info → boa prática não bloqueante

Corrija o DNS ou o arquivo de política, aguarde a propagação e relance o verificador.

O que é MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) é um mecanismo que:

Publica uma política HTTPS que indica quais hosts MX suportam TLS
Impõe a cifragem TLS entre MTAs remetentes e receptores
Bloqueia ataques de downgrade que removem STARTTLS

A arquitetura combina três elementos:

Elemento	Função
Registro DNS TXT	Publicado em `_mta-sts.dominio`. Sinaliza a existência de uma política e o seu ID.
Política HTTPS	Servida em `https://mta-sts.dominio/.well-known/mta-sts.txt`. Contém modo, MX, max_age.
Certificado TLS	O subdomínio `mta-sts` deve apresentar um certificado válido de uma CA reconhecida.

Exemplo de registro DNS:

_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260501T000000Z"

Exemplo de política:

version: STSv1
mode: enforce
mx: mail.captaindns.com
mx: *.mail.captaindns.com
max_age: 604800

Diferença em relação ao DANE: MTA-STS apoia-se na PKI pública (autoridades de certificação), DANE apoia-se em DNSSEC e nos registros TLSA. Ambos os mecanismos são compatíveis e podem ser implantados em conjunto.

O que o verificador verifica

Sete dimensões são analisadas em paralelo para produzir um score 0-100:

Registro DNS publicado

Verificação	Erro se...
TXT presente em `_mta-sts.dominio`	Nenhum registro
Começa com `v=STSv1`	Prefixo ausente ou malformado
Campo `id=` presente	ID em falta ou caracteres inválidos
Registro único	Vários TXT MTA-STS detectados

Busca do arquivo de política

Verificação	Erro se...
URL acessível via HTTPS	Ligação recusada ou timeout
Sem redirecionamentos	Servidor responde 3xx em vez de 200
Content-Type `text/plain`	Tipo MIME incorreto
HTTP em claro recusado	Política servida na porta 80

Sintaxe da política

Verificação	Erro se...
`version: STSv1` presente	Linha em falta ou versão desconhecida
`mode:` válido	Valor diferente de `none`, `testing`, `enforce`
Pelo menos uma linha `mx:`	Nenhum padrão MX definido
`max_age:` no intervalo	Fora dos limites RFC (1 a 31557600 segundos)

Cobertura dos servidores MX

Todos os hosts MX resolvidos para o domínio devem corresponder a pelo menos um padrão:

Correspondência direta: mx: mail.captaindns.com cobre mail.captaindns.com
Wildcard limitado a uma label: *.mail.captaindns.com cobre eu.mail.captaindns.com mas não mail.captaindns.com

Validade do certificado TLS

O subdomínio mta-sts.dominio é sondado via HTTPS:

Certificado não expirado
Nome do host presente no SAN
Cadeia completa até uma CA reconhecida
Versão TLS recente (1.2 mínimo)

Coerência entre DNS e política

O ID DNS e o ID da política servida devem corresponder. Uma divergência indica uma atualização parcial perigosa para a cache dos MTAs remetentes.

Presença de TLS-RPT

O verificador sinaliza a ausência do registro _smtp._tls (TLS-RPT, RFC 8460). Sem TLS-RPT, nunca saberá se a política provoca falhas de entrega silenciosas.

Diagnósticos comuns e soluções

Política inacessível (policy_fetch_failed)

Causa: o subdomínio mta-sts.dominio não responde, não serve HTTPS ou retorna um erro HTTP.

Soluções:

Verificar que mta-sts.dominio resolve em DNS (A ou CNAME)
Confirmar que é servido um certificado TLS válido (Let's Encrypt, autocert, etc.)
Confirmar que /.well-known/mta-sts.txt retorna 200 OK em text/plain

Certificado TLS inválido (cert_invalid)

Causa: certificado expirado, autoassinado, nome do host não coberto pelo SAN, ou cadeia incompleta.

Soluções:

Renovar o certificado antes da expiração
Incluir mta-sts.dominio no SAN
Servir a cadeia intermediária completa

Registro DNS ausente (missing_record)

Causa: nenhum TXT existe em _mta-sts.dominio.

Solução: publicar

_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260501T000000Z"

Política desativada (mode_none)

Causa: mode: none indica que MTA-STS é anunciado mas sem efeito.

Solução: passar para mode: testing após a publicação inicial, depois para mode: enforce quando TLS-RPT estiver limpo.

Cobertura MX incompleta (mx_partial_match)

Causa: um ou mais MX resolvidos não correspondem a nenhum padrão da política.

Solução: listar explicitamente cada host MX ou usar um wildcard mais amplo adequado à sua infraestrutura.

Ausência de TLS-RPT (tls_rpt_missing)

Causa: nenhum registro _smtp._tls.dominio está publicado.

Solução: publicar

_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Progressão de testing para enforce

Fase 1: publicação inicial em modo testing

version: STSv1
mode: testing
mx: mail.captaindns.com
max_age: 86400

Os MTAs remetentes relatam falhas TLS via TLS-RPT sem bloquear a entrega
Mantenha max_age curto (1 a 7 dias) para iterar rapidamente
Recolha relatórios TLS-RPT durante 2 a 4 semanas

Fase 2: estabilização e observação

Durante este período, verifique:

Nenhum MX legítimo excluído (TLS-RPT sinalizaria falhas mx-mismatch)
Nenhum problema de certificado nos hosts MX (TLS-RPT sinalizaria certificate-not-trusted)
Nenhum MTA remetente em dificuldade (relatórios vazios ou nulos)

Fase 3: passagem ao modo enforce

version: STSv1
mode: enforce
mx: mail.captaindns.com
max_age: 604800

Alongar max_age (mínimo 7 dias, até 1 ano)
Monitorizar TLS-RPT em contínuo: as falhas tornam-se agora não-entregas
Preparar um plano de rollback (voltar a testing rapidamente se necessário)

Erros frequentes:

max_age demasiado curto → os MTAs remetentes voltam a buscar a política com demasiada frequência, carga inútil
max_age demasiado longo → uma alteração de MX leva semanas a propagar-se
Padrões MX incompletos → os emails legítimos são rejeitados silenciosamente

MTA-STS vs DANE

Ambos os mecanismos protegem o transporte SMTP contra ataques de downgrade, mas com abordagens diferentes.

Critério	MTA-STS	DANE
RFC	8461	7672
Pré-requisitos	PKI pública (CA)	DNSSEC assinado
Distribuição	DNS TXT + HTTPS	DNS (registros TLSA)
Pinning	Não	Sim (impressão digital do certificado)
Adoção MTA remetente	Ampla (Gmail, Outlook)	Limitada fora do ecossistema alemão
Reporting	TLS-RPT (RFC 8460)	TLS-RPT (RFC 8460)
Custo de implementação	Moderado (DNS + HTTPS)	Elevado (DNSSEC obrigatório)

Quando escolher MTA-STS: não tem DNSSEC, ou pretende uma implementação rápida com esforço operacional mínimo.

Quando escolher DANE: o seu domínio já está assinado com DNSSEC e pretende a garantia adicional do pinning criptográfico.

Ambos são compatíveis e podem ser implantados em paralelo. Os MTAs remetentes escolhem o mecanismo que sabem tratar.

Ferramentas complementares e recursos

Ferramenta	Utilidade
Validador Sintaxe MTA-STS	Validar a sintaxe de uma política ANTES da publicação
Gerador MTA-STS	Criar registro TXT e política HTTPS conformes
Alojamento MTA-STS	Alojar gratuitamente a sua política com TLS gerido
Verificador TLS-RPT	Verificar o registro TLS-RPT associado
Monitoramento TLS-RPT	Receba e analise automaticamente os seus relatórios TLS-RPT
Inspetor DMARC	Completar a autenticação de email com DMARC
Lookup MX	Inspecionar os registros MX do domínio

Recursos: