DMARC falha mas SPF e DKIM passam: como encontrar a causa

Você abre um relatório DMARC ou o cabeçalho de uma mensagem e vê spf=pass e dkim=pass ao lado de dmarc=fail. Nada está quebrado do jeito que parece: as duas verificações passaram, só que não para o domínio que importa ao DMARC. Este guia é um roteiro de diagnóstico para essa situação exata. Ele supõe que você já sabe o que é alinhamento e quer descobrir qual das causas habituais é a sua, na ordem em que são mais prováveis.

A resposta curta#

O DMARC passa quando o SPF ou o DKIM passa e se alinha com o domínio do endereço From visível. "Passar" e "estar alinhado" são perguntas diferentes. O SPF é comparado com o domínio do Return-Path (remetente do envelope), e o DKIM é comparado com o domínio d= da assinatura. Se o seu serviço de e-mail assina com o domínio dele e envia os bounces pelo domínio dele, as duas verificações passam e nenhuma se alinha. A correção é quase sempre a mesma: configure um domínio de assinatura DKIM personalizado no seu próprio domínio e, se quiser que o SPF também se alinhe, um domínio de return-path personalizado. Verifique as tags de modo estrito, o encaminhamento e os subdomínios só depois disso. Para o conceito em si, veja a explicação de SPF, DKIM e DMARC.

Com o que cada verificação é comparada#

Toda mensagem carrega três domínios que importam, e o DMARC os alinha em pares. A maior parte da confusão desaparece quando você consegue dizer qual deles cada verificação usa.

Veja como é a falha clássica em uma mensagem recebida. O From é seu, as duas verificações passam, e os outros dois domínios pertencem ao remetente:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce.mail.vendor.example;
  dkim=pass header.d=mail.vendor.example;
  dmarc=fail header.from=yourdomain.com

O analisador de cabeçalhos de e-mail mostra os veredictos de SPF, DKIM e DMARC e os campos From e Return-Path. Leia você mesmo o valor d= da DKIM no cabeçalho DKIM-Signature. Se você só tem um relatório agregado, a mesma informação está em auth_results (resultados brutos e domínios) em contraste com policy_evaluated (o veredito alinhado). O guia de leitura de relatórios explica essa divisão.

O roteiro de decisão#

Percorra esta lista de cima para baixo e pare no primeiro passo que combinar. Cada passo é uma causa raiz diferente com uma correção diferente.

1. O DKIM passa, mas o d= é o domínio do remetente. Esta é a causa mais comum e a melhor correção. Ative a assinatura DKIM personalizada (às vezes chamada de domínio com marca ou domínio autenticado) no serviço de envio para que ele assine com d=yourdomain.com ou um subdomínio dele. O DKIM viaja com a mensagem, então continua se alinhando após o encaminhamento.
2. O SPF passa, mas o Return-Path é o domínio do remetente. O SPF só pode se alinhar se o remetente do envelope for o seu domínio. Configure um domínio de return-path (bounce) personalizado no serviço, em geral um subdomínio como bounce.yourdomain.com apontado para o provedor por CNAME ou por registros MX e TXT que eles fornecem. Adicionar o provedor ao seu próprio registro SPF não resolve isso: o SPF é verificado contra o domínio do Return-Path, que é o do provedor, então o seu registro nunca é consultado para essa mensagem.
3. Os dois são personalizados, mas o DMARC ainda falha. Olhe adkim e aspf no seu registro DMARC. Se qualquer um for s (strict), a correspondência precisa ser exata, então uma assinatura de mail.yourdomain.com não se alinha com um From yourdomain.com. Assine com o domínio exato do From ou remova a tag estrita.
4. Falha só para algumas origens ou só em alguns receptores. Suspeite de encaminhamento, uma lista de e-mail ou um gateway de segurança que reescreve mensagens. Veja a seção sobre encaminhamento abaixo.
5. Falha só em um subdomínio. Verifique se o subdomínio tem o seu próprio SPF e DKIM, e qual registro DMARC se aplica a ele. Veja a seção de subdomínios.
6. Nada passa. Isso não é alinhamento. O SPF ou o DKIM está ausente ou quebrado para essa origem, o que é um problema diferente e mais simples.

Relaxado versus estrito, na prática#

O padrão é relaxado nos dois. No alinhamento relaxado, os dois domínios só precisam compartilhar um domínio organizacional, então um Return-Path de bounce.yourdomain.com se alinha com um From de news.yourdomain.com. No estrito, eles precisam ser idênticos.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Deixe os dois em r, a menos que você tenha um motivo por escrito. O modo estrito raramente impede um ataque real que o relaxado permitiria, e é uma causa frequente de falha em e-mail legítimo de subdomínios. Um detalhe mudou no padrão atual: a RFC 9989 (maio de 2026) substitui a RFC 7489 e define o domínio organizacional por uma busca na árvore do DNS, e não por uma lista de sufixos públicos. Se você usa domínios incomuns com vários rótulos, verifique como os seus receptores a aplicam.

