SPF, DKIM e DMARC: por que os e-mails da empresa caem no spam

SPF, DKIM e DMARC são três registros no DNS do domínio que provam ao servidor de quem recebe que a mensagem com o seu endereço saiu de um serviço autorizado por você. Quando um deles falta ou está errado, Gmail, Outlook e Yahoo tratam a mensagem como suspeita: ela vai para o spam ou é recusada.

Isso vale para toda empresa que manda e-mail com o próprio domínio: o orçamento do comercial, a nota fiscal que sai do ERP, a notificação do formulário do site, a newsletter. E deixou de ser opcional. Desde fevereiro de 2024, Google e Yahoo exigem autenticação para entregar mensagens aos usuários deles, e a Microsoft seguiu o mesmo caminho no Outlook.com em 2025.

Os registros ficam na zona de DNS do domínio. Se você ainda não sabe onde ela está, comece por domínio, DNS, e-mail e hospedagem: o que a empresa precisa controlar.

O que são SPF, DKIM e DMARC

SPF: a lista de quem pode enviar

O SPF (Sender Policy Framework) é um registro TXT na raiz do domínio com os servidores autorizados a enviar e-mail em nome dele. O servidor que recebe a mensagem confere se a origem está na lista.

exemplo.com.br.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.marketing.example ~all"

v=spf1 identifica o registro. Cada include: autoriza os servidores de um serviço: aqui, o Google Workspace e uma ferramenta de e-mail marketing fictícia. ~all diz que qualquer outra origem não está autorizada e deve ser tratada com desconfiança; a variação -all pede recusa. O Google usa ~all no registro que recomenda para quem usa só o Workspace. No painel de DNS, isso vira um registro TXT com nome @ (ou vazio) e o texto entre aspas como valor.

O SPF tem um ponto cego: ele confere o endereço de retorno técnico da mensagem (o envelope, que o destinatário não vê), e não o remetente que aparece no campo De. Sozinho, não impede que alguém use o seu domínio no De.

DKIM: a assinatura de cada mensagem

O DKIM (DomainKeys Identified Mail) assina cada mensagem com uma chave privada guardada no serviço de envio. A chave pública fica no DNS, num nome que começa por um seletor, e o servidor de destino a usa para conferir que a mensagem saiu de quem tem a chave e não foi alterada no caminho.

seletor1._domainkey.exemplo.com.br.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Você não inventa esse registro: o serviço de e-mail gera a chave e mostra o nome e o valor exatos. Alguns pedem um CNAME em vez de TXT, apontando para uma chave que eles mesmos mantêm. Cada serviço tem o próprio seletor, então é normal haver vários DKIM, um por serviço. O Gmail exige chave de pelo menos 1.024 bits e recomenda 2.048. Em suítes como Google Workspace e Microsoft 365, a assinatura ainda precisa ser ativada no painel depois de publicar o registro.

DMARC: a regra e o relatório

O DMARC (Domain-based Message Authentication, Reporting and Conformance) junta os dois e fecha a brecha do campo De. Ele exige alinhamento: o domínio que aparece no De precisa ser o mesmo que passou no SPF ou no DKIM. E diz ao servidor de destino o que fazer quando a mensagem não passa, além de pedir relatórios.

_dmarc.exemplo.com.br.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@exemplo.com.br"

p é a política (none, quarantine ou reject) e rua é o endereço que recebe os relatórios agregados.

Por que o e-mail cai no spam mesmo com SPF configurado

O e-mail do dia a dia costuma sair da suíte já autenticado. O problema está nas outras origens:

• Serviço fora do SPF. O ERP que manda boleto, o emissor de nota fiscal, o CRM, a plataforma de atendimento: cada um envia por servidores próprios, e sem o include dele no SPF a mensagem chega sem autorização.
• SPF que passa, mas não alinha. Muitas plataformas enviam com o domínio delas no envelope. O SPF passa para o domínio da plataforma, não para o seu, e o DMARC falha se ela também não assinar com DKIM do seu domínio. A correção é configurar a autenticação do domínio próprio dentro da ferramenta.
• Encaminhamento. Mensagem encaminhada por outro servidor chega de um endereço que não está no seu SPF. Só a assinatura DKIM sobrevive ao encaminhamento, e por isso ela não é opcional.
• Reputação. Autenticação prova quem enviou; não compensa lista comprada nem taxa alta de denúncia.

O caso clássico é o formulário de contato. A notificação de novo contato sai com contato@exemplo.com.br no De, mas pelo servidor da hospedagem, que não está no SPF e não assina com a chave do domínio. A mensagem cai no spam da própria empresa, e o cliente fica dias sem resposta. Um site institucional que gera contato depende desse aviso chegar.

O limite de 10 consultas DNS do SPF

A norma do SPF, a RFC 7208, limita a 10 os termos que obrigam o servidor a fazer nova consulta DNS durante a verificação: include, a, mx, ptr, exists e o modificador redirect. Os termos ip4, ip6 e all não contam. O limite vale para a verificação inteira: os include que estão dentro de outros include entram na mesma conta. Passou de 10, o resultado é erro permanente (permerror), e o SPF deixa de valer para todas as mensagens, inclusive as legítimas.

O limite estoura aos poucos. Cada serviço novo pede um include, e cada include pode puxar outros por dentro. Suíte de e-mail, ferramenta de marketing, CRM, emissor de nota e sistema de atendimento somados chegam perto de 10 sem ninguém perceber. Como resolver:

• Tire os includes de serviços que a empresa não usa mais.
• Troque a e mx por ip4 quando o endereço for fixo e seu.
• Mande envios de volume (marketing, notificações de sistema) por um subdomínio, como news.exemplo.com.br, que tem SPF próprio e conta própria de consultas.
• Evite substituir includes por listas de IP copiadas à mão: quando o fornecedor muda de IP, o e-mail quebra sem aviso.

Para contar, use um verificador de SPF que mostre a árvore de consultas e o total.

DMARC em etapas: none, quarantine e reject

Publicar DMARC direto em reject é o jeito mais rápido de bloquear o boleto que o ERP manda e que ninguém lembrou de autenticar. A própria documentação do Google sobre DMARC orienta começar em none e endurecer aos poucos, e sugere esperar 48 horas depois de configurar SPF e DKIM antes de publicar o DMARC.

; etapa 1: observar
_dmarc.exemplo.com.br.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@exemplo.com.br"
; etapa 2: quarentena aplicada a 25% das mensagens que falham
_dmarc.exemplo.com.br.  IN  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@exemplo.com.br"
; etapa 3: rejeição
_dmarc.exemplo.com.br.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@exemplo.com.br"

Só um desses registros existe por vez: cada etapa substitui a anterior. A tag pct aplica a política a uma parte das mensagens que falham, e a porcentagem sobe aos poucos.

Os relatórios agregados do rua chegam como arquivos XML compactados, em geral um por dia de cada provedor que recebeu mensagens com o seu domínio. Cada um diz de quais IPs saíram mensagens usando o domínio, quantas, e se passaram no SPF, no DKIM e no alinhamento. É assim que aparece o serviço esquecido, como o sistema de cobrança que ninguém listou, e também quem usa o seu domínio para aplicar golpe. Lido cru, o XML é ilegível: use uma caixa dedicada e uma ferramenta que transforme os relatórios em tabela.

O que Google, Yahoo e Microsoft passaram a exigir

As diretrizes para remetentes do Gmail valem desde 1º de fevereiro de 2024 para quem envia a contas pessoais do Gmail. O Yahoo começou a aplicar regras equivalentes no mesmo mês, descritas nas boas práticas para remetentes do Yahoo. A Microsoft anunciou exigências para quem envia em volume ao Outlook.com, serviço que atende endereços outlook.com, hotmail.com e live.com, a partir de maio de 2025.

A empresa que envia pouco só é obrigada ao mínimo, mas configurar os três dá o mesmo trabalho, e o próprio Google recomenda SPF, DKIM e DMARC em qualquer domínio. Assim, uma campanha maior ou um sistema novo que dispara notificações não pega o domínio despreparado.

Como testar a configuração

Comece consultando os registros publicados. No Windows, nslookup -type=TXT exemplo.com.br faz o mesmo que o primeiro comando:

dig TXT exemplo.com.br +short
dig TXT _dmarc.exemplo.com.br +short
dig TXT seletor1._domainkey.exemplo.com.br +short

Depois:

1. Confira se há um único registro começando por v=spf1 e um único começando por v=DMARC1.
2. Mande uma mensagem real de cada origem para uma conta do Gmail e abra "Mostrar original" no menu da mensagem. O Gmail mostra o resultado de SPF, DKIM e DMARC e o domínio avaliado em cada um.
3. Confira se o PASS está no seu domínio, e não no do fornecedor. DKIM que passa só para o domínio da plataforma de marketing não alinha.
4. Depois de uma ou duas semanas em p=none, leia os relatórios e procure origens que você não reconhece.

Teste cada origem, não só o e-mail do dia a dia: o boleto do ERP, a nota fiscal, a notificação do formulário, a newsletter, a resposta automática do atendimento.

Erros comuns na configuração

• Dois registros SPF no mesmo domínio. A RFC 7208 proíbe, e o resultado é erro permanente. Acontece quando cada fornecedor pede para "adicionar um registro TXT" e alguém cria um novo em vez de editar o existente. O certo é um registro só, com todos os includes.
• Esquecer o serviço de e-mail marketing. A newsletter sai por uma ferramenta que não está no SPF nem assina com DKIM do domínio. Com DMARC em reject, a campanha inteira é recusada.
• Parar no p=none para sempre. A política none só observa. Quem falsifica o seu domínio para mandar boleto falso continua entregando. O none é a primeira etapa, não o destino.
• Relatório indo para lugar nenhum. O rua aponta para uma caixa que não existe ou que ninguém abre, e a fase de observação vira tempo perdido.
• Registro criado no nome errado. O painel completa o domínio sozinho, alguém digita _dmarc.exemplo.com.br no campo nome, e o registro vai parar em _dmarc.exemplo.com.br.exemplo.com.br. Consulte com dig depois de salvar.
• Chave DKIM esquecida na troca de provedor. O registro do provedor anterior fica no DNS, o do novo nunca é publicado, e ninguém percebe porque o SPF continua passando.

Próximo passo

Liste todas as origens de e-mail do domínio, publique o DMARC em p=none com relatório e leia os relatórios por duas semanas antes de apertar a política. Esse trabalho faz parte do nosso serviço de infraestrutura digital e segue o método das outras entregas: cada mudança de política só entra quando os relatórios mostram que nenhum envio legítimo vai ser barrado, e voltar à etapa anterior é trocar uma linha no DNS. Com o DMARC em reject, o boleto falso enviado em nome da empresa passa a ser recusado na entrada, um item que também aparece no checklist de segurança da informação para pequenas empresas.