Entregabilidade de e-mail: SPF, DKIM e DMARC na prática

Entregabilidade de e-mail (deliverability) é a taxa em que suas mensagens realmente chegam à caixa de entrada — e ela se decide no DNS, antes de qualquer campanha. SPF, DKIM e DMARC são os três registros que provam ao Gmail, ao Yahoo e ao Outlook que você está autorizado a enviar pelo seu domínio e que a mensagem não foi adulterada no caminho. Sem eles, o melhor e-mail do seu Mautic tende ao spam; com os três bem configurados, você constrói a reputação que leva à inbox.

Pense neles como um passaporte do seu domínio: o SPF diz quais servidores podem enviar em seu nome, o DKIM assina cada mensagem para provar que ela é genuína, e o DMARC define o que os provedores devem fazer quando algo não bate. Na prática, quase todo problema de "e-mail caindo no spam" que eu depuro começa no mesmo lugar: autenticação ausente, incompleta ou desalinhada. Configurar isso direito é o primeiro passo de qualquer estratégia séria de e-mail marketing.

Por que os e-mails vão para o spam

Provedores como Gmail, Outlook e Yahoo usam algoritmos para decidir onde cada mensagem cai. Eles avaliam, em resumo:

• Reputação de IP: de qual IP o e-mail está vindo e se esse IP já enviou spam antes.
• Reputação de domínio: se o seu domínio está em alguma blacklist ou tem histórico ruim.
• Autenticação: o envio está autorizado (SPF)? A mensagem está assinada (DKIM)? Existe uma política publicada (DMARC)?
• Conteúdo: excesso de links, palavras clássicas de spam, HTML mal formado, proporção ruim de texto e imagem.
• Comportamento: taxa de bounce, reclamações de spam, quantas pessoas abrem, respondem ou apagam sem ler.

SPF, DKIM e DMARC cobrem a autenticação. Os outros fatores dependem de infraestrutura (reputação de IP, warm-up) e de conteúdo (copy, design, lista limpa). Autenticação não é tudo — mas sem ela, nada mais adianta.

SPF, DKIM e DMARC lado a lado

Antes de configurar, vale entender o que cada um faz, onde vive no DNS e o que ele realmente valida:

O ponto que muita gente ignora: DMARC não é um quarto teste independente. Ele só dá "pass" quando SPF ou DKIM passa E alinha com o domínio que aparece no campo From. Guarde essa frase — ela explica metade dos problemas.

SPF (Sender Policy Framework): o primeiro passo

O que é

O SPF é um registro TXT no DNS que declara: "estes servidores estão autorizados a enviar e-mail em nome do meu domínio". Um exemplo, para quem envia via Amazon SES:

v=spf1 include:amazonses.com ~all

Leitura: "Versão 1 do SPF. Autorize os servidores que o Amazon SES publica no amazonses.com e, se qualquer outro servidor tentar enviar, trate como suspeito (~all)."

Os mecanismos dizem quem está autorizado — os mais comuns são ip4: e ip6: (IPs diretos), a e mx (os hosts A/MX do próprio domínio) e include: (delega para o SPF de um provedor). Os qualificadores definem o veredito para o resto: ~all é softfail (marca como suspeito, mas costuma entregar) e -all é hardfail (recomenda rejeitar). Comece com ~all e migre para -all quando tiver certeza de que listou tudo.

Limite dos 10 lookups. O SPF permite no máximo 10 consultas de DNS por avaliação, e cada include, a, mx, ptr e redirect conta. Passou de 10, o resultado vira PermError e o SPF falha por inteiro — um erro silencioso que derruba a entrega de quem soma muitos provedores. Quando isso acontece, achate (flatten) os includes ou enxugue o registro.

Como configurar

Você precisa acessar o painel de DNS do seu provedor (Registro.br, Cloudflare, GoDaddy, etc.):

1. Abra o gerenciador de DNS do domínio.
2. Localize os registros TXT.
3. Crie um novo registro:
   • Type: TXT
   • Name: @ (o domínio raiz)
   • Value: v=spf1 include:amazonses.com ~all
4. Se usa mais de um provedor, combine tudo num único registro SPF (nunca publique dois registros SPF separados):
   • v=spf1 include:_spf.google.com include:amazonses.com ~all
5. Salve. A propagação costuma ser de minutos, mas pode levar até 24-48h.

Validar o SPF

Use uma ferramenta de checagem, como o MXToolbox SPF Check (mxtoolbox.com/spf.aspx) ou o Google Admin Toolbox / Check MX (toolbox.googleapps.com/apps/checkmx). O resultado esperado é "SPF record found" com um único registro e menos de 10 lookups.

DKIM (DomainKeys Identified Mail): a assinatura criptográfica

O que é

