Por que seus e-mails caem no spam, e o que ajuda de verdade
Os conselhos de sempre falam do assunto. Quem decide a entrega são três registros DNS, a reputação do seu domínio e a qualidade da sua lista.
O roteiro costuma ser sempre o mesmo. A confirmação do formulário nunca chega ao cliente, a newsletter cai na aba de promoções ou no spam de metade dos destinatários, e a primeira busca por solução termina numa lista de palavras a evitar no assunto. Então some o ponto de exclamação e "grátis" vira outra coisa. Depois disso nada muda.
Isso acontece porque esse conselho age sobre a menor alavanca disponível. Um servidor que recebe a mensagem pergunta primeiro quem está escrevendo e só depois o que está escrito. A primeira pergunta é respondida por três registros DNS e pelo que o seu domínio andou enviando nas últimas semanas. Nada disso está no assunto.
Este artigo coloca as alavancas em ordem de efeito. No fim você sabe qual registro mexer primeiro.
O trabalho rende nesta ordem
A maioria das listas de verificação sobre entregabilidade joga vinte itens no mesmo saco e não pesa nenhum. Em ordem de efeito, a coisa fica mais simples:
- Autenticação. SPF, DKIM e DMARC estão configurados e o alinhamento fecha.
- Caminho de envio. Seus e-mails saem de um servidor que os seus próprios registros DNS autorizam a enviar pelo domínio.
- Qualidade da lista. Na lista estão endereços com consentimento documentado, e os retornos são removidos.
- Reputação do remetente. Volume e frequência combinam com o que esse domínio enviou até agora.
- Conteúdo. Assunto, texto, proporção entre imagem e texto, número e destino dos links.
O ponto cinco é o mais escrito por aí. Ele só começa a contar quando os quatro anteriores estão de pé. Quem inverte a ordem lapida frases de uma mensagem que o servidor de destino nem consegue atribuir a alguém.
O que cada um dos três realmente verifica
Os três são citados juntos o tempo todo e confundidos com a mesma frequência. Eles respondem a três perguntas diferentes.
SPF diz quais servidores podem enviar
SPF está descrito na RFC 7208. É um registro TXT no seu domínio que lista quais servidores podem entregar e-mail em nome desse domínio. O servidor que recebe compara o endereço IP de quem entregou com essa lista e tem a resposta para uma pergunta: esse caminho é permitido ou não.
O segundo erro mais comum da prática mora exatamente aqui. Avaliar um registro SPF pode disparar no máximo dez consultas DNS, e cada serviço incluído custa pelo menos uma. Se você for somando o provedor da caixa postal, um serviço de newsletter, uma ferramenta de faturamento e um sistema de chamados, uma hora estoura o limite. O resultado é um permerror, e um registro SPF com permerror não vale nada. No painel de DNS ele continua com aparência totalmente normal.
DKIM prova que nada foi alterado no caminho
DKIM está na RFC 6376. No envio, uma assinatura criptográfica entra no cabeçalho da mensagem, e a chave pública correspondente fica no DNS do seu domínio. Com ela quem recebe confere duas coisas de uma vez: a mensagem saiu mesmo daquele domínio e a parte assinada chegou sem alteração.
DMARC junta os dois resultados com uma instrução
DMARC está descrito na RFC 7489 e é o registro que transforma dois resultados em uma decisão. Nele você define o que quem recebe deve fazer quando a verificação falha. São três valores: none significa não fazer nada, quarantine significa mandar para o spam, reject significa recusar. Além disso o DMARC abre o canal de relatórios que conta quem envia em seu nome.
O erro mais comum de longe: o registro fica em p=none e permanece ali para sempre. Como ponto de partida isso está certo, porque a primeira coisa que você quer é enxergar o que sai com o seu nome. Como estado permanente é uma linha no DNS sem efeito. Um registro que fala sério termina assim:
_dmarc.suaempresa.com.br. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@suaempresa.com.br"O alinhamento é onde a maioria das configurações cai
Aqui está a parte que quase nenhum guia conta. O DMARC não verifica só se SPF ou DKIM passaram. Ele exige também que o domínio remetente visível combine com o domínio que foi verificado. Isso se chama alinhamento, alignment em inglês, e é o termo que aparece nas ferramentas.
Na prática funciona assim. Você dispara sua newsletter por um serviço de envio. No campo do remetente aparece o seu próprio endereço. Tecnicamente, porém, quem entrega é o serviço, e ele tem um registro SPF impecável para o domínio dele. Então o SPF passa. A assinatura também sai com o domínio do serviço. Do ponto de vista do DMARC a cena é esta: verificou-se um domínio de terceiro enquanto o visível é o seu. O alinhamento falha, o DMARC falha junto, e qualquer ferramenta de teste continua mostrando um SPF verde.
A saída é a mesma em todo provedor sério: você cadastra o seu próprio domínio na sua conta do serviço de envio e publica no seu DNS a chave DKIM que ele emite para esse domínio. A partir daí a assinatura sai em nome do seu domínio, o alinhamento fecha e o DMARC passa.
O que Google, Yahoo e Microsoft exigem de quem envia em massa
Desde fevereiro de 2024, Google e Yahoo aplicam exigências a remetentes em massa, ou seja, em linhas gerais, a quem envia mais de cerca de 5.000 mensagens por dia para contas do Gmail. São exigidos SPF, DKIM e DMARC, um descadastro em um clique que funcione no cabeçalho da mensagem conforme a RFC 8058 e uma taxa de reclamações de spam abaixo de 0,3 por cento. A Microsoft anunciou e aplicou exigências comparáveis para o Outlook.com em 2025.
Se você está bem abaixo desse volume, formalmente não conta como remetente em massa. Só que isso não muda nada na configuração: os três registros custam uma hora uma única vez, o descadastro em um clique quem coloca é a sua ferramenta de envio, e a taxa de reclamações depende do estado da sua lista em qualquer volume. A única diferença abaixo do limite é que ninguém está te medindo por ele.
Ache o seu caso nesta tabela
| Sintoma | Causa provável | Como verificar |
|---|---|---|
| Confirmações de formulário não chegam a lugar nenhum | Envio pelo caminho padrão do PHP a partir do servidor web, sem SPF e sem assinatura | Abrir os cabeçalhos de uma mensagem de teste e ver qual servidor entregou |
| O Gmail aceita, o Outlook.com separa como spam | DMARC ausente ou em p=none | Consultar o registro TXT em _dmarc e ler o valor depois de p |
| A newsletter cai no spam, as faturas não | Dois caminhos de envio, só um assinado com o seu domínio | Comparar a assinatura DKIM no cabeçalho dos dois tipos de mensagem |
| SPF passa e o DMARC falha mesmo assim | Alinhamento: o domínio remetente visível não combina com o verificado | Olhar a linha Authentication-Results, lá aparece spf=pass ao lado de dmarc=fail |
| As ferramentas apontam permerror no SPF | O registro dispara mais de dez consultas DNS | Contar todos os include e cortar os serviços que você não usa mais |
| Primeiro entrega boa, depois spam de repente | Volume subiu rápido demais ou a taxa de reclamações aumentou | Rever os volumes das últimas semanas e os descadastros por disparo |
Por que o primeiro disparo grande quase sempre é freado
Os sistemas que recebem mantêm uma espécie de histórico para cada domínio que envia. Um domínio que passou anos sem enviar nada e de repente entrega 2.000 mensagens numa terça de manhã parece uma conta invadida. Ele é freado, e não importa o quanto os registros DNS estejam limpos.
A saída se chama aquecimento, warmup nas ferramentas, e é pouco espetacular. Comece pequeno e aumente o volume ao longo de várias semanas. Comece pelos destinatários que abriram, clicaram ou compraram há pouco tempo, porque a reação deles é o que constrói a sua reputação. Os contatos de quem você não ouve falar há mais tempo entram depois.
Se o contato mais recente da sua lista tem três anos, o aquecimento sozinho ajuda pouco. Aí o trabalho na lista vem antes do disparo.
Uma lista bem cuidada rende mais do que qualquer ajuste de texto
Listas compradas, endereços com anos de idade e retornos ignorados custam mais entregabilidade do que qualquer palavra suspeita que você já tenha evitado no assunto. O motivo é simples: cada mensagem para um endereço morto e cada reclamação é um sinal que conta direto contra a sua reputação.
As regras são curtas. Hard bounces, ou seja, endereços definitivamente não entregáveis, saem da lista na hora. Soft bounces podem ser tentados algumas vezes e depois removidos. Uma reclamação vira descadastro imediato, sem pergunta de volta. Endereços que há anos não abrem nada são risco para todo o resto da lista.
No começo de tudo está o consentimento. Como é um duplo opt-in limpo, o que precisa ser registrado e por que isso ajuda também no lado técnico está no artigo sobre duplo opt-in e LGPD. Se você envia para contatos na Europa, vale o RGPD, e as exigências de registro são parecidas. Isso é uma orientação prática e não aconselhamento jurídico, para uma avaliação vinculante do seu caso você precisa de alguém habilitado.
O WordPress envia pelo caminho errado por padrão
Merece um item próprio, porque em projetos pequenos é a causa isolada mais frequente. O WordPress envia por wp_mail e, sem configuração adicional, isso termina na função mail() do PHP, que entrega a mensagem direto ao servidor web. Esse servidor web em geral não está em nenhum registro SPF do seu domínio e também não assina nada. A mensagem sai e falha nas duas verificações ao mesmo tempo.
A saída usual é levar o envio por SMTP ou pela API do seu provedor, com o seu próprio domínio verificado. Isso vale para tudo que o seu site envia sozinho: confirmações de formulário, e-mails de redefinição de senha, confirmações de pedido e faturas. Essas mensagens importam mais ao cliente do que qualquer newsletter, e são justamente as que somem de forma mais discreta.
Onde você está perdendo tempo
Fica a pergunta do que sobra dos conselhos de sempre. Palavras suspeitas no assunto são o clássico, e hoje são em boa parte folclore. Os filtros pesam o comportamento do remetente muito mais do que uma palavra isolada. A palavra "grátis" no assunto não é problema enquanto o remetente tem boa reputação, e não salva nada enquanto ele não tem.
Com isso o trabalho no assunto não fica sem sentido. Ele só rende para a taxa de abertura e não para a entrega. Separar essas duas obras poupa uma pilha de reescritas inúteis.
p=none, você tem relatórios e efeito nenhum. Se lá não está nada, você não tem nem relatórios.Newsletter no seu próprio WordPress, de olho na entrega
O Kurato envia pelo seu próprio acesso de provedor e traz descadastro em um clique conforme a RFC 8058, tratamento de retornos e reclamações e um semáforo de entregabilidade para SPF, DKIM e DMARC. Os dados de contato ficam no seu banco de dados.
O que a versão gratuita cobre e onde começa o Pro está na página de preços. Por honestidade: sequências de automação com ramificações ainda estão em construção no Kurato.
Perguntas frequentes
Qual é a diferença entre SPF, DKIM e DMARC?
SPF (RFC 7208) diz quais servidores podem enviar pelo seu domínio. DKIM (RFC 6376) coloca uma assinatura criptográfica com a qual quem recebe confere que a mensagem saiu do seu domínio e não foi alterada no caminho. DMARC (RFC 7489) liga os dois resultados a uma instrução sobre o que deve acontecer em caso de falha, e abre os relatórios. Só os três juntos dão um quadro completo.
Meu registro DMARC está em p=none. Isso basta?
Como ponto de partida sim, como estado permanente não. Com p=none nada acontece quando uma verificação falha, você só recebe relatórios. O sentido dessa etapa é enxergar por algumas semanas quem envia em seu nome. Depois a instrução precisa ir para quarantine e mais tarde para reject, senão o registro é uma linha sem efeito.
O SPF passa e o DMARC falha assim mesmo. Como pode?
Isso é quase sempre alinhamento. O DMARC exige que o domínio remetente visível combine com o domínio verificado por SPF ou DKIM. Quem envia por um serviço de envio sem verificar e assinar ali o próprio domínio passa no SPF pelo domínio do serviço e falha no DMARC. A solução é a chave DKIM emitida para o seu próprio domínio.
Adianta evitar palavras suspeitas no assunto?
Quase nada. Os filtros de hoje pesam o comportamento do remetente muito mais do que uma palavra isolada. Um remetente com boa reputação passa tranquilo com a palavra grátis no assunto, e um remetente sem reputação falha até com a formulação mais comportada. Trabalhar o assunto rende para a taxa de abertura, para a entrega rende pouco.
Por que confirmações de formulário do WordPress caem no spam?
Porque sem configuração adicional o WordPress envia pela função mail() do PHP e a mensagem passa a sair do servidor web. Ele em geral não está em nenhum registro SPF do seu domínio e não assina nada, então SPF e DKIM falham ao mesmo tempo. O caminho usual é levar o envio por SMTP ou pela API do seu provedor com o seu próprio domínio verificado.
