Boleto caindo no spam: por que o e-mail do provedor não chega e como resolver

Quando o cliente liga dizendo que não recebeu o boleto, o e-mail quase sempre saiu do sistema de gestão (SGP, HubSoft, IXC Soft, DuoBox, MK-Auth) e foi desviado ou barrado por um motivo que dá para apontar. O envio sai por um servidor SMTP (o protocolo que leva a mensagem até o servidor do destinatário), e é nessa entrega que o destino decide o que fazer com ela.

As causas mais comuns em provedor regional:

• Servidor SMTP genérico ou IP sem reputação. O sistema manda pelo SMTP da hospedagem do site ou por um servidor na rede do provedor. Se o IP não tem reverso (o registro PTR, que traduz o IP de volta para um nome de servidor) ou está na Spamhaus PBL (a lista de faixas de IP de usuário final, que não deveriam enviar e-mail direto), o destino desconfia antes de ler o conteúdo.
• Domínio próprio sem SPF, DKIM e DMARC. SPF é a lista de servidores que podem enviar em nome do seu domínio; DKIM é uma assinatura digital que prova que a mensagem saiu de quem diz; DMARC amarra os dois ao campo De (o remetente que o cliente vê) e diz ao destino o que fazer quando a checagem falha. Sem eles, o destino não sabe se cobranca@seuprovedor.com.br é você ou um golpe.
• Remetente @gmail.com ou @hotmail.com. O provedor não controla esses domínios, então não consegue autenticá-los. O Google pede para não usar @gmail.com no campo De fora dos servidores dele e avisa que aplica quarentena por DMARC a quem fizer isso.
• Insistir em endereços mortos. Cada e-mail para uma caixa que não existe volta como bounce (devolução). O Yahoo manda tirar esses endereços da lista logo; o Google sugere descadastrar quem nunca abre. Isso pesa na reputação.
• Volume em rajada e conteúdo. Milhares de faturas no mesmo minuto de um domínio sem histórico (o Gmail devolve 421 4.7.28, volume incomum), texto que é só um link encurtado, anexo pesado. Nenhum sozinho condena a mensagem, mas todos pesam.

Desde 1º de fevereiro de 2024, o Google exige de todo remetente: SPF ou DKIM, IP com reverso válido, conexão com TLS (a criptografia entre os servidores) e taxa de spam no Postmaster Tools abaixo de 0,30% (o ideal, segundo o Google, é abaixo de 0,10%).

De quem envia cerca de 5.000 mensagens ou mais por dia a contas @gmail.com, exige mais: SPF e DKIM juntos, DMARC publicado (p=none já atende) e domínio do De alinhado, isto é, igual ao que passou no SPF ou no DKIM. Mensagens de marketing e de assinatura precisam do descadastro em um clique (cabeçalho List-Unsubscribe, RFC 8058); o Google exclui as transacionais. A conta é por dia, somando subdomínios; quem cruzou a linha uma vez fica como remetente em volume para sempre. Um provedor que dispara as faturas do mês num único dia pode cruzar essa linha. Desde novembro de 2025 o Gmail recusa mensagens fora dessas regras.

O Yahoo publicou exigências equivalentes em fevereiro de 2024. A Microsoft seguiu em 5 de maio de 2025: quem envia 5.000 mensagens ou mais por dia para Outlook.com, Hotmail e Live precisa de SPF e DKIM passando, DMARC (ao menos p=none) e alinhamento com um dos dois. As mensagens fora da regra foram primeiro para o Lixo Eletrônico; a etapa seguinte é a rejeição com o erro 550 5.7.515.

O Gmail responde na hora a quem não cumpre: 550 5.7.26 ("remetente não autenticado") ou 421 4.7.0 ("reputação muito baixa do IP de envio"). Os três registros estão explicados, com exemplos para copiar, no guia SPF, DKIM e DMARC para provedor: como configurar.

Um cenário hipotético com as causas acima: o sistema de gestão roda num servidor no rack do provedor, com IP da própria faixa de clientes (cadastrada na PBL como usuário final) e sem PTR, e envia as faturas como cobranca.provedor@gmail.com. Não há alinhamento possível e o DMARC falha. O sistema segue mandando fatura para endereços cancelados há anos, e cada um volta como bounce.

