Voltar pro blog json-p.org

PilarEntregabilidade de email Publicado1 de outubro de 2026 AutorElton

SPF, DKIM e DMARC: por que seu email de infoproduto cai no spam

Email de infoproduto caindo no spam quase sempre é autenticação: SPF, DKIM e DMARC alinhados com o From. Os registros e os erros que o checador não pega.

O aluno compra às 23h, o PIX cai, a plataforma aprova. Às 23h05 chega no suporte: "paguei e não recebi o acesso". Você confere e o email de boas-vindas com o login da área de membros saiu certinho. Pede pra ele olhar o spam. Estava lá. Na manhã seguinte são mais seis mensagens iguais, uma delas já pedindo reembolso.

No marketing é o mesmo filme, só que silencioso. A sequência de nutrição que abria 35% hoje abre 9%. O email de recuperação de carrinho sai, o painel da ferramenta mostra "entregue: 98,7%", e ninguém clica. Você troca o assunto, tira a palavra "grátis", testa emoji. Nada muda, porque o problema não está no texto.

Na maioria dos casos que eu já peguei pra investigar, o email nem chegou a ser julgado pelo conteúdo. Foi barrado antes, na pergunta mais básica que o Gmail faz pra qualquer mensagem: quem mandou isso consegue provar que é quem diz ser? E a resposta estava num TXT de DNS esquecido, duplicado ou que nunca existiu.

A resposta curta: por que o email de infoproduto está caindo no spam

SPF, DKIM e DMARC não são filtro anti-spam. São autenticação de remetente: provam que quem entregou a mensagem tinha autorização pra falar em nome do seu domínio. Desde fevereiro de 2024 o Gmail exige SPF ou DKIM de todo remetente, e os três (com o From alinhado) de quem manda mais de 5 mil mensagens por dia pra contas Gmail. A partir de novembro de 2025 ele passou a aplicar isso com rejeição temporária e permanente, não só pasta de spam. O Outlook.com cobra o mesmo trio desde maio de 2025 de quem passa de 5 mil por dia, com bounce 550 5.7.515 pra quem não cumpre. O conserto: um único SPF por domínio com todo provedor que envia por você dentro, DKIM assinando com o seu domínio, DMARC começando em p=none pra enxergar quem manda email em seu nome, e só depois apertar. Autenticação não garante caixa de entrada (reputação e reclamação de spam pesam), mas sem ela o resto nem entra na conta.

O que cada um verifica de verdade

A confusão começa porque todo mundo explica os três como "coisas pra não cair no spam". Cada um responde uma pergunta diferente, e nenhum olha o conteúdo.

Por isso um sozinho não resolve. SPF sem DMARC deixa qualquer um usar seu domínio no From, desde que use outro envelope. DKIM sem DMARC prova que alguém assinou, não que esse alguém é você. DMARC sem os outros dois é política sem nada pra avaliar. Juntos, fecham a pergunta inteira: quem mandou, se foi alterado e se bate com o nome no remetente.

Os três registros, um de cada

Exemplo genérico com o domínio fictício seucurso.com.br, mandando o transacional (recibo, acesso à área de membros) por mail.seucurso.com.br. Os provedores terminam em .example de propósito: troque pelo que o seu provedor indicar.

SPF, publicado no domínio que aparece no Return-Path:

mail.seucurso.com.br.  TXT  "v=spf1 include:spf.provedortransacional.example include:spf.provedormarketing.example ~all"

Um registro, todos os provedores dentro dele. O ~all diz "o resto é suspeito" sem mandar rejeitar. Dá pra ir pro -all quando o inventário de quem envia estiver fechado, mas com DMARC no lugar a decisão de bloquear fica com o DMARC, que é onde ela deve ficar.

DKIM, a chave pública num seletor definido pelo provedor:

pt1._domainkey.mail.seucurso.com.br.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...IDAQAB"

O pt1 é o seletor. Cada provedor usa o seu, e vários convivem no mesmo domínio sem conflito (diferente do SPF). Muitos provedores pedem um CNAME apontando pra chave deles em vez do TXT, pra rotacionar a chave sem você mexer no DNS. Tanto faz, desde que a assinatura saia com d= do seu domínio. Se puder escolher, chave de 2048 bits, que é a recomendação do Google.

DMARC, sempre em _dmarc do domínio raiz:

_dmarc.seucurso.com.br.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

p=none é modo monitor: nada é bloqueado, mas os provedores grandes passam a mandar pro endereço do rua um relatório agregado dizendo quantas mensagens viram com seu domínio no From, de quais IPs, e se passaram. Subdomínio sem registro próprio herda essa política; a tag sp existe se você quiser outra regra pra eles.

Pra conferir se publicou certo:

dig +short TXT mail.seucurso.com.br
dig +short TXT pt1._domainkey.mail.seucurso.com.br
dig +short TXT _dmarc.seucurso.com.br

Só que a prova que vale não é o checador online, é o cabeçalho de um email real. Manda um recibo de teste pra uma conta Gmail, abre, menu de três pontos, "Mostrar original". O que você quer ver:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=pt1;
       spf=pass (google.com: domain of [email protected]
         designates 203.0.113.25 as permitted sender)
         [email protected];
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=mail.seucurso.com.br

Três pass, e o domínio do header.from batendo com o do DKIM e o do SPF. Esse último detalhe é onde a maioria tropeça, e já chego nele.

SPF que passa no checador e falha na hora real

1. Dois registros SPF no mesmo domínio. Acontece toda vez que alguém contrata ferramenta nova e cola o TXT que ela mandou sem olhar o que já existia:

seucurso.com.br.  TXT  "v=spf1 include:_spf.google.com ~all"
seucurso.com.br.  TXT  "v=spf1 include:spf.provedormarketing.example ~all"

Parece que os dois estão autorizados. Não estão. A RFC 7208, que define o SPF, é explícita: mais de um registro v=spf1 no mesmo nome dá permerror, e na prática é como não ter SPF nenhum. Tem checador que lê só o primeiro e mostra tudo verde. O conserto é fundir num só: "v=spf1 include:_spf.google.com include:spf.provedormarketing.example ~all".

2. Mais de 10 consultas de DNS. Cada include, a, mx, ptr, exists e redirect obriga o servidor a fazer uma consulta, e o limite é 10 no total, contando os includes dentro dos includes. Passou, permerror de novo. ip4, ip6 e all não contam. O problema é que o aninhamento não aparece: um único include de provedor grande pode puxar várias consultas por baixo. Quem já passou por quatro ferramentas de email, um checkout que manda nota, o Workspace e um CRM bate no limite sem perceber. A mesma RFC ainda recomenda limitar a 2 as consultas que voltam vazias, então include de ferramenta cancelada ano passado não é só sujeira, é risco.

Pra contar, resolve cada include na mão (dig +short TXT spf.provedormarketing.example) e soma, ou usa uma ferramenta que mostre a árvore expandida. Estourou? Tira o que não usa e separa os envios em subdomínios, cada um com o próprio SPF e o próprio limite de 10. "Achatar" o SPF trocando includes por ip4 funciona, mas quebra em silêncio no dia em que o provedor muda de IP.

3. O provedor transacional que ninguém lembrou. Esse é o que mais pega infoprodutor. O marketing está autenticado pela ferramenta de email marketing, lindo. Só que o recibo e o acesso não saem dela: saem do SMTP configurado na área de membros, do plugin de WordPress mandando pelo servidor da VPS, de um serviço transacional que um freelancer ligou dois anos atrás. Esse remetente usa o seu domínio no From e não está no SPF nem assina DKIM com seu domínio. Resultado: o email mais importante da operação, o que entrega o produto que a pessoa acabou de pagar, é justamente o que cai no spam. E se a sua régua de recuperação de PIX pendente roda em email e WhatsApp ao mesmo tempo, metade dela está morta sem você saber.

Antes de mexer em qualquer registro, faz o inventário: tudo que manda email com seu domínio no From. Checkout, área de membros, ferramenta de marketing, Workspace, CRM, formulário do site, servidor próprio. Não sabe a lista completa? O DMARC em p=none vai te contar.

Alinhamento DMARC: o erro de quem jura que configurou tudo

Esse é o tropeço mais caro, porque o painel mostra SPF verde, DKIM verde, e mesmo assim o DMARC falha. Olha um cabeçalho típico de quem conectou a ferramenta de email e parou no "verificar domínio":

From: Curso Exemplo <[email protected]>
Return-Path: <[email protected]>
DKIM-Signature: v=1; a=rsa-sha256; d=provedor.example; s=k1; ...

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass smtp.mailfrom=em.provedor.example;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=seucurso.com.br

O SPF passou, mas pro domínio do provedor (o Return-Path é dele). O DKIM passou, mas assinado pelo provedor (d=provedor.example). Nenhum dos dois é seucurso.com.br, que é o que está no From. Pro DMARC isso é falha: alguém autenticado mandou email com o seu nome. É exatamente o padrão de phishing que o DMARC existe pra pegar, e o seu email legítimo cai na mesma regra.

O conserto tem dois lados, e você precisa de pelo menos um (os dois é melhor):

