SPF, DKIM e DMARC explicados: O guia completo de autenticação de e-mail [2026]

O e-mail tem um problema de confiança. Não há uma maneira integrada de provar que uma mensagem realmente veio do domínio que afirma ser, e é por isso que alguém pode enviar um e-mail que parece ser do seu chefe, do seu banco ou do seu negócio com pouco mais do que alguns minutos de configuração.

SPF, DKIM e DMARC são os três registros DNS que corrigem isso. Juntos, eles informam aos servidores de e-mail receptores quais servidores têm permissão para enviar em nome do seu domínio, se cada mensagem foi adulterada durante o trânsito e o que fazer quando uma dessas verificações falha.

Este guia explica o que cada um faz, como eles trabalham juntos, a ordem para configurá-los e como testá-los. A partir de 2026, todos os três são obrigatórios para qualquer empresa que envia e-mails. Gmail, Yahoo e Microsoft o aplicam diretamente, e pular qualquer um deles prejudica a entrega na caixa de entrada.

Respostas rápidas

• O que são SPF, DKIM e DMARC? Três registros DNS que trabalham juntos para verificar se seus e-mails são genuinamente seus. SPF autoriza quais servidores podem enviar em nome do seu domínio, DKIM adiciona uma assinatura criptográfica provando que a mensagem não foi alterada, e DMARC informa aos destinatários o que fazer quando SPF ou DKIM falham.
• Você precisa dos três? Sim. Cada um corrige o que os outros não cobrem, e desde fevereiro de 2024, Gmail e Yahoo os exigem para remetentes de mais de 5.000 e-mails por dia.
• Em que ordem você os configura? SPF primeiro, depois DKIM, depois DMARC, com verificação entre cada etapa.
• Verifique os seus agora: Use o verificador gratuito nesta página para testar os três registros no seu domínio.

SPF, DKIM e DMARC: Autenticação de E-mail Explicada

Os três registros são verificações independentes que se combinam em uma política. Uma vez implementados, você para de ter que adivinhar por que uma redefinição de senha nunca chegou ou por que um e-mail transacional foi para o spam.

O que são SPF, DKIM e DMARC?

SPF, DKIM e DMARC são três registros DNS que autenticam o e-mail vindo do seu domínio.

• SPF (Sender Policy Framework) lista todos os servidores que têm permissão para enviar e-mails em nome do seu domínio.
• DKIM (DomainKeys Identified Mail) adiciona uma assinatura criptográfica a cada mensagem para que os destinatários possam confirmar que o conteúdo não foi alterado durante o trânsito.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) informa aos destinatários o que fazer quando SPF ou DKIM falham e vincula ambas as verificações ao endereço From: visível.

Cada um corrige uma lacuna diferente. SPF impede que servidores não autorizados reivindiquem seu domínio, DKIM impede que alguém modifique suas mensagens em trânsito e DMARC impede que atacantes passem nas verificações SPF ou DKIM com um domínio diferente enquanto falsificam o seu na linha From: visível.

Comparação rápida

	SPF	DKIM	DMARC
O que faz	Lista servidores permitidos a enviar e-mails para o seu domínio	Assina cada e-mail para que os destinatários possam confirmar que ele não foi modificado	Diz aos destinatários o que fazer quando SPF ou DKIM falham
Como funciona	O destinatário compara o IP de envio com uma lista em seu DNS	O destinatário verifica uma assinatura criptográfica em relação à sua chave pública	O destinatário aplica sua política (entregar, spam ou rejeitar) aos e-mails com falha
O que não faz	Não verifica o endereço From: visível, falha no encaminhamento	Não informa quais servidores podem enviar, pode falhar se retransmissores modificarem o e-mail	Não autentica nada por si só, depende de SPF e DKIM
Onde ele reside no DNS	Registro TXT no seu domínio raiz	Registro TXT em [seletor]._domainkey.seudominio.com	Registro TXT em _dmarc.seudominio.com
Obrigatório em 2026?	Sim	Sim	Sim

Quando um e-mail chega ao Gmail, Outlook ou qualquer outra caixa de entrada, três verificações ocorrem uma após a outra. O destinatário consulta seu registro SPF e compara o IP de envio com a lista. O destinatário verifica a assinatura DKIM em relação à chave pública em seu DNS. Em seguida, o destinatário lê sua política DMARC e decide o que fazer com o resultado.

O que é SPF?

SPF é um registro TXT em seu DNS que lista todos os servidores e serviços autorizados a enviar e-mails em nome do seu domínio. É a primeira linha de defesa contra a falsificação de domínio.

Um registro SPF básico se parece com isto:

v=spf1 include:sendlayer.net ~all

As partes:

• v=spf1 declara que este é um registro SPF.
• include:sendlayer.net autoriza um serviço de envio, aqui o SendLayer. Cada ferramenta de envio tem sua própria diretiva include:.
• ~all é a regra geral para qualquer coisa que não corresponda. O til significa “falha suave”, que permite o e-mail, mas o sinaliza. Use -all para “falha rígida” (rejeitar) quando tiver certeza de que seu registro cobre todos os remetentes legítimos.

Quando um e-mail chega, o servidor receptor pega o IP de onde ele veio e verifica se esse IP é permitido pelo seu registro SPF. Se sim, o SPF passa. Se não, o SPF falha.

O que o SPF não pode fazer

O SPF tem duas limitações bem conhecidas. Ele falha no encaminhamento de e-mail. Quando alguém encaminha seu e-mail, o servidor de encaminhamento usa seu próprio IP, que não está em seu registro SPF, então o SPF falha, mesmo que o original fosse legítimo. Ele também verifica apenas o return-path, não o endereço visível From:. Um invasor pode passar no SPF com um domínio que controla, enquanto faz a linha From: parecer a sua. É por isso que o alinhamento DMARC é importante (mais sobre isso abaixo).

O limite de 10 consultas DNS

Os registros SPF são limitados a 10 consultas DNS no total (RFC 7208). Cada diretiva include:, a, mx, ptr e exists: conta para o limite. Adicione muitos serviços de envio e você atingirá um PERMERROR, momento em que toda autenticação falha silenciosamente.

A maioria dos domínios atinge este limite ao agrupar várias ferramentas de marketing, CRMs, serviços transacionais e centrais de atendimento. Se você estiver perto do limite, siga nosso guia sobre como mesclar vários registros SPF em um único registro simplificado.

E note, você só pode ter um registro SPF por domínio. Se você tentar adicionar um segundo, o RFC 7208 diz que os receptores devem tratar toda a configuração como inválida, o mesmo efeito de não ter nenhum SPF.

O que é DKIM?

O DKIM adiciona uma assinatura criptográfica a cada e-mail que você envia. A assinatura é gerada usando uma chave privada mantida pelo seu serviço de envio, e seu DNS contém a chave pública correspondente. Servidores receptores comparam as duas para confirmar que o e-mail realmente veio do seu domínio e que nada nele foi modificado durante o trânsito.

Um registro DKIM no DNS se parece com isto:

selector1._domainkey.example.com.    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."

O seletor (“selector1” neste exemplo) informa aos servidores receptores qual chave DKIM procurar. A maioria dos provedores rotaciona as chaves periodicamente e usa seletores diferentes para diferentes fluxos de envio, portanto, o nome do seletor faz parte da localização do registro.

Cada e-mail que você envia carrega um cabeçalho DKIM-Signature que se parece com isto:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

A tag d= é o domínio que reivindica a assinatura. A tag s= é o seletor. Esse é o registro DNS que os receptores procurarão.

O que o DKIM não pode fazer

O DKIM é poderoso, mas tem limites. Ele não diz quais servidores podem enviar para o seu domínio. Esse é o trabalho do SPF. Um invasor pode falsificar seu domínio sem assinar com DKIM, e o DKIM sozinho não tem opinião sobre isso. Ele também pode falhar se um servidor de retransmissão modificar o corpo da mensagem, por exemplo, uma lista de e-mails que adiciona um rodapé ao correio de saída. E o DKIM não tem aplicação integrada. Um servidor receptor pode ignorar uma assinatura falha, a menos que o DMARC o instrua a não fazer isso.

Comprimento da chave DKIM

Chaves DKIM modernas têm 2048 bits, o que produz uma string de chave pública com mais de 255 caracteres, o comprimento máximo de um único valor de registro TXT. A maioria dos provedores de DNS lida com isso automaticamente dividindo o valor em várias strings entre aspas, mas alguns não. Se o seu registro DKIM não salvar ou não validar, consulte nosso guia sobre como dividir um registro DKIM.

O que é DMARC?

O DMARC une SPF e DKIM e diz aos servidores receptores o que fazer quando a autenticação falha. É o único dos três que gera relatórios para você.

Um registro DMARC típico se parece com isto:

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; aspf=r; adkim=r"

Cada tag tem uma função:

• v=DMARC1 declara que este é um registro DMARC.
• p= é a política, uma de none, quarantine ou reject.
• rua= é para onde os relatórios agregados são enviados.
• pct= é a porcentagem de e-mails aos quais a política se aplica (útil para implementações graduais).
• aspf= e adkim= controlam o modo de alinhamento, relaxado (r) ou estrito (s).

