SPF, DKIM e DMARC Explicados: O Guia Completo de Autenticação de Email [2026]

O e-mail tem um problema de confiança. Não existe uma forma integrada de provar que uma mensagem veio realmente do domínio que afirma ser, razão pela qual alguém pode enviar um e-mail que parece ser do seu chefe, do seu banco ou da sua empresa com pouco mais do que alguns minutos de configuração.

SPF, DKIM e DMARC são os três registos DNS que resolvem este problema. Juntos, indicam aos servidores de correio recetores quais os servidores autorizados a enviar para o 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 trabalham em conjunto, 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. O Gmail, o Yahoo e a Microsoft impõem-no diretamente, e saltar qualquer um deles afeta a sua colocação na caixa de entrada.

Respostas rápidas

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

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

Os três registos são verificações independentes que se combinam numa única política. Uma vez implementados, deixa de ter de adivinhar porque é que um reenvio de palavra-passe nunca chegou ou porque é 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 registos DNS que autenticam o e-mail proveniente do seu domínio.

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

Cada um corrige uma falha diferente. O SPF impede que servidores não autorizados se apropriem do seu domínio, o DKIM impede que alguém modifique as suas mensagens a meio do voo, e o DMARC impede que atacantes passem no SPF ou DKIM com um domínio diferente enquanto falsificam o seu no endereço From: visível.

Comparação rápida

	SPF	DKIM	DMARC
O que faz	Lista os servidores autorizados a enviar e-mail para o seu domínio	Assina cada e-mail para que os recetores possam confirmar que não foi modificado	Indica aos recetores o que fazer quando SPF ou DKIM falham
Como funciona	O recetor compara o IP de envio com uma lista no seu DNS	O recetor verifica uma assinatura criptográfica em relação à sua chave pública	O recetor aplica a sua política (entregar, spam ou rejeitar) ao e-mail com falha
O que não faz	Não verifica o endereço From: visível, falha no reencaminhamento	Não indica quais servidores podem enviar, pode falhar se os reencaminhadores modificarem o e-mail	Não autentica nada por si só, depende de SPF e DKIM
Onde reside no DNS	Registo TXT no seu domínio de ápice	Registo TXT em [selector]._domainkey.yourdomain.com	Registo TXT em _dmarc.yourdomain.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 recetor consulta o seu registo SPF e compara o IP de envio com a lista. O recetor verifica a assinatura DKIM em relação à chave pública no seu DNS. Em seguida, o recetor lê a sua política DMARC e decide o que fazer com o resultado.

O que é SPF?

SPF é um registo TXT no 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 registo SPF básico parece com isto:

v=spf1 include:sendlayer.net ~all

As partes:

• v=spf1 declara que este é um registo SPF.
• include:sendlayer.net autoriza um serviço de envio, aqui o SendLayer. Cada ferramenta de envio tem a sua própria diretiva include:.
• ~all é a regra de captura para tudo o que não corresponde. O til significa "falha suave", que permite o e-mail mas marca-o. Use -all para "falha dura" (rejeitar) quando tiver a certeza de que o seu registo abrange todos os remetentes legítimos.

Quando um e-mail chega, o servidor recetor obtém o IP de onde veio e verifica se esse IP é permitido pelo seu registo 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. Quebra com o reencaminhamento de e-mail. Quando alguém reencaminha o seu e-mail, o servidor de reencaminhamento usa o seu próprio IP, que não está no seu registo SPF, pelo que o SPF falha, mesmo que o original fosse legítimo. Também só verifica o return-path, não o endereço From: visível. Um atacante pode passar o SPF com um domínio que controla, enquanto faz com que a linha From: pareça a sua. É por isso que o alinhamento DMARC é importante (mais sobre isso abaixo).

O limite de 10 consultas DNS

Os registos 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 demasiados serviços de envio e atingirá um PERMERROR, altura em que toda a autenticação falha silenciosamente.

A maioria dos domínios atinge este limite quando empilha várias ferramentas de marketing, CRMs, serviços transacionais e helpdesks. Se estiver perto do limite, siga o nosso guia sobre como fundir vários registos SPF num único registo achatado.

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

