SPF, DKIM e DMARC: O Trio que Impede Seus Emails de Cair no Spam

Você configurou o email profissional da empresa. Cadastrou o [email protected], testou o envio, tudo parecia funcionar. Mas semanas depois, clientes reclamam que suas mensagens não chegam — ou pior, que estão recebendo emails fraudulentos fingindo ser do seu domínio.

Esse não é um problema de servidor de email. É um problema de autenticação DNS. E a solução passa por três registros que a maioria dos administradores ignora até que o estrago já esteja feito: SPF, DKIM e DMARC.

Configurar SPF DKIM DMARC não é opcional em 2024. Gmail, Outlook e Yahoo passaram a exigir autenticação de email para domínios que enviam volume significativo — e mesmo para domínios pequenos, a ausência desses registros é um convite para o spam e para o abuso de identidade.

---

O Que Cada Um Faz

Os três protocolos trabalham juntos, mas cada um resolve um problema diferente. Entender a função de cada um é o primeiro passo para configurar tudo corretamente.

SPF: Quem Pode Enviar em Nome do Seu Domínio

SPF (Sender Policy Framework) é um registro TXT no DNS que lista quais servidores têm autorização para enviar emails usando o seu domínio no campo From.

Quando um servidor recebe um email de [email protected], ele consulta o DNS do domínio suaempresa.com e verifica se o IP remetente está na lista autorizada. Se não estiver, o email falha a verificação SPF.

Um registro SPF típico se parece com isso:

v=spf1 include:_spf.google.com include:mail.zoho.com ~all

• v=spf1 — identifica o registro como SPF versão 1
• include: — inclui os ranges de IP de um provedor específico
• ~all — define o que fazer com IPs não listados (~ = softfail, - = hardfail)

O problema mais comum: usar múltiplos provedores de email (Google Workspace para corporativo, Mailchimp para marketing, Zoho para suporte) sem incluir todos no SPF. Qualquer provedor não listado vai gerar falhas.

DKIM: A Assinatura Digital que Prova Autenticidade

DKIM (DomainKeys Identified Mail) funciona como uma assinatura digital criptográfica em cada email enviado. O servidor de email usa uma chave privada para assinar o cabeçalho da mensagem — e qualquer servidor receptor pode verificar essa assinatura usando a chave pública publicada no DNS do domínio.

O resultado é que o destinatário sabe que aquele email realmente saiu do servidor legítimo e que o conteúdo não foi alterado em trânsito.

Um registro DKIM no DNS tem o formato:

google._domainkey.suaempresa.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

• google é o seletor — uma string que identifica qual chave usar (útil quando você tem vários provedores)
• _domainkey é sufixo padrão do protocolo
• p= é a chave pública RSA

A chave privada fica no servidor do seu provedor de email. Você nunca a vê — o provedor a gerencia automaticamente. Sua única responsabilidade é publicar a chave pública no DNS.

DMARC: A Política que Unifica Tudo

DMARC (Domain-based Message Authentication, Reporting and Conformance) é o protocolo que dá coerência ao sistema. Ele define o que os servidores receptores devem fazer com emails que falham SPF ou DKIM — e pede relatórios sobre o que está acontecendo com seu domínio.

Um registro DMARC básico:

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

• p=none — só monitora, não age (bom para começar)
• p=quarantine — manda emails suspeitos para spam
• p=reject — rejeita emails que falham autenticação
• rua= — endereço que recebe relatórios agregados (XML) diários
• pct= — percentual do tráfego ao qual a política se aplica

DMARC também define o conceito de alinhamento: para um email passar, o domínio no campo From precisa alinhar com o domínio que passou SPF ou DKIM. Isso fecha uma brecha importante — sem DMARC, um atacante poderia usar SPF de um domínio diferente para passar na verificação.

---

Como Verificar se Estão Configurados

Antes de criar qualquer registro, verifique o que já existe no seu domínio. O MX Lookup do FlashMon foi construído exatamente para isso: ele mostra os registros MX, faz health check dos mail servers, e exibe o status de SPF, DKIM e DMARC do domínio pesquisado em uma única consulta.

Para verificar a autenticação de email do seu domínio:

1. Acesse o MX Lookup
2. Digite seu domínio (ex: suaempresa.com)
3. A ferramenta retorna os registros MX ativos, a resposta de cada mail server, e os registros de autenticação encontrados

Se você quiser inspecionar os registros TXT individualmente, o DNS Lookup permite consultar tipo por tipo. Para SPF, pesquise registros TXT no domínio raiz. Para DMARC, consulte _dmarc.suaempresa.com.

