E-mail autogerenciado em VPS caindo no spam (2026): solução de problemas de SPF, DKIM, DMARC, PTR e logs de rejeição

Não comece alterando o SPF. Primeiro confirme em qual situação você está:

1. Rejeição direta: você recebe um bounce contendo 550, 5.7.1, policy, SPF fail, PTR required e strings semelhantes;
2. O destinatário aceitou, mas caiu no spam: os logs SMTP parecem bem-sucedidos, Gmail/Outlook receberam, mas não chega à caixa de entrada;
3. Entrega atrasada: os logs mostram deferred, temporarily rejected, rate limited, e pode ter sucesso mais tarde.

Esses três casos têm causas diferentes.

Rejeições geralmente são erros duros: priorize autenticação DNS, PTR e listas negras; cair no spam geralmente é um problema de reputação e conteúdo; entrega atrasada geralmente é limite de frequência, reputação, greylisting ou políticas temporárias.

Comece verificando os logs de e-mail. Caminhos comuns no Debian/Ubuntu:

sudo tail -n 200 /var/log/mail.log

Se estiver usando Docker Mailserver:

docker logs mailserver --tail=200

Fila do Postfix:

postqueue -p

Ver detalhes da fila de uma mensagem específica:

postcat -vq QUEUE_ID

Aja somente depois de ver o código de erro específico; não corrija às cegas.

O SPF informa ao destinatário quais servidores podem enviar e-mail em nome do seu domínio.

Primeiro verifique o DNS:

dig TXT example.com +short

Um SPF mínimo para e-mail autogerenciado pode ser assim:

v=spf1 mx -all

Ou listar explicitamente o IP:

v=spf1 ip4:203.0.113.10 -all

Erros comuns:

• Existem dois registros v=spf1 para o mesmo domínio;
• Esquecer de adicionar o IP do VPS;
• Adicionar muitos include, ultrapassando o limite de 10 consultas DNS do SPF;
• Usar sempre ~all e nunca restringir;
• A aplicação na verdade envia por um serviço de terceiros, mas o SPF não inclui esse serviço.

Observação: o SPF analisa o envelope sender / Return-Path, não necessariamente o From que o usuário vê. Muitas falhas de DMARC são, na verdade, casos em que o SPF passou, mas não estava alinhado com o domínio do From.

O DKIM adiciona uma assinatura ao e-mail. O destinatário usa a chave pública no DNS para verificar se a mensagem não foi alterada.

Procure DKIM-Signature no e-mail original e você verá algo como:

s=mail; d=example.com;

Aqui s=mail é o selector. Consulte o DNS:

dig TXT mail._domainkey.example.com +short

Erros comuns:

• O selector no e-mail é mail, mas o DNS publica em default._domainkey;
• A chave pública DKIM foi copiada de forma incompleta;
• O provedor de DNS trunca registros TXT longos;
• A chave DKIM do servidor foi trocada, mas o DNS ainda tem a chave pública antiga;
• O DKIM não foi habilitado para todos os serviços de envio.

Depois de enviar para o Gmail, clique em "Mostrar original" e verifique se Authentication-Results contém:

dkim=pass
spf=pass
dmarc=pass

Se o DKIM falhar, não se preocupe ainda com o texto do conteúdo: a identidade não foi verificada e a chance de chegar à caixa de entrada é muito baixa.

O DMARC é construído sobre SPF e DKIM. Ele se importa se o domínio do From que o usuário vê está alinhado com um domínio que passou na verificação SPF ou DKIM.

Consulte o DMARC:

dig TXT _dmarc.example.com +short

Ao começar o diagnóstico, recomenda-se usar:

v=DMARC1; p=none; rua=mailto:[email protected]

Depois de confirmar que todas as fontes de envio estão funcionando corretamente, suba gradualmente para:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Só então considere:

v=DMARC1; p=reject; rua=mailto:[email protected]

