SPF, DKIM, DMARC: o guia completo para configurar seu e-mail (2026)

SPF, DKIM e DMARC: se você envia e-mails, e especialmente e-mails de prospecção, certamente já se deparou com essas três siglas. E provavelmente já soltou um suspiro de desespero diante da documentação técnica. Em 2026, esses três protocolos de autenticação de e-mail não são mais opcionais: desde fevereiro de 2024, Google e Yahoo rejeitam os e-mails não autenticados de remetentes em massa, e a Microsoft seguiu o mesmo caminho em maio de 2025. Para as equipes que fazem cold email B2B, isso se tornou a condição mínima para chegar à caixa de entrada. Neste guia completo, explicamos exatamente o que são SPF, DKIM e DMARC, como eles funcionam em conjunto e, principalmente, como configurá-los corretamente no seu domínio. Com exemplos concretos de registros DNS, os erros comuns a evitar e um FAQ para responder a todas as suas dúvidas.

SPF, DKIM e DMARC são três protocolos complementares de autenticação de e-mail. Cada um desempenha um papel diferente e específico na verificação de que um e-mail enviado a partir do seu domínio é realmente legítimo.

• SPF (Sender Policy Framework): declara quais servidores estão autorizados a enviar e-mails a partir do seu domínio.

• DKIM (DomainKeys Identified Mail): adiciona uma assinatura criptográfica a cada e-mail para provar que ele não foi alterado.

• DMARC (Domain-based Message Authentication, Reporting and Conformance): informa aos servidores destinatários o que fazer se SPF ou DKIM falharem, e envia relatórios de monitoramento.

Configurar os três corretamente é a condição mínima para chegar à caixa de entrada em 2026. Se faltar apenas um deles, seus e-mails correm o risco de cair em spam ou, pior, de serem simplesmente rejeitados pelo Gmail, Outlook ou Yahoo.

O SPF é o mais antigo dos três protocolos (surgiu oficialmente em 2006 com a RFC 4408, atualizada em 2014 com a RFC 7208). Seu princípio é simples: você publica no seu DNS a lista dos servidores autorizados a enviar e-mails em nome do seu domínio. Quando um servidor recebe um e-mail que diz vir do seu domínio, ele verifica se o endereço IP do remetente está realmente nessa lista.

O SPF é implementado por meio de um registro TXT na sua zona DNS, na raiz do seu domínio. Veja um exemplo típico:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Esse registro diz: «Os e-mails deste domínio podem ser enviados pelos servidores do Google Workspace ou do Microsoft 365. Qualquer outro servidor deve ser considerado suspeito (~all = soft fail).»

Se a sua empresa usa vários serviços de envio (Google Workspace para os e-mails internos, uma ferramenta de cold email como a Emelia e uma ferramenta transacional como o SendGrid), o seu SPF precisa incluir todos eles:

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

O SPF impõe uma restrição técnica frequentemente esquecida: um registro SPF não pode gerar mais de 10 lookups DNS. Cada mecanismo include: dispara um lookup adicional, e alguns serviços (como o Microsoft 365) consomem vários sozinhos. Acima de 10, todo o SPF retorna um erro PermError e a verificação falha. Se você tem muitos serviços a autorizar, precisa «achatar» o seu SPF (SPF flattening) com uma ferramenta dedicada.

O mecanismo final do seu SPF determina como os servidores tratam um e-mail que falha na verificação.

• ~all (soft fail): o e-mail falha no SPF, mas ainda pode ser entregue, geralmente marcado como suspeito. Recomendado durante a fase de instalação e na maior parte do tempo em 2026.

• -all (hard fail): o e-mail é rejeitado pelos servidores estritos. Use apenas depois de validar que todos os seus serviços de envio legítimos estão de fato no SPF.

Em 2026, a prática recomendada é começar com ~all e, depois de validar pelos relatórios DMARC que tudo está limpo, mudar para -all se você quiser uma abordagem estrita.

O DKIM (RFC 6376) adiciona uma assinatura criptográfica a cada e-mail enviado. Essa assinatura, calculada com uma chave privada, é verificada pelo servidor destinatário por meio de uma chave pública publicada no seu DNS. O DKIM prova duas coisas: que a mensagem realmente vem do seu domínio e que ela não foi modificada no caminho.

Quando o seu servidor de envio envia um e-mail, ele calcula uma impressão criptográfica do conteúdo (cabeçalho + corpo) e a criptografa com uma chave privada. Essa assinatura é adicionada ao cabeçalho DKIM-Signature do e-mail. O servidor destinatário recupera a chave pública correspondente no seu DNS, descriptografa a assinatura e verifica se ela corresponde de fato ao e-mail recebido. Se uma única vírgula tiver sido modificada no caminho, a verificação falha.

Um registro DKIM é um TXT publicado em um seletor específico no seu DNS. O seletor (selector) permite ter várias chaves DKIM em paralelo, o que é útil para a rotação. Formato típico:

selector1._domainkey.seudominio.com  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

