Alojamento MTA-STS Gratuito

Por que razão o MTA-STS é essencial

O SMTP foi concebido em 1982 sem cifragem. O STARTTLS foi adicionado posteriormente para cifrar o email em trânsito, mas tem uma falha crítica: é oportunista. Um servidor remetente anuncia o suporte STARTTLS, e o servidor recetor pode aceitar ou ignorar. Nada obriga a ligação a permanecer cifrada.

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

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

A barreira à implementação: o MTA-STS exige o alojamento de um ficheiro 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 ficheiro 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 oportunístico. Eis o que isso significa na prática:

• Interceção em texto simples: qualquer atacante ao nível da rede pode ler os seus emails removendo o STARTTLS. Isto não é teórico. Programas de vigilância estatais e interceção ao nível de ISP estão documentados.
• Sem verificação pelo remetente: sem uma política publicada, os servidores remetentes não têm forma de 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 cifragem de dados sensíveis em trânsito. O TLS oportunístico por si só não cumpre este requisito, pois pode ser contornado.
• Falhas invisíveis: sem TLS-RPT (o protocolo de relatório complementar), nunca saberá que emails para o seu domínio foram entregues sem cifragem. O problema é silencioso.

Em 2014, investigadores documentaram a supressão em larga escala de STARTTLS por intermediários de rede em vários países. O Transparency Report da Google confirmou posteriormente que uma parte significativa dos emails recebidos ainda chega sem cifragem. 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 registo DNS TXT em _mta-sts.captaindns.com

Este registo 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 ficheiro de política alojado em HTTPS em https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Este ficheiro 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 registos MX
• max_age: durante quanto tempo os servidores remetentes devem guardar 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 registo TXT _mta-sts. Se estiver presente, obtém o ficheiro 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

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

2. Verifique a propriedade do domínio

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

3. Adicione os registos DNS de implementação

Dois registos 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 fornecedores de email

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

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

Alojado vs. auto-alojado: qual opção escolher?

Escolha alojado se pretende implementar MTA-STS em minutos, sem qualquer infraestrutura. Escolha auto-alojado se necessita de controlo 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 a entregar os emails mesmo se o TLS falhar. Isto dá-lhe 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. O ID da política é rodado 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 cifragem 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 cifragem 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 registos 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. Monitorize 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 de 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.