SPF, DKIM and DMARC: why your emails land in spam

Você gastou semanas escrevendo a newsletter perfeita. Mandou pra 5.000 contatos. Abriu o relatório no dia seguinte: taxa de entrega 62%. O resto foi pro spam — ou nem chegou.

A culpa raramente é do conteúdo. É de três siglas que você provavelmente não configurou direito: SPF, DKIM e DMARC.

O problema que essas siglas resolvem

E-mail é um protocolo dos anos 1980. Quando foi criado, qualquer servidor podia mandar mensagem dizendo ser qualquer um. Eu posso, agora, configurar um servidor SMTP e enviar um e-mail com From: presidente@gov.br — o protocolo não impede.

Por 40 anos, isso foi a porta de entrada de phishing, spam e fraudes corporativas. SPF, DKIM e DMARC são as três camadas que o setor adicionou pra que o servidor que recebe possa verificar que o e-mail veio mesmo de quem diz que veio.

Quem não tem essas três configuradas hoje é tratado como suspeito por padrão. Gmail e Yahoo, desde fevereiro de 2024, exigem todas as três pra remetentes que enviam volume.

SPF — "quem pode mandar e-mail em meu nome"

SPF (Sender Policy Framework) é um registro DNS que lista os servidores autorizados a enviar e-mail com o seu domínio no From.

Aparência típica:

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

Lê-se: "e-mails do meu domínio podem vir do Google Workspace OU do SendGrid. Qualquer outro servidor, marque como suspeito (~all = softfail)."

O que dá errado:

• Limite de 10 lookups DNS (RFC 7208 §4.6.4). Cada include: conta. Se você tem include:_spf.google.com include:sendgrid.net include:mailchimp.com include:mailgun.org include:_spf.mandrillapp.com… provavelmente já estourou o limite. Resultado: toda validação SPF retorna permerror e o e-mail vai pro spam.
• +all no final — significa "qualquer servidor pode enviar em meu nome". É como deixar a porta aberta. Nunca use.
• Esquecer um serviço. Você mandou o boleto via sistema novo, esqueceu de adicionar no SPF, e o boleto foi pro spam do cliente. Aconteceu.

DKIM — "esse e-mail não foi alterado no caminho"

DKIM (DomainKeys Identified Mail) assina cada e-mail enviado com uma chave criptográfica. O servidor que recebe consulta o DNS, pega a chave pública correspondente, e verifica a assinatura.

Se baterem, dois fatos ficam comprovados:

1. O e-mail veio mesmo de quem tem a chave privada (o servidor autorizado).
2. O conteúdo não foi modificado em trânsito.

O que dá errado:

• Não configurar. O serviço de envio gera as chaves, mas você precisa adicionar o registro DNS (tipo TXT em selector._domainkey.seudominio.com.br). Sem isso, não há DKIM.
• Selector errado. Cada provedor usa um nome diferente: Google usa google, SendGrid usa s1/s2, Mailchimp usa k1/k2. Configurou o selector errado, DKIM falha.
• Chave fraca. Chaves DKIM de 1024 bits ainda são aceitas mas o setor pede 2048+.

DMARC — "o que fazer quando SPF ou DKIM falham"

SPF e DKIM dizem "esse e-mail é legítimo" ou "esse e-mail é suspeito". Mas quem decide o que fazer com o suspeito? Sem DMARC, cada provedor decide do seu jeito.

DMARC (Domain-based Message Authentication, Reporting and Conformance) é a política. Você diz no DNS:

v=DMARC1; p=reject; rua=mailto:dmarc@seudominio.com.br; pct=100

Lê-se: "se SPF e DKIM falharem, rejeite o e-mail. E me mande um relatório semanal sobre quem está tentando se passar por mim."

Os três modos de política:

• p=none — só monitora, não faz nada. Use no começo.
• p=quarantine — manda pro spam quando falha.
• p=reject — bloqueia totalmente.

O que dá errado:

• Pular pra p=reject direto sem monitorar. Você descobre que sua própria ferramenta de RH ou sistema interno enviava com seu domínio e nunca passou em SPF/DKIM. De repente nenhum colaborador recebe holerite por e-mail. Sempre comece em p=none, leia os relatórios por 2-4 semanas, depois suba.
• Não publicar DMARC. Gmail e Yahoo agora exigem pelo menos p=none pra remetentes em volume. Sem DMARC, sua entregabilidade vai colapsando lentamente.
• Falta de alinhamento. O From: precisa bater com o domínio assinado pelo DKIM e/ou autorizado pelo SPF. Se você manda como marketing@seudominio.com.br mas o SPF autoriza mail.servico-terceiro.com, não há alinhamento e DMARC falha.

Como verificar agora

Você pode checar manualmente:

dig +short TXT seudominio.com.br | grep spf
dig +short TXT _dmarc.seudominio.com.br
dig +short TXT google._domainkey.seudominio.com.br   # ou o selector que você usa

Mas pra ter um diagnóstico contínuo — porque DNS muda, serviços novos são adicionados, e DKIM pode ser desativado em rotação de chaves — o ideal é monitorar de fora.

O que o Sentinela checa

O probe de Email do Sentinela analisa, em cada audit:

• SPF existe? Quantos lookups DNS consome? Está perto ou acima do limite de 10? Tem +all? Tem múltiplos registros (que viola a RFC)?
• DKIM — testa selectors comuns (default, google, selector1, selector2, k1, k2, s1, s2, mail, etc.). Reporta quais existem, tamanho da chave, se está revogada.
• DMARC está publicado? Em qual policy (none, quarantine, reject)? Tem rua configurado pra receber relatórios?
• MX aponta pra servidores válidos e responsivos?
• DNSSEC está habilitado pro domínio?

O resultado vai num PDF de auditoria com severidade por finding (critical/high/medium/low/info) — exatamente o tipo de documento que sua equipe de TI ou seu cliente vai querer ver.

Crie uma conta grátis e rode o primeiro audit em menos de 1 minuto. Você descobre na hora se sua entregabilidade tá comprometida — antes de gastar a próxima campanha.

A regra simples

Se você envia e-mail pelo seu domínio — newsletter, transacional, suporte, qualquer coisa — você precisa das três configuradas. Não é mais opção. Provedores grandes (Gmail, Outlook, Yahoo, iCloud) já tratam como obrigatório, e isso só vai apertar.

A boa notícia: configura uma vez direito, monitora periodicamente, e dura anos. A má: a maioria das empresas configurou metade, há dois anos, e ninguém olha mais. Olha hoje.