DMARC falha mas SPF e DKIM passam? A correção do alinhamento (2026)

Publicado 2026-07-08

Números a 2026-06-29 · metodologia v7. Dados agregados do censo de 261 milhões de domínios classificados. Veja como classificamos.

O DMARC precisa de mais do que um pass — o domínio que passou o SPF ou o DKIM tem de corresponder ao seu domínio do From. A maior parte do correio “SPF pass, DMARC fail” passou o SPF no domínio de devoluções do fornecedor, não no seu. Só 7,4% de 261.086.232 domínios classificados passam o SPF com alinhamento sob uma política DMARC com aplicação, segundo o censo do Defaults.Exposed (2026-06-29).

A correção é mais rápida do que a confusão sugere. Leia o cabeçalho Authentication-Results para ver que perna — SPF ou DKIM — está a passar no domínio errado; depois, ou ativa a assinatura DKIM com domínio próprio do seu serviço de envio (normalmente uns CNAMEs, e a correção que sobrevive ao reencaminhamento), ou define o return-path personalizado dele para que o SPF passe no seu domínio. Uma perna alinhada é tudo o que o DMARC precisa.

Como pode o DMARC falhar quando o SPF e o DKIM passam ambos?

Porque o DMARC nunca pergunta “o SPF passou?” Pergunta: o SPF ou o DKIM passaram para um domínio que corresponde ao endereço From que o seu destinatário vê? Essa condição extra chama-se alinhamento, e é todo o propósito do DMARC — sem ela, qualquer pessoa podia passar o SPF num domínio que possui enquanto exibe o seu no cabeçalho From.

Cada verificação autentica um domínio diferente:

Verificação	Domínio que realmente avalia	Onde o ver
SPF	O Return-Path (RFC5321.MailFrom, o endereço de devoluções/envelope-from) — não o cabeçalho From	`smtp.mailfrom=` no Authentication-Results
DKIM	O domínio na tag `d=` da assinatura — o que o assinador escolheu	`header.d=` no Authentication-Results
DMARC	O seu domínio do cabeçalho From — e exige que o domínio do SPF ou o `d=` do DKIM correspondam a ele	`header.from=` no Authentication-Results

É assim que as peças normalmente correm mal: a sua plataforma de newsletters ou CRM envia com um Return-Path como [email protected], o SPF é verificado contra vendor.com e passa, o DKIM passa com d=vendor.com — e o DMARC falha, porque nenhum dos domínios que passaram corresponde a yourcompany.com. Todas as verificações disseram a verdade; nenhuma delas autenticou você. Editar o seu próprio registo SPF não pode corrigir isto — ele nunca foi consultado. É a mesma armadilha coberta em SPF a falhar para as suas ferramentas SaaS.

O censo mostra quão poucos remetentes completam este último passo: 27.640.987 de 261.086.232 domínios classificados (10,59%) têm sequer uma política DMARC com aplicação, e só 7,4% passam o SPF com alinhamento sob uma. Entre os 77,5 milhões de domínios cujo SPF termina em softfail (~all), apenas 9,2% estão sob uma política DMARC com aplicação; entre os publicadores de hardfail (-all), 12.142.351 têm aplicação enquanto 42.514.532 não têm. A maioria dos domínios para em “o SPF passa” — o que, sem o DMARC a agir sobre isso, protege quase nada.

Como leio o Authentication-Results para ver que perna está desalinhada?

Envie a si próprio uma mensagem através do serviço que falha, abra o código-fonte em bruto e encontre o cabeçalho Authentication-Results. Um resultado desalinhado típico parece-se com isto:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

Leia-o em três comparações:

Perna SPF: o smtp.mailfrom= termina no seu domínio? Aqui é bounces.espmail.net — desalinhado.
Perna DKIM: o header.d= termina no seu domínio? Aqui é espmail.net — desalinhado.
Veredicto DMARC: header.from= é o domínio que o DMARC está a defender. Nenhuma perna correspondeu a ele, portanto dmarc=fail — mesmo com ambas as verificações individuais a dizer pass.

A perna que já envolve o seu próprio domínio (ou que pode passar a envolver) é a que deve corrigir. Só precisa de uma.

Qual é a diferença entre alinhamento relaxado e estrito?

O DMARC oferece dois modos de correspondência, definidos com as tags aspf (SPF) e adkim (DKIM) no seu registo DMARC:

Relaxado (r, a omissão): os dois domínios têm de partilhar o mesmo domínio organizacional — o domínio registável segundo a Public Suffix List. bounce.yourcompany.com alinha com yourcompany.com; o mesmo vale para um DKIM d=mail.yourcompany.com. É por isto que os return-paths personalizados de fornecedores e o DKIM personalizado, que vivem em subdomínios, funcionam.
Estrito (s): os domínios têm de corresponder exatamente, carácter a carácter. bounce.yourcompany.com deixa de alinhar com yourcompany.com.

Se o seu registo não menciona aspf nem adkim, está em modo relaxado — e quase de certeza quer ficar lá. O modo estrito não acrescenta segurança significativa à maioria dos remetentes e parte silenciosamente todos os remetentes de subdomínio legítimos que configurar. Se o DMARC está a falhar e o seu registo contém aspf=s ou adkim=s, isso sozinho pode ser o defeito.

Como corrijo o alinhamento do DMARC?