O DKIM adiciona uma assinatura digital a cada mensagem, com um par de chaves: a privada fica no servidor de envio e assina o e-mail; a pública fica publicada no seu DNS para qualquer provedor conferir. O fluxo:

Servidor de envio (ex.: Mautic + provedor SMTP):
  1. Assina o e-mail com a chave privada
  2. Envia com o cabeçalho "DKIM-Signature: ..."

Gmail ao receber:
  1. Lê o cabeçalho DKIM-Signature (selector + domínio)
  2. Busca a chave pública em selector._domainkey.dominio
  3. Recalcula e confere a assinatura
  4. Assinatura confere  -> mensagem íntegra e autêntica
  5. Assinatura não confere -> adulterada ou forjada

Gerar as chaves

Em geral, o seu provedor de envio (SMTP transacional, Mautic gerenciado, cPanel/Plesk) gera as chaves e já entrega o registro pronto para colar no DNS. Se precisar gerar manualmente:

openssl genrsa -out dkim-private.key 2048
openssl rsa -in dkim-private.key -pubout -out dkim-public.key

A chave privada fica guardada no servidor de envio; a pública vai para o DNS, sem os cabeçalhos -----BEGIN..., apenas o conteúdo em base64.

Adicionar o DKIM ao DNS

1. Abra o gerenciador de DNS (o mesmo lugar do SPF).
2. Crie um registro TXT:
   • Type: TXT
   • Name: selector._domainkey (o selector é o que o seu provedor informa — algo como s1, google ou mautic)
   • Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... (sua chave pública)
3. Salve e aguarde a propagação.

Validar o DKIM

Consulte o registro direto no DNS:

dig s1._domainkey.atraca.com.br TXT +short

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Ou use o MXToolbox DKIM Check (mxtoolbox.com/dkim.aspx), informando o domínio e o selector.

DMARC (Domain-based Message Authentication): a política e o alinhamento

O que é

O DMARC amarra tudo. Ele publica uma política que responde: "se um e-mail não passar SPF nem DKIM alinhados ao meu domínio, o que os provedores devem fazer?". As opções de política (p):

• none: não fazer nada, apenas monitorar e enviar relatórios. É por onde se começa.
• quarantine: mandar para a pasta de spam.
• reject: recusar a mensagem na entrega (a mais restritiva — só depois de validar tudo).

O que separa o DMARC de SPF e DKIM é o alinhamento (alignment). Não basta o SPF ou o DKIM passar: o domínio autenticado precisa bater com o domínio que o destinatário vê no From. O alinhamento pode ser relaxed (mesmo domínio organizacional — o padrão) ou strict (domínio idêntico), controlado pelas tags aspf e adkim. DMARC passa quando SPF alinha OU DKIM alinha — basta um dos dois.

Implementar o DMARC

1. Abra o gerenciador de DNS.
2. Crie um registro TXT:
   • Type: TXT
   • Name: _dmarc
   • Value: v=DMARC1; p=none; rua=mailto:dmarc@atraca.com.br
3. Salve. A partir daí você passa a receber relatórios agregados (arquivos XML) de quem falha e de quem passa.

As tags mais úteis:

• v=DMARC1 — versão (obrigatória, sempre a primeira).
• p=none — a política: aqui, só monitorar.
• rua=mailto:... — endereço que recebe os relatórios agregados (o que você lê no dia a dia).
• ruf=mailto:... — relatórios forenses, opcionais e cada vez menos entregues por questões de privacidade.
• sp= — política para subdomínios (herda a de p se omitida).
• pct= — percentual de mensagens ao qual a política se aplica, útil para migrar aos poucos.

Subir a política aos poucos

Não pule direto para p=reject. O caminho seguro é gradual:

1. Semanas iniciais (p=none): monitore os relatórios rua. Descubra o que envia pelo seu domínio e o que está desalinhado.
2. Depois (p=quarantine): quando o legítimo já passa e alinha, mande o suspeito para o spam.

v=DMARC1; p=quarantine; rua=mailto:dmarc@atraca.com.br

3. Por fim (p=reject): proteção máxima contra spoofing, só quando os relatórios confirmarem que todo o envio legítimo passa e alinha.

v=DMARC1; p=reject; rua=mailto:dmarc@atraca.com.br

O que Gmail e Yahoo exigem desde 2024

Em fevereiro de 2024, Gmail e Yahoo endureceram as regras para remetentes em volume (o gatilho do Google é em torno de 5.000 mensagens por dia para endereços Gmail). Quem envia campanhas pelo Mautic precisa cumprir:

• Autenticar com SPF e DKIM — os dois, não um ou outro.
• Publicar um registro DMARC com, no mínimo, p=none, e garantir o alinhamento.
• Descadastro em um clique via cabeçalho List-Unsubscribe, processado em até dois dias.
• Manter a taxa de reclamação de spam baixa — abaixo de 0,3% medida no Google Postmaster Tools, e o ideal é ficar abaixo de 0,1%.

