Seus clientes dizem que nunca receberam seu email. Para onde ele foi?

Um cliente está no telefone dizendo que a fatura nunca chegou. Sua plataforma de envio mostra um check verde ao lado do endereço dele. Nenhum bounce caiu na sua caixa de entrada, nenhum erro apareceu em lugar nenhum, e quanto mais você encara aquele check, menos ele diz.

A resposta curta: esse check significa que o servidor de destino aceitou a mensagem, não que ela chegou. Um email sumido está em um de quatro lugares: na pasta de spam, na quarentena de um gateway corporativo, em um bounce que ninguém leu no log, ou nunca foi enviado. A causa mais comum é queda na pasta de spam, e duas verificações revelam a verdade em minutos: a palavra de status ao lado do endereço no log da sua plataforma, e uma pergunta ao cliente, se ele pode conferir a pasta de spam. O resto deste artigo percorre cada causa e sua correção.

Onde o email realmente está

O log da sua plataforma tem uma linha para essa mensagem, e ela é mais ou menos assim:

Aug 26 09:14   jane@ardentsupply.com   delivered   250 2.0.0 OK   14.2s

A palavra delivered e o código ao lado significam uma única coisa: o servidor de destino recebeu a mensagem. Uma resposta 250 significa que a outra máquina a aceitou. O que acontece depois acontece dentro da pilha de filtros de outra pessoa. Seu log termina nessa palavra.

Logo, uma mensagem que ninguém recebeu está em um de quatro estados:

1. Na pasta de spam. O filtro do destinatário classificou a mensagem como lixo. Ela espera ali até o cliente olhar.
2. Retida na quarentena de um gateway corporativo. Empresas grandes usam sistemas de email que retêm mensagens em que não confiam. O funcionário nunca vê a retenção, e nenhum bounce volta.
3. Deu bounce, e o bounce não foi lido. O endereço está morto ou foi rejeitado. A falha está registrada em um log que ninguém abriu.
4. Nunca foi enviada. O endereço foi suprimido após uma falha anterior, a campanha parou no meio, ou o endereço foi digitado errado no cadastro.

Faça isto: busque o endereço exato do cliente no log da sua plataforma antes de mexer em qualquer DNS ou configuração. A palavra de status ao lado reduz quatro estados possíveis a um ou dois.

O que “delivered” realmente diz

Plataformas de envio só conseguem relatar o lado delas da conversa. No instante em que o servidor de destino responde 250, a conversa acabou. A plataforma grava delivered, independentemente de a mensagem seguir para uma caixa de entrada, uma pasta de lixo ou uma quarentena.

O posicionamento é decidido depois da aceitação, por filtros que pesam fatores que seu log nunca vê: se seus registros SPF, DKIM e DMARC passam, como está a reputação do domínio de envio e se esse destinatário já respondeu você alguma vez. Duas mensagens com a mesma linha de log podem parar em pastas opostas. Um gateway corporativo pode engolir uma mensagem inteira sem avisar ninguém, porque um servidor que aceita email não é obrigado a relatar o que fez com ela.

Esse é o engano do check verde. Ele não está mentindo. Está respondendo a uma pergunta diferente da que você faz.

Faça isto: trate delivered como “a porta abriu”. Depois vá descobrir em qual sala a mensagem entrou. A próxima seção mostra como.

Uma pergunta que resolve metade dos casos

Antes de diagnosticar qualquer coisa, peça ao cliente para procurar na pasta de spam a sua mensagem da manhã de terça.

Se ele encontrar, você tem a resposta: queda na pasta de spam, causa um abaixo, e você sabe exatamente qual mensagem inspecionar. Se não encontrar nada em lugar nenhum, mesmo com ajuda do time de TI dele, a mensagem provavelmente nunca completou a entrega. Isso aponta para as causas dois e três. Não custa nada e leva um minuto. Vale mais do que chutar registros DNS que podem estar perfeitamente corretos.

Faça isto: envie essa pergunta agora, e leia o resto do texto enquanto espera a resposta.

As três causas, da mais comum para a menos

Causa um: está na pasta de spam

De longe a resposta mais comum. O filtro classificou sua mensagem como lixo. O motivo costuma ser seus registros ou sua reputação, não as palavras da mensagem. Uma fatura com link de pagamento, enviada a um cliente que nunca respondeu seu domínio, é exatamente o tipo de mensagem que os filtros tratam com desconfiança.

O sinal: o cliente encontra a mensagem no lixo, ou um segundo cliente relata o mesmo. Rode o email health check no seu domínio de envio e leia os vereditos dos registros antes de mudar uma palavra da mensagem. Se os registros estão limpos e isso continua acontecendo entre clientes, leia o hub de diagnóstico de spam para os sinais de reputação e reclamações.

O que fazer: corrija o que o health check apontar. Se continuar acontecendo entre clientes depois disso, trate como problema de reputação, não de template.

Causa dois: o endereço está morto ou errado

Segunda mais comum, e a mais fácil de confirmar, porque o seu próprio log já sabe. Busque nele de novo e olhe a linha de falha:

Aug 26 09:14   jane@ardentsuply.com   bounced   550 5.1.1 User unknown

Falta uma letra no domínio. A caixa postal fechou no ano passado. O cliente digitou o endereço errado no seu formulário de checkout, a versão desse problema que marcas de ecommerce mais veem. Os três casos terminam na mesma forma 550 5.1.1. A mensagem nunca chegou a uma pessoa, e nada no seu domínio tem culpa.