Execute a verificação gratuita em defaults.exposed antes de tocar no DNS. Mostra o seu registo e política DMARC, se o seu SPF e DKIM estão configurados para alinhar, e o que mais está partido — para corrigir a perna certa primeiro.
Teste cada serviço de envio e leia o seu Authentication-Results (como acima). Liste todas as origens — fornecedor de caixa de correio, ferramenta de newsletters, CRM, aplicação de faturação — e anote por origem se smtp.mailfrom e header.d são o seu domínio ou o do fornecedor.
Ative a assinatura DKIM com domínio próprio em cada fornecedor — a correção que dura. Todos os serviços de envio sérios oferecem “autenticação de domínio”: uns quantos registos CNAME que o deixam assinar como d=yourcompany.com (ou um subdomínio, que alinha em modo relaxado). O DKIM alinhado é normalmente a correção mais fácil e a única que sobrevive ao reencaminhamento, porque o reencaminhamento parte o SPF por conceção.
Para o alinhamento do SPF, ative o return-path personalizado do fornecedor (muitas vezes chamado domínio de devoluções personalizado) — tipicamente um CNAME como bounce.yourcompany.com a apontar para o fornecedor. O SPF passa então no seu domínio organizacional e alinha. Faça-o onde for oferecido, mas trate-o como a segunda perna, não como um substituto do DKIM alinhado.
Deixe o alinhamento em modo relaxado a menos que tenha uma razão específica e compreendida para aspf=s/adkim=s.
Volte a verificar, confirme ambas as pernas, e avance rumo à aplicação. Uma política DMARC de p=none reporta mas não bloqueia nada; quando os seus remetentes reais alinharem, o caminho completo para uma política que o protege está na página corrigir o DMARC, e passo a passos por fornecedor como DMARC na IONOS cobrem os cliques no painel de DNS.

Devo corrigir o alinhamento do SPF ou do DKIM?

Precisa de uma perna alinhada por origem de envio. Se só puder fazer uma, a escolha não é renhida:

Correção	O que envolve	Sobrevive ao reencaminhamento?
DKIM alinhado (assinatura com domínio próprio)	Uns quantos CNAMEs no painel de “autenticação de domínio” do fornecedor	Sim — a assinatura viaja com a mensagem
SPF alinhado (return-path/domínio de devoluções personalizado)	Um CNAME, onde o fornecedor o oferece	Não — o IP de qualquer reencaminhador substitui o do fornecedor

O caso especial que vale a pena conhecer: o Google Workspace e o Microsoft 365 assinam o seu correio com DKIM por omissão com os seus próprios domínios de recurso (gappssmtp.com, onmicrosoft.com) — portanto o DKIM mostra pass enquanto o DMARC continua a falhar. É a instância específica mais comum de todo este problema, e tem guia próprio: DKIM passa mas o DMARC continua a falhar: a armadilha da assinatura por omissão.

Perguntas frequentes

O SPF e o DKIM precisam ambos de alinhar para o DMARC passar? Não — um pass alinhado é suficiente. A boa prática é alinhar os dois na mesma, para que, quando o reencaminhamento partir a perna SPF, a perna DKIM continue a transportar o pass do DMARC. De 261.086.232 domínios classificados no censo de 2026-06-29, só 3,87% completam a tríade completa SPF + DMARC + DKIM.

O painel do meu ESP diz que o SPF e o DKIM estão “verified” — porque é que o DMARC continua a falhar? “Verified” normalmente significa que o envio do próprio fornecedor passa nos domínios do fornecedor. A menos que tenha completado os passos de domínio personalizado deles (CNAMEs de DKIM, return-path personalizado), o correio autentica-se como o fornecedor, não como você — e o DMARC compara contra o seu domínio do From.

Um registo SPF estrito -all chega sem alinhamento? Não. Um qualificador estrito reforça o veredicto do SPF sobre o domínio do Return-Path, mas o DMARC continua a precisar que esse domínio seja o seu. À data do censo de 2026-06-29, só 12.142.351 dos domínios que publicam -all estão sob uma política DMARC com aplicação — os outros 42.514.532 têm um registo estrito sobre o qual nenhuma política age.

Devo mudar para o alinhamento estrito (aspf=s/adkim=s) para mais segurança? Quase nunca. O alinhamento relaxado já exige o mesmo domínio registável, que um falsificador não controla. O modo estrito sobretudo parte os seus próprios remetentes de subdomínio — procure-o sempre que o alinhamento falhar inesperadamente.

O DMARC falha só em correio que os destinatários reencaminham — mesma correção? Isso é a perna SPF a morrer em trânsito: o servidor do reencaminhador não está no registo SPF de ninguém para o seu return-path. Não pode corrigir o SPF para correio reencaminhado; o DKIM alinhado é a resposta, já que a assinatura sobrevive intacta ao reencaminhamento. Detalhes em email reencaminhado falha o SPF.

Envie o relatório ao proprietário

Se está a corrigir isto para um cliente ou para o seu empregador, feche o ciclo com evidência. Volte a executar a verificação gratuita depois de os CNAMEs assentarem e reencaminhe o relatório classificado ao dono do negócio: datado, em linguagem simples, a mostrar SPF, DKIM e DMARC alinhados e a passar. É o comprovativo de que vão precisar na renovação do seguro cibernético e no próximo questionário de segurança de fornecedor — prova de uma configuração a funcionar, não apenas “adicionei uns registos DNS”.

Verifique o seu domínio → · DKIM passa mas o DMARC continua a falhar → · Corrigir o DMARC → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.