Por que o encaminhamento quebra uma verificação mas não a outra#

Quando uma mensagem é encaminhada, o servidor de encaminhamento a envia adiante a partir do seu próprio IP. O SPF é avaliado contra o IP de conexão, então o SPF falha ou deixa de se alinhar. É por isso que uma origem pode mostrar um DMARC saudável em um receptor e falhas em outro: as falhas são as cópias encaminhadas.

O DKIM em geral sobrevive ao encaminhamento, porque a assinatura vai dentro da mensagem. Ele quebra quando o encaminhador ou uma lista de e-mail altera o que foi assinado, por exemplo ao acrescentar um rodapé ou editar o assunto. É por isso que o conselho é sempre o mesmo: alinhe o DKIM para toda origem, para que o DMARC possa passar mesmo quando o SPF não puder.

Você não consegue corrigir totalmente o encaminhamento do seu lado. Pequenas falhas residuais que remontam a encaminhadores e listas são normais, o que é uma razão para julgar o progresso pela tendência e por origem, não por um dia ruim.

Divergências de subdomínio#

Um subdomínio não herda o registro SPF do domínio pai, e as chaves DKIM são procuradas sob cada seletor e domínio, então um subdomínio que envia e-mail precisa da sua própria autenticação. A política DMARC é diferente: se o subdomínio não publica nenhum registro DMARC próprio, os receptores encontram o do domínio pai, e a tag sp= do pai (se existir) define a política do subdomínio.

Duas verificações resolvem a maior parte dos problemas de subdomínio. Primeiro, confirme que o serviço de envio assina com um domínio que corresponde ao subdomínio do From, ou ao pai no modo relaxado. Segundo, se você definiu sp=reject no pai, confirme que todo subdomínio de envio está passando antes de contar com isso. O guia de subdomínio de envio explica como estruturar isso para que cada fluxo de e-mail fique isolado.

Encontrando rapidamente a origem com falha#

A parte cara de uma falha de alinhamento não é a correção, é descobrir qual origem precisa dela. Seus relatórios agrupam o e-mail por IP de envio, então uma origem que assina com o próprio domínio aparece como uma linha com baixa porcentagem de DMARC.

Os Relatórios DMARC da Qualisend mostram cada origem com porcentagens separadas de DMARC, DKIM e SPF, e sinalizam linhas abaixo de 100%. Uma origem que assina e devolve por domínios do próprio fornecedor mostra DMARC, DKIM e SPF baixos juntos, que é o padrão do passo 1 ou 2 acima. A página não mostra o domínio d= nem o Return-Path de cada linha, então você ainda pega uma mensagem dessa origem e lê os cabeçalhos para ver qual dos dois domínios está errado. Ela também reporta apenas o que os receptores devolvem, então um receptor que não envia relatórios agregados fica invisível nela.

Para uma primeira olhada sem conta, o analisador de relatórios DMARC gratuito lê um arquivo de relatório no seu navegador. Para testar um remetente de ponta a ponta, envie uma mensagem para o teste de entregabilidade de e-mail gratuito e leia os resultados de autenticação dele.

Um checklist por serviço#

Cada serviço de envio usa palavras próprias para as configurações, mas o trabalho é o mesmo, quatro itens. Verifique cada um na documentação do próprio serviço em vez de confiar em uma cola, porque menus e padrões mudam.

• Domínio DKIM personalizado. Procure "authenticate your domain", "branded sending domain" ou "DKIM". Publique as chaves que ele fornece. Um nome de seletor novo não entra em conflito com os que você já tem.
• Domínio de return-path personalizado. Procure "custom bounce domain", "return-path" ou "link branding". Muitas vezes é uma configuração separada do DKIM.
• Endereço From. Confirme que o From usa o seu domínio. Um From em um domínio de e-mail gratuito, enviado por um terceiro, não pode se alinhar com nada seu.
• Uma alteração por vez. Faça a alteração, envie um teste, leia o cabeçalho e depois verifique o próximo relatório. Várias alterações de uma vez tornam impossível ver qual funcionou.

Quando parar e quando se preocupar#

Você está pronto para pensar em aplicar a política quando toda origem legítima passa no DMARC por pelo menos uma verificação alinhada, e as falhas que restam pertencem a encaminhadores ou a e-mails que você não reconhece. Se você ainda está descobrindo como chegar lá, o guia de configuração do DMARC traz a ordem de implantação, e o guia de requisitos de remetente explica por que o DMARC alinhado agora importa para e-mail em massa.

O alinhamento diz aos receptores que o e-mail é realmente seu, mas não diz nada sobre a lista por trás dele. Quando todas as suas origens estiverem passando, confira alguns endereços com o verificador de e-mail gratuito, que testa sintaxe, registros MX e erros de digitação de um endereço por vez. Para uma lista inteira, o plano gratuito na página de preços dá 100 créditos que rodam a verificação completa, porque um domínio perfeitamente alinhado ainda precisa de uma lista saudável para chegar à caixa de entrada.