GuiasAutenticação

DMARC falha embora SPF e DKIM passem

As duas verificações dizem pass, e o DMARC ainda diz fail. A causa é um domínio que não corresponde ao seu endereço From. Um email de teste mostra qual é, e a correção é uma configuração em quem envia os emails.

Atualizado em 5 de outubro de 20269 min de leitura

Em resumo

O DMARC só passa se o SPF ou o DKIM passar para o domínio do seu endereço From. Um pass para o domínio do seu provedor não conta.
Abra uma mensagem enviada no Gmail com Show original (Mostrar original) e compare smtp.mailfrom, header.i e header.from no cabeçalho Authentication-Results.
Corrija primeiro o DKIM: ative a assinatura com o seu próprio domínio em cada serviço que envia por você. Uma assinatura DKIM sobrevive ao encaminhamento, o SPF não.
Um subdomínio é próximo o bastante por padrão. Se o seu registro DMARC contém adkim=s ou aspf=s, não é.
O aquecimento não corrige o alinhamento. Os emails de aquecimento são enviados pela sua caixa de email e falham junto com ela.

O DMARC não pergunta se o SPF e o DKIM passaram. Ele pergunta se um deles passou para o domínio do seu endereço From. Se o SPF passou para o domínio de devolução do seu provedor e o DKIM passou para o domínio de assinatura do seu provedor, as duas linhas dizem “pass” e o DMARC ainda diz “fail”. A correção fica em quem envia: faça o serviço assinar com o seu domínio ou use um endereço de devolução no seu domínio. Um dos dois basta.

O nome dessa correspondência é alinhamento. É a parte do DMARC que um verificador de DNS não consegue ver. Só uma mensagem realmente enviada mostra se os seus emails estão alinhados. Esta página mostra como ler uma.

Três domínios viajam com cada email

Um email leva o seu domínio em até três lugares. Cada verificação olha para um deles.

Uma flâmula azul-marinho com um emblema de envelope, um malote com uma etiqueta de latão e uma carta com lacre de cera, lado a lado em um cais; o lacre repete o emblema da flâmula, a etiqueta não — A flâmula é a linha From, a etiqueta do malote é o Return-Path, o lacre de cera é a assinatura DKIM. O DMARC quer que a etiqueta ou o lacre corresponda à flâmula.

Onde	Também chamado de	Quem olha para ele
A linha From que o seu leitor vê	Cabeçalho From, `header.from`	DMARC. É a referência para os outros dois.
O Return-Path	Remetente do envelope (envelope sender), MAIL FROM, endereço de devolução, `smtp.mailfrom`	SPF. Verifica se o servidor de envio tem permissão para usar este domínio.
O valor `d=` no cabeçalho DKIM-Signature	Domínio de assinatura, `header.d` ou `header.i`	DKIM. Verifica se a assinatura deste domínio é válida.

O SPF (RFC 7208) e o DKIM (RFC 6376) respondem cada um a uma pergunta restrita, e nenhuma das duas menciona a sua linha From. Um serviço de newsletter pode passar no SPF com o próprio domínio de devolução e assinar com a própria chave, e a mensagem ainda pode alegar que vem de você. O DMARC fecha essa brecha. A RFC 9989, a norma do DMARC desde maio de 2026, só aceita um resultado se o domínio por trás dele corresponder ao domínio From, e dá o motivo, no caso do DKIM, em uma frase:

O DMARC exige que o alinhamento de identificadores seja aplicado ao identificador autenticado pelo DKIM porque uma mensagem pode trazer uma assinatura válida de qualquer domínio, até mesmo de um usado por um agente mal-intencionado.

O mesmo vale para o SPF, já que qualquer pessoa pode publicar um registro SPF para um domínio que possui. Então a regra é: o DMARC passa se o SPF passa e o domínio dele está alinhado, ou se o DKIM passa e o domínio dele está alinhado.

Encontre a divergência em uma mensagem real

Você precisa de um email enviado do jeito que os seus emails de verdade são enviados e de um endereço do Gmail para recebê-lo.

Envie uma mensagem da caixa de email ou da ferramenta em questão para um endereço do Gmail que você consiga abrir.
Abra a mensagem no Gmail em um computador. Ao lado de Reply (Responder), clique em More (Mais) e depois em Show original (Mostrar original). O Google descreve os mesmos passos em Rastrear um email com o cabeçalho completo.
Encontre o cabeçalho Authentication-Results, em que o servidor de recebimento anota o resultado das suas verificações (RFC 8601). Compare três valores: o domínio depois de smtp.mailfrom=, o domínio depois de header.i=@ (alguns servidores de recebimento escrevem header.d=) e o domínio depois de header.from=. Como ler os cabeçalhos de um email percorre essa linha passo a passo.

