Programação Por Equipe DevBras

Capa do artigo: E-mail não chegou: como testar se o seu domínio recebe antes de culpar o remetente

E-mail não chegou: como testar se o seu domínio recebe antes de culpar o remetente

Confira o MX, a porta 25, o STARTTLS e se a caixa existe, em comandos curtos. Assim você descobre se o problema é o envio, o DNS ou a sua caixa.

O fornecedor jura que mandou a nota fiscal ontem às 15h. A caixa financeiro@lojaverde.com.br está vazia, o spam também, e ele já reenviou duas vezes. Antes de pedir a terceira, dá para saber de que lado está o problema. A resposta curta: um teste de recepção separa três suspeitos. Confira se o registro MX do domínio aponta para o servidor que você acha que usa, se esse servidor aceita conexão na porta 25 com um certificado coerente e se ele aceita o endereço de destino. Se tudo isso passa, o problema está no remetente ou num filtro, e o próximo passo é pedir a mensagem de erro que ele recebeu.

O exemplo deste guia é a Loja Verde, que migrou o e-mail de um provedor de hospedagem para um serviço de e-mail corporativo há três semanas.

Por que o e-mail some sem aviso

Quando alguém envia para financeiro@lojaverde.com.br, o servidor do remetente consulta o DNS atrás do registro MX de lojaverde.com.br, conecta no servidor indicado pela porta 25 e conversa em SMTP: apresenta-se, diz quem envia, diz para quem é e só então manda o conteúdo. Em qualquer ponto, o servidor de destino pode recusar com um código.

Se a recusa é definitiva (códigos 5xx), o remetente recebe uma mensagem de devolução. Se é temporária (4xx), o servidor dele tenta de novo por um tempo, e a pessoa não vê nada. Se o MX aponta para o lugar errado, a mensagem pode ser entregue com sucesso numa caixa que ninguém mais olha. Em todos esses casos, do seu lado, a caixa simplesmente fica vazia.

Na Loja Verde, a suspeita principal é a migração: se algum registro MX antigo ficou no DNS, parte das mensagens vai para o provedor de hospedagem que ninguém acessa mais.

Como testar a recepção passo a passo

  1. Liste os registros MX do domínio. Todos, não só o primeiro.
  2. Confirme que cada nome do MX pertence ao seu serviço atual e resolve para um IP.
  3. Teste a porta 25 de uma rede que permita saída nessa porta.
  4. Verifique o STARTTLS e o certificado que o servidor apresenta.
  5. Pergunte ao servidor se aceita o destinatário, sem enviar mensagem.
  6. Peça ao remetente a mensagem de devolução ou o registro de envio, com data e hora.
  7. Procure no rastreamento de mensagens do seu serviço e na quarentena.

Os registros MX

Resolve-DnsName lojaverde.com.br -Type MX

No Linux ou macOS:

dig +short MX lojaverde.com.br

Na Loja Verde, a resposta foi esta:

10 mx1.servicocorporativo.com.
10 mx2.servicocorporativo.com.
20 mail.hospedagemantiga.com.br.

O número é a preferência: menor é tentado primeiro. O terceiro registro, de prioridade 20, é a sobra da migração. Sempre que mx1 e mx2 demorarem ou recusarem temporariamente, o remetente tenta o servidor antigo, que ainda aceita mensagens para o domínio e as guarda numa caixa abandonada. Apagar esse registro resolve o "às vezes não chega". Se você mexer no MX, lembre do TTL, como em baixar o TTL antes de mudar o DNS.

Um domínio sem nenhum registro MX não está necessariamente sem e-mail: pela regra do SMTP, o remetente pode tentar o endereço do próprio domínio. Isso quase nunca é o que você quer. Declare o MX explicitamente.

A porta 25 e o certificado

Test-NetConnection mx1.servicocorporativo.com -Port 25