Domínios sem SPF aparecem em listas negras com frequência. Você pode verificar se o seu já foi comprometido usando o Blacklist Checker.

---

Como Configurar Cada Um

Google Workspace

SPF:

v=spf1 include:_spf.google.com ~all

Adicione como registro TXT no domínio raiz (@).

DKIM: No Google Admin Console, vá em Apps → Google Workspace → Gmail → Autenticar email. Gere a chave DKIM e publique o registro TXT fornecido no DNS. O seletor padrão do Google é google.

DMARC:

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

Adicione como registro TXT em _dmarc.suaempresa.com. Comece com p=none para monitorar sem bloquear.

---

Zoho Mail

SPF:

v=spf1 include:zoho.com ~all

DKIM: No painel do Zoho Mail, acesse Configurações → Organização → Configuração de Email → DKIM. Gere a chave e publique o registro TXT no DNS. O seletor padrão é zoho.

DMARC:

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

Registro TXT em _dmarc.suaempresa.com.

---

Hostinger (hPanel)

SPF:

v=spf1 include:_spf.hostinger.com ~all

DKIM: Na Hostinger, o DKIM é gerado automaticamente ao configurar o email. Verifique em hPanel → Email → Configurações de Email → Registros DNS. Se não estiver ativo, ative pelo painel e aguarde a propagação.

DMARC:

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

Adicione manualmente na zona DNS como registro TXT em _dmarc.

---

Erros Comuns na Configuração

Múltiplos registros SPF no mesmo domínio

O SPF permite apenas um registro TXT por domínio. Se você tem dois registros SPF separados, os servidores receptores vão ignorar um deles — e metade dos seus emails vai falhar. A solução é consolidar tudo em um único registro usando múltiplos include::

v=spf1 include:_spf.google.com include:_spf.mailchimp.com ~all

Muitos lookups DNS no SPF

O SPF tem um limite de 10 consultas DNS por verificação. Cada include: conta como uma consulta, e os include: aninhados também contam. Superar esse limite invalida o registro inteiro. Use ferramentas de análise SPF para contar os lookups antes de publicar.

DMARC configurado antes de SPF e DKIM estarem funcionando

Se você publicar p=reject antes de validar que SPF e DKIM estão corretos, vai começar a rejeitar seus próprios emails legítimos. O caminho certo:

1. Publique SPF e DKIM
2. Configure DMARC com p=none e um endereço rua
3. Analise os relatórios por 2–4 semanas
4. Quando confirmar que nenhum email legítimo está falhando, mova para p=quarantine
5. Depois para p=reject

DKIM com seletor errado ou chave expirada

Alguns provedores rotacionam as chaves DKIM periodicamente. Se o provedor gerou uma chave nova e você não atualizou o registro DNS, todos os emails vão começar a falhar DKIM silenciosamente. Verifique o painel do seu provedor periodicamente — ou monitore com o MX Lookup do FlashMon para detectar mudanças.

Usar ~all quando deveria usar -all

~all (softfail) marca o email como suspeito mas ainda permite entrega. -all (hardfail) rejeita. Para domínios com DMARC configurado em reject, o ~all no SPF é aceitável — o DMARC vai fazer o trabalho pesado. Mas sem DMARC, use -all para domínios que não devem enviar email algum (como subdomínios inativos).

---

Por Onde Começar Hoje

Se você nunca configurou autenticação de email no seu domínio, o caminho mais seguro é este:

1. Verifique o estado atual com o MX Lookup do FlashMon — veja o que já existe
2. Configure o SPF com os provedores que você realmente usa
3. Ative o DKIM no painel do seu provedor de email
4. Publique DMARC com p=none e um endereço para receber relatórios
5. Aguarde 2 semanas, analise os relatórios, corrija o que aparecer
6. Mova o DMARC para p=quarantine e depois para p=reject

O processo completo leva menos de uma hora para implementar. A falta dele pode levar meses para reverter — especialmente se o seu domínio for usado em campanhas de phishing e acabar em listas negras.

Email autenticação DNS não é um detalhe técnico opcional. É a diferença entre uma empresa que aparece na caixa de entrada e uma que cai no spam ou, pior, tem a identidade usada por criminosos.

---

Leia também

• Autenticação falhou ou o domínio já foi marcado? Veja como verificar se seu IP está em blacklist.
• Antes de editar DNS em produção, inspecione os registros atuais com o DNS Lookup e o MX Lookup.