Progressão da política, de none para quarantine para reject

A aplicação do DMARC é uma jornada, não um interruptor. As três políticas são estágios, e você progride por elas à medida que sua confiança aumenta.

• p=none é o modo de monitoramento. E-mails com falha são entregues normalmente, mas você recebe relatórios sobre eles. Sempre comece aqui.
• p=quarantine envia e-mails com falha para a pasta de spam do destinatário. Mova para cá após 2 a 4 semanas em p=none sem que nenhum e-mail legítimo falhe.
• p=reject rejeita e-mails com falha imediatamente (um erro SMTP 550). Mova para cá após mais 2 a 4 semanas em p=quarantine.

Pular direto para p=reject é a causa mais comum de interrupções relacionadas ao DMARC. Você descobrirá fontes de envio legítimas que esqueceu (seu CRM, sua ferramenta de marketing, sua central de suporte) somente depois que elas forem rejeitadas. Comece sempre em p=none, leia os relatórios e, em seguida, escale.

Relatórios agregados do DMARC

Quando você define rua= em seu registro DMARC, começará a receber relatórios XML diários de todos os provedores de e-mail que gerenciam o e-mail do seu domínio, incluindo Google, Microsoft, Yahoo e outros. Esses relatórios mostram cada IP que enviou e-mail sob seu domínio e se SPF e DKIM passaram e se alinharam para cada um.

O XML bruto é barulhento e legível por máquina, então a maioria das equipes conecta seu endereço rua= a um serviço de relatórios DMARC (Postmark, dmarcian, EasyDMARC e similares) que analisa os relatórios em um painel legível. É a única maneira prática de descobrir fontes de envio legítimas que você pode ter perdido antes de apertar sua política.

Alinhamento DMARC

DMARC introduz um conceito que os outros protocolos não têm, chamado alinhamento. SPF e DKIM passam quando sua respectiva verificação é válida, mas DMARC só conta essa passagem se o domínio autenticado corresponder ao endereço From: visível.

Existem dois tipos de alinhamento.

• Alinhamento SPF significa que o domínio smtp.mailfrom (return-path) corresponde ao domínio From:.
• Alinhamento DKIM significa que a tag d= na assinatura DKIM corresponde ao domínio From:.

DMARC passa se pelo menos um desses se alinhar E a verificação subjacente foi bem-sucedida.

Alinhamento flexível (o padrão) permite correspondências de subdomínio, então e-mails de mail.example.com se alinham com um From: em example.com. Alinhamento estrito requer uma correspondência exata. A maioria dos remetentes usa o flexível, a menos que tenham um motivo de segurança específico para o estrito.

O alinhamento é o motivo mais comum para falha do DMARC, mesmo quando SPF e DKIM passam individualmente. Muitos serviços de envio autenticam usando *seu próprio* domínio (por exemplo, sendgrid.net), não o seu, o que significa que SPF e DKIM passam, mas o DMARC falha porque nada se alinha com example.com. Corrigir o alinhamento geralmente significa mudar para um return-path personalizado ou assinatura DKIM de marca oferecida pelo seu provedor.

Como adicionar um registro DMARC

Se o seu provedor de e-mail fornecer um registro DMARC específico, adicione-o. Se não, este é um registro inicial genérico seguro em _dmarc.seudominio.com:

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

Isso coloca você em modo de monitoramento com relatórios enviados para uma caixa de correio que você controla. Para configuração completa, incluindo tratamento de relatórios e progressão de políticas, consulte nosso guia dedicado sobre como criar um registro DMARC.

Por que você precisa dos três

Cada protocolo corrige o que os outros não conseguem. Aqui está o detalhamento.

	SPF	DKIM	DMARC
O que ele previne	Servidores não autorizados enviando como seu domínio	Conteúdo de e-mail sendo modificado em trânsito	Atacantes falsificando seu endereço From: mesmo quando outras verificações são aprovadas
O que ele verifica	IP de envio contra sua lista autorizada	Assinatura criptográfica contra sua chave pública	Alinhamento entre resultados de autenticação e o domínio From:
Falha comum	E-mails legítimos quebram no encaminhamento	Relays de listas de e-mail modificam o corpo e quebram a assinatura	Tanto SPF quanto DKIM falham no alinhamento com o domínio visível
Se você pular	Qualquer servidor pode alegar enviar como seu domínio	Qualquer pessoa pode modificar seu e-mail em trânsito sem detecção	Autenticações falhas não recebem aplicação