Não vá direto para p=reject. Se você ainda tem formulários do site, sistemas de monitoramento, serviços de e-mail de terceiros ou notificações de serviços Git enviando e-mail, rejeitar sem ter mapeado tudo pode derrubar também seus próprios e-mails legítimos.

O DNS reverso PTR é um dos requisitos rígidos do e-mail autogerenciado.

Consulte o IP do seu VPS:

dig -x 203.0.113.10 +short

O resultado ideal deve retornar seu hostname de e-mail, por exemplo:

mail.example.com.

Depois verifique a resolução direta:

dig A mail.example.com +short

Deve resolver para o mesmo IP.

Isso se chama DNS reverso confirmado por encaminhamento (forward-confirmed reverse DNS). Muitos destinatários analisam esse sinal.

O PTR não é configurado no Cloudflare DNS, nem no painel DNS do seu domínio. Ele deve ser configurado no console do provedor do VPS, ou abrindo um ticket para o provedor alterar.

Erros comuns:

• O PTR está vazio;
• O PTR aponta para o hostname padrão do provedor;
• O PTR aponta para mail.example.com, mas mail.example.com não tem registro A;
• O hostname HELO/EHLO não corresponde ao PTR;
• Vários domínios compartilham um servidor de e-mail, mas as identidades não estão unificadas.

Verifique o hostname no Postfix:

postconf myhostname
postconf myorigin

Se o seu servidor se anuncia como vps123.provider.com, mas o From do e-mail é example.com, sua reputação vai ficar muito ruim.

Muitos provedores de nuvem bloqueiam a porta 25 de saída por padrão. Conseguir fazer login no cliente de e-mail localmente não significa que o servidor consegue entregar para fora.

Teste contra o MX do Gmail:

nc -vz gmail-smtp-in.l.google.com 25

Se der timeout ou for recusado, o provedor pode ter bloqueado a porta 25.

Você também pode usar telnet:

telnet gmail-smtp-in.l.google.com 25

Se a porta 25 estiver bloqueada, normalmente há apenas três opções:

1. Abrir um ticket solicitando o desbloqueio;
2. Mudar para um provedor de VPS que permita e-mail de saída;
3. Usar um SMTP relay, como Amazon SES, Mailgun, SendGrid ou Postmark.

Não use 587/465 como substituto da entrega entre servidores na porta 25. 587/465 são para envio de clientes, não um substituto da entrega normal MTA para MTA.

Se o DNS está correto e o PTR também, mas o e-mail continua sendo rejeitado, o próximo passo é verificar a reputação do IP.

Primeiro verifique as RBL/DNSBL comuns. Você pode usar ferramentas online ou consultar algumas listas diretamente:

dig 10.113.0.203.zen.spamhaus.org A

Aqui o IP deve ser escrito ao contrário. Por exemplo, 203.0.113.10 vira 10.113.0.203.

Opções mais práticas:

• MxToolbox blacklist check;
• Spamhaus;
• Google Postmaster Tools;
• Microsoft SNDS / JMRP.

Verifique o IP assim que comprar um VPS novo. Já escrevemos sobre isso antes:

• Como verificar listas negras e reputação de IP de VPS: não se apresse em montar um site ou fazer login em contas com um IP sujo

Se o IP já está em uma lista negra principal, não perca tempo mexendo no Postfix. Primeiro veja se consegue trocar o IP, obter reembolso ou mudar de provedor. Alguns ASNs de VPS baratos são abusados a longo prazo, e mesmo com configuração perfeita, chegar à caixa de entrada do Gmail pode ser muito difícil.

Se o destinatário já aceitou o e-mail, mas ele cai no spam, significa que a autenticação técnica pode ser apenas "suficiente" e a reputação ainda não foi estabelecida.

Verifique nesta ordem:

1. Se spf/dkim/dmarc no original do Gmail passa em tudo;
2. Se o domínio do From está alinhado com o d= do DKIM;
3. Se PTR, HELO e registro A são consistentes;
4. Se um IP novo está enviando muito e-mail logo de cara;
5. Se está enviando demais para endereços inexistentes, causando muitas rejeições;
6. Se o conteúdo é todo imagens, tem muitos links curtos ou domínios de link inconsistentes;
7. Se está misturando e-mail de marketing com e-mail transacional;
8. Se o Google Postmaster Tools mostra reputação baixa.

Não faça envio em massa de um IP novo imediatamente. Comece com volume baixo e e-mail com interação real, e aumente o volume gradualmente. O e-mail autogerenciado é mais adequado para:

• E-mail pessoal;
• Notificações do site;
• Uma pequena quantidade de e-mail transacional;
• Alertas de sistemas internos.

Não é adequado para enviar e-mail de marketing logo de cara. Isso é destruir ativamente a reputação do seu IP.

As pistas comuns são mais ou menos assim:

Um 4xx geralmente é uma rejeição temporária; um 5xx é quase sempre uma rejeição dura. Não fique só no "falhou": leia o texto que vem depois.

Isso não é vergonha, é a realidade.

Se você se deparar com as seguintes situações, considere seriamente um SMTP relay:

• O provedor não abre a porta 25;
• A faixa de IP tem reputação ruim, e trocar de IP também não é estável;
• Você precisa enviar notificações de negócio, códigos de verificação ou e-mails de pedido e não pode apostar na entregabilidade;
• Você não tem energia para manter RBL, relatórios DMARC e tratamento de rejeições;
• Gmail/Outlook continuam mandando para o spam mesmo com a autenticação toda passando.

Uma abordagem de meio-termo é:

• Seu próprio VPS cuida do recebimento, IMAP e armazenamento da caixa;
• O e-mail de saída passa por um relay como Amazon SES, Mailgun, SendGrid ou Postmark;
• From, DKIM e Return-Path são todos alinhados conforme os requisitos do relay;
• E-mails transacionais importantes e e-mails pessoais usam domínios ou subdomínios separados.

Assim você continua controlando os dados da sua caixa de e-mail, mas não coloca toda a pressão de entrega em um IP de VPS barato.

Se o e-mail está caindo no spam agora, faça isto na ordem:

• Verifique /var/log/mail.log ou os logs do Docker para confirmar se é rejeição, atraso ou queda no spam;
• Envie para o Gmail e verifique spf/dkim/dmarc na mensagem original;
• Use dig TXT example.com +short para verificar o SPF;
• Use dig TXT selector._domainkey.example.com +short para verificar o DKIM;
• Use dig TXT _dmarc.example.com +short para verificar o DMARC;
• Use dig -x VPS_IP +short para verificar o PTR;
• Use postconf myhostname para verificar a identidade HELO/EHLO;
• Use nc -vz gmail-smtp-in.l.google.com 25 para verificar a porta 25;
• Verifique Spamhaus / MxToolbox;
• Cadastre-se no Google Postmaster Tools;
• Envie com volume baixo de um IP novo primeiro; não faça envio em massa;
• Se continuar instável, considere um SMTP relay.

Quando o e-mail autogerenciado em VPS cai no spam, a causa mais comum não é "o servidor de e-mail está quebrado", mas sim que a identidade e a reputação não passaram no teste.

A ordem de diagnóstico é simples: verifique primeiro os logs de rejeição, depois SPF, DKIM, DMARC, em seguida PTR/rDNS, HELO, porta 25, listas negras de IP e dados do Postmaster. Se a autenticação falhar, corrija primeiro a autenticação; depois que passar, analise a reputação e o comportamento de envio.

Se você usa um VPS barato cuja faixa de IP é abusada a longo prazo, não gaste todo o seu tempo na configuração. Troque o IP quando for preciso, e use um SMTP relay quando for preciso. A entrega confiável do e-mail autogerenciado é só metade sobre configuração técnica; a outra metade é reputação.