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

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

O ficheiro 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 registo 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 aceites por todos os clientes.

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

O seu servidor MX real não corresponde a nenhum pattern mx: no ficheiro 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: Porque 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 registo DNS e analise os relatórios TLS-RPT para identificar a causa exata antes de retornar ao modo enforce.

Q: Como voltar para o modo testing em emergência?

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

Q: 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 registo 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.

Por CaptainDNS
Publicado em 9 de fevereiro de 2026

Atualizado em 31 de julho de 2026

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

TL;DR

Verifique primeiro os três fundamentos: registo DNS _mta-sts, ficheiro 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 ficheiro mta-sts.txt está inacessível - verifique o alojamento, 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 registo DNS

Implantou o MTA-STS no seu domínio seguindo todas as etapas: registo DNS publicado, ficheiro de política alojado, TLS-RPT ativado. Porém, os relatórios indicam falhas, o verificador exibe erros ou, pior, emails estão a ser rejeitados no modo enforce.

O MTA-STS envolve vários componentes que devem funcionar juntos: um registo DNS TXT, um ficheiro 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, as suas causas e os comandos para diagnosticá-los. Seja com Microsoft 365, Google Workspace ou Cloudflare para alojamento, encontrará a solução para o seu problema. Se ainda não implantou o MTA-STS, consulte primeiro nosso guia completo MTA-STS.

Diagnóstico rápido: verificar a 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 registo DNS _mta-sts

O registo 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 registo 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 ficheiro de política

O ficheiro 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: registo DNS, ficheiro 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 o seu ficheiro de política.

Causa	Comando de diagnóstico	Solução
Ficheiro ausente	`curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt`	Criar e alojar o ficheiro
DNS mal configurado	`dig A mta-sts.captaindns.com +short`	Verificar o CNAME ou registo 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 gerem os certificados dos seus MX. Se 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 ficheiro 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 (não cobre nenhum servidor `aspmx`)	`mx: smtp.google.com` (MX único documentado desde 2023) ou `mx: aspmx.l.google.com` + `mx: .aspmx.l.google.com` + `mx: .googlemail.com` (conjunto histórico)
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 fornecedor de alojamento (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-alojado, renove o certificado via Let's Encrypt ou a 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á a faltar.

# 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 em falta no seu servidor.

Problemas específicos por fornecedor

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 (gerido pela Microsoft)	Contatar o suporte da Microsoft

Google Workspace

Problema	Causa	Solução
MX não cobertos	Política limitada ao conjunto `aspmx` quando o domínio publica `smtp.google.com`, ou atalho `*.google.com`, cujo wildcard abrange apenas uma etiqueta	Declarar os MX realmente publicados: `mx: smtp.google.com`, ou `mx: aspmx.l.google.com` + `mx: .aspmx.l.google.com` + `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 ficheiro 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 fornecedores 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`	Ficheiro mta-sts.txt inacessível	Alta	Verificar o alojamento
`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 mudou para o modo enforce e emails legítimos estão a ser rejeitados, aja imediatamente:

1. Retorno de emergência para o modo testing

Modifique o ficheiro de política:

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

2. Atualizar o registo DNS

Altere o campo id para forçar os servidores remetentes a descarregar 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 a sua política em cache durante o período do max_age anterior. Se tinha max_age: 2592000 (30 dias), alguns servidores podem não descarregar 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 registo DNS MTA-STS
dig TXT _mta-sts.captaindns.com +short

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

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

# 4. Verificar os headers HTTP do ficheiro 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 ligaçã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: Registo DNS, ficheiro de política, certificado TLS (nesta ordem)
Consulte os relatórios TLS-RPT: O campo result-type indica exatamente o que está a falhar
Corrija o problema identificado: Siga as soluções da secção correspondente acima
Valide a correção: Use o validador de sintaxe MTA-STS para confirmar que a política está correta
Monitorize durante 48h: Verifique se os relatórios TLS-RPT não indicam mais o erro

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

FAQ

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

O ficheiro 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 registo 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 aceites por todos os clientes.

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

O seu servidor MX real não corresponde a nenhum pattern mx: no ficheiro 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 fornecedor de alojamento (o Cloudflare renova automaticamente). Se for o certificado de um servidor MX: com Microsoft 365 ou Google Workspace, é gerido automaticamente. Para um MX auto-alojado, verifique a cadeia de certificados completa e a data de expiração.

Porque 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 registo 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 ficheiro mta-sts.txt substituindo mode: enforce por mode: testing. Em seguida, atualize o campo id do registo DNS TXT _mta-sts com um novo timestamp. Os servidores remetentes descarregarã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 ficheiros JSON enviados diariamente para o endereço especificado no seu registo _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 registo 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 a sua política em cache durante o período do max_age. Se tinha max_age: 86400 (24h), a correção será efetiva em no máximo 24h. Se 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 encriptação TLS para a receçã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 ficheiro 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 encriptar a ligação entre servidores de email. O MTA-STS impõe o seu uso com um certificado válido.