Configurar MTA-STS para Microsoft 365 e Google Workspace

⚡TL;DR

• O Microsoft 365 utiliza o pattern MX *.mail.protection.outlook.com na política MTA-STS; o Google Workspace exige os patterns *.google.com e *.googlemail.com
• O arquivo de política mta-sts.txt deve ser hospedado em HTTPS no subdomínio mta-sts do seu domínio, com um certificado TLS válido
• O Cloudflare Pages ou o Cloudflare Workers permitem hospedar gratuitamente o arquivo de política com HTTPS automático
• Sempre implante em modo testing com TLS-RPT ativo antes de mudar para o modo enforce

Você utiliza o Microsoft 365 ou o Google Workspace para seus emails profissionais. Seus servidores MX estão corretamente configurados, SPF, DKIM e DMARC estão implementados. Mas o transporte entre servidores SMTP continua vulnerável: sem o MTA-STS, um invasor pode forçar uma conexão sem criptografia e interceptar suas mensagens.

O MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) resolve esse problema ao impor a criptografia TLS para a recepção de emails. O princípio é simples: você publica um registro DNS e um arquivo de política que declaram seus servidores MX autorizados e exigem uma conexão TLS válida.

Este tutorial guia você passo a passo para implantar o MTA-STS no Microsoft 365, Google Workspace e Cloudflare. Cada seção contém os patterns MX exatos, os arquivos de configuração prontos para copiar e os comandos de validação. Se você está descobrindo o MTA-STS, consulte primeiro nosso guia completo MTA-STS para entender o funcionamento do protocolo (veja a seção Guias relacionados no final do artigo).

Pré-requisitos comuns a todos os provedores

Antes de configurar o MTA-STS, verifique estes três pontos para o seu domínio:

1. Certificados TLS válidos nos seus MX

Todos os seus servidores MX devem possuir um certificado TLS válido (TLS 1.2 no mínimo). Com o Microsoft 365 e o Google Workspace, isso já vem por padrão: a Microsoft e o Google gerenciam os certificados dos seus servidores MX.

2. Acesso à sua zona DNS

Você deve poder criar um registro TXT em _mta-sts.captaindns.com e um registro CNAME ou A para o subdomínio mta-sts.captaindns.com.

3. Hospedagem HTTPS para o arquivo de política

O arquivo mta-sts.txt deve estar acessível na URL exata https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Você precisa de uma hospedagem HTTPS com um certificado válido para o subdomínio mta-sts.

MTA-STS para Microsoft 365 / Office 365

O pattern MX do Microsoft 365

O Microsoft 365 utiliza servidores MX no formato captaindns-com.mail.protection.outlook.com. O pattern wildcard correspondente para sua política MTA-STS é:

*.mail.protection.outlook.com

Esse pattern cobre todos os servidores MX do Microsoft 365, incluindo as variações regionais e as configurações com o Exchange Online Protection (EOP).

Para verificar seus MX do Microsoft 365:

dig MX captaindns.com +short
# Resultado esperado: 0 captaindns-com.mail.protection.outlook.com.

Arquivo de política para Microsoft 365

Crie o arquivo mta-sts.txt com o seguinte conteúdo:

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

Diretiva	Valor	Explicação
version	STSv1	Versão do protocolo
mode	testing	Monitoramento sem bloqueio (fase inicial)
mx	*.mail.protection.outlook.com	Cobre todos os MX do Microsoft 365
max_age	86400	Cache de 24h (adequado para testing)

Registro DNS para Microsoft 365

Adicione este registro TXT na sua zona DNS:

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

O campo id deve ser atualizado a cada modificação da política. Utilize um timestamp no formato YYYYMMDDHHMMSS para facilitar o acompanhamento.

O Microsoft 365 suporta MTA-STS?

A Microsoft suporta o MTA-STS no envio: quando um servidor Microsoft 365 envia um email, ele verifica a política MTA-STS do domínio destinatário. A Microsoft também suporta o MTA-STS na recepção: você pode publicar uma política para o seu domínio hospedado no Microsoft 365, e os servidores remetentes a respeitarão.

MTA-STS para Google Workspace

Os patterns MX do Google Workspace

O Google Workspace utiliza vários servidores MX com nomes variados. Os patterns a incluir na sua política MTA-STS são:

*.google.com
*.googlemail.com

Esses dois patterns cobrem todos os servidores MX do Google Workspace, incluindo:

Servidor MX	Prioridade
aspmx.l.google.com	1
alt1.aspmx.l.google.com	5
alt2.aspmx.l.google.com	5
alt3.aspmx.l.google.com	10
alt4.aspmx.l.google.com	10

Arquivo de política para Google Workspace

version: STSv1
mode: testing
mx: *.google.com
mx: *.googlemail.com
max_age: 86400

Note que são necessárias duas linhas mx: uma para *.google.com e outra para *.googlemail.com. O MTA-STS exige que cada pattern seja declarado em uma linha separada.

Registro DNS para Google Workspace

O registro DNS tem a mesma estrutura:

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

Google Workspace e TLS-RPT