Execute apenas com SPF, e você estará vulnerável a falsificação baseada em alinhamento, onde um invasor se autentica com seu próprio domínio enquanto exibe o seu. Execute apenas com DKIM, e qualquer servidor ainda pode se passar por você. Execute apenas com DMARC, e você não terá autenticação subjacente para impor. Todos os três juntos é a única configuração que realmente funciona.

SPF, DKIM e DMARC são obrigatórios em 2026?

A autenticação de e-mail passou de melhores práticas para inegociável entre 2024 e 2026. Aqui está a situação.

Remetentes em massa (5.000+ e-mails por dia para Gmail ou Yahoo)

• Fevereiro de 2024. Gmail e Yahoo introduziram requisitos para remetentes em massa. SPF, DKIM e DMARC são todos necessários. Cabeçalhos de cancelamento de inscrição com um clique são necessários. A taxa de reclamação de spam deve permanecer abaixo de 0,3%.
• Maio de 2025. A Microsoft introduziu requisitos equivalentes para Outlook.com, Hotmail e Live.com.
• Novembro de 2025. O Gmail passou de adiamentos suaves (erros temporários 421) para rejeição permanente (erros 550) para mensagens não conformes. Não há mais período de carência. E-mails não conformes são rejeitados imediatamente.

Remetentes de menor volume (menos de 5.000 por dia)

Você não está tecnicamente sujeito às regras de remetente em massa, mas as verificações de autenticação subjacentes se aplicam a cada conexão. A falta de SPF, DKIM ou DMARC reduz a entrega na caixa de entrada em até 76%, mesmo com baixo volume. As regras visam nominalmente remetentes em massa, mas os filtros de spam usam os mesmos sinais para todos.

Contextos de conformidade

• PCI DSS v4.0 inclui requisitos de autenticação de e-mail para organizações que lidam com dados de cartão de pagamento.
• CISA Binding Operational Directive 18-01 exige que todas as agências federais dos EUA implementem SPF, DKIM e DMARC com p=reject.
• Requisitos semelhantes existem no Reino Unido (NCSC), Austrália (ACSC) e Canadá (CCCS) para governos e infraestruturas críticas.

Mesmo que você envie 50 e-mails por mês do seu formulário de contato, você ainda precisa dos três registros.

A ordem de configuração que importa

Adicione o SPF primeiro. Depois o DKIM. Depois o DMARC. Com esperas entre cada um. Essa ordem é inegociável, e errar nela é o motivo mais comum para que novas implementações quebrem a entrega.

Por que esta ordem importa

O DMARC verifica os resultados do SPF e DKIM. Se você adicionar o DMARC antes que esses dois estejam implementados e validados, todos os e-mails falharão na autenticação. Com uma política de p=quarantine ou p=reject, seus e-mails começarão a ir para o spam ou a serem rejeitados no momento em que o DMARC se propagar. Muitos provedores nem sequer permitem que você adicione um registro DMARC até que o SPF passe na validação.

Tempo até cada um estar ativo

• SPF: 5 a 30 minutos
• DKIM: 1 a 4 horas
• DMARC: 1 a 24 horas

Após a propagação de cada registro, envie um e-mail de teste para um endereço do Gmail que você controla e verifique os cabeçalhos em Mostrar original. Tanto o SPF quanto o DKIM devem mostrar PASS antes de você adicionar o DMARC.

Onde adicionar registros SPF, DKIM e DMARC

Todos os três registros são adicionados como registros TXT nas configurações de DNS do seu domínio, o mesmo local onde você gerencia registros A, registros MX e nameservers. Onde exatamente isso fica depende de quem está gerenciando seu DNS.

Hospedagens compartilhadas (Bluehost, SiteGround, HostGator)

A maioria das hospedagens compartilhadas inclui um Editor de Zona DNS em seu painel de controle em Domínio ou Gerenciamento de DNS. Procure uma opção para adicionar um registro TXT.

Registradores de domínio (GoDaddy, Namecheap, Google Domains)

Se sua hospedagem e domínio forem separados, seu DNS geralmente fica com seu registrador. Procure por Configurações de DNS ou Gerenciar DNS no painel do seu domínio.

Cloudflare

Abra o painel do Cloudflare, selecione seu domínio, clique em DNS no menu à esquerda e adicione um novo registro TXT. Aqui está a visualização do editor.

Vercel

Se a Vercel hospeda o DNS do seu domínio, abra o projeto, clique em Configurações » Domínios » Registros DNS e adicione um novo registro TXT. O campo Host aceita @ para o ápice (usado para SPF) e _dmarc para DMARC.

Netlify

O DNS da Netlify fica em Domínios no painel da sua equipe. Clique no domínio, depois em Configurar DNS da Netlify se ainda não o fez, e então adicione registros em Registros DNS.