E o que é "bater"? No modo padrão, relaxado (adkim=r, aspf=r), basta o domínio organizacional ser o mesmo: mail.seucurso.com.br alinha com seucurso.com.br. No estrito (adkim=s), tem que ser idêntico. Quem envia por subdomínio fica no relaxado, que é o padrão e é exatamente o que o Gmail exige de remetente em massa: domínio organizacional do From alinhado com o do SPF ou o do DKIM.

p=none primeiro, reject depois

Com o DMARC em p=none, em geral em um ou dois dias começam a chegar os relatórios agregados: XML compactado, um por provedor por dia. Feio de ler, mas é a única visão de fora de tudo que sai com seu domínio. Um trecho simplificado:

<record>
  <row>
    <source_ip>198.51.100.7</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>seucurso.com.br</header_from>
  </identifiers>
</record>

412 mensagens num dia, de um IP que você não reconhece, falhando nos dois. Ou é um remetente seu fora do inventário (o servidor da área de membros, quase sempre), ou é alguém usando seu domínio pra golpe. Os dois você precisa saber. O primeiro se conserta autenticando. O segundo é motivo pra apertar a política.

A sequência que eu sigo: p=none até os relatórios mostrarem todo remetente legítimo passando alinhado, depois p=quarantine (falhou, vai pro spam), observa mais um tempo, e só então p=reject (falhou, nem entra). O Google recomenda começar em none, e a especificação nova do DMARC (RFC 9989, publicada em maio de 2026) trata o modo monitor como ponto de partida normal. Não tenho número mágico de semanas. O critério é relatório limpo cobrindo um ciclo completo da operação, incluindo um dia de lançamento, porque é no disparo grande que o remetente esquecido aparece. Se você está seguindo tutorial antigo: a tag pct saiu da especificação nova (no lugar entrou a t=y, de teste), então não monte a rampa em cima dela.

Por que não ir direto pro reject, já que "é mais seguro"? Porque reject não manda pro spam, manda de volta. Se o servidor da área de membros não estava no inventário, o email de acesso deixa de existir pro aluno. Nem na pasta de spam ele acha. Você descobre pelos tickets de "não recebi" e pelos reembolsos de quem nem abriu ticket.

Subdomínio dedicado pra envio

Mandar tudo pelo domínio raiz funciona até o dia em que não funciona. Um lançamento pra lista velha gera pico de reclamação, a reputação despenca, e junto vai o email do suporte, o do Workspace, o recibo. Tudo dividindo o mesmo nome.

O desenho que eu uso separa por função:

Cada subdomínio tem SPF e DKIM próprios, e o DMARC do raiz cobre todos por herança. Separar não dá imunidade (subdomínio queimado ainda respinga no domínio), mas na prática segura o pior: lançamento mal feito não derruba o email que entrega o produto.

E subdomínio não é truque pra fugir de regra. Pro Gmail, a conta das 5 mil mensagens por dia soma o domínio principal com todos os subdomínios, então espalhar envio em news1, news2, news3 não muda nada. Pior: segundo a própria documentação do Gmail, a classificação de remetente em massa não expira. Infoprodutor que dispara um lançamento pra 20 mil contatos num dia fica sob a régua de remetente em massa dali pra frente, mesmo que o resto do ano seja 300 emails por dia.

O que dá errado

A parte chata disso tudo não é publicar três TXT. É manter o inventário de remetentes em dia e ler XML de relatório toda semana pra pegar o remetente novo que alguém plugou sem avisar. É o tipo de coisa que uma infraestrutura de envio dedicada deveria entregar resolvida de fábrica, e é a ideia por trás do mailforge, a infra de envio de email que eu mantenho. Mas nada aqui depende dela: dig, uma caixa recebendo os relatórios e um script que transforma o XML em planilha já te colocam na frente da maioria.

Fechando

Email de infoproduto caindo no spam quase nunca é palavra proibida no assunto. É o provedor perguntando "quem é você?" e o seu DNS sem saber responder. Um SPF só, com todo mundo que envia por você dentro. DKIM assinando com o seu domínio. DMARC em p=none mostrando a verdade antes de você apertar. Subdomínio separando o recibo do lançamento. Feito isso, o email que entrega o produto volta pra onde o aluno olha, e o resto (aquecimento, reputação, lista) vira problema que dá pra medir.

Fontes primárias consultadas em 01/10/2026: diretrizes de remetente do Gmail e FAQ das diretrizes (requisitos desde fevereiro de 2024, rejeição a partir de novembro de 2025, contagem por domínio principal, classificação permanente, taxa de spam, descadastro de um clique); anúncio da Microsoft sobre requisitos do Outlook.com pra remetentes de alto volume; RFC 7208 (SPF: registro múltiplo e limite de 10 consultas); RFC 9989 (DMARC, maio de 2026: modo monitor, tag t e remoção do pct).