Este é o padrão de uma mensagem que passa no SPF e no DKIM e falha no DMARC. O cabeçalho está abreviado e usa domínios de exemplo:

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

Leia de baixo para cima. O domínio From é example.com. O SPF passou, mas para send.vendor-mail.example. O DKIM passou, mas a assinatura pertence a vendor-mail.example. Nenhum dos dois é example.com, então nada responde pelo nome que aparece na linha From.

Depois que o serviço é configurado para assinar com o seu domínio, a mesma mensagem fica assim:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

O SPF continua apontando para o fornecedor. Não há problema. O DKIM agora corresponde, e um pass alinhado é tudo de que o DMARC precisa.

Quão próximo é o bastante: alinhamento relaxado e estrito

Os dois domínios não precisam ser idênticos. Por padrão, o alinhamento é relaxado (relaxed): basta que os dois pertençam ao mesmo domínio registrado, que a norma chama de domínio organizacional. O alinhamento estrito (strict) exige correspondência exata. Você escolhe com as tags adkim, para o DKIM, e aspf, para o SPF, no seu registro DMARC.

SPF ou DKIM passou para	Domínio From	Relaxado (padrão)	Estrito
`example.com`	`example.com`	Alinhado	Alinhado
`mail.example.com`	`example.com`	Alinhado	Não alinhado
`example.com`	`news.example.com`	Alinhado	Não alinhado
`vendor-mail.example`	`example.com`	Não alinhado	Não alinhado

A norma observa que “quase todos os proprietários de domínio consideraram o alinhamento relaxado suficiente para atender às suas necessidades”. Mesmo assim, confira o seu próprio registro. O registro de exemplo no topo da página Configurar o DMARC do Google termina em adkim=s; aspf=s, então um registro copiado de lá é estrito. Se o seu tem essas duas tags e uma ferramenta envia de um subdomínio, remova-as. O próprio Google avisa nessa página que o alinhamento estrito “pode fazer com que mensagens de subdomínios associados sejam rejeitadas ou enviadas para o spam”.

De onde a divergência costuma vir

Um serviço que envia dos próprios servidores

Plataformas de newsletter, CRMs, ferramentas de faturamento e centrais de atendimento enviam os seus emails a partir da infraestrutura delas. Até você conectar o seu domínio, elas normalmente usam um endereço de devolução no domínio delas e assinam com a própria chave. A documentação da Amazon diz claramente por que o alinhamento de SPF é raro aqui: o Return-Path “é usado para devoluções e denúncias que o provedor (SES) acompanha usando um endereço que pertence a ele” (Amazon SES). A configuração que resolve isso tem um nome diferente em cada serviço e termina em alguns registros DNS do seu lado.

Serviço	Antes de você conectar o seu domínio	A configuração a procurar
Twilio SendGrid	O email aparece como enviado “via sendgrid.net”.	Domain authentication (autenticação de domínio): registros CNAME para um subdomínio de devolução e duas chaves DKIM.
Amazon SES	O Return-Path é um subdomínio de `amazonses.com`.	Easy DKIM para a assinatura e um custom MAIL FROM domain (domínio MAIL FROM personalizado) para o SPF.
Mailchimp	O domínio está verificado, mas não autenticado.	Email domain authentication (autenticação do domínio de email): dois registros CNAME para o DKIM.

Estas são as descrições dos próprios fornecedores em outubro de 2026. Outros serviços funcionam de forma parecida. Procure na ajuda deles por “authenticate domain”, “custom DKIM” ou “branded sending domain”.

Seu provedor de email assina com o próprio domínio, ou não assina

Com uma caixa de email no seu próprio domínio, o Return-Path normalmente é o seu próprio endereço, então o SPF fica alinhado assim que o seu registro SPF inclui o provedor. O valor depois de smtp.mailfrom= mostra isso. O DKIM é a parte que você precisa ativar.