Não é recomendação: é requisito de entrega. Sem isso, mensagens em massa passam a ser rejeitadas ou jogadas no spam. Os detalhes oficiais estão nas diretrizes do DMARC.org e nas orientações para remetentes do Google Postmaster Tools.

Configurando no Mautic

No Mautic, o envio é definido em Settings → Configuration → Email Settings:

• Mailer / SMTP Host: o host do seu provedor de envio (ex.: email-smtp.us-east-1.amazonaws.com).
• SMTP User / Password: as credenciais do provedor — use as chaves de API/SMTP, nunca a senha da sua conta principal.
• Return Path (bounce): um endereço dedicado a bounces, como bounce@atraca.com.br. Ele é o envelope-from e é o domínio que o SPF avalia — por isso importa para o alinhamento do DMARC.

Se o seu provedor de SMTP transacional já gera o DKIM (o caso mais comum), basta colar no DNS o registro que ele entrega e confirmar a validação no painel dele. E lembre: no Mautic, nada sai sem os crons configurados — é o emails:send que esvazia a fila para o SMTP. Autenticação perfeita não entrega e-mail nenhum se o cron não roda.

Warm-up: reputação não se configura, se constrói

Mesmo com SPF, DKIM e DMARC impecáveis, um IP ou domínio novo tem reputação desconhecida — e o provedor não confia de cara. A solução é o warm-up (aquecimento): subir o volume aos poucos, ao longo de semanas, enviando primeiro para contatos que abrem, respondem e não marcam como spam. Assim o provedor aprende, envio a envio, que você é legítimo.

Uma rampa ilustrativa — os números variam conforme provedor, base e histórico:

Comece pela sua base mais engajada (contatos que você sabe que são válidos) e mantenha a lista limpa: remova bounces e quem pediu para sair. Se o seu caso é prospecção fria, o cuidado é ainda maior — vale ler o guia de cold email e outreach, que trata de reputação e cadência sem virar spam.

Testando tudo de ponta a ponta

O teste definitivo é enviar uma mensagem real e ler os cabeçalhos:

1. Envie um e-mail do seu Mautic para uma conta Gmail sua.
2. No Gmail, abra a mensagem, clique nos três pontos (⋮) e escolha "Mostrar original".
3. Procure pelo bloco de autenticação:
   • SPF: PASS — o servidor de envio estava autorizado.
   • DKIM: PASS — a assinatura conferiu.
   • DMARC: PASS — passou e alinhou.
4. Se aparecer FAIL em algum, volte ao registro correspondente — quase sempre é alinhamento ou um include a mais no SPF.

Perguntas frequentes sobre entregabilidade de e-mail

Preciso de SPF, DKIM e DMARC ao mesmo tempo?

SPF e DKIM são a base — configure os dois. O DMARC vem em cima deles: sem SPF ou DKIM passando e alinhando com o domínio do remetente, o DMARC não tem o que avaliar. Desde 2024, Gmail e Yahoo exigem os três de quem envia em volume (SPF, DKIM e ao menos DMARC com p=none). Comece por SPF e DKIM e publique o DMARC em p=none logo em seguida, só para monitorar.

O que significa o ~all no fim do registro SPF?

É o qualificador que diz o que fazer com quem não está na lista. O ~all é softfail (marca como suspeito, mas o e-mail costuma ser entregue); o -all é hardfail (recomenda rejeitar). Comece com ~all enquanto valida o registro e migre para -all quando tiver certeza de que listou todos os servidores que enviam pelo seu domínio.

Por que meu SPF parou de funcionar depois que adicionei provedores?

O SPF tem um limite de 10 consultas de DNS por avaliação. Cada include, a, mx, ptr e redirect conta. Ao passar de 10, o resultado vira PermError e o SPF falha por inteiro. A saída é achatar (flatten) os includes ou reduzir o número de provedores dentro do mesmo registro.

DMARC com p=reject vai bloquear os meus próprios e-mails?

Só bloqueia o que falhar SPF e DKIM ao mesmo tempo e não alinhar com o domínio do cabeçalho From. Por isso a política sobe aos poucos: fique semanas em p=none lendo os relatórios (rua), passe para p=quarantine e só chegue a p=reject quando os relatórios mostrarem que o envio legítimo já passa e alinha.

Configurei SPF, DKIM e DMARC e ainda caio no spam. O que falta?

Autenticação é condição necessária, não suficiente. Se os três passam e o e-mail ainda cai no spam, o problema costuma ser reputação (IP ou domínio novos, sem warm-up), lista suja (bounces e reclamações) ou o próprio conteúdo. A autenticação abre a porta; reputação e engajamento decidem a caixa de entrada.