MTA-STS não funciona? Guia completo de solução de problemas

Q: Por que minha política MTA-STS não é recuperada?

O arquivo mta-sts.txt deve estar acessível na URL exata https://mta-sts.captaindns.com/.well-known/mta-sts.txt . Verifique se o subdomínio mta-sts resolve corretamente (CNAME ou registro A), se o certificado TLS é válido e se o servidor responde com o código 200 e o Content-Type text/plain . Os redirecionamentos HTTP para HTTPS não são aceitos por todos os clientes.

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

Seu servidor MX real não corresponde a nenhum pattern mx: no arquivo de política. Por exemplo, se o seu MX é captaindns-com.mail.protection.outlook.com mas a política contém mx: mail.protection.outlook.com (sem wildcard), o servidor remetente considera que o MX não está autorizado. Adicione o wildcard: mx: *.mail.protection.outlook.com .

Q: Por que o modo enforce bloqueia emails?

No modo enforce , os servidores remetentes rejeitam o envio se a política MTA-STS não puder ser satisfeita (certificado inválido, MX não coberto, política inacessível). Volte imediatamente para o modo testing , atualize o campo id do registro DNS e analise os relatórios TLS-RPT para identificar a causa exata antes de retornar ao modo enforce.

Por CaptainDNS
Publicado em 9 de fevereiro de 2026

Solução de problemas MTA-STS: diagnóstico e resolução de erros comuns

TL;DR

Verifique primeiro os três fundamentos: registro DNS _mta-sts, arquivo de política acessível via HTTPS e certificado TLS válido no subdomínio mta-sts
O erro sts-policy-fetch-error significa que o arquivo mta-sts.txt está inacessível — verifique a hospedagem, o DNS e o certificado do subdomínio
Os relatórios TLS-RPT identificam com precisão o tipo de falha (certificate-expired, validation-failure, sts-webpki-invalid) para orientar o diagnóstico
Em caso de emergência com o modo enforce, volte imediatamente para testing e atualize o campo id do registro DNS

Você implantou o MTA-STS no seu domínio seguindo todas as etapas: registro DNS publicado, arquivo de política hospedado, TLS-RPT ativado. Porém, os relatórios indicam falhas, o verificador exibe erros ou, pior, emails estão sendo rejeitados no modo enforce.

O MTA-STS envolve vários componentes que devem funcionar juntos: um registro DNS TXT, um arquivo de política servido via HTTPS em um subdomínio específico, certificados TLS válidos e patterns MX que correspondam exatamente aos seus servidores. Um único elo defeituoso é suficiente para quebrar a cadeia.

Este guia de solução de problemas cobre os erros mais frequentes, suas causas e os comandos para diagnosticá-los. Seja com Microsoft 365, Google Workspace ou Cloudflare para hospedagem, você encontrará a solução para o seu problema. Se você ainda não implantou o MTA-STS, consulte primeiro nosso guia completo MTA-STS.

Diagnóstico rápido: verificar sua configuração MTA-STS

Antes de buscar um problema específico, verifique estes três fundamentos na ordem. A maioria dos problemas MTA-STS vem de um desses três pontos.

Etapa 1: Verificar o registro DNS _mta-sts

O registro TXT em _mta-sts.captaindns.com deve existir e conter um valor válido:

dig TXT _mta-sts.captaindns.com +short
# Resultado esperado: "v=STSv1; id=20260208120000"

Problemas comuns:

Nenhum resultado → o registro não existe ou ainda não foi propagado
v=STS1 em vez de v=STSv1 → erro de digitação na versão
Ausência do campo id → campo obrigatório ausente

Etapa 2: Verificar o arquivo de política

O arquivo deve estar acessível na URL exata https://mta-sts.captaindns.com/.well-known/mta-sts.txt:

curl -v https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Verificações:

Código HTTP 200 (não 301, 302, 403 ou 404)
Content-Type text/plain (não text/html)
Conteúdo válido com version: STSv1, mode:, mx: e max_age:
Sem redirecionamento HTTP → HTTPS (o servidor deve responder diretamente em HTTPS)

Etapa 3: Verificar o certificado TLS

O subdomínio mta-sts.captaindns.com deve ter um certificado TLS válido:

openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

Verificações:

O certificado não está expirado (notAfter no futuro)
O certificado cobre mta-sts.captaindns.com (no CN ou SAN)
A cadeia de certificados está completa (sem erro unable to verify)