O que é DKIM?

O DKIM adiciona uma assinatura criptográfica a todos os e-mails que envia. A assinatura é gerada usando uma chave privada detida pelo seu serviço de envio, e o seu DNS detém a chave pública correspondente. Os servidores recetores comparam as duas para confirmar que o e-mail veio realmente do seu domínio e que nada nele foi modificado durante o trânsito.

Um registo DKIM no DNS parece com isto:

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

O seletor (“selector1” neste exemplo) diz aos servidores recetores qual a chave DKIM a procurar. A maioria dos fornecedores roda as chaves periodicamente e usa seletores diferentes para diferentes fluxos de envio, pelo que o nome do seletor faz parte da localização do registo.

Todos os e-mails que envia carregam 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 etiqueta d= é o domínio que reivindica a assinatura. A etiqueta s= é o seletor. Esse é o registo DNS que os recetores procurarão.

O que o DKIM não pode fazer

O DKIM é poderoso, mas tem limites. Não diz quais os servidores que podem enviar para o seu domínio. Essa é a tarefa do SPF. Um atacante pode falsificar o seu domínio sem assinar com DKIM, e o DKIM sozinho não tem opinião sobre isso. Também pode falhar se um servidor de retransmissão modificar o corpo da mensagem, por exemplo, uma lista de correio que adiciona um rodapé ao correio de saída. E o DKIM não tem aplicação integrada. Um servidor recetor pode ignorar uma assinatura falhada, a menos que o DMARC lhe diga para não o fazer.

Comprimento da chave DKIM

As chaves DKIM modernas têm 2048 bits, o que produz uma string de chave pública mais longa do que 255 caracteres, o comprimento máximo de um único valor de registo TXT. A maioria dos fornecedores de DNS lida com isto automaticamente dividindo o valor em várias strings entre aspas, mas alguns não. Se o seu registo DKIM não guardar ou não validar, veja o nosso guia sobre como dividir um registo DKIM.

O que é DMARC?

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

Um registo DMARC típico parece com isto:

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

Cada etiqueta tem uma função:

• v=DMARC1 declara que este é um registo DMARC.
• p= é a política, uma de none, quarantine ou reject.
• rua= é para onde os relatórios agregados são enviados.
• pct= é a percentagem de e-mails a que 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 etapas, e progride através delas à medida que a sua confiança aumenta.

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

Saltar diretamente para p=reject é a causa mais comum de interrupções relacionadas com o DMARC. Descobrirá fontes de envio legítimas de que se esqueceu (o seu CRM, a sua ferramenta de marketing, o seu serviço de apoio) apenas depois de serem rejeitadas. Comece sempre em p=none, leia os relatórios e, em seguida, escale.

Relatórios agregados do DMARC

Quando define rua= no seu registo DMARC, começará a receber relatórios XML diários de todos os fornecedores de email que processam o email do seu domínio, incluindo Google, Microsoft, Yahoo e outros. Estes relatórios mostram todos os IPs que enviaram emails sob o seu domínio e se SPF e DKIM passaram e alinharam para cada um.

O XML bruto é ruidoso e legível por máquina, pelo que a maioria das equipas liga o seu endereço rua= a um serviço de relatórios DMARC (Postmark, dmarcian, EasyDMARC e similares) que analisa os relatórios num painel legível. É a única forma prática de descobrir fontes de envio legítimas que possa ter perdido antes de apertar a sua política.

Alinhamento DMARC

O DMARC introduz um conceito que os outros protocolos não têm, chamado alinhamento. SPF e DKIM passam quando a sua respetiva verificação é válida, mas o 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 etiqueta d= na assinatura DKIM corresponde ao domínio From:.

O DMARC passa se pelo menos um destes alinhar E a verificação subjacente passou.

Alinhamento relaxado (o padrão) permite correspondências de subdomínio, pelo que emails de mail.example.com alinham com um From: em example.com. Alinhamento estrito requer uma correspondência exata. A maioria dos remetentes usa o relaxado, a menos que tenham uma razão de segurança específica para o estrito.