O Google é um dos provedores mais ativos em relação ao TLS-RPT. Se você ativar o MTA-STS e o TLS-RPT, receberá relatórios detalhados do Google sobre as negociações TLS com o seu domínio. Esses relatórios são valiosos para identificar problemas antes de mudar para o modo enforce.

Hospedar o MTA-STS no Cloudflare

O arquivo de política deve estar acessível em https://mta-sts.captaindns.com/.well-known/mta-sts.txt. O Cloudflare oferece duas opções gratuitas para hospedagem.

Opção 1: Cloudflare Pages (recomendado)

O Cloudflare Pages é a solução mais simples. Crie um repositório com a seguinte estrutura:

meu-projeto-mta-sts/
  .well-known/
    mta-sts.txt

Etapas de implantação:

1. Crie um repositório Git (GitHub ou GitLab) com o arquivo .well-known/mta-sts.txt
2. Conecte-o ao Cloudflare Pages: Dashboard Cloudflare > Pages > Create a project
3. Configure o build: Framework preset = None, Build command = (vazio), Output directory = /
4. Adicione o domínio personalizado: Settings > Custom domains > mta-sts.captaindns.com
5. Configure o DNS: O Cloudflare cria automaticamente um registro CNAME

O Cloudflare Pages fornece um certificado TLS automático via Let's Encrypt. Nenhuma configuração adicional é necessária.

Opção 2: Cloudflare Worker

Para um controle mais detalhado ou se você não deseja usar um repositório Git, um Cloudflare Worker pode servir o arquivo de política:

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname === '/.well-known/mta-sts.txt') {
      const policy = `version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400`;

      return new Response(policy, {
        headers: {
          'Content-Type': 'text/plain; charset=utf-8',
          'Cache-Control': 'public, max-age=3600',
        },
      });
    }

    return new Response('Not Found', { status: 404 });
  },
};

Etapas:

1. Crie um Worker: Dashboard Cloudflare > Workers & Pages > Create application
2. Cole o código acima (adapte as linhas mx ao seu provedor)
3. Adicione uma rota personalizada: mta-sts.captaindns.com/*
4. Configure o DNS: Adicione um registro AAAA mta-sts apontando para 100:: (proxied)

O plano gratuito do Cloudflare Workers inclui 100.000 requisições por dia, mais do que suficiente para o MTA-STS.

Qual Content-Type usar?

O arquivo de política deve ser servido com o Content-Type text/plain. A RFC 8461 não especifica um charset obrigatório, mas text/plain; charset=utf-8 é recomendado para compatibilidade.

Ativar o TLS-RPT para monitorar a implantação

O TLS-RPT (SMTP TLS Reporting, RFC 8460) é o companheiro indispensável do MTA-STS. Ele envia relatórios diários sobre os sucessos e falhas de negociação TLS.

Criar o registro TLS-RPT

Adicione este registro TXT na sua zona DNS:

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

Os relatórios são enviados em formato JSON, comprimidos em gzip, para o endereço de email especificado. Você também pode usar uma URL HTTPS para receber os relatórios via webhook:

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=https://tls-reports.captaindns.com/v1/report"

O que contêm os relatórios TLS-RPT?

Cada relatório cobre um período de 24 horas e inclui:

Informação	Descrição
Domínio da política	Seu domínio (captaindns.com)
Período do relatório	Data de início e de fim
Organização remetente	Google, Microsoft, etc.
Contador de sucessos	Número de conexões TLS bem-sucedidas
Contador de falhas	Número de conexões que falharam
Tipo de falha	starttls-not-supported, certificate-expired, validation-failure, etc.

Interpretar os relatórios

Em modo testing, monitore os relatórios durante 2 a 4 semanas. Se a taxa de falha for nula ou próxima de zero, você pode mudar para o modo enforce com total confiança.

Os erros mais comuns nos relatórios:

Erro	Causa provável	Ação
certificate-expired	Certificado TLS expirado em um MX	Renovar o certificado
certificate-host-mismatch	Nome do host MX não coberto pelo certificado	Verificar o SAN do certificado
validation-failure	Cadeia de certificados incompleta	Instalar os certificados intermediários
sts-policy-fetch-error	Arquivo mta-sts.txt inacessível	Verificar a hospedagem HTTPS
sts-webpki-invalid	Certificado do subdomínio mta-sts inválido	Renovar o certificado

Do testing ao enforce: plano de migração

Fase 1: Implantação inicial (semana 1)

1. Crie o arquivo de política em modo testing com max_age: 86400
2. Hospede-o no Cloudflare Pages ou Workers
3. Publique o registro DNS _mta-sts
4. Ative o TLS-RPT
5. Valide com o verificador MTA-STS CaptainDNS

Fase 2: Monitoramento (semanas 2-4)

1. Analise os relatórios TLS-RPT diários
2. Corrija os erros identificados (certificados, MX não cobertos)
3. Verifique se a taxa de sucesso TLS atinge 100%

Fase 3: Mudança para enforce

1. Modifique o arquivo de política: mode: enforce
2. Aumente o max_age: passe para 604800 (7 dias) e depois 2592000 (30 dias)
3. Atualize o campo id do registro DNS
4. Continue monitorando os relatórios TLS-RPT

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 2592000

Retorno de emergência ao modo testing

Se emails forem rejeitados após a mudança para enforce:

1. Volte imediatamente para mode: testing no arquivo de política
2. Atualize o campo id do registro DNS
3. Os servidores remetentes baixarão novamente a política e deixarão de rejeitar

O tempo de propagação depende do max_age anterior. Por isso, é recomendado aumentar o max_age progressivamente.

Plano de ação recomendado

1. Identifique seu provedor de email: Verifique seus registros MX com dig MX captaindns.com +short
2. Crie o arquivo de política: Utilize o gerador MTA-STS CaptainDNS com os patterns MX do seu provedor
3. Hospede a política: Implante no Cloudflare Pages (opção mais simples e gratuita)
4. Publique os registros DNS: Adicione _mta-sts (TXT) e _smtp._tls (TLS-RPT)
5. Valide a configuração: Verifique com o verificador de sintaxe MTA-STS se a política está correta
6. Monitore durante 2-4 semanas: Analise os relatórios TLS-RPT antes de mudar para enforce

---

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

---

FAQ

Como configurar o MTA-STS para Microsoft 365?

Crie um arquivo mta-sts.txt com a diretiva mx: *.mail.protection.outlook.com, hospede-o em HTTPS no subdomínio mta-sts do seu domínio, e publique um registro DNS TXT em _mta-sts com v=STSv1; id=<timestamp>. Comece em modo testing com um max_age de 86400 segundos (24 horas).

Como configurar o MTA-STS para Google Workspace?

O arquivo de política deve conter duas linhas mx: mx: *.google.com e mx: *.googlemail.com. Esses patterns cobrem todos os servidores MX do Google Workspace (aspmx.l.google.com e suas alternativas). O restante da configuração (registro DNS, hospedagem HTTPS) é idêntico ao do Microsoft 365.

Qual pattern MX usar para o Office 365 na política MTA-STS?

O pattern correto é *.mail.protection.outlook.com. Esse wildcard cobre todos os servidores MX do Microsoft 365, incluindo as variantes regionais e o Exchange Online Protection. Verifique seus MX com dig MX captaindns.com +short para confirmar que correspondem a esse pattern.

Como hospedar o arquivo mta-sts.txt no Cloudflare?

Duas opções: Cloudflare Pages (crie um repositório Git com o arquivo .well-known/mta-sts.txt e adicione o domínio personalizado mta-sts.captaindns.com) ou Cloudflare Workers (implante um script que retorna o conteúdo da política com o Content-Type text/plain). Ambas as opções são gratuitas e fornecem um certificado TLS automático.

É necessário configurar o TLS-RPT junto com o MTA-STS?

Sim, é altamente recomendado. O TLS-RPT (RFC 8460) envia relatórios diários sobre os sucessos e falhas de negociação TLS. Publique um registro DNS TXT em _smtp._tls com v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com. Sem o TLS-RPT, você não tem nenhuma visibilidade sobre os problemas da sua implantação MTA-STS.

O MTA-STS funciona com um Cloudflare Worker gratuito?

Sim. O plano gratuito do Cloudflare Workers inclui 100.000 requisições por dia, mais do que suficiente para o MTA-STS. Os servidores remetentes consultam sua política ocasionalmente (no primeiro envio e quando o cache max_age expira). Um Worker gratuito atende facilmente milhões de emails por mês.

A Microsoft e o Google suportam MTA-STS nativamente?

Sim, ambos. O Google suporta o MTA-STS no envio (ele verifica as políticas dos domínios destinatários) e publica relatórios TLS-RPT. O Microsoft 365 suporta o MTA-STS no envio desde 2020 e também envia relatórios TLS-RPT. Ambos os provedores gerenciam os certificados TLS dos seus servidores MX automaticamente.

Como verificar se meu registro MTA-STS é válido?

Utilize o verificador MTA-STS CaptainDNS para conferir seu registro DNS, o arquivo de política, o certificado TLS do subdomínio mta-sts e a correspondência entre os patterns MX declarados e seus MX reais. Você também pode verificar manualmente com dig TXT _mta-sts.captaindns.com e curl https://mta-sts.captaindns.com/.well-known/mta-sts.txt.

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 sobre os sucessos e falhas de negociação TLS.
• Exchange Online Protection (EOP): Serviço de filtragem de email do Microsoft 365 que gerencia os servidores MX *.mail.protection.outlook.com.
• Cloudflare Pages: Serviço de hospedagem de sites estáticos do Cloudflare com HTTPS automático e implantação via Git.
• Cloudflare Workers: Plataforma serverless do Cloudflare que permite executar JavaScript o mais próximo possível dos usuários.
• max_age: Diretiva da política MTA-STS que indica a duração do cache em segundos.

Guias de MTA-STS relacionados

• MTA-STS: o guia completo para proteger o transporte de email
• MTA-STS não funciona? Guia completo de solução de problemas (em breve)

Fontes

• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460 - SMTP TLS Reporting
• Google Support - Reforçar a segurança do email com MTA-STS e TLS-RPT
• Microsoft Learn - SMTP MTA-STS