Checklist de diagnóstico MTA-STS: registro DNS, arquivo de política e certificado TLS

Erros comuns e soluções

Erro "Policy not found" (sts-policy-fetch-error)

É o erro mais frequente nos relatórios TLS-RPT. Ele significa que o servidor remetente não conseguiu recuperar seu arquivo de política.

Causa	Comando de diagnóstico	Solução
Arquivo ausente	`curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt`	Criar e hospedar o arquivo
DNS mal configurado	`dig A mta-sts.captaindns.com +short`	Verificar o CNAME ou registro A
Redirecionamento HTTP	`curl -v http://mta-sts.captaindns.com/.well-known/mta-sts.txt`	Configurar HTTPS diretamente
Certificado inválido	`curl -vI https://mta-sts.captaindns.com/`	Renovar ou corrigir o certificado
Cloudflare pausado	Verificar o dashboard Cloudflare	Reativar o proxy ou o Worker

Erro "Certificate mismatch" (certificate-host-mismatch)

O certificado TLS de um servidor MX não corresponde ao nome de host MX. Este não é o certificado do subdomínio mta-sts, mas sim o do próprio servidor MX.

# Verificar o certificado de um servidor MX
openssl s_client -connect captaindns-com.mail.protection.outlook.com:25 -starttls smtp -servername captaindns-com.mail.protection.outlook.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Com Microsoft 365 ou Google Workspace: esse problema não deveria ocorrer, pois a Microsoft e o Google gerenciam os certificados dos seus MX. Se você encontrar esse erro, verifique se os patterns MX na política correspondem aos seus MX reais.

Erro "MX not covered by policy"

O servidor MX do seu domínio não corresponde a nenhum pattern mx: no arquivo de política. Geralmente é um erro de wildcard.

# Listar seus MX
dig MX captaindns.com +short

# Comparar com a política
curl -s https://mta-sts.captaindns.com/.well-known/mta-sts.txt | grep "^mx:"

Causas comuns:

Situação	Pattern incorreto	Pattern correto
Microsoft 365	`mx: mail.protection.outlook.com`	`mx: *.mail.protection.outlook.com`
Google Workspace	`mx: *.google.com` (sozinho)	`mx: .google.com` + `mx: .googlemail.com`
MX personalizado	Pattern wildcard muito restritivo	Verificar cada MX individualmente

Erro "Certificate expired" (certificate-expired)

Um certificado TLS expirou em um dos seus servidores MX ou no subdomínio mta-sts.

# Verificar a data de expiração do certificado mta-sts
echo | openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com 2>/dev/null | openssl x509 -noout -enddate

Se for o subdomínio mta-sts: renove o certificado pelo seu provedor de hospedagem (o Cloudflare faz isso automaticamente). Se for um servidor MX: com Microsoft 365 ou Google Workspace, a renovação é automática. Para um MX auto-hospedado, renove o certificado via Let's Encrypt ou sua autoridade de certificação.

Erro "Validation failure" (validation-failure)

A cadeia de certificados está incompleta: o certificado raiz ou um certificado intermediário está faltando.

# Testar a cadeia completa
openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com </dev/null 2>&1 | grep "Verify return code"
# Resultado esperado: Verify return code: 0 (ok)

Se o código de retorno não for 0, instale os certificados intermediários faltantes no seu servidor.

Problemas específicos por provedor

Microsoft 365

Problema	Causa	Solução
MX não coberto	Pattern sem wildcard	Usar `mx: *.mail.protection.outlook.com`
Relatórios TLS-RPT vazios	O M365 envia os relatórios com atraso	Aguardar 48-72h após a ativação
Certificado MX com erro	Raro (gerenciado pela Microsoft)	Contatar o suporte da Microsoft

Google Workspace

Problema	Causa	Solução
MX parcialmente cobertos	Um único pattern `mx:`	Adicionar `mx: .google.com` E `mx: .googlemail.com`
Relatórios TLS-RPT incompletos	O Google agrega em 24h	Aguardar o relatório completo do dia seguinte
Mudança de MX do Google	Migração para novos MX	Verificar os MX atuais com `dig MX`

Cloudflare Pages / Workers