O alinhamento é a razão mais comum para falha do DMARC, mesmo quando o SPF e o DKIM passam individualmente. Muitos serviços de envio autenticam usando o seu próprio domínio (por exemplo, sendgrid.net), não o seu, o que significa que o SPF e o 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 fornecedor.

Como adicionar um registo DMARC

Se o seu fornecedor de e-mail lhe der um registo DMARC específico, adicione-o. Se não, este é um registo inicial genérico seguro em _dmarc.yourdomain.com:

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

Isto coloca-o no modo de monitorização com relatórios a serem enviados para uma caixa de correio que controla. Para uma configuração completa, incluindo o tratamento de relatórios e a progressão de políticas, consulte o nosso guia dedicado sobre como criar um registo DMARC.

Porque precisa dos três

Cada protocolo corrige o que os outros não conseguem. Aqui está a análise.

	SPF	DKIM	DMARC
O que impede	Servidores não autorizados a enviar em nome do seu domínio	Conteúdo de e-mail a ser modificado em trânsito	Atacantes a falsificar o seu endereço From: mesmo quando outras verificações são bem-sucedidas
O que verifica	IP de envio contra a sua lista autorizada	Assinatura criptográfica contra a sua chave pública	Alinhamento entre os resultados de autenticação e o domínio From:
Falha comum	E-mails legítimos falham ao serem reencaminhados	Relays de listas de e-mail modificam o corpo e quebram a assinatura	Tanto SPF como DKIM falham no alinhamento com o domínio visível
Se o saltar	Qualquer servidor pode afirmar enviar em nome do seu domínio	Qualquer pessoa pode modificar o seu e-mail em trânsito sem ser detetado	Autenticações falhadas não têm aplicação

Execute apenas com SPF, e estará vulnerável a spoofing baseado em alinhamento, onde um atacante se autentica com o seu próprio domínio enquanto exibe o seu. Execute apenas com DKIM, e qualquer servidor ainda pode afirmar ser você. Execute apenas com DMARC, e 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 email passou de melhor prática para inegociável entre 2024 e 2026. Eis onde as coisas estã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. Já não há período de carência. Emails não conformes são rejeitados imediatamente.

Remetentes de menor volume (menos de 5.000 por dia)

Não está tecnicamente sujeito às regras de remetente em massa, mas as verificações de autenticação subjacentes aplicam-se a todas as ligações. A falta de SPF, DKIM ou DMARC reduz a colocação na caixa de entrada em até 76%, mesmo com baixo volume. As regras visam nominalmente os remetentes em massa, mas os filtros de spam utilizam 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ões de pagamento.
• A Diretiva Operacional Vinculativa 18-01 da CISA 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 envie 50 e-mails por mês a partir do seu formulário de contacto, ainda necessita dos três registos.

A ordem de configuração que importa

Adicione primeiro o SPF. Depois o DKIM. Depois o DMARC. Com esperas entre cada um. Esta ordem é inegociável, e errar nela é a razão mais comum pela qual novas implementações quebram a entrega.

Porque esta ordem importa

O DMARC verifica os resultados do SPF e do DKIM. Se adicionar o DMARC antes de estes dois estarem implementados e validados, todos os e-mails falham a autenticação. Com uma política de p=quarantine ou p=reject, o seu correio começa a ir para spam ou a ser rejeitado no momento em que o DMARC se propaga. Muitos fornecedores nem sequer lhe permitem adicionar um registo 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 cada registo se propagar, envie um e-mail de teste para um endereço Gmail que controle e verifique os cabeçalhos através de Mostrar original. Tanto o SPF como o DKIM devem mostrar PASS antes de adicionar o DMARC.

Onde adicionar registos SPF, DKIM e DMARC

Todos os três registos são adicionados como registos TXT nas definições de DNS do seu domínio, o mesmo local onde gere os registos A, registos MX e nameservers. Onde exatamente isso se encontra depende de quem está a gerir o seu DNS.