Google Workspace. Até você ativar o DKIM para o seu domínio, o Google vinha assinando com um dos próprios domínios. Uma versão anterior da página de ajuda do Google dizia que o Gmail então assina “com esta chave de domínio DKIM padrão: d=*.gappssmtp.com”. A página atual não cita mais o domínio, então confira o seu próprio cabeçalho: um header.i que termina em gappssmtp.com significa que a sua chave não está ativa. Gere a chave no Admin console em Apps, Google Workspace, Gmail, Authenticate email (autenticar email), adicione o registro TXT que ele mostra e depois clique em Start authentication (iniciar autenticação), como descrito em Configurar o DKIM.
Microsoft 365. A documentação da Microsoft, atualizada em agosto de 2026, afirma: “Atualmente, nenhuma assinatura DKIM é feita nos emails de saída de domínios personalizados”. Você publica dois registros CNAME e ativa a assinatura no portal do Defender (Como usar o DKIM para emails no seu domínio personalizado).

O registro que você adiciona para uma chave DKIM fica sempre abaixo de _domainkey, com um nome que o provedor escolhe. No Google Workspace, ele é assim, com a chave abreviada:

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Uma ferramenta que se conecta à sua caixa de email e envia por ela não acrescenta nenhuma assinatura própria. Os emails de uma ferramenta assim são idênticos aos que você escreve à mão, então a correção fica no provedor de email, e não na ferramenta.

A mensagem foi encaminhada

Quando um destinatário encaminha o seu email automaticamente, ele chega de um servidor que o seu registro SPF não inclui. O SPF falha ou passa para o domínio de quem encaminhou. Uma assinatura DKIM sobrevive ao trajeto desde que ninguém altere a mensagem. Listas de discussão que acrescentam um rodapé ou uma marca no assunto também quebram a assinatura. Você não consegue corrigir isso do seu lado. As perguntas frequentes para remetentes do Google dizem que, no Gmail, “o alinhamento DMARC não é exigido para mensagens encaminhadas ou de listas de discussão”. É o motivo para ter o DKIM alinhado e não depender só do SPF.

Uma carta lacrada passa de um barco de correio para outro; cada barco tem o próprio malote com etiqueta, e o lacre de cera da carta está intacto — O encaminhamento troca o malote e a etiqueta. O lacre da carta continua intacto.

Os emails não são seus

Se os seus relatórios DMARC mostram falhas vindas de servidores que você nunca usou, alguém pode estar enviando com o seu endereço. Essas mensagens devem mesmo falhar. Não há nada a corrigir, e elas são o argumento para uma política mais rígida depois.

Corrija primeiro o DKIM, depois o SPF

Qualquer um dos dois garante um pass. Vale mais ter o DKIM, porque ele viaja com a mensagem. As boas práticas do M3AAWG colocam isso como regra: “Assine todos os emails de saída com uma chave DKIM alinhada ao domínio do cabeçalho RFC5322.From.” A RFC 9989 recomenda usar os dois.

Liste tudo o que envia em nome do seu domínio. Caixas de email, a ferramenta de newsletter, o CRM, as faturas, o formulário de contato do seu site. Os seus relatórios DMARC apontam os que você esqueceu.
Teste cada um com a verificação de cabeçalho acima e anote qual dos dois domínios não é o seu.
Ative a assinatura com o seu domínio onde header.i mostrar outro nome e publique os registros que o serviço fornece. Escolha uma chave de 2048 bits se o seu provedor de DNS aceitar. O Gmail exige pelo menos 1024 bits e recomenda 2048.
Defina um domínio de devolução personalizado onde o serviço oferecer, em um subdomínio como bounce.example.com. Isso alinha o SPF também.
Envie o teste de novo e procure dmarc=pass. Alterações de DNS podem demorar. O Google dá até 48 horas para uma nova chave DKIM começar a funcionar.

O que não funciona é adicionar o fornecedor aos seus próprios registros. Um include: do fornecedor no seu registro SPF não muda nada se o Return-Path está no domínio do fornecedor, porque o SPF consulta o registro desse domínio, e não o seu. Um registro DMARC também não pode listar terceiros de confiança. A norma diz que não existe “nenhum mecanismo amplamente aceito” para isso.

Se o cabeçalho mostra dmarc=pass e a mensagem ainda cai no spam, a autenticação não é mais a causa. SPF, DKIM e DMARC passam, mas o email ainda cai no spam continua a partir daí.

O que um DMARC que falha custa enquanto a sua política é p=none

Com p=none, você pede aos servidores de recebimento que não tomem nenhuma medida em caso de falha, então nada é rejeitado por causa da sua política. Mesmo assim, isso pesa contra você de duas maneiras.