Problema	Causa	Solução
404 em mta-sts.txt	Caminho errado no repositório	O arquivo deve estar em `.well-known/mta-sts.txt`
Certificado TLS ausente	Domínio personalizado não configurado	Adicionar `mta-sts.captaindns.com` em Custom Domains
Worker não responde	Rota mal configurada	Verificar se a rota `mta-sts.captaindns.com/*` está ativa
Content-Type incorreto	Worker retorna `text/html`	Forçar `Content-Type: text/plain` na Response
DNS não resolvido	CNAME ausente	Adicionar o CNAME para o projeto Pages ou o AAAA `100::` para Workers

Ler e interpretar os relatórios TLS-RPT

Os relatórios TLS-RPT enviados pelos provedores de email contêm os detalhes das falhas TLS. Veja como interpretá-los.

Estrutura de um relatório TLS-RPT

Um relatório JSON típico contém:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-08T00:00:00Z",
    "end-datetime": "2026-02-08T23:59:59Z"
  },
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-domain": "captaindns.com"
    },
    "summary": {
      "total-successful-session-count": 150,
      "total-failure-session-count": 2
    },
    "failure-details": [{
      "result-type": "certificate-host-mismatch",
      "sending-mta-ip": "209.85.220.41",
      "receiving-mx-hostname": "captaindns-com.mail.protection.outlook.com",
      "failed-session-count": 2
    }]
  }]
}

Tabela de correspondência dos erros TLS-RPT

Código TLS-RPT	Significado	Gravidade	Ação
`starttls-not-supported`	O MX não suporta STARTTLS	Crítica	Ativar TLS no servidor MX
`certificate-host-mismatch`	O certificado não corresponde ao MX	Alta	Verificar o SAN do certificado
`certificate-expired`	Certificado expirado	Alta	Renovar imediatamente
`certificate-not-trusted`	Certificado autoassinado ou CA desconhecida	Alta	Usar um certificado de uma CA reconhecida
`validation-failure`	Cadeia de certificados incompleta	Alta	Instalar os certificados intermediários
`sts-policy-fetch-error`	Arquivo mta-sts.txt inacessível	Alta	Verificar a hospedagem
`sts-policy-invalid`	Conteúdo da política inválido	Alta	Corrigir a sintaxe
`sts-webpki-invalid`	Certificado do subdomínio mta-sts inválido	Alta	Renovar o certificado

Fluxo de diagnóstico dos erros TLS-RPT: do erro à solução

O modo enforce bloqueia emails: o que fazer?

Se você mudou para o modo enforce e emails legítimos estão sendo rejeitados, aja imediatamente:

1. Retorno de emergência para o modo testing

Modifique o arquivo de política:

version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400

2. Atualizar o registro DNS

Altere o campo id para forçar os servidores remetentes a baixar novamente a política:

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260208180000"

3. Tempo de propagação

Os servidores remetentes mantêm sua política em cache durante o período do max_age anterior. Se você tinha max_age: 2592000 (30 dias), alguns servidores podem não baixar novamente a política durante 30 dias. Por isso, é recomendado aumentar o max_age progressivamente:

Fase	max_age	Duração	Uso
Testing inicial	`86400`	24 horas	Permite um retorno rápido
Testing avançado	`604800`	7 dias	Após 2 semanas sem erro
Enforce prudente	`604800`	7 dias	Primeiras semanas em enforce
Enforce estável	`2592000`	30 dias	Após 1 mês em enforce sem problemas

Comandos de diagnóstico essenciais

Aqui estão os comandos para ter sempre à mão ao diagnosticar qualquer problema MTA-STS:

# 1. Verificar o registro DNS MTA-STS
dig TXT _mta-sts.captaindns.com +short

# 2. Verificar o registro TLS-RPT
dig TXT _smtp._tls.captaindns.com +short

# 3. Recuperar o arquivo de política
curl -s https://mta-sts.captaindns.com/.well-known/mta-sts.txt

# 4. Verificar os headers HTTP do arquivo de política
curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt

# 5. Listar os servidores MX
dig MX captaindns.com +short

# 6. Verificar o certificado do subdomínio mta-sts
echo | openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com 2>/dev/null | openssl x509 -noout -dates -subject

# 7. Testar a conexão STARTTLS em um MX
openssl s_client -connect captaindns-com.mail.protection.outlook.com:25 -starttls smtp -servername captaindns-com.mail.protection.outlook.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Plano de ação recomendado