Hospedagens partilhadas (Bluehost, SiteGround, HostGator)

A maioria dos alojamentos partilhados inclui um Editor de Zona DNS no seu painel de controlo em Domínio ou Gestão de DNS. Procure uma opção para adicionar um registo TXT.

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

Se o seu alojamento e domínio forem separados, o seu DNS geralmente reside com o seu registador. Procure por Definições de DNS ou Gerir DNS no painel do seu domínio.

Cloudflare

Abra o painel Cloudflare, selecione o seu domínio, clique em DNS no menu esquerdo e adicione um novo registo TXT. Aqui está a vista do editor.

Vercel

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

Netlify

O DNS da Netlify encontra-se em Domínios no painel da sua equipa. Clique no domínio, depois em Configurar DNS Netlify se ainda não o fez, e depois adicione registos em Registos DNS.

Squarespace

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

WP Engine

O WP Engine não aloja o seu DNS por defeito, pelo que adicionará os registos SPF, DKIM e DMARC no registador que utilizar para o domínio (GoDaddy, Namecheap, Cloudflare, etc.). O que precisará do WP Engine é o valor correto para o seu include: SPF para que os seus servidores de correio possam enviar em nome do seu site. Encontre isto no Portal do Utilizador WP Engine, nas definições de DNS ou de correio do seu ambiente. O seu include SPF típico é mail1.wpengine.com. Adicione-o ao seu registo SPF existente juntamente com quaisquer outros remetentes, nunca como um segundo registo v=spf1.

Como testar SPF, DKIM e DMARC

Três formas fiáveis de verificar se todos os três registos estão a funcionar como esperado.

Gmail “Mostrar original”

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

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

Se algum destes mostrar FAIL ou NEUTRAL, avance para a secção de resoluçã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 todos os três registos sempre que envia um e-mail de teste, sem necessidade de uma ferramenta separada. Sinaliza registos em falta, múltiplos registos SPF, problemas de assinatura DKIM, falhas de alinhamento DMARC e problemas de registo PTR, tudo a partir do seu painel 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. Introduza o seu domínio e obterá um estado rápido de aprovação/rejeição para cada registo, além de diagnósticos para erros comuns como excesso de consultas DNS ou problemas de sintaxe.

Resolução de problemas comuns

Se os seus registos estiverem configurados, mas a autenticação ainda falhar, um destes 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 o seu e-mail com “550-5.7.26”

Sintoma. O Gmail devolve com uma rejeição SMTP 550-5.7.26. O texto completo geralmente lê 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 o seu domínio através do verificador no topo desta página, ou use o Verificador de Domínio do WP Mail SMTP. O resultado mostrará qual dos três registos está em falta ou a falhar.

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

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

Sintoma. O painel do seu fornecedor de SMTP mostra um aviso de que o seu registo SPF está em falta ou não os inclui.

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

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

Correção. Adicione o include: do fornecedor ao seu registo SPF existente. Por exemplo, um registo SPF que usa SendLayer mais Google Workspace leria v=spf1 include:sendlayer.net include:_spf.google.com ~all. Nunca crie um segundo registo 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 de alinhamento SPF. O seu domínio de endereço de retorno não corresponde ao domínio From: visível.

Diagnóstico. Olhe para o valor smtp.mailfrom nos cabeçalhos. Corresponde ao domínio em From:?

Correção. Altere o caminho de retorno do seu serviço de envio para o seu domínio (a maioria dos fornecedores oferece uma configuração de "caminho de retorno personalizado" ou "domínio de devolução"), ou confie no alinhamento DKIM, que é frequentemente mais fácil de configurar.

4. Assinatura DKIM em falta nos e-mails recebidos

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

Causa provável. O DKIM não está realmente configurado no lado do remetente, ou o seletor incorreto está a ser utilizado.

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

Correção. Verifique novamente se os registos CNAME ou TXT do DKIM existem exatamente como o seu fornecedor especificou. O nome do seletor no seu registo DNS tem de corresponder ao que o fornecedor está a assinar. Erros de digitação aqui são extremamente comuns.