Regras para remetentes em massa. O Gmail, o Yahoo e o Outlook.com exigem emails alinhados dos remetentes em massa, o que, no Gmail e no Outlook.com, significa a partir de 5.000 mensagens por dia. As perguntas frequentes para remetentes do Google listam o erro temporário 4.7.32 para emails cujo cabeçalho From “não está alinhado com o domínio organizacional autenticado por SPF nem com o autenticado por DKIM” e apontam como consequência “códigos de falha temporária ou permanente, ou envio para a pasta de spam”.
Isso bloqueia o próximo passo. Assim que você passa para p=quarantine ou p=reject, toda mensagem sua que não esteja alinhada deve ser tratada como spam ou recusada. No Gmail, a devolução diz “Unauthenticated email from domain-name is not accepted due to domain's DMARC policy”, ou seja, o email não autenticado é recusado por causa da política DMARC do domínio. É o erro 5.7.26 (Resolver problemas de DMARC).

Se você não tem nenhum registro DMARC, comece pelo registro a adicionar. Ele também ativa os relatórios que mostram o alinhamento de todos os seus remetentes de uma vez.

O que o aquecimento pode e não pode fazer aqui

Um aquecimento não corrige o alinhamento. O WarmupBay se conecta à sua caixa de email e envia a partir dela, então os emails de aquecimento são enviados e assinados pelo seu provedor exatamente como os emails que você mesmo escreve. Se a sua caixa de email falha no DMARC, eles falham junto. Corrija os registros primeiro.

O WarmupBay ajuda na parte de antes e na de depois. Quando você conecta uma caixa de email, ele verifica SPF, DKIM e DMARC do domínio e para o aquecimento se eles ainda estiverem faltando depois de 72 horas. Quando estão no lugar, a sua caixa de email troca alguns emails por dia com outras em uma rede compartilhada, e o painel mostra onde eles chegaram: caixa de entrada, uma aba do Gmail ou spam, separadamente para o Google e para outros provedores. Ele não testa emails da sua ferramenta de newsletter ou do CRM, porque esses nunca passam pela sua caixa de email, e ainda não consegue conectar caixas de email do Microsoft 365 ou do Outlook.com. É grátis para 10 emails de aquecimento por dia. Conecte sua caixa de email quando o cabeçalho mostrar dmarc=pass.

Perguntas frequentes

O SPF passa e está alinhado, o DKIM não está alinhado. Isso basta?

Para o DMARC, sim. Um pass alinhado basta. Deixa de bastar quando um destinatário encaminha seu email, porque o SPF então não corresponde mais. O Google também escreve nas perguntas frequentes para remetentes que o alinhamento tanto com o SPF quanto com o DKIM provavelmente se tornará um requisito, então configure o DKIM para o seu domínio de qualquer forma.

Por que o DMARC falha para alguns destinatários e passa para outros?

Porque os emails chegam a eles por caminhos diferentes ou de remetentes diferentes. Um destinatário que encaminha para outra caixa de email, ou uma lista de discussão, muda o que o SPF e às vezes o DKIM enxergam. Também pode ser um entre vários serviços de envio que ainda não foi configurado. Os relatórios agregados listam os resultados por servidor de envio e mostram qual é o caso.

O endereço Reply-To influencia o DMARC?

Não. O DMARC usa apenas o domínio do cabeçalho From. O endereço Reply-To, o nome de exibição e o cabeçalho Sender não fazem parte da verificação.

Como vejo problemas de alinhamento sem abrir cabeçalhos?

Nos relatórios agregados DMARC. Cada registro tem um bloco policy_evaluated com um resultado dkim e um spf, que são os resultados depois do teste de alinhamento. O bloco auth_results, logo abaixo, mostra os resultados brutos e os domínios a que se referem. Um pass bruto ao lado de um fail avaliado é exatamente o caso desta página. Você recebe os relatórios adicionando um endereço rua ao seu registro DMARC.

O cabeçalho diz dkim=fail ou dkim=neutral. É o mesmo problema?

Não. Nesse caso, a própria assinatura não foi validada, o que é outra falha. Se o texto diz body hash did not verify, a página de solução de problemas do Google aponta a causa: a mensagem foi alterada depois de assinada, por exemplo por um gateway que acrescenta um rodapé. O alinhamento trata de uma assinatura que é válida, mas pertence a outro domínio.

Preciso de uma chave DKIM separada para cada serviço que envia por mim?

Na prática, sim. Cada serviço assina com a própria chave e a publica sob o próprio nome de seletor abaixo de _domainkey no seu domínio, então várias chaves ficam lado a lado sem conflito. É diferente do SPF, em que um domínio só pode ter um registro.