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; no Google Workspace tudo depende da antiguidade do domínio: smtp.google.com desde 2023 e o conjunto aspmx.l.google.com / *.aspmx.l.google.com / *.googlemail.com para os domínios anteriores
• O ficheiro de política mta-sts.txt deve ser alojado 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 alojar gratuitamente o ficheiro de política com HTTPS automático
• Sempre implante em modo testing com TLS-RPT ativo antes de mudar para o modo enforce

Utiliza o Microsoft 365 ou o Google Workspace para os seus emails profissionais. Os 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 ligação sem encriptação e interceptar as suas mensagens.

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

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

Pré-requisitos comuns a todos os fornecedores

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 predefinição: a Microsoft e o Google gerem os certificados dos seus servidores MX.

2. Acesso à sua zona DNS

Deve poder criar um registo TXT em _mta-sts.captaindns.com e um registo CNAME ou A para o subdomínio mta-sts.captaindns.com.

3. Alojamento HTTPS para o ficheiro de política

O ficheiro mta-sts.txt deve estar acessível na URL exata https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Precisa de um alojamento 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 a 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 os seus MX do Microsoft 365:

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

Ficheiro de política para Microsoft 365

Crie o ficheiro 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	Monitorização 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)

Registo DNS para Microsoft 365

Adicione este registo 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 receção: pode publicar uma política para o seu domínio alojado no Microsoft 365, e os servidores remetentes a respeitarão.

MTA-STS para Google Workspace

Os patterns MX do Google Workspace

O Google Workspace publica dois conjuntos de MX consoante a antiguidade do domínio, e a sua política tem de declarar aquele que o seu domínio publica realmente. Comece por lê-lo: dig MX captaindns.com +short.

Desde 2023, o Google documenta um registo único:

Servidor MX	Prioridade
smtp.google.com	1

Os domínios Workspace criados antes de 2023 publicam o conjunto histórico, que o Google continua a suportar:

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

Daí quatro patterns possíveis:

smtp.google.com
aspmx.l.google.com
*.aspmx.l.google.com
*.googlemail.com

O primeiro chega para um domínio recente, os três seguintes cobrem o conjunto histórico e os quatro em conjunto servem um domínio em plena migração. Um pattern declarado a mais não impede qualquer entrega; um MX publicado sem pattern correspondente, sim.

Convém abandonar o atalho *.google.com, ainda repetido em muitos sítios: a RFC 8461 limita o wildcard MTA-STS a uma única etiqueta, a mais à esquerda. Cobre smtp.google.com, mas perante aspmx.l.google.com sobra aspmx.l, que contém um ponto. A correspondência falha e nenhum dos cinco MX históricos fica coberto. Daí o pattern *.aspmx.l.google.com para os quatro servidores alternativos e a declaração exata do MX principal.

Ficheiro de política para Google Workspace

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

Este exemplo cobre os dois conjuntos ao mesmo tempo: serve tal como está para um domínio recente e para um domínio anterior a 2023, e aguenta durante uma migração de um para o outro. Depois de ler os seus próprios MX, guarde apenas as linhas que lhes correspondem: uma política que declara só os seus servidores reais é mais estrita. O MTA-STS exige que cada pattern seja declarado numa linha separada.

Registo DNS para Google Workspace

O registo 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 fornecedores mais ativos em relação ao TLS-RPT. Se 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.

Alojar o MTA-STS no Cloudflare

O ficheiro 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 alojamento.

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 ficheiro .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 registo 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 controlo mais detalhado ou se não deseja usar um repositório Git, um Cloudflare Worker pode servir o ficheiro 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 fornecedor)
3. Adicione uma rota personalizada: mta-sts.captaindns.com/*
4. Configure o DNS: Adicione um registo 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 ficheiro 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 monitorizar 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 registo TLS-RPT

Adicione este registo 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. 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	O 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 ligações TLS bem-sucedidas
Contador de falhas	Número de ligações que falharam
Tipo de falha	starttls-not-supported, certificate-expired, validation-failure, etc.

Interpretar os relatórios

Em modo testing, monitorize os relatórios durante 2 a 4 semanas. Se a taxa de falha for nula ou próxima de zero, 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	Ficheiro mta-sts.txt inacessível	Verificar o alojamento 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 ficheiro de política em modo testing com max_age: 86400
2. Aloje-o no Cloudflare Pages ou Workers
3. Publique o registo DNS _mta-sts
4. Ative o TLS-RPT
5. Valide com o verificador MTA-STS CaptainDNS

Fase 2: Monitorização (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 ficheiro 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 registo DNS
4. Continue a monitorizar 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 ficheiro de política
2. Atualize o campo id do registo DNS
3. Os servidores remetentes descarregarã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 o seu fornecedor de email: Verifique os seus registos MX com dig MX captaindns.com +short
2. Crie o ficheiro de política: Utilize o gerador MTA-STS CaptainDNS com os patterns MX do seu fornecedor
3. Aloje a política: Implante no Cloudflare Pages (opção mais simples e gratuita)
4. Publique os registos 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. Monitorize durante 2-4 semanas: Analise os relatórios TLS-RPT antes de mudar para enforce

---

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

---

FAQ

Como configurar o MTA-STS para Microsoft 365?

Crie um ficheiro mta-sts.txt com a diretiva mx: *.mail.protection.outlook.com, aloje-o em HTTPS no subdomínio mta-sts do seu domínio, e publique um registo 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 ficheiro de política deve declarar os MX que o seu domínio publica realmente. Desde 2023, o Google documenta um registo único: basta uma linha mx: smtp.google.com. Um domínio Workspace anterior a 2023 publica o conjunto histórico, ainda suportado, e exige três linhas: mx: aspmx.l.google.com, mx: *.aspmx.l.google.com e mx: *.googlemail.com. O wildcard MTA-STS cobre apenas uma etiqueta, pelo que *.google.com não corresponde a nenhum servidor desse conjunto histórico. O restante da configuração (registo DNS, alojamento 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 os seus MX com dig MX captaindns.com +short para confirmar que correspondem a esse pattern.

Como alojar o ficheiro mta-sts.txt no Cloudflare?

Duas opções: Cloudflare Pages (crie um repositório Git com o ficheiro .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 registo DNS TXT em _smtp._tls com v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com. Sem o TLS-RPT, 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 a 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 fornecedores gerem os certificados TLS dos seus servidores MX automaticamente.

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

Utilize o verificador MTA-STS CaptainDNS para conferir o seu registo DNS, o ficheiro de política, o certificado TLS do subdomínio mta-sts e a correspondência entre os patterns MX declarados e os seus MX reais. 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 encriptação TLS para a receçã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 gere os servidores MX *.mail.protection.outlook.com.
• Cloudflare Pages: Serviço de alojamento 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 utilizadores.
• 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

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