5. SPF "permerror: demasiadas procuras DNS"

Sintoma. Os servidores de correio rejeitam as suas mensagens com um PERMERROR do SPF.

Causa provável. O seu registo SPF contém mais de 10 procuras DNS (o limite rígido de 10 do RFC 7208). Comum ao empilhar diretivas include: para múltiplos serviços.

Diagnóstico. Utilize uma ferramenta de "aplainamento" de SPF para contar as suas procuras. Cada include:, a, mx, ptr e exists: conta.

Correção. Remova os includes desnecessários ou utilize um serviço de "aplainamento" de SPF que resolva os includes em entradas de IP diretas. Guia completo no nosso guia de fusão de SPF.

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

Sintoma. PERMERROR ou NEUTRAL do SPF, apesar de ter um registo com aspeto válido.

Causa provável. Tem dois ou mais registos TXT do SPF. O RFC 7208 afirma que isto é inválido, e os recetores tratarão como se não existisse nenhum registo SPF.

Diagnóstico. Execute dig TXT oseudominio.com, ou utilize a procura SPF do MxToolbox. Se vir dois registos que começam com v=spf1, esse é o problema.

Correção. Combine as diretivas include: de ambos os registos num único registo. Veja o guia de fusão acima.

7. Registo DKIM demasiado longo para DNS

Sintoma. O seu fornecedor deu-lhe uma chave DKIM, mas o DNS não a aceita.

Causa provável. Registos TXT individuais têm um limite de 255 caracteres por string. Chaves DKIM de 2048 bits excedem isto e devem ser divididas em múltiplas strings entre aspas dentro do mesmo registo.

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 fornecedores de DNS modernos faz isto automaticamente. Alguns não. Veja a secção do comprimento da chave DKIM acima para o guia completo.

8. Falha de 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 etiqueta DKIM d=. Pelo menos um dos dois últimos deve corresponder ao primeiro.

Correção. Configure o seu serviço de envio para usar o seu domínio no return-path (para alinhamento SPF) ou na assinatura DKIM (para alinhamento DKIM). A maioria dos fornecedores usa o seu próprio domínio por defeito. Tem de optar pelo alinhamento.

9. p=reject do DMARC a bloquear os seus próprios e-mails legítimos

Sintoma. Os clientes deixam de receber os seus e-mails transacionais (redefinições de palavra-passe, recibos), mas os seus envios de teste funcionam bem.

Causa provável. Passou para p=reject demasiado depressa, antes de abranger todas as fontes de envio legítimas no seu SPF.

