Consulta de MX:
o seu servidor de correio responde?

Escreva o seu domínio acima. Consultamos os respetivos registos MX, ordenamo-los por prioridade, resolvemos cada nome de servidor para IPv4 e IPv6, executamos o ciclo de FCrDNS em cada endereço, identificamos o fornecedor de correio a partir do padrão e, depois, ligamo-nos a cada servidor na porta 25 a partir da nossa rede de sondas — lendo o banner SMTP e testando o STARTTLS. Grátis, sem registo, uns segundos do princípio ao fim.

Número mais baixo = tentado primeiro. Os remetentes só avançam na lista quando os servidores de melhor prioridade não respondem. Prioridades iguais não são um erro — são balanceamento de carga em round-robin, e os grandes fornecedores usam-nas (o conjunto clássico do Google tem dois servidores em 5 e dois em 10). O problema das estruturas com vários níveis não são os números — é o facto de o nível de reserva correr software mais antigo e filtragem mais permissiva, e é exatamente por isso que os spammers o visam.

DNS inverso confirmado no sentido direto: o IP do seu servidor de correio tem de ter um registo PTR, e o nome desse PTR tem de resolver de volta para o mesmo IP. É uma prova barata de que quem controla o IP também controla o nome — as máquinas de spam em gamas de IP sequestradas normalmente não conseguem cumpri-la. As diretrizes do Google para remetentes exigem um PTR válido e correspondente para entregar no Gmail, e a maioria dos filtros pontua-o. E antes de arrumar isto na gaveta do «isto é só de saída»: o seu servidor MX também envia — todas as rejeições, todas as respostas de ausência, todos os reencaminhamentos. Um ciclo quebrado na máquina de entrada penaliza discretamente tudo isso.

Um único MX com preferência 0 e a raiz como servidor — 0 . — definido pela RFC 7505. É a forma padrão de declarar «este domínio não aceita correio.» Os remetentes veem-no e devolvem uma rejeição permanente em segundos, em vez de recorrerem à regra do MX implícito e martelarem o seu servidor web com novas tentativas durante dias. É o registo certo para domínios estacionados e só-web — combinado com v=spf1 -all e uma política de rejeição no DMARC, para que também ninguém possa enviar em nome do domínio.

Surpreendentemente, sim. A regra do MX implícito da RFC 5321 diz que, quando não existe nenhum MX, os remetentes tratam o registo A/AAAA do domínio como um MX com preferência 0 — por isso o correio é entregue a quem quer que responda no IP do seu servidor web. Se essa máquina tiver por acaso um MTA a correr, o correio flui; há quem tenha o correio de produção assente neste acidente durante anos. É frágil — muda o site, perde-se o correio — e raramente é intencional. Publique registos MX explícitos para correio a sério, ou 0 . para nenhum.

Não — e é uma confusão comum. O MX responde a «para onde vai o correio dirigido a este domínio»; a sua reputação de envio vive no IP de origem, no SPF, no DKIM e no DMARC, que as nossas ferramentas irmãs avaliam uma a uma. Duas exceções: se o correio estiver em alojamento próprio, a máquina do MX é a máquina de envio, por isso o FCrDNS e a higiene de TLS contam a dobrar; e alguns recetores verificam se um domínio que envia correio também o consegue receber — um conjunto de MX quebrado falha esse teste discretamente.

A sonda abre uma ligação TCP a cada servidor MX na porta 25, lê o banner de saudação, envia EHLO e verifica se o STARTTLS é oferecido — depois negoceia-o e regista a versão de TLS e o certificado. Não envia correio: a conversa para antes do MAIL FROM. Não consegue fazer isto a partir de uma ligação doméstica porque os ISPs residenciais bloqueiam a porta 25 de saída para combater o spam de botnets. Uma ressalva a saber: o STARTTLS na porta 25 é oportunista — um atacante no caminho da ligação pode remover a oferta. O MTA-STS é o cadeado; o nosso Verificador de Versões TLS percorre cada versão de protocolo que o seu servidor vai falar.