Identifique o problema: Use o verificador MTA-STS CaptainDNS para um diagnóstico automático completo
Verifique os três fundamentos: Registro DNS, arquivo de política, certificado TLS (nesta ordem)
Consulte os relatórios TLS-RPT: O campo result-type indica exatamente o que está falhando
Corrija o problema identificado: Siga as soluções da seção correspondente acima
Valide a correção: Use o validador de sintaxe MTA-STS para confirmar que a política está correta
Monitore durante 48h: Verifique se os relatórios TLS-RPT não indicam mais o erro

Verifique sua configuração MTA-STS agora: Use nosso verificador MTA-STS para diagnosticar seu domínio em poucos segundos.

FAQ

Por que minha política MTA-STS não é recuperada?

O arquivo mta-sts.txt deve estar acessível na URL exata https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Verifique se o subdomínio mta-sts resolve corretamente (CNAME ou registro A), se o certificado TLS é válido e se o servidor responde com o código 200 e o Content-Type text/plain. Os redirecionamentos HTTP para HTTPS não são aceitos por todos os clientes.

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

Seu servidor MX real não corresponde a nenhum pattern mx: no arquivo de política. Por exemplo, se o seu MX é captaindns-com.mail.protection.outlook.com mas a política contém mx: mail.protection.outlook.com (sem wildcard), o servidor remetente considera que o MX não está autorizado. Adicione o wildcard: mx: *.mail.protection.outlook.com.

Como corrigir um erro de certificado TLS no MTA-STS?

Identifique primeiro qual certificado está com problema. Se for o certificado do subdomínio mta-sts: renove-o pelo seu provedor de hospedagem (o Cloudflare renova automaticamente). Se for o certificado de um servidor MX: com Microsoft 365 ou Google Workspace, é gerenciado automaticamente. Para um MX auto-hospedado, verifique a cadeia de certificados completa e a data de expiração.

Por que o modo enforce bloqueia emails?

No modo enforce, os servidores remetentes rejeitam o envio se a política MTA-STS não puder ser satisfeita (certificado inválido, MX não coberto, política inacessível). Volte imediatamente para o modo testing, atualize o campo id do registro DNS e analise os relatórios TLS-RPT para identificar a causa exata antes de retornar ao modo enforce.

Como voltar para o modo testing em emergência?

Modifique o arquivo mta-sts.txt substituindo mode: enforce por mode: testing. Em seguida, atualize o campo id do registro DNS TXT _mta-sts com um novo timestamp. Os servidores remetentes baixarão novamente a política e deixarão de rejeitar os emails. O prazo depende do max_age anterior.

Como ler um relatório TLS-RPT?

Os relatórios TLS-RPT são arquivos JSON enviados diariamente para o endereço especificado no seu registro _smtp._tls. O campo result-type indica o tipo de erro (certificate-expired, sts-policy-fetch-error, etc.), receiving-mx-hostname identifica o servidor MX envolvido e failed-session-count mostra o número de falhas.

MTA-STS não funciona com Cloudflare Workers: o que verificar?

Verifique se a rota mta-sts.captaindns.com/* está configurada no Worker, se o DNS contém um registro AAAA mta-sts apontando para 100:: (proxied) e se o Worker retorna o Content-Type text/plain; charset=utf-8. Teste com curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt para confirmar o código 200 e os headers.

Quanto tempo é necessário para que as correções entrem em vigor?

Os servidores remetentes mantêm sua política em cache durante o período do max_age. Se você tinha max_age: 86400 (24h), a correção será efetiva em no máximo 24h. Se você tinha max_age: 2592000 (30 dias), alguns servidores podem não ver a correção durante 30 dias. Por isso, é recomendado manter um max_age curto na fase de testes.

Glossário

MTA-STS: Mail Transfer Agent Strict Transport Security. Padrão RFC 8461 que impõe a criptografia TLS para a recepção de emails.
TLS-RPT: SMTP TLS Reporting (RFC 8460). Mecanismo de relatório diário sobre os sucessos e falhas de negociação TLS.
sts-policy-fetch-error: Código de erro TLS-RPT indicando que o arquivo de política mta-sts.txt não pôde ser recuperado pelo servidor remetente.
max_age: Diretiva da política MTA-STS indicando a duração do cache em segundos. Determina o prazo de propagação das modificações.
STARTTLS: Extensão SMTP que permite criptografar a conexão entre servidores de email. O MTA-STS impõe seu uso com um certificado válido.