Hospedagem MTA-STS Gratuita

Por que o MTA-STS é essencial

O SMTP foi concebido em 1982 sem criptografia. O STARTTLS foi adicionado posteriormente para criptografar o email em trânsito, mas tem uma falha crítica: é oportunista. Um servidor remetente anuncia o suporte STARTTLS, e o servidor receptor pode aceitar ou ignorar. Nada obriga a conexão a permanecer criptografada.

Isto cria uma janela para ataques de downgrade SMTP. Um atacante posicionado entre dois servidores de email (via BGP hijacking, DNS spoofing ou interceptação no nível da rede) remove o comando STARTTLS do handshake SMTP. O servidor remetente não detecta nenhuma opção de criptografia e recorre a texto simples. O email circula sem criptografia, legível por qualquer pessoa no percurso.

O MTA-STS (RFC 8461) supre esta lacuna. Você publica uma política que indica aos servidores remetentes: "este domínio exige TLS. Se a criptografia falhar, não recorrer a texto simples." O servidor remetente deve estabelecer uma conexão TLS válida ou colocar a mensagem em fila de espera para nova tentativa.

A barreira à implementação: o MTA-STS exige a hospedagem de um arquivo de política em https://mta-sts.captaindns.com/.well-known/mta-sts.txt por HTTPS com um certificado válido. Para muitas organizações, configurar e manter um servidor web dedicado para um único arquivo de texto é desproporcionado. O CaptainDNS elimina esta barreira por completo.

O que acontece sem MTA-STS

Sem MTA-STS, o transporte do seu email depende exclusivamente de TLS oportunista. Eis o que isso significa na prática:

• Interceptação em texto simples: qualquer atacante no nível da rede pode ler os seus emails removendo o STARTTLS. Isto não é teórico. Programas de vigilância estatais e interceptação no nível do ISP estão documentados.
• Sem verificação pelo remetente: sem uma política publicada, os servidores remetentes não têm como saber que o seu domínio exige TLS. Recorrem silenciosamente a texto simples em caso de problema.
• Exposição regulamentar: regulamentos como RGPD, HIPAA e PCI-DSS exigem a criptografia de dados sensíveis em trânsito. O TLS oportunista por si só não cumpre este requisito, pois pode ser contornado.
• Falhas invisíveis: sem TLS-RPT (o protocolo de relatório complementar), você nunca saberá que emails para o seu domínio foram entregues sem criptografia. O problema é silencioso.

Em 2014, pesquisadores documentaram a supressão em larga escala de STARTTLS por intermediários de rede em vários países. O Transparency Report do Google confirmou posteriormente que uma parte significativa dos emails recebidos ainda chega sem criptografia. O MTA-STS é o protocolo concebido para pôr fim a esta situação.

O MTA-STS aliado ao TLS-RPT proporciona tanto a aplicação como a visibilidade.

Como funciona o MTA-STS em detalhe

O MTA-STS utiliza dois componentes que funcionam em conjunto:

1. Um registro DNS TXT em _mta-sts.captaindns.com

Este registro anuncia a sua política MTA-STS e contém um ID de política único. Quando o ID muda, os servidores remetentes sabem que devem obter uma cópia atualizada da política.

Exemplo: v=STSv1; id=20260308120000

2. Um arquivo de política hospedado em HTTPS em https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Este arquivo define três elementos:

• mode: testing (apenas relatório) ou enforce (rejeitar em caso de falha TLS)
• mx: os padrões de servidor de email que devem corresponder aos seus registros MX
• max_age: durante quanto tempo os servidores remetentes devem armazenar a política em cache (em segundos)

Exemplo:

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

Quando um servidor remetente pretende entregar email ao seu domínio, verifica o registro TXT _mta-sts. Se estiver presente, obtém o arquivo de política por HTTPS, valida o certificado TLS dos seus servidores MX conforme os padrões da política e prossegue apenas se tudo corresponder.

Trust on first use (TOFU): o MTA-STS baseia-se no pressuposto de que a primeira obtenção da política é legítima. A partir daí, a política em cache protege contra futuros ataques durante o período de max_age. Por isso, um max_age mais longo (7 ou mais dias) é recomendado no modo enforce.

Como funciona

1. Crie a sua política

Faça login e crie uma nova política. Defina o domínio, o modo (testing ou enforce), os padrões MX e a duração do cache (max_age).

2. Verifique a propriedade do domínio

Adicione o registro TXT de verificação ao seu DNS. Detectamo-lo automaticamente em segundos.

3. Adicione os registros DNS de implementação

Dois registros DNS:

• CNAME: Aponta mta-sts.captaindns.com para o nosso servidor de políticas
• TXT: Anuncia a sua política MTA-STS em _mta-sts.captaindns.com

A sua política MTA-STS está ativa.

Compatível com os principais provedores de email

O MTA-STS funciona com qualquer provedor de email que utilize registros MX padrão. Os padrões MX na sua política devem corresponder aos servidores de email do seu provedor:

Ao criar a sua política no CaptainDNS, insira os padrões MX que correspondem ao seu provedor. O painel valida-os comparando com os seus registros MX ativos para evitar incompatibilidades.

Hospedado vs. auto-hospedado: qual opção escolher?

Escolha hospedado se pretende implementar MTA-STS em minutos, sem qualquer infraestrutura. Escolha auto-hospedado se precisa de controle total sobre o endpoint da política ou opera num ambiente isolado.

De testing a enforce: uma estratégia progressiva

Implementar o MTA-STS diretamente no modo enforce é arriscado. Se os padrões MX estiverem incorretos ou um certificado TLS expirar, os emails legítimos são rejeitados. A abordagem recomendada é progressiva:

Fase 1: Implementar no modo testing (1 a 2 semanas)

Defina mode: testing na sua política. Os servidores remetentes tentam TLS e reportam falhas via TLS-RPT, mas continuam entregando os emails mesmo se o TLS falhar. Isso dá a você visibilidade sem risco.

Fase 2: Analisar os relatórios TLS-RPT

Reveja os relatórios para identificar problemas: incompatibilidades de certificados, padrões MX que não cobrem todos os servidores de email ou remetentes terceiros com TLS defeituoso. Corrija cada problema antes de avançar.

Fase 3: Mudar para o modo enforce

Quando os relatórios mostrarem zero falhas durante pelo menos uma semana, altere o modo para enforce e aumente o max_age para 604800 (7 dias) ou mais. No CaptainDNS, basta um clique no painel. A rotação do ID da política é feita automaticamente.

Reversão de emergência: se o modo enforce bloquear email legítimo, volte imediatamente a testing. Os servidores remetentes obterão a política atualizada e deixarão de rejeitar em minutos (ou, no máximo, dentro da janela do max_age anterior).

MTA-STS e DANE: duas abordagens complementares

Existem dois protocolos para impor a criptografia no transporte de email: MTA-STS e DANE (DNS-based Authentication of Named Entities). Resolvem o mesmo problema de formas diferentes.

Se o seu domínio não utiliza DNSSEC, o MTA-STS é a sua única opção para criptografia de transporte obrigatória.

Se o seu domínio utiliza DNSSEC, implementar ambos os protocolos oferece a proteção mais forte: o DANE elimina o TOFU para remetentes compatíveis com DNSSEC, enquanto o MTA-STS cobre os remetentes que não suportam DANE.

Boas práticas de implementação MTA-STS

1. Comece no modo testing: identifique problemas de conectividade TLS antes de mudar para enforce.
2. Configure TLS-RPT: receba relatórios sobre falhas de entrega TLS. Use o nosso Gerador TLS-RPT.
3. Valide os seus registros MX: certifique-se de que os padrões MX na política correspondem aos seus servidores de email reais. Incompatibilidades causam falhas de entrega no modo enforce.
4. Monitore antes de aplicar: analise os relatórios TLS-RPT durante pelo menos uma semana com zero falhas antes de mudar para enforce.
5. Use um max_age longo no modo enforce: 604800 segundos (7 dias) ou mais. Isto garante que os servidores remetentes guardam a política em cache tempo suficiente para resistir a ataques de downgrade.
6. Mude para enforce: quando os relatórios TLS-RPT confirmarem que tudo funciona, ative o modo enforce para proteção completa.

Ferramentas complementares

Guias e recursos

• MTA-STS: o guia completo para proteger o transporte dos seus emails - Tudo o que precisa saber sobre a configuração e a implementação do MTA-STS.
• De testing a enforce: estratégia de implementação progressiva do MTA-STS - Boas práticas para uma implementação gradual do MTA-STS.
• Configurar MTA-STS para Microsoft 365 e Google Workspace - Configuração passo a passo para as duas plataformas de email mais populares.
• MTA-STS não funciona? Guia completo de resolução de problemas - Diagnostique e corrija os erros de configuração MTA-STS mais comuns.
• MTA-STS vs DANE: qual protocolo escolher para proteger o transporte de email? - Comparação detalhada para escolher o protocolo certo.