Squarespace

O Squarespace gerencia o DNS através de Domínios » [nome do domínio] » Configurações de DNS » Registros Personalizados. Adicione registros TXT com Host = @ para o domínio ápice, ou _dmarc para DMARC.

WP Engine

O WP Engine não hospeda seu DNS por padrão, então você adicionará os registros SPF, DKIM e DMARC no registrador que você usa para o domínio (GoDaddy, Namecheap, Cloudflare, etc.). O que você precisará do WP Engine é o valor correto para o seu include: do SPF para que os servidores de e-mail deles possam enviar em nome do seu site. Encontre isso no Portal do Usuário do WP Engine, nas configurações de DNS ou e-mail do seu ambiente. O include SPF típico deles é mail1.wpengine.com. Adicione-o ao seu registro SPF existente junto com quaisquer outros remetentes, nunca como um segundo registro v=spf1.

Como testar SPF, DKIM e DMARC

Três maneiras confiáveis de verificar se todos os três registros estão funcionando como esperado.

Gmail “Mostrar original”

Envie um e-mail de teste do seu domínio para um endereço do Gmail que você controla. Assim que ele chegar, abra o e-mail, clique no menu de três pontos no canto superior direito e escolha Mostrar original. Procure por estas três linhas perto do topo.

• SPF: PASS (com seu domínio)
• DKIM: PASS (com header.d= mostrando seu domínio)
• DMARC: PASS

Se algum destes mostrar FAIL ou NEUTRAL, pule para a seção de solução de problemas abaixo.

Verificador de Domínio do WP Mail SMTP

A ferramenta de teste de e-mail do WP Mail SMTP valida automaticamente os três registros sempre que você envia um e-mail de teste, sem a necessidade de uma ferramenta separada. Ele sinaliza registros ausentes, múltiplos registros SPF, problemas de assinatura DKIM, falhas de alinhamento DMARC e problemas de registro PTR, tudo a partir do seu painel do WordPress. O Verificador de Domínio é gratuito no WP Mail SMTP Lite.

Verificadores online

MxToolbox, dmarcian e HostedScan oferecem verificações gratuitas de SPF, DKIM e DMARC. Insira seu domínio e você obterá um status rápido de aprovação/reprovação para cada registro, além de diagnósticos para erros comuns como muitas consultas DNS ou problemas de sintaxe.

Solução de problemas comuns

Se seus registros estiverem configurados, mas a autenticação ainda estiver falhando, um desses cenários é quase sempre a causa. Cada um segue o mesmo modelo: sintoma, causa provável, diagnóstico e correção.

1. O Gmail rejeitou seu e-mail com “550-5.7.26”

Sintoma. O Gmail retorna com uma rejeição SMTP 550-5.7.26. O texto completo geralmente diz algo como “O Gmail exige que todos os remetentes se autentiquem com SPF ou DKIM.”

Causa provável. Ausência de SPF ou DKIM válido no domínio de envio, ou ambos estão mal configurados.

Diagnóstico. Execute seu domínio no verificador no topo desta página ou use o Verificador de Domínio do WP Mail SMTP. O resultado mostrará qual dos três registros está ausente ou falhando.

Correção. Adicione um registro SPF válido e confirme se o DKIM está assinando para o seu domínio de envio. Reenvie após a propagação de ambos os registros. Para o diagnóstico completo, consulte nosso guia sobre como corrigir o bloqueio de e-mails pelo Gmail.

2. “Ação necessária: o registro SPF exigido pelo seu servidor SMTP não foi adicionado”

Sintoma. O painel do seu provedor de SMTP mostra um aviso de que seu registro SPF está ausente ou não os inclui.

Causa provável. A diretiva include: do seu provedor não está no registro SPF do seu domínio.

Diagnóstico. Execute dig TXT seu_dominio.com ou use o verificador acima. Procure pelo registro SPF e confirme se o domínio do provedor (por exemplo, sendlayer.net, _spf.google.com) está na lista.

Correção. Adicione o include: do provedor ao seu registro SPF existente. Por exemplo, um registro SPF usando SendLayer mais o Google Workspace leria v=spf1 include:sendlayer.net include:_spf.google.com ~all. Nunca crie um segundo registro SPF no mesmo domínio.

3. DMARC falha apesar do SPF passar

Sintoma. O Mostrar original do Gmail mostra SPF: PASS, mas DMARC: FAIL.

Causa provável. Falha no alinhamento do SPF. Seu domínio de return-path não corresponde ao domínio visível de From:.

Diagnóstico. Verifique o valor smtp.mailfrom nos cabeçalhos. Ele corresponde ao domínio em From:?

