Por que o e-mail da sua empresa cai no spam do cliente

O cliente afirma que não recebeu a proposta. Você abre a caixa de enviados e a mensagem está lá, com hora e tudo. Os dois estão dizendo a verdade: a mensagem saiu da sua máquina e nunca apareceu na frente dele.

Esse é o detalhe que torna o problema tão difícil de perceber. A falha é silenciosa dos dois lados. Quem envia vê “enviado” e vai dormir tranquilo. Quem recebe não vê nada — nem na caixa de entrada, nem no lixo eletrônico, porque em boa parte dos casos a mensagem foi recusada ainda na porta do servidor e nunca chegou a existir para o destinatário. Ninguém é avisado. O negócio simplesmente não acontece, e a explicação que sobra é “ele não respondeu”.

Quem decide isso não é um filtro de palavras

A ideia de que existe um filtro procurando palavras como “promoção” ou “grátis” é de 2005. O servidor que recebe a sua mensagem hoje faz três perguntas, nesta ordem:

1. Quem é você? A mensagem realmente vem de quem diz vir?
2. Qual é o seu histórico? O que aconteceu das outras vezes em que mensagens iguais a essa chegaram aqui?
3. As pessoas querem isso? Elas abrem, respondem, arrastam para fora do lixo — ou marcam como spam?

O conteúdo entra nessa conta, mas em último lugar. As duas primeiras perguntas são técnicas e respondem pela maioria absoluta dos casos.

Os três cartórios: SPF, DKIM e DMARC

São três registros que você publica no DNS do seu domínio. Sem jargão:

• SPF é a lista de quem tem permissão para enviar e-mail em nome do seu domínio. Se a sua empresa usa um serviço de e-mail, um sistema de emissão de nota e uma ferramenta de disparo, os três precisam estar nessa lista. Quem não está, é impostor aos olhos do destinatário.
• DKIM é um lacre criptográfico que o seu servidor coloca em cada mensagem. Ele prova duas coisas: que saiu mesmo de lá e que ninguém mexeu no caminho.
• DMARC é a instrução do que fazer quando os dois anteriores não batem — ignorar, mandar para o lixo eletrônico ou recusar. E, o que quase ninguém usa, é também um canal de relatórios: bem configurado, ele te conta quem anda mandando e-mail se passando pela sua empresa.

Faltar qualquer um dos três hoje é motivo suficiente para ir direto ao lixo eletrônico. Os grandes provedores deixaram de tratar autenticação como diferencial: para quem envia volume — a partir da casa dos milhares de mensagens por dia para o mesmo provedor — os três são exigência mínima, junto com um link de descadastro que funcione em um clique e seja processado em até dois dias.

A parte que surpreende: os três podem estar certos e o e-mail cair assim mesmo

É aqui que a maioria dos textos sobre o assunto para, e é onde o problema de verdade começa.

Você abre o cabeçalho de uma mensagem entregue e lê algo assim:

spf=pass    dkim=pass    dmarc=pass

Três aprovações. E, ainda assim, o mesmo remetente leva uma recusa na mensagem seguinte, com um texto parecido com este:

550 5.7.1 ... message rejected due to the reputation of the sending domain

Não há contradição. Autenticação é o crachá na portaria; reputação é a sua ficha lá dentro. O crachá provou que você é quem diz ser — e foi exatamente por isso que deu para ligar o seu nome ao histórico. Um remetente perfeitamente autenticado e com histórico ruim é mais fácil de bloquear, não mais difícil.

E tem um agravante: essa reputação é interna de cada provedor. Ela não aparece em nenhuma lista pública de bloqueio. Dá para conferir o seu endereço em dezenas de listas, achar tudo limpo, e continuar sendo recusado — porque o problema está num painel que só o provedor enxerga, e para o qual existe uma porta de entrada que quase ninguém abre. Falo dela adiante.

As cinco conferências que você faz hoje

Nenhuma delas exige contratar nada. Na ordem em que resolvem mais casos:

1. Leia o cabeçalho de uma mensagem que chegou. Peça a alguém de fora da empresa — um cliente, um amigo com e-mail pessoal — que abra uma mensagem sua e use a opção de exibir a mensagem original. As três linhas de autenticação estarão lá. Três pass significa que a portaria está em ordem e você pode passar para o item 4. Qualquer fail ou none é o seu problema, e é o mais barato de resolver.

2. Confira o nome reverso do endereço de onde você envia. Todo servidor de e-mail sério tem um nome de volta configurado, e esse nome precisa ser coerente com o que ele anuncia ao se apresentar. Servidor que se apresenta com um nome e responde por outro, ou que não tem nome nenhum, é tratado como suspeito antes mesmo de mostrar a mensagem.

