- SPF autoriza servidores a enviarem em nome do seu domínio; não “assina” a mensagem
- DKIM assina criptograficamente o e-mail; costuma ser o divisor de águas na reputação
- DMARC define o que fazer quando SPF/DKIM falham e habilita relatórios
- Para automações, prefira um subdomínio dedicado (ex.: mail.seudominio.com) para isolar reputação
- Mudanças em DNS podem levar algum tempo para propagar; valide com testes de envio reais
1) Decida o domínio (ou subdomínio) de envio para automações
Se você manda e-mails transacionais (senha, fatura, confirmação) e também campanhas, separar ajuda muito. Um caminho comum é usar um subdomínio só para automações, como mail.seudominio.com. Isso reduz o estrago quando alguma automação dispara errado e preserva o domínio principal.
2) Publique o SPF (TXT) do domínio de envio
O SPF é um registro TXT que lista quais servidores/serviços podem enviar e-mail por aquele domínio. Regra prática: tenha apenas UM SPF por domínio. Se você tiver vários, una tudo em um só. Exemplo genérico (você vai adaptar ao seu provedor): v=spf1 include:provedorA.com include:provedorB.com -all. Use “~all” (softfail) só como fase temporária; quando estiver confiante, prefira “-all”.
3) Ative e publique o DKIM (TXT/CNAME) fornecido pelo provedor
No provedor de e-mail/transacional, habilite DKIM para o domínio (ou subdomínio) e copie os registros DNS indicados. Alguns provedores pedem CNAME; outros pedem TXT. Evite “chutar” seletor e chave: use exatamente o que o provedor gerar. Depois, faça um envio de teste e verifique se o cabeçalho mostra DKIM=pass.
4) Crie o DMARC começando conservador (p=none)
DMARC é o registro TXT no host _dmarc.seudominio.com. Comece com política de monitoramento para coletar relatórios antes de aplicar quarentena ou rejeição. Exemplo inicial: v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s. Se você não sabe lidar com relatórios, ainda dá para começar com rua e deixar ruf de fora.
5) Ajuste alinhamento (alignment) e passe para quarentena/rejeição
Depois que seus envios legítimos estiverem passando (SPF e/ou DKIM alinhados), suba o DMARC gradualmente: primeiro p=quarantine e só depois p=reject. Se você usa múltiplos sistemas enviando pelo mesmo domínio, esse passo costuma revelar “envios escondidos” (por exemplo, alguma ferramenta antiga, um servidor interno ou integrações esquecidas).
6) Teste do jeito certo: cenários reais das automações
Não teste só com um e-mail manual. Dispare as automações reais: confirmação de cadastro, alerta interno, cobrança, notificação de pedido. Observe: taxa de entrega, bounces, e principalmente se provedores (Gmail/Outlook) passam a aceitar melhor. Se um fluxo manda alto volume de uma vez, limite e escalone para não parecer ataque.
O que cada sigla resolve (sem misticismo)
SPF responde: “este servidor está autorizado a enviar por este domínio?”. Ele protege contra spoofing simples, mas não garante que o conteúdo não foi alterado.
DKIM responde: “a mensagem saiu daqui e não foi mexida no caminho?”. É uma assinatura criptográfica no e-mail, baseada numa chave pública publicada no DNS.
DMARC amarra os dois e diz ao provedor destinatário: “se falhar, faça X (nada/quarentena/rejeitar) e me envie relatórios”. Para automação, DMARC é o que evita que alguém use seu domínio para golpes e ainda te dá visibilidade do que está acontecendo.
| Item | Onde fica | O que quebra quando falta | Sinal típico |
|---|---|---|---|
| SPF | DNS (TXT no domínio) | Falha de autenticação básica; spoofing mais fácil | SPF=fail/softfail no header |
| DKIM | DNS (TXT/CNAME no seletor) | Entregabilidade pior e mais variação entre provedores | DKIM=none ou DKIM=fail |
| DMARC | DNS (_dmarc) | Sem política e sem visibilidade; domínio mais vulnerável | DMARC=none/fail; sem relatórios |
Checklist rápido de DNS (com exemplos genéricos)
A parte chata é que cada provedor fornece valores diferentes. Então o que dá para padronizar aqui é o formato e as pegadinhas.
Use isso como checklist para revisar com calma o seu DNS:
- SPF: um único TXT no domínio/subdomínio de envio (evite dois SPF competindo)
- DKIM: registros no seletor (ex.: selector1._domainkey) exatamente como o provedor gerou
- DMARC: TXT em _dmarc (comece em p=none, suba depois)
- From/Return-Path: evite misturar domínios sem alinhamento; se possível, mantenha o mesmo domínio (ou subdomínio) no envio
- Subdomínio dedicado para automações de alto volume: isola reputação
Erros que derrubam automações (e você só percebe quando para de vender)
Dois SPF publicados: acontece muito em empresas que foram “somando ferramentas” com o tempo. Resultado: autenticação inconsistente.
DMARC agressivo cedo demais (p=reject sem mapear tudo): você resolve spoofing, mas pode derrubar e-mails legítimos de sistemas esquecidos.
DKIM configurado no domínio errado: a automação envia por um subdomínio, mas o DKIM foi publicado no domínio raiz (ou vice-versa).
Rajadas de envio: automação que dispara centenas/milhares em poucos minutos pode parecer comportamento malicioso. Mesmo autenticado, você pode sofrer limitação e cair em spam.
Tabela de decisão: qual política DMARC usar e quando
Não existe bala de prata, mas existe sequência segura. Abaixo, um caminho típico para quem está colocando automações em produção.
| Fase | Política (p=) | Objetivo | Risco |
|---|---|---|---|
| Observação | none | Receber relatórios e descobrir todos os emissores reais | Baixo (não bloqueia) |
| Controle gradual | quarantine | Mandar falhas para spam/quarentena e medir impacto | Médio (pode afetar emissor legítimo mal configurado) |
| Proteção forte | reject | Bloquear spoofing e falhas de autenticação | Alto se ainda existir envio legítimo sem alinhamento |
Perguntas frequentes
Preciso de SPF e DKIM ao mesmo tempo, ou só um já resolve?
Posso ter mais de um registro SPF no DNS?
O que significa começar DMARC com p=none?
Subdomínio para automações realmente ajuda ou é frescura?
Leia também
Como automatizar emails: guia prático para negócios em 2026
Aprenda a automatizar emails de boas-vindas, follow-up, nutrição e pós-venda usando ferramentas no-code. Guia prático com passos, ferramentas e exemplos reais.
Ler →
Como monitorar automações (n8n, Make e Zapier): alertas, logs e erros sem virar refém do “falhou e ninguém viu”
Guia prático para monitorar automações em n8n, Make e Zapier: quais alertas criar, como registrar logs, tratar erros, retries e evitar falhas silenciosas.
Ler →
Rate limit, retry e backoff: como parar de quebrar automação em API (n8n, Make, Zapier)
Guia direto para lidar com rate limit (429), retries e backoff em automações com APIs. Aprenda padrões práticos para n8n, Make e Zapier e evite falhas intermitentes, duplicidades e banimentos.
Ler →