Diagnóstico. Verifique os seus relatórios agregados de DMARC. Mostram todos os remetentes que falharam sob o seu domínio. Os legítimos serão óbvios (o 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 em falta ao SPF. Espere 2 a 4 semanas até que os relatórios mostrem 0% de falhas de e-mail legítimo, depois reforce.

10. Registos adicionados mas não a propagar

Sintoma. Adicionou os registos, mas as ferramentas ainda dizem que estão em falta.

Causa provável. Cache DNS no seu registador, no seu resolvedor local ou no servidor recetor. Comum com alterações de TTL baixo após registos de TTL alto terem sido previamente cacheados.

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

Correção. Espere. A maior parte da propagação completa-se dentro de uma hora para SPF e até 24 horas para DMARC. Se após 48 horas ainda não vir nada, verifique novamente se o registo foi guardado corretamente no seu registador. Um erro comum são interfaces que necessitam de um passo de confirmação que falhou.

Notas específicas para WordPress

O WordPress tem um problema específico de e-mail. Por defeito, usa a função mail() do PHP, que envia mensagens sem qualquer autenticação. Os seus registos SPF, DKIM e DMARC podem estar perfeitamente configurados, mas se o WordPress estiver a enviar e-mails através da função mail() do PHP a partir do IP partilhado do seu alojamento web, e esse IP não estiver no seu registo SPF, todas as verificações de autenticação falham.

A solução é encaminhar todo o e-mail 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 com o seu domínio. Os recursos melhorados de entrega de e-mail do WP Mail SMTP incluem o Verificador de Domínio gratuito que sinaliza registos SPF, DKIM e DMARC em falta ou mal configurados diretamente no WordPress.

Se os seus e-mails do WordPress estiverem a ir para o spam, a causa é geralmente a autenticação em falta ou desalinhada. O diagnóstico completo encontra-se no nosso guia sobre porquê os e-mails do WordPress vão para o spam. Para a configuração, o nosso guia de validação de e-mail do WordPress percorre a verificação dos registos.

Corrija os Seus Emails do WordPress Agora

FAQs sobre SPF, DKIM e DMARC

Estas são as perguntas mais pesquisadas sobre autenticação de e-mail, organizadas das mais frequentes às mais técnicas. Cada resposta é autónoma.

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

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

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

Precisa de todos os três, SPF, DKIM e DMARC?

Sim. Desde fevereiro de 2024, o Gmail e o Yahoo exigem todos 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 falta de um dos três reduz a colocação na caixa de entrada.

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

Pode usar DMARC sem SPF ou DKIM?

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

Executar DMARC apenas com SPF significa que os e-mails encaminhados falham. Executá-lo apenas com DKIM significa que as mensagens modificadas em trânsito falham. Ambos em conjunto proporcionam uma autenticação fiável.

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

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

p=none é o modo de monitorização. Reporta falhas, mas não bloqueia nada, e é por onde todos os domínios devem começar. p=quarantine envia e-mails com falha para a pasta de spam. p=reject bloqueia completamente os e-mails com falha.

Mova de none para quarantine e depois para reject gradualmente, apenas depois de os seus relatórios confirmarem que nenhum e-mail legítimo está a falhar.

Em que ordem deve configurar SPF, DKIM e DMARC?

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

Adicione o SPF, aguarde a sua propagação, adicione o DKIM, verifique se ambos passam numa verificação Mostrar original do Gmail, e depois adicione o DMARC começando com p=none.

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

Utilize uma ferramenta de verificação (como a gratuita no topo desta página) que consulta os três registos para o seu domínio e reporta o seu estado.

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 que SPF, DKIM e DMARC mostram PASS.

O que é o alinhamento DMARC?

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

O alinhamento SPF requer que o domínio do caminho de retorno corresponda ao domínio From:. O alinhamento DKIM requer que a etiqueta d= da assinatura corresponda. A causa mais comum de falha do DMARC é o desalinhamento, não uma falha direta do 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 o seu e-mail porque o domínio remetente não está autenticado. O Gmail exige agora que todos os remetentes se autentiquem com SPF ou DKIM.

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

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

Significa que o seu e-mail foi devidamente autenticado. 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 o seu endereço visível From:.

Ter os três a passar é o resultado que pretende. Maximiza a colocação na caixa de entrada.

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

São necessários, mas não suficientes. A autenticação diz aos provedores de caixa de entrada que os 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 a reputação do remetente, a qualidade do conteúdo, as taxas de envolvimento, a higiene da lista e um registo PTR válido.

Configure os três primeiro, depois trate dos outros fatores de entregabilidade de e-mail.

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

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

Qual é o significado completo 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 formam o conjunto padrão para autenticar e-mails e proteger um domínio contra spoofing.

Em seguida, Verifique o Seu Registo PTR

SPF, DKIM e DMARC são três dos quatro registos DNS que importam para a entregabilidade de e-mail. O quarto é o seu registo PTR, a entrada DNS inversa que mapeia o seu IP de envio de volta para o seu domínio. Os fornecedores de caixas de correio verificam-no em cada ligação, e um PTR em falta ou genérico prejudicará a sua entregabilidade mesmo quando SPF, DKIM e DMARC passarem.

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

Corrija os Seus Emails do WordPress Agora

Pronto para corrigir os seus emails? Comece hoje mesmo com o melhor plugin SMTP para WordPress. Se não tem tempo para corrigir os seus emails, pode obter assistência completa de Configuração White Glove como compra adicional, e existe uma garantia de reembolso de 14 dias para todos os planos pagos.