Muitas redes residenciais e vários provedores de nuvem bloqueiam a saída pela porta 25 para conter spam. Se o teste falhar de casa, não conclua nada: repita de um servidor que tenha essa porta liberada ou use um serviço de teste de recepção online, como o da sourceUrl deste post, que conecta de fora no seu MX e mostra cada etapa.

Para ver o STARTTLS e o certificado:

openssl s_client -starttls smtp -connect mx1.servicocorporativo.com:25 -servername mx1.servicocorporativo.com -crlf

Procure no fim da saída a linha Verify return code: 0 (ok) e confira se o nome no certificado combina com o nome do MX. Certificado vencido ou com nome que não bate não impede todos os envios, mas remetentes que exigem TLS verificado podem recusar a entrega.

A caixa existe?

Na mesma sessão do openssl, depois da negociação, você pode conduzir a conversa SMTP até o destinatário e parar antes de enviar qualquer conteúdo:

EHLO teste.lojaverde.com.br
MAIL FROM:<teste@lojaverde.com.br>
RCPT TO:<financeiro@lojaverde.com.br>
QUIT

Um 250 depois do RCPT TO indica que o servidor aceita aquele endereço. Um 550 com algo como "user unknown" diz que a caixa não existe no serviço novo, o que acontece quando a migração criou financeiro@ como apelido em vez de caixa, ou esqueceu dele. Respostas com códigos de caixa cheia ou de rejeição por política também aparecem aqui. Faça esse teste com os seus próprios endereços e com moderação: servidores podem limitar quem faz muitas consultas assim.

Quando o teste passa e a mensagem não aparece

Se o MX está certo, a porta responde, o certificado fecha e a caixa é aceita, o problema provavelmente não é a recepção do domínio. Restam três caminhos:

  • A mensagem nunca saiu. Peça ao remetente a devolução (bounce) ou o registro do envio. Sem isso, "eu mandei" é só uma lembrança.
  • Ela chegou e foi filtrada. Serviços corporativos têm quarentena separada da pasta de spam e um rastreamento de mensagens no painel administrativo, como o message trace do Microsoft 365 e a pesquisa de registros de e-mail do Google Workspace. Procure pelo endereço do remetente e pelo horário.
  • Uma regra da caixa moveu a mensagem. Regras de encaminhamento ou de mover para pasta criadas há anos continuam rodando em silêncio.

Se o problema é o contrário, mensagens que o seu site envia e não chegam aos clientes, o assunto é outro: veja formulário de contato que chega e por que entregar e-mail na caixa dos outros é a parte difícil.

Erros comuns

  • Pedir reenvio sem testar nada. A mensagem nova segue o mesmo caminho quebrado e some igual.
  • Deixar MX antigo depois de migrar. Parte das mensagens cai num servidor que ninguém acessa, de forma intermitente.
  • Testar a porta 25 de uma rede que a bloqueia. Você conclui que o servidor está fora quando o bloqueio é na sua saída.
  • Testar a máquina errada. O servidor que você conferiu não é o que está no MX, e o diagnóstico vale para nada.
  • Ignorar a quarentena do serviço corporativo. A mensagem está retida no painel do administrador, e a pessoa só olha a pasta de spam.
  • Caixa criada como apelido em vez de caixa real, ou esquecida na migração. O servidor recusa o endereço e só o remetente fica sabendo.

Checklist

  • Todos os registros MX apontam para o serviço atual.
  • Cada nome do MX resolve para um IP.
  • A porta 25 responde quando testada de uma rede sem bloqueio.
  • O STARTTLS funciona e o certificado combina com o nome do MX.
  • O RCPT TO do endereço reclamado recebe 250.
  • Você tem a devolução ou o registro de envio do remetente.
  • Rastreamento de mensagens e quarentena foram consultados pelo horário.

Rode agora a consulta de MX do seu domínio. Todos os nomes que aparecem são do serviço que você usa hoje, ou algum ainda entrega mensagens num lugar que você não está olhando?

Avalie este artigo

Referência: https://www.checktls.com/TestReceiver