Correção. Altere o return-path do seu serviço de envio para o seu domínio (a maioria dos provedores oferece uma configuração de “return-path personalizado” ou “domínio de bounce”), ou confie no alinhamento DKIM, que geralmente é mais fácil de configurar.

4. Assinatura DKIM ausente em e-mails recebidos

Sintoma. Os cabeçalhos não mostram nenhuma linha DKIM-Signature:.

Causa provável. DKIM não está realmente configurado no lado do remetente, ou o seletor incorreto está sendo usado.

Diagnóstico. Envie um teste de outra ferramenta (diretamente do Gmail ou outro serviço SMTP) para comparar. Verifique o painel do seu provedor SMTP para o status DKIM, pois a maioria mostra se o seletor foi verificado.

Correção. Verifique novamente se os registros CNAME ou TXT do DKIM existem exatamente como seu provedor especificou. O nome do seletor no seu registro DNS deve corresponder ao que o provedor está assinando. Erros de digitação aqui são extremamente comuns.

5. SPF “permerror: muitas consultas DNS”

Sintoma. Servidores de e-mail rejeitam suas mensagens com um PERMERROR do SPF.

Causa provável. Seu registro SPF contém mais de 10 consultas DNS (o limite rígido de 10 da RFC 7208). Comum ao empilhar diretivas include: para vários serviços.

Diagnóstico. Use uma ferramenta de achatamento de SPF para contar suas consultas. Cada include:, a, mx, ptr e exists: conta.

Correção. Remova includes desnecessários ou use um serviço de achatamento de SPF que resolva os includes em entradas de IP diretas. Guia completo em nosso guia de mesclagem de SPF.

6. Múltiplos registros SPF no mesmo domínio

Sintoma. PERMERROR ou NEUTRAL do SPF, apesar de ter um registro com aparência válida.

Causa provável. Você tem dois ou mais registros TXT do SPF. A RFC 7208 afirma que isso é inválido, e os receptores tratarão como se nenhum registro SPF existisse.

Diagnóstico. Execute dig TXT seudominio.com ou use a consulta SPF do MxToolbox. Se você vir dois registros começando com v=spf1, esse é o problema.

Correção. Combine as diretivas include: de ambos os registros em um único registro. Veja o guia de mesclagem acima.

7. Registro DKIM muito longo para DNS

Sintoma. Seu provedor forneceu uma chave DKIM, mas o DNS não a aceita.

Causa provável. Registros TXT únicos têm um limite de 255 caracteres por string. Chaves DKIM de 2048 bits excedem isso e devem ser divididas em várias strings entre aspas dentro do mesmo registro.

Diagnóstico. Conte os caracteres da sua chave. Mais de 255 significa que este é o problema.

Correção. Divida o valor em blocos de 255 caracteres, cada um entre aspas, como "v=DKIM1; k=rsa; p=ABC..." "DEF..." "GHI...". A maioria dos provedores de DNS modernos faz isso automaticamente. Alguns não. Veja a seção de comprimento da chave DKIM acima para o guia completo.

8. Falha no alinhamento DMARC (o assassino silencioso)

Sintoma. SPF: PASS e DKIM: PASS, mas DMARC: FAIL.

Causa provável. Nenhum dos protocolos está alinhado com o domínio From:, embora ambos passem individualmente.

Diagnóstico. Compare três valores nos cabeçalhos: o domínio From:, o domínio smtp.mailfrom e a tag DKIM d=. Pelo menos um dos dois últimos deve corresponder ao primeiro.

Correção. Configure seu serviço de envio para usar seu domínio no return-path (para alinhamento SPF) ou na assinatura DKIM (para alinhamento DKIM). A maioria dos provedores usa o domínio deles por padrão. Você precisa optar pelo alinhamento.

9. DMARC p=reject bloqueando seus próprios e-mails legítimos

Sintoma. Clientes param de receber seus e-mails transacionais (redefinições de senha, recibos), mas seus envios de teste funcionam bem.

Causa provável. Você passou para p=reject muito rapidamente, antes de capturar todas as fontes de envio legítimas em seu SPF.

Diagnóstico. Verifique seus relatórios agregados de DMARC. Eles mostram todos os remetentes que falharam sob seu domínio. Os legítimos serão óbvios (seu CRM, ferramenta de marketing, helpdesk).

Correção. Volte para p=quarantine ou p=none. Use os relatórios DMARC para adicionar os remetentes legítimos ausentes ao SPF. Espere de 2 a 4 semanas até que os relatórios mostrem 0% de falha de e-mails legítimos, então reforce.

10. Registros adicionados, mas não propagados