O sinal: a linha do log para esse endereço diz bounced com um código permanente. Ou o endereço sumiu da lista de envio por completo, porque sua plataforma parou de enviar para ele depois de uma falha anterior. Cada código permanente carrega seu próprio significado. O que significa “o servidor de destino não quer seu email”, e não “este endereço está morto”, é destrinchado em 550 5.7.1 mensagem rejeitada.

O que fazer: consiga o endereço correto com o cliente e remova o morto. Depois verifique por onde o endereço errado entrou no seu sistema. Vários assim numa mesma lista é problema de coleta, e enviar para endereços mortos é uma das formas mais rápidas de prejudicar um domínio saudável. Endereço rejeitado continua rejeitado, então não fique tentando de novo.

Causa três: um gateway corporativo pôs em quarentena

O caso silencioso. Empregadores grandes usam gateways de email que retêm mensagens consideradas suspeitas. A mensagem fica numa quarentena que o funcionário nunca abriu e não encontra sem o time de TI. Nenhum bounce volta, porque o gateway aceitou a mensagem. Seu log diz delivered, e dessa vez é verdade.

Acontece mais com faturas e avisos de conta indo para empresas grandes. Que também é a pior hora, porque há dinheiro esperando pela mensagem. E para cada cliente que liga, outros podem estar perdendo o mesmo email sem dizer uma palavra.

O sinal: o cliente não encontra nada na própria pasta de spam, e o time de TI dele localiza a mensagem numa quarentena do lado de lá. Essa última parte é a confirmação. Nada do seu lado consegue vê-la.

O que fazer: peça ao seu contato para solicitar ao TI dele a liberação da mensagem e uma entrada de allowlist para o seu domínio. Do seu lado, garanta que o email esteja totalmente autenticado. Um SPF, DKIM e DMARC passando limpo é a melhor evidência de que a sua mensagem é o que diz ser. Depois disso, o ajuste do filtro de outra empresa cabe a eles.

Soft bounce ou hard bounce: qual deles parou este email?

Seu log responde isso antes do código. Um hard bounce é permanente: a família 550, como a linha 550 5.1.1 User unknown acima. O endereço está morto ou foi rejeitado, e a correção é remover, não tentar de novo. Um soft bounce é temporário: a família 4xx, como 421 4.7.0. O destinatário não aceitou mensagem desta vez, mas não fechou a porta. Caixa cheia, servidor ocupado, um rate limit. A maioria das plataformas tenta soft bounces de novo por conta própria.

Faça isto: olhe o primeiro dígito do código no seu log. Um 5 significa remover o endereço ou investigar a rejeição. Um 4 significa esperar e observar, porque um monte crescente de respostas 4xx é um alerta precoce que vale ler antes de virar 5s.

Como verificar se seu domínio de email está em blocklist

A queda na pasta de spam tem uma prima mais dura: uma listagem em blocklist. Blocklists são as listas que servidores de destino e filtros consultam antes de aceitar email. Um domínio listado pode ver o email sumir na porta, às vezes com um bounce que cita a lista, às vezes sem rastro visível nenhum, o que coloca você de volta exatamente na lacuna com que este artigo começou.

O blocklist checker responde a pergunta em segundos, para as listas que realmente afetam a entrega, e verificar não custa nada. Se o seu domínio aparecer listado, o procedimento de remoção é um trabalho à parte, e o passo a passo gratuito está no guia de saída de blocklist.

Faça isto: rode a verificação no seu domínio de envio antes de culpar a mensagem. Um resultado limpo elimina um ramo inteiro do diagnóstico em menos de um minuto.

Verifique antes do próximo envio

Seja qual for a causa, feche o caso verificando o domínio de envio de fora da sua plataforma. O email health check lê seus registros SPF, DKIM e DMARC do jeito que um servidor de destino lê e mostra os vereditos numa única tela.

Depois confirme com a realidade. Após a correção, envie a próxima mensagem real para aquele cliente e peça que confirme se chegou. Uma entrega confirmada vale mais do que qualquer dashboard.

O que o log nunca vai dizer

Cada verificação acima responde por uma mensagem num único dia. A lacuna no meio do fluxo, entre aceito e posicionado, continua escura não importa quantas vezes você repita as verificações à mão. Um registro DNS pode quebrar numa terça e mandar um mês de faturas para o lixo antes de alguém ligar. Uma listagem em blocklist pode chegar e sair dentro da mesma semana, levando o envio daquela semana junto, e uma verificação feita aos domingos nunca vai vê-la. Uma campanha para um segmento velho pode atrair reclamações suficientes para afetar o posicionamento de toda mensagem seguinte, para todo cliente.

Essa lacuna é o que a LitInboxes observa. Ela reverifica seus registros, status de blocklist e sinais de reputação a cada seis horas. Ela guarda o histórico datado que transforma “os clientes pararam de confirmar” em “o registro DKIM quebrou no dia 14”. E envia um alerta quando algo muda, por email em todos os planos, e por Slack, Discord ou webhook no Pro. Há uma demo ao vivo se você quiser ver a tela antes que qualquer outra coisa suma.

O checklist

1. Busque o endereço exato do cliente no log da sua plataforma. Leia a palavra de status.
2. Peça ao cliente para procurar essa mensagem específica na pasta de spam.
3. Se deu bounce, corrija o endereço e verifique de onde veio o errado.
4. Se não existir nada do lado dele, peça ao time de TI para procurar na quarentena do gateway.
5. Rode o email health check no seu domínio de envio e corrija cada registro sinalizado.
6. Rode o blocklist checker se os problemas de posicionamento antecedem esta mensagem.
7. Peça ao gateway para incluir seu domínio na allowlist se a quarentena foi a causa.
8. Coloque o domínio num ciclo de observação, semanal à mão ou com monitoramento contínuo, para que a próxima falha silenciosa se anuncie sozinha.