Pelas regras publicadas, o Gmail trata esse remetente como não autenticado e pode recusar (550 5.7.26) ou desconfiar do IP (421 4.7.0); no Outlook, acima de 5.000 por dia, a fatura vai para o Lixo Eletrônico ou é recusada. O financeiro só descobre quando o cliente reclama da multa. E não tem como provar o envio, porque o sistema registra "enviado" ao passar a mensagem ao servidor de saída, não o que o servidor do cliente respondeu.

Antes de mexer em qualquer coisa, olhe quatro lugares.

• A resposta SMTP do destino. Todo servidor responde com um código: 250 é aceita; 550 5.7.26 no Gmail é falta de autenticação; 421 4.7.28 é volume incomum; 550 5.7.515 no Outlook é domínio sem a autenticação exigida. Se o seu sistema ou o seu SMTP não mostra essa resposta por mensagem, você está às cegas.
• O Google Postmaster Tools. É gratuito, pede para comprovar o domínio com um registro TXT ou CNAME no DNS e mostra taxa de spam, reputação do IP e do domínio, autenticação e erros de entrega.
• Os registros do domínio. Abra uma fatura recebida no Gmail, use "Mostrar original" e veja as linhas SPF, DKIM e DMARC com PASS ou FAIL. Se aparece FAIL, ou o domínio ao lado não é o seu, está aí o problema.
• O IP de envio. Consulte-o em check.spamhaus.org. Se está na PBL ou não tem reverso, não deveria enviar e-mail direto: ou você regulariza (IP fixo, registros A e PTR batendo) ou envia por um servidor que já tenha isso resolvido.

Primeiro, remetente com domínio próprio: cobranca@seuprovedor.com.br, não @gmail.com. Só assim SPF, DKIM e DMARC apontam para um domínio que você controla. Publique os três no DNS. O DMARC pode começar em p=none, que já satisfaz Gmail, Yahoo e Outlook e ainda traz relatórios de quem manda e-mail em seu nome.

Segundo, um servidor SMTP autenticado (usuário e senha, porta 587 com TLS) cujo IP tenha reverso, esteja fora de listas e tenha a reputação acompanhada todos os dias. Um IP na rede de clientes do provedor raramente atende a isso.

Terceiro, lista de supressão: endereço que devolveu bounce definitivo ou marcou a fatura como spam sai do envio. Aqui vale ligar para o cliente e pedir um e-mail válido; é trabalho de cadastro, não de tecnologia.

Quarto, registro por mensagem: quando saiu, para quem e o que o servidor de destino respondeu. Dizer que o servidor do Gmail aceitou às 9h12 do dia 5 é diferente de dizer que consta como enviado.

Por fim, separe cobrança de campanha. Boleto, aviso de vencimento e código de acesso não podem esperar uma promoção sair da fila. Campanha precisa do descadastro em um clique; boleto não, mas quem pediu para parar tem que parar.

O SendMix é um servidor SMTP feito para provedor. Você não troca o SGP, o HubSoft, o IXC Soft, o DuoBox nem o MK-Auth: na configuração de e-mail do sistema, coloca smtp.sendmix.net na porta 587 (ou 465) com o usuário e a senha do painel, e a fatura continua saindo do lugar de sempre.

O painel em app.sendmix.net mostra os registros SPF, DKIM e DMARC do seu domínio e verifica sozinho se estão no ar. Cada mensagem fica registrada com a resposta do servidor de destino. Endereço que devolveu bounce definitivo entra na lista de supressão, para de receber e não gasta crédito. Cobrança e código de acesso têm prioridade na fila sobre campanha. Um webhook devolve tudo isso ao seu sistema.

O que o SendMix não faz é garantir caixa de entrada, e desconfie de quem garantir. Resposta positiva do servidor de destino quer dizer que ele aceitou a mensagem; a decisão entre caixa de entrada e spam é dele. O que dá para fazer é cuidar do que está sob controle (domínio autenticado, IP com reputação acompanhada, lista limpa) e mostrar, mensagem por mensagem, o que o destino respondeu.

Não tem mensalidade. Um crédito é um destinatário, e a conta começa com 500 créditos grátis para testar com faturas reais.