Na prática, o seu provedor de e-mail (Google Workspace, Microsoft 365 ou uma ferramenta como a Emelia) gera o par de chaves e fornece o conteúdo exato a ser colado na sua zona DNS.

Eis por que o DKIM é tão importante: diferentemente do SPF, o DKIM sobrevive ao encaminhamento de e-mail. Quando um destinatário encaminha a sua mensagem para outra pessoa, o endereço IP do remetente muda (já não é mais o seu servidor, é o servidor da pessoa que encaminha). Por isso, o SPF falha mecanicamente. Mas a assinatura DKIM permanece intacta enquanto o conteúdo não for modificado. É por isso que, em 2026, o DKIM se tornou o pilar central da autenticação de e-mail.

As chaves DKIM existem historicamente em 1024 bits ou 2048 bits. Em 2026, a recomendação clara do mercado é usar 2048 bits. As chaves 1024 ainda são aceitas, mas cada vez mais penalizadas pelos filtros antispam. O ideal é fazer a rotação das suas chaves DKIM a cada 6 a 12 meses, para limitar a janela de risco em caso de vazamento da chave privada.

O DMARC (RFC 7489) não substitui nem o SPF nem o DKIM. Ele vem por cima para responder a duas perguntas: «O que o servidor destinatário deve fazer se SPF ou DKIM falharem?» e «Como eu sei quem está tentando enviar e-mails em nome do meu domínio?».

O DMARC se apoia em um conceito chamado alinhamento. Para que um e-mail passe no DMARC, é preciso que SPF ou DKIM tenha sucesso E que o domínio verificado por um dos dois corresponda ao domínio visível no campo «From» do e-mail (aquele que o destinatário vê). Sem esse alinhamento, um atacante poderia passar no SPF com o próprio domínio enquanto se faz passar por você no From, que é exatamente a técnica de falsificação que o DMARC impede.

O DMARC é publicado como um TXT em _dmarc.seudominio.com:

_dmarc.seudominio.com  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@seudominio.com; pct=100; aspf=r; adkim=r"

A tag p= define o que os servidores devem fazer em caso de falha:

• p=none: apenas monitoramento, o e-mail é entregue normalmente. É o modo de partida recomendado para coletar relatórios sem quebrar nada.

• p=quarantine: os e-mails não autenticados vão para o spam. Etapa intermediária após algumas semanas de monitoramento limpo.

• p=reject: os e-mails não autenticados são simplesmente rejeitados. É o modo final desejado, que oferece a melhor proteção contra falsificação.

A progressão normal em 2026: começar com p=none por 4 a 6 semanas, analisar os relatórios DMARC, corrigir todas as fontes de e-mail legítimas que estão falhando, depois passar para p=quarantine por 2 a 4 semanas e, por fim, p=reject.

As tags aspf= e adkim= controlam o nível de alinhamento exigido entre os domínios.

• Modo relaxed (r): os subdomínios são aceitos. Se o seu From é «contato@seudominio.com» e o SPF passa com «mail.seudominio.com», o alinhamento está OK. É o modo recomendado para a maioria das organizações.

• Modo strict (s): é preciso ter correspondência exata. «contato@seudominio.com» e «mail.seudominio.com» não estão mais alinhados. Use apenas se você tiver controle total sobre todos os seus subdomínios de envio.

Esse é provavelmente o benefício mais subestimado do DMARC. Com rua=mailto:dmarc@seudominio.com, você recebe diariamente relatórios XML agregados detalhando quem está tentando enviar e-mails em nome do seu domínio, a partir de quais IPs, e com qual taxa de sucesso de SPF/DKIM. Esses relatórios revelam os serviços esquecidos (que enviam por você sem autenticação), as tentativas de falsificação e os erros de configuração. Várias ferramentas gratuitas ou pagas, como dmarcian, Postmark DMARC ou URIports, transformam esses XMLs em painéis legíveis.

Cada protocolo cobre uma lacuna que os outros não preenchem:

• Só o SPF não basta: ele verifica o IP do servidor de envio (Return-Path), não o From visível. Um atacante pode passar no SPF com o próprio domínio enquanto falsifica o seu no From.

• Só o DKIM não basta: ele prova que a mensagem não foi alterada, mas não diz ao servidor destinatário o que fazer em caso de falha. E nem todos os remetentes assinam com DKIM.

• Só o DMARC não tem efeito: ele depende do SPF ou do DKIM para funcionar. Sem eles, o DMARC não tem nada para avaliar.

Juntos, os três formam um sistema completo: o SPF verifica o IP, o DKIM verifica a integridade do conteúdo, o DMARC aplica a política e oferece a visibilidade. É exatamente por isso que Google, Yahoo, Outlook e Apple agora exigem os três para os remetentes em massa.

A ordem lógica de implementação é: SPF primeiro (o mais rápido), DKIM em seguida (exige a geração de um par de chaves) e DMARC por último (depende dos outros dois). Veja o passo a passo.

Liste todos os serviços que enviam e-mails em nome do seu domínio: o seu provedor de e-mail (Google Workspace, Microsoft 365), as suas ferramentas de cold email, os seus serviços transacionais, as suas newsletters. Peça a cada um o valor de include: a ser utilizado. Combine todos em um único registro TXT na raiz do seu domínio. Comece com ~all (soft fail). Em seguida, verifique com uma ferramenta como o MXToolbox se o registro está sintaticamente correto e se permanece abaixo do limite dos 10 lookups.

Para cada serviço de envio, siga o procedimento de geração de chave DKIM na sua interface (Google Workspace: Apps → Gmail → Autenticar e-mail → Gerar um novo record em 2048 bits). Copie o TXT fornecido e publique-o no seu DNS no seletor indicado. Aguarde a propagação DNS (5 a 60 minutos) e, em seguida, ative a autenticação na interface do provedor. Repita para cada ferramenta de envio.

Comece com uma política permissiva para coletar relatórios sem correr o risco de bloquear tráfego legítimo:

v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com; pct=100; aspf=r; adkim=r

Durante 4 a 6 semanas, leia os relatórios diários e identifique todas as fontes de e-mail legítimas que estão falhando. Corrija-as (adicione o include SPF que está faltando, ative o DKIM no serviço esquecido, etc.). Quando os seus relatórios estiverem limpos, passe para p=quarantine por 2 a 4 semanas e, em seguida, p=reject.

Várias ferramentas gratuitas permitem testar a sua configuração:

• MXToolbox: verificação de SPF, DKIM, DMARC e diagnóstico completo do domínio.

• Google Admin Toolbox: diagnóstico específico para domínios Google Workspace.

• dmarcian: análise dos relatórios DMARC em painel legível.

• Comando dig localmente: «dig TXT seudominio.com» para SPF, «dig TXT _dmarc.seudominio.com» para DMARC.

Mesmo com as melhores intenções, certos erros aparecem constantemente nas configurações de SPF, DKIM e DMARC.

• Ultrapassar o limite dos 10 lookups DNS no SPF: o seu registro retorna um erro PermError e tudo falha. Achate o seu SPF se necessário.

• Publicar vários registros SPF distintos: você só pode ter um único TXT SPF por domínio. Vários registros = falha automática.

• Esquecer de alinhar o domínio de envio: se o DMARC está em modo strict e o seu From está no domínio raiz, enquanto o SPF passa com um subdomínio, o alinhamento falha.

• Não monitorar os relatórios DMARC: publicar um DMARC em p=none sem nunca ler os relatórios é inútil. É exatamente esse o momento em que se identificam os problemas.

• Usar uma chave DKIM curta demais (1024 bits): cada vez mais penalizada pelos filtros modernos. Prefira 2048 bits.

• Passar para p=reject rápido demais: sem monitoramento prévio, você bloqueia os seus próprios e-mails legítimos. Conte com no mínimo 6 semanas antes do enforcement.

Se você faz cold email B2B em 2026, configurar corretamente SPF, DKIM e DMARC não é opcional, é a condição de sobrevivência das suas campanhas. Os limites de tolerância dos filtros antispam endureceram radicalmente desde 2024: Gmail, Outlook e Yahoo agora rejeitam os e-mails não autenticados em vez de simplesmente classificá-los como spam, como antes. Na prática, um cold email enviado de um domínio sem SPF/DKIM/DMARC corretos tem uma chance próxima de zero de chegar à caixa de entrada.

O outro ponto crítico: a sua reputação de domínio se constrói sobre o conjunto dos e-mails enviados. Se uma parte dos seus envios está mal autenticada, é todo o seu domínio que sofre. É por isso que os profissionais de cold email costumam usar domínios dedicados à prospecção (por exemplo, «empresa-contato.com» em vez do domínio principal «empresa.com»), com SPF/DKIM/DMARC próprios, para isolar a sua reputação.

Na Emelia, a autenticação SPF/DKIM/DMARC é gerenciada automaticamente quando você conecta as suas caixas de e-mail à plataforma. A configuração DNS continua do seu lado (você mantém o controle do seu domínio), mas a ferramenta orienta você passo a passo e verifica a validade do seu setup antes de cada envio de campanha.

SPF, DKIM e DMARC não são mais opcionais em 2026: são a base técnica sobre a qual se apoia a entregabilidade dos seus e-mails. Que você faça cold email, newsletters, e-mails transacionais ou simplesmente comunicação interna, esses três protocolos determinam se as suas mensagens chegam à caixa de entrada ou desaparecem no spam.

A boa notícia: a implementação é um investimento pontual que se paga ao longo do tempo. Uma vez configurados corretamente e em p=reject, você protege o seu domínio contra falsificação, melhora significativamente a sua entregabilidade e ganha a visibilidade oferecida pelos relatórios DMARC. Se você está começando hoje uma estratégia de prospecção por e-mail B2B, comece por aí, antes mesmo de pensar em copywriting ou na sequência.