Sintoma. Você adicionou os registros, mas as ferramentas ainda dizem que eles estão faltando.

Causa provável. Cache de DNS em seu registrador, seu resolvedor local ou o servidor receptor. Comum com alterações de TTL baixo após registros de TTL alto terem sido cacheados anteriormente.

Diagnóstico. Execute dig +trace TXT yourdomain.com de uma rede diferente, ou consulte o Google DNS diretamente com dig @8.8.8.8 TXT yourdomain.com. Se estes mostrarem o registro, mas o seu testador não, é o cache.

Correção. Espere. A maioria da propagação é concluída em até uma hora para SPF e até 24 horas para DMARC. Se após 48 horas você ainda não vir nada, verifique novamente se o registro foi salvo corretamente em seu registrador. Um problema comum são interfaces que precisam de uma etapa de confirmação que você perdeu.

Observações específicas do WordPress

O WordPress tem um problema específico de e-mail. Por padrão, ele usa a função mail() do PHP, que envia mensagens sem nenhuma autenticação. Seus registros SPF, DKIM e DMARC podem estar perfeitamente configurados, mas se o WordPress estiver enviando e-mails através do mail() do PHP a partir do IP compartilhado do seu provedor de hospedagem, e esse IP não estiver em seu registro SPF, todas as verificações de autenticação falharão.

A solução é rotear todos os e-mails do WordPress através de um serviço SMTP autenticado. O WP Mail SMTP faz isso com integrações de um clique para SendLayer, SMTP.com, Brevo, Gmail/Google Workspace, Microsoft 365, Amazon SES, Mailgun, SendGrid, Postmark, SparkPost e outros. Cada integração é pré-configurada para autenticar corretamente e alinhar-se ao seu domínio. Os recursos aprimorados de entrega de e-mail do WP Mail SMTP incluem o Verificador de Domínio gratuito que sinaliza registros SPF, DKIM e DMARC ausentes ou mal configurados diretamente no WordPress.

Se seus e-mails do WordPress estão caindo no spam, a causa geralmente é autenticação ausente ou desalinhada. O diagnóstico completo está em nosso guia sobre por que os e-mails do WordPress vão para o spam. Para configuração, nosso guia de validação de e-mail do WordPress detalha a verificação dos registros.

Corrija seus e-mails do WordPress agora

Perguntas Frequentes sobre SPF, DKIM e DMARC

Estas são as perguntas mais pesquisadas sobre autenticação de e-mail, organizadas do mais frequente ao mais técnico. Cada resposta é autônoma.

Qual a diferença entre SPF, DKIM e DMARC?

SPF diz quem pode enviar, DKIM prova que os e-mails são genuínos e inalterados, e DMARC impõe o que acontece quando qualquer uma das verificações falha.

SPF autoriza servidores de envio, DKIM adiciona uma assinatura criptográfica à prova de violação, e DMARC define a política que os destinatários seguem quando SPF ou DKIM falham no alinhamento. Você precisa dos três porque cada um cobre uma lacuna que os outros deixam aberta. SPF sem DKIM falha em e-mails encaminhados. DKIM sem SPF permite que servidores não autorizados reivindiquem seu domínio. Ambos sem DMARC significa que os servidores de recebimento não têm instruções de imposição quando algo falha.

Você precisa dos três, SPF, DKIM e DMARC?

Sim. Desde fevereiro de 2024, Gmail e Yahoo exigem os três para remetentes de mais de 5.000 e-mails por dia, e o Gmail começou a rejeitar e-mails não conformes em novembro de 2025. Mesmo abaixo desse limite, a ausência de qualquer um dos três reduz a colocação na caixa de entrada.

SPF e DKIM falham em situações diferentes (SPF falha no encaminhamento, DKIM falha se um relay modificar a mensagem), então uma configuração de protocolo único falha de forma imprevisível.

Você pode usar DMARC sem SPF ou DKIM?

Tecnicamente, o DMARC passa se o SPF ou o DKIM passarem e se alinharem, então você pode executar o DMARC com apenas um. Na prática, você deve configurar ambos, porque cada um falha em cenários que o outro sobrevive.

Executar DMARC apenas com SPF significa que e-mails encaminhados falham. Executá-lo apenas com DKIM significa que mensagens modificadas em trânsito falham. Ambos juntos fornecem autenticação confiável.

O que significam p=none, p=quarantine e p=reject?

Estes são os níveis de imposição do DMARC, em ordem de rigor.

p=none é o modo de monitoramento. Ele relata falhas, mas não bloqueia nada, e é onde todo domínio deve começar. p=quarantine envia e-mails com falha para a pasta de spam. p=reject bloqueia e-mails com falha completamente.