3. Veja se o seu domínio publica DMARC — e em qual política. Se não publica, comece pela política mais leve, a que só observa e envia relatórios. Publicar a política severa de largada, sem antes olhar os relatórios, costuma derrubar sistemas legítimos da própria empresa que ninguém lembrava que existiam: o sistema de nota fiscal, o formulário do site, a impressora que manda o digitalizado por e-mail.

4. Verifique as listas públicas de bloqueio. É rápido e vale pela eliminação. Mas leia o resultado com cuidado: limpo nessas listas não significa nada sobre o filtro interno do Google ou da Microsoft. Serve para descartar o caso grave, não para provar que está tudo bem.

5. Cadastre o seu domínio nos painéis dos provedores. Este é o passo que separa quem chuta de quem enxerga. Google e Microsoft mantêm painéis gratuitos onde o dono de um domínio ou de um endereço de envio vê a própria reputação, o percentual de pessoas que marcaram as mensagens como spam e os erros que os servidores estão devolvendo. É a única janela para a informação que realmente decide o destino do seu e-mail. Leva alguns minutos para cadastrar e costuma exigir provar que o domínio é seu, publicando um registro no DNS.

Seis hábitos que derrubam a entrega de empresa honesta

Misturar canais no mesmo domínio. É o erro mais caro e o mais comum. A reputação é avaliada também no nome do domínio, não só no endereço do servidor. Quando a campanha de marketing sai pelo mesmo domínio que emite a cobrança e a nota fiscal, uma leva de reclamações na campanha contamina justamente o que não pode falhar. Marketing em um subdomínio ou domínio próprio; cobrança, contrato e nota em outro.

Disparar para uma base antiga sem limpar. Endereço de gente que saiu da empresa vira devolução. Devolução em excesso é lido como sinal de quem não sabe para quem está mandando — e o preço é pago pelos contatos que ainda leem você. Como regra prática: devolução acima de mais ou menos 2% de um envio já é motivo para parar e limpar a lista antes de continuar.

Estrear um remetente com volume alto. Domínio ou servidor sem histórico que dispara milhares de mensagens de uma vez não parece uma empresa: parece um surto. Remetente novo começa com dezenas de mensagens por dia para gente que responde, e sobe aos poucos ao longo de semanas.

Ignorar o descadastro. Quem não acha o link de sair da lista usa o botão de spam, que é o que mais machuca a sua reputação. O link visível e funcionando protege você, não o contrário. Para envio em volume, os provedores esperam também o descadastro de um clique, que o próprio aplicativo de e-mail exibe no topo da mensagem.

Mandar mensagem que é uma imagem só. Peça inteira em imagem, sem texto de verdade, com um link enorme encurtado, é a assinatura visual de quem quer esconder o conteúdo do filtro.

Responder à recusa mandando de novo. Quando o servidor devolve um erro definitivo, reenviar o mesmo conteúdo para o mesmo endereço piora o quadro. Erro definitivo pede correção; só erro temporário pede paciência.

Quando o problema não é seu

Vale saber que nem tudo que parece culpa sua é. Sistemas corporativos de proteção abrem e clicam automaticamente nos links de cada mensagem para inspecioná-los antes de liberar ao usuário. Isso infla as estatísticas de abertura e clique — e, se o robô de inspeção passar pelo link de descadastro, chega a remover contatos da lista sem que nenhuma pessoa tenha clicado em nada. Se os seus relatórios mostram aberturas instantâneas em massa ou descadastros inexplicáveis, considere essa hipótese antes de reescrever a peça inteira.

Também existe o caso simples: o cliente configurou uma regra agressiva, ou alguém do outro lado marcou a sua mensagem como spam uma vez e o provedor aprendeu. Quando o problema é em um destinatário só, quase sempre é isso — e a solução é pedir a ele que tire a mensagem do lixo eletrônico e marque o seu endereço como confiável.

O teste de dez minutos

1. Peça a alguém de fora que abra uma mensagem sua e leia as três linhas de autenticação.
2. Confira se o servidor de envio tem nome reverso coerente.
3. Veja se o domínio publica DMARC e em que política.
4. Cheque as listas públicas de bloqueio, sabendo que limpo ali não prova nada.
5. Cadastre o domínio nos painéis gratuitos dos grandes provedores e volte lá em uma semana.

Se os cinco itens estiverem em ordem e o problema continuar, o assunto deixou de ser configuração. Configuração se conserta em um dia. Reputação se reconstrói em semanas, baixando volume, limpando lista e mandando só para quem responde — não existe atalho, e quem promete atalho está vendendo outra coisa.

Apêndice: para quem administra o servidor

O que vem daqui para baixo é para quem tem acesso ao DNS e ao servidor de envio. Se você é o dono da empresa e não mexe nisso, pode parar aqui — mande este trecho para quem cuida da sua infraestrutura.

PTR, DNS reverso e o nome com que o servidor se apresenta

Três coisas precisam contar a mesma história, e é comum que só duas contem:

1. O endereço IP de envio tem um PTR — um nome reverso.
2. Esse nome, consultado normalmente, resolve de volta para o mesmo IP. Quando os dois sentidos batem, diz-se que o servidor tem DNS reverso confirmado.
3. O servidor se apresenta com esse mesmo nome na saudação inicial da conversa, o HELO (ou EHLO).

Conferir leva trinta segundos:

dig -x 203.0.113.25 +short          # IP  →  nome reverso
dig +short mail.suaempresa.com.br   # nome →  IP (tem que voltar o mesmo)

Se o PTR não existe, se ele aponta para um nome genérico do provedor de hospedagem, ou se o servidor se apresenta como localhost ou como um nome que não resolve, boa parte dos provedores grandes recusa antes de olhar o conteúdo. Servidor que muda de IP e esquece o PTR para trás é um clássico.

O erro mais comum de quem “já configurou tudo”: alinhamento

Existem dois remetentes em cada mensagem, e eles não precisam ser iguais:

• o From, que a pessoa vê na tela;
• o Return-Path (o remetente do envelope), que é para onde volta a devolução e é o que o SPF realmente verifica.

O DMARC exige que o domínio do From alinhe com o do Return-Path ou com o d= da assinatura DKIM. Alinhamento tolerante aceita subdomínio; o estrito exige domínio idêntico.

É por isso que uma configuração aparentemente correta falha: a ferramenta de disparo envia com envelope no domínio dela, o SPF dela passa lindamente, e o DMARC do seu domínio reprova porque nada alinha com o From que o cliente vê. O conserto é assinar em DKIM com o seu domínio, ou apontar o envelope para um subdomínio seu delegado à ferramenta.

SPF: os limites que derrubam registro grande

• O SPF tem teto de dez consultas de DNS por avaliação. Mecanismos como include, a, mx, exists e redirect contam. Passou do teto, o resultado é erro permanente — e erro permanente costuma ser tratado como falha, não como “deixa passar”. Empresa que acumula serviços (e-mail, emissor de nota, CRM, ferramenta de disparo) estoura isso sem perceber.
• Evite o mecanismo ptr: é lento e desaconselhado há anos.
• -all recusa quem não está na lista; ~all só marca. Comece com ~all, confira os relatórios e feche depois.
• E o principal: o SPF sozinho não protege o From que a pessoa vê — ele olha o envelope. Sem DKIM e DMARC, seu domínio continua falsificável.

DKIM na prática

Chave de 2048 bits, um seletor por origem de envio (assim dá para revogar uma sem derrubar as outras) e canonicalização tolerante, porque servidores no caminho reescrevem espaços e quebras de linha e uma assinatura rígida se rompe à toa. Na rotação, publique o seletor novo, espere propagar, troque a assinatura e só então remova o antigo. E assine depois de qualquer sistema que altere o corpo da mensagem: aparelho que adiciona aviso de confidencial no rodapé invalida assinatura feita antes dele.

A escada do DMARC

Comece em p=none com endereço de relatório agregado configurado e leia os relatórios por algumas semanas — é ali que aparecem os sistemas legítimos que ninguém lembrava: o emissor de nota, o formulário do site, a multifuncional que digitaliza e envia. Depois suba para quarentena com porcentagem parcial, acompanhe, e só então recuse. Publicar recusa de largada derruba a própria empresa antes de derrubar qualquer golpista.

Leia o código da recusa antes de reagir

Reenviar em cima de um 5xx é o reflexo errado mais caro que existe nesse assunto.

Encaminhamento, TLS e descadastro

• Encaminhamento quebra o SPF. Quando o destinatário reencaminha automaticamente para outro endereço, quem entrega passa a ser o servidor dele, que não está no seu SPF. Existe um mecanismo de cadeia autenticada que preserva o resultado original ao longo dos saltos — se você opera servidor que reencaminha, vale implementar.
• Transporte: declarar no DNS que o seu domínio exige TLS, e publicar um endereço para receber relatórios de falha de TLS, protege contra rebaixamento de conexão e ainda te avisa quando alguém tenta. Para quem já tem DNSSEC, há a opção de amarrar o certificado no próprio DNS.
• Descadastro de um clique, para envio em massa, são dois cabeçalhos trabalhando juntos: o List-Unsubscribe com um endereço de saída, e o List-Unsubscribe-Post declarando que a saída se resolve em uma requisição só, sem página intermediária pedindo login.

Ellos Informática — suporte e infraestrutura de TI em São Paulo capital, desde 2009. Se a sua empresa está com e-mail caindo no lixo eletrônico do cliente, fale com a gente: o diagnóstico acima é o mesmo que fazemos antes de mexer em qualquer coisa.