Teste de MX e STARTTLS

Como uma mensagem encontra o seu servidor

Quando alguém escreve para anna@example.com, o servidor de e-mail dessa pessoa consulta os registros MX de example.com. Cada registro indica um servidor e lhe dá um número. O menor número é tentado primeiro e os outros servem de reserva. O servidor remetente então abre uma conexão na porta 25 e as duas máquinas conversam em SMTP, um protocolo de 1982 que envia tudo como texto legível.

A criptografia veio depois, como uma melhoria dentro da mesma conversa. O servidor que recebe lista STARTTLS entre os seus recursos, o remetente responde com a mesma palavra e, a partir daí, a sessão é protegida por TLS, a tecnologia por trás do HTTPS. Se a palavra não estiver na lista, a mensagem viaja sem criptografia.

O que o teste faz na porta 25

Para até cinco servidores MX, em ordem de prioridade, ele resolve o primeiro endereço IPv4 e encena o início de uma entrega:

S: 220 mx1.example.com ESMTP
C: EHLO <our server>
S: 250-mx1.example.com
S: 250-SIZE 52428800
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
   (TLS handshake, certificate read)
C: QUIT

E para por aí. Nunca informa remetente, destinatário nem mensagem. Do handshake, ele anota a versão de TLS, a cifra, o emissor e a data de validade do certificado, se o certificado cita o host MX e se a cadeia leva a uma autoridade confiável.

Em seguida, procura dois registros DNS e um arquivo: o registro TXT em _mta-sts, a política em https://mta-sts.example.com/.well-known/mta-sts.txt e o registro TXT em _smtp._tls.

Lendo os quatro blocos

Servidores

Quantos hosts MX responderam à conexão. Um servidor de reserva mudo gera um alerta. Se nenhum responder, os remetentes deixam o seu e-mail na fila e o devolvem depois de alguns dias.

Criptografia

“Parcial” quer dizer que pelo menos um servidor acessível não concluiu o STARTTLS. É a única constatação aqui que deixa o resultado inteiro vermelho enquanto o e-mail continua chegando.

Certificados

“Revisar” cobre um certificado vencido, um autoassinado ou um emitido para outro nome. TLS 1.0 e 1.1 são marcados à parte como ultrapassados.

MTA-STS

Mostra o modo encontrado no arquivo de política: enforce, testing ou none. Fica vermelho quando o registro DNS existe mas o arquivo não pode ser baixado, não tem a linha de modo ou deixa de fora um dos seus hosts MX.

Um domínio sem MX, ou com o registro “null MX” 0 ., é indicado como um domínio que não recebe e-mail. Para um domínio que só serve um site, essa é uma configuração válida.

Por que um certificado ruim ainda recebe e-mail, e como o MTA-STS muda isso

O STARTTLS puro é oportunista. A maioria dos remetentes criptografa quando pode e não verifica o certificado. Então quem controla o caminho na rede pode apagar a linha STARTTLS da resposta e ler tudo. O MTA-STS fecha esse buraco. Você publica, por HTTPS, a lista dos seus hosts MX e a regra de que eles precisam apresentar um certificado válido. O Gmail e o Outlook.com aplicam essa regra quando enviam para você.

O arquivo de política tem quatro linhas:

version: STSv1
mode: testing
mx: mx1.example.com
max_age: 604800

Sirva-o a partir do subdomínio mta-sts com um certificado HTTPS válido e depois acrescente dois registros TXT:

_mta-sts.example.com.   TXT "v=STSv1; id=20260115"
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Fique em testing até que os relatórios diários TLS-RPT voltem sem falhas, depois passe para enforce e mude o valor de id para que os remetentes recarreguem a política. Em e-mail hospedado, como Google Workspace ou Microsoft 365, os certificados dos MX são responsabilidade do provedor. A política é a única parte que você precisa publicar.