Mova de none para quarantine para reject gradualmente, somente após seus relatórios confirmarem que nenhum e-mail legítimo está falhando.

Em que ordem você deve configurar SPF, DKIM e DMARC?

Configure o SPF primeiro, depois o DKIM e, por último, o DMARC. O DMARC lê os resultados do SPF e do DKIM, portanto, adicioná-lo primeiro faz com que todos os e-mails falhem na autenticação imediatamente.

Adicione o SPF, espere a propagação, adicione o DKIM, verifique se ambos passam em uma verificação Mostrar original do Gmail e, em seguida, adicione o DMARC começando com p=none.

Como verificar se SPF, DKIM e DMARC estão configurados corretamente?

Use uma ferramenta de verificação (como a gratuita no topo desta página) que consulta os três registros do seu domínio e relata o status deles.

Você também pode verificar manualmente. Envie um e-mail para um endereço do Gmail, abra-o, clique no menu de três pontos, escolha Mostrar original e confirme se SPF, DKIM e DMARC mostram PASS.

O que é alinhamento DMARC?

O alinhamento é a verificação que torna o DMARC significativo. Ele confirma que o domínio que passou no SPF ou DKIM corresponde ao domínio no endereço From: visível do e-mail.

O alinhamento SPF exige que o domínio do return-path corresponda ao domínio From:. O alinhamento DKIM exige que a tag d= da assinatura corresponda a ele. A causa mais comum de falha no DMARC é o desalinhamento, não uma falha direta de SPF ou DKIM.

O que significa o erro "550-5.7.26" do Gmail?

O erro 550-5.7.26 significa que o Gmail rejeitou seu e-mail porque o domínio remetente não está autenticado. O Gmail agora exige que todos os remetentes se autentiquem com SPF ou DKIM.

Para corrigir, adicione um registro SPF válido e uma assinatura DKIM para seu domínio remetente, confirme se ambos passam antes de reenviar. O primeiro item de solução de problemas acima detalha o diagnóstico completo.

O que significa quando o "Mostrar original" do Gmail mostra SPF, DKIM e DMARC PASS?

Significa que seu e-mail foi autenticado corretamente. SPF PASS confirma que o e-mail veio de um servidor autorizado. DKIM PASS confirma que a mensagem não foi alterada durante o trânsito. DMARC PASS confirma que o domínio autenticado está alinhado com seu endereço From: visível.

Todos os três passando é o resultado que você deseja. Maximiza a colocação na caixa de entrada.

SPF, DKIM e DMARC impedem que e-mails vão para spam?

Eles são necessários, mas não suficientes. A autenticação informa aos provedores de caixa de entrada que seus e-mails são genuinamente seus, o que é um pré-requisito para a colocação na caixa de entrada, mas outros fatores ainda importam. Estes incluem reputação do remetente, qualidade do conteúdo, taxas de engajamento, higiene da lista e um registro PTR válido.

Configure os três primeiro e, em seguida, aborde os outros fatores de entregabilidade de e-mail.

Qual é a melhor ferramenta para verificar DMARC, SPF e DKIM?

A maneira mais rápida é um verificador que testa os três ao mesmo tempo, como o gratuito nesta página. Para monitoramento contínuo, o Google Postmaster Tools mostra como o Gmail avalia sua autenticação, e o Verificador de Domínio integrado do WP Mail SMTP verifica os três registros diretamente no WordPress.

Qual é a forma completa de SPF, DKIM e DMARC?

SPF significa Sender Policy Framework. DKIM significa DomainKeys Identified Mail. DMARC significa Domain-based Message Authentication, Reporting, and Conformance.

Juntos, eles formam o conjunto padrão para autenticar e-mails e proteger um domínio contra spoofing.

Em seguida, Verifique seu Registro PTR

SPF, DKIM e DMARC são três dos quatro registros DNS importantes para a entregabilidade de e-mails. O quarto é o seu registro PTR, a entrada DNS reversa que mapeia seu IP de envio de volta ao seu domínio. Os provedores de caixa de correio o verificam em cada conexão, e um PTR ausente ou genérico prejudicará sua entregabilidade, mesmo quando SPF, DKIM e DMARC passarem.

Para a análise completa, consulte nosso guia sobre registros PTR e DNS reverso.

Corrija seus e-mails do WordPress agora

Pronto para corrigir seus e-mails? Comece hoje mesmo com o melhor plugin SMTP para WordPress. Se você não tem tempo para corrigir seus e-mails, pode obter assistência completa de Configuração White Glove como uma compra adicional, e há uma garantia de devolução do dinheiro em 14 dias para todos os planos pagos.