Por que o seu email falha no DMARC quando o SPF passa?
Você encontrou um email na pasta de spam e abriu o código-fonte para ver o que deu errado. Uma linha diz spf=pass. A linha logo abaixo diz dmarc=fail. A mesma mensagem. Duas respostas opostas.
As duas respostas são verdadeiras, e seus registros provavelmente estão bem. O SPF e o DMARC fazem perguntas diferentes. O SPF pergunta: este computador tinha permissão para enviar este email? O DMARC pergunta: o remetente que passou no teste carrega o seu domínio, aquele da linha From que as pessoas veem? Na maioria das ferramentas de envio, não carrega. Esse desencontro é o problema inteiro, e ele tem nome: alinhamento. A causa mais comum é uma plataforma de envio que despacha emails pelo domínio dela. A checagem mais rápida fica em duas linhas dos cabeçalhos da mensagem, e este artigo percorre as duas.
O que faz o SPF passar e o que faz o DMARC passar no email
Todo email tem dois endereços de remetente. A linha From é a que as pessoas veem. A outra fica escondida dentro da mensagem, e os servidores de email a usam para repassar a mensagem adiante. Esse endereço oculto é o envelope. Pense numa carta de verdade: o nome no topo da página é a linha From, o endereço do lado de fora é o envelope.
O SPF funciona como uma lista de convidados. Seu registro DNS lista os computadores autorizados a enviar emails em nome de um domínio. O receptor confere o computador remetente contra a lista que pertence ao domínio do envelope. Estar na lista significa spf=pass. O SPF nunca olha para a linha From.
O DMARC funciona como uma checagem de identidade. Ele pergunta: o domínio que passou no SPF, ou o domínio que assinou a mensagem com DKIM, combina com o domínio da linha From? Essa combinação se chama alinhamento. Uma combinação, de qualquer um dos caminhos, basta para passar.
Aqui estão os cabeçalhos de uma mensagem que falha em ambos os caminhos, reduzidos às linhas que importam:
From: Ana <ana@example.com>
Return-Path: <bounces+7c2f-jane=example.net@mailpilot.example>
DKIM-Signature: v=1; a=rsa-sha256; d=mailpilot.example; s=s1; ...
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of bounces+7c2f@mailpilot.example
designates 198.51.100.7 as permitted sender)
dkim=pass header.i=@mailpilot.example
dmarc=fail (p=NONE dis=NONE) header.from=example.comLeia do jeito que o receptor leu. O SPF passou, para mailpilot.example. O DKIM passou, também para mailpilot.example. A linha From diz example.com. Nenhuma das duas verificações aprovadas nomeia esse domínio. Ou seja, a mensagem não tem prova de que vem do domínio que ela alega.
Se o SPF em si está falhando, com softfail, permerror ou limite de lookups, a reparação é outra, e está coberta no post sobre falhas de SPF.
Faça isto: antes de tocar em qualquer DNS, abra uma mensagem que falhou e encontre o domínio dentro da linha spf=pass dela. Se esse domínio não é seu, o problema é de alinhamento, não de registro.
As três causas, ranqueadas
Causa um: sua plataforma envia pelo domínio de bounce dela
A resposta mais comum de longe. Todo ESP, ferramenta de faturamento, helpdesk e plataforma de cursos envia pelos equipamentos dela no começo. Com esses padrões, o envelope e a assinatura DKIM carregam o domínio da ferramenta, não o seu. O SPF verifica o domínio da ferramenta e passa. O DMARC verifica o seu domínio do From e falha.
O Gmail às vezes mostra esse mesmo problema ali na caixa de entrada: uma pequena linha cinza embaixo do seu nome que diz via mailpilot.example. Mesma causa raiz, dois sintomas. O post sobre o “via” no email cobre o lado da exibição.
A pista: o domínio depois de domain of na linha spf=pass pertence à sua plataforma, e você nunca publicou registros DNS para ele.
O que fazer: ative o custom sending domain da plataforma, mostrado na seção de correção abaixo.
Causa dois: a assinatura DKIM do email não salva a mensagem
Quando o SPF não alinha, o DKIM é o único caminho restante que pode fazer o DMARC passar. Três coisas quebram esse caminho. A assinatura não existe de jeito nenhum, e o resultado é dkim=none. A assinatura existe mas falha, dkim=fail, geralmente porque um registro DNS sumiu ou a plataforma trocou a chave de assinatura. Ou a assinatura passa, mas para o domínio da plataforma, como a linha d=mailpilot.example acima. Passar para o domínio de outra pessoa não ajuda você.
Essa causa costuma chegar devagar. Os registros ficaram bem por um ano. Aí uma migração de DNS derrubou um registro, o último caminho funcional apagou, e o DMARC começou a falhar. Nenhum erro em lugar nenhum.
A pista: dkim=none, dkim=fail, ou um dkim=pass aprovado cujo domínio do header.i= não é o seu domínio do From.
O que fazer: republique ou complete os registros DKIM do seu domínio na plataforma. O guia de configuração do DKIM tem os passos.
Causa três: um encaminhador ou uma lista reenviou o email
Às vezes a sua configuração está boa e o último salto quebrou tudo. Um encaminhador ou uma lista de discussão pega a sua mensagem e a envia de novo com o envelope dele. O SPF então verifica o domínio do encaminhador, e pode passar para ele. Listas de discussão também adicionam um rodapé ao corpo e mudam a linha de assunto, o que quebra a assinatura DKIM, porque a assinatura cobre as palavras exatas da mensagem. A cópia encaminhada falha no DMARC. A cópia na sua própria pasta de enviados passou.
A pista: as falhas aparecem em um destinatário, uma empresa ou uma lista, enquanto todo o resto recebe seus emails normalmente. O domínio do spf=pass nomeia o encaminhador, muitas vezes o próprio empregador do destinatário.
O que fazer: confira se os seus próprios cabeçalhos alinham, e mantenha sua assinatura DKIM viva, porque esse é o caminho que o encaminhamento quebra. O salto do encaminhador é problema dele consertar.
Alinhamento de SPF ou de DKIM: qual caminho do email falhou?
O bloco Authentication-Results nomeia os três domínios de que você precisa. Compare smtp.mailfrom com header.from primeiro. Quando o domínio do mailfrom combina com o seu domínio do From, o SPF alinhou, e um dmarc=fail ao lado disso aponta para o lado do DKIM, ou para o modo strict, mais abaixo.
Uma configuração muda o que conta como correspondência. Por padrão, os dois caminhos usam alinhamento relaxed: os dois domínios só precisam da mesma parte principal. em892.example.com combina com example.com. Um registro pode exigir correspondências exatas em vez disso:
v=DMARC1; p=quarantine; aspf=s; adkim=s; rua=mailto:dmarc@example.comCom aspf=s, um email de billing.example.com com From: ana@example.com passa no SPF e mesmo assim falha no alinhamento. O modo strict é raro, e a maioria das pessoas que o tem o herdou. Se seus relatórios mostram falhas para emails que parecem bem, confira o registro antes de culpar o email.
Faça isto: leia smtp.mailfrom e header.from primeiro. Eles resolvem o alinhamento do SPF num relance. Depois leia o header.i=, ou o d= na assinatura, para o lado do DKIM.
O que o p=quarantine faz quando o DMARC do email falha
A falha e o que acontece depois são duas coisas separadas. A tag p= no seu registro DMARC diz aos receptores o que fazer com emails que falham. none significa coletar relatórios, não mudar nada. quarantine significa colocar na pasta de spam. reject significa recusar na porta. Um registro também pode começar devagar com pct=, colocando em quarentena apenas 10% das falhas no começo.
O cabeçalho mostra qual regra o receptor aplicou. dmarc=fail (p=NONE ...) significa que seu registro diz none, então a mensagem foi pontuada e reportada, não jogada no lixo pelo DMARC em si. Sair do none rumo a regras mais fortes é uma jornada à parte, e o post sobre DMARC none a percorre.
Faça isto: veja o que seu registro realmente diz antes de presumir o pior. Uma falha sob p=none é um item de relatório, não um descarte no lixo.
Como conferir o alinhamento de DMARC, SPF e DKIM no email
Cole o código-fonte bruto de uma mensagem que falhou no analisador de cabeçalhos gratuito. Ele coloca os domínios do envelope, da assinatura e do From lado a lado, então a comparação leva segundos. Duas checagens a mais completam o trabalho. O gerador de DMARC mostra o que seu registro diz hoje, incluindo o modo de alinhamento. O email health check lê seus registros DNS ativos do jeito que um receptor lê, e pega um registro faltando que o painel da plataforma ainda chama de verificado.
Faça isto: rode o analisador em uma mensagem primeiro, depois a checagem de saúde no domínio. A mensagem diz qual caminho falhou. O domínio diz por quê.
Falhas de DMARC em emails pelo Google Workspace e Office 365
Cada suíte tem a sua versão deste problema.
No Google Workspace, emails enviados pela própria suíte alinham de fábrica: o envelope carrega o seu domínio. As falhas vêm das bordas: um endereço From num domínio nunca adicionado e verificado no painel de administração, uma ferramenta de workflow retransmitindo pelo Gmail com o envelope dela, um domínio alias com registros no domínio principal mas nenhum próprio.
No Office 365, o DKIM de um domínio customizado fica desligado até alguém ligar, o que surpreende quase todo mundo. Até lá seus emails não carregam assinatura, dkim=none, ou são assinados pelo domínio padrão onmicrosoft.com. O SPF via Microsoft ainda pode carregar a mensagem. Mas no momento em que o email passa por um conector de terceiros, o segundo caminho ausente vira dmarc=fail.
Faça isto: no admin center do 365, abra o DKIM do seu domínio customizado e ative, publicando os dois registros CNAME que ele pede. No Workspace, garanta que todo domínio que aparece num endereço From em qualquer ponto do seu stack está adicionado, verificado e autenticado.
O que uma falha de DMARC custa para a entregabilidade dos seus emails
Sob p=none, uma falha não filtra emails por si só, mas ainda custa caro. O Gmail e o Yahoo exigem DMARC publicado de remetentes de alto volume desde fevereiro de 2024, e o email que falha nele é exatamente o email que os filtros deles desconfiam, então ele pode afundar rumo ao spam antes que a sua política diga qualquer coisa. As regras completas estão no post de requisitos para remetentes. Email desalinhado também parece spoofing, e spoofing é onde começa toda a história de queda no spam.
Faça isto: trate cada veredito de falha como informação gratuita dos receptores para quem você envia. Conserte o alinhamento, depois deixe os relatórios confirmarem.
A correção
A reparação é a mesma em toda plataforma, sob nomes diferentes. A Mailchimp chama de authenticated domain. A SendGrid chama de sending domain authentication. A Amazon SES chama de custom MAIL FROM domain. Ative o recurso para o domínio do seu endereço From, publique todos os registros que ele fornecer, o subdomínio de return path e os registros DKIM juntos, e espere a propagação do DNS. Meia configuração funciona bem até a metade alinhada quebrar, então publique o conjunto inteiro. O guia de configuração do DMARC tem os passos, e o post sobre o “via” no email mostra os formatos dos registros.
Os cabeçalhos de uma mensagem corrigida ficam assim:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of bounces+7c2f@em892.example.com
designates 198.51.100.7 as permitted sender)
dkim=pass header.i=@example.com
dmarc=pass (p=NONE dis=NONE) header.from=example.comO envelope mudou para em892.example.com. A assinatura mudou para example.com. Os dois caminhos alinham. O DMARC passa.
Faça isto: depois da propagação do DNS, envie um teste novo para um endereço real e leia os cabeçalhos dele no analisador antes de declarar resolvido.
O que uma checagem única não enxerga
Alinhamento é um estado, não um conserto único, e estados desandam. Uma plataforma troca as chaves de assinatura e os registros antigos param de funcionar. Uma migração de DNS derruba o registro do envelope em silêncio. Uma ferramenta nova entra no seu stack e começa a enviar com os padrões dela, falhando no DMARC desde o primeiro dia. Cada uma dessas vira o pass de hoje de volta para dmarc=fail, sem nenhum erro em lugar nenhum. O primeiro sinal costuma ser email caindo no spam, semanas depois.
Essa é a distância entre checar e vigiar. O LitInboxes reverifica seus registros SPF, DKIM e DMARC a cada seis horas. Ele guarda histórico com data, então “o alinhamento quebrou no mês passado” vira “o registro DKIM quebrou no dia 14”. Ele envia um alerta no momento em que um registro muda. Alertas por email estão em todos os planos. Alertas por Slack, Discord e webhook estão no Pro. Um painel cobre o domínio de cada cliente para agências e consultores. Se quiser ver antes, abra a demonstração ao vivo.
O checklist
- Abra uma mensagem que falhou e encontre o Authentication-Results dela.
- Encontre o domínio dentro do
spf=pass. Não é o seu domínio? Essa é a falha. - Leia o
dkim=e od=na assinatura. Quando o SPF não alinha, esse caminho precisa passar e alinhar. - Compare
smtp.mailfromcomheader.frompara ver qual alinhamento errou. - Confira a tag
p=no seu registro DMARC para saber se as falhas são apenas reportadas ou de fato filtradas. - Ative o custom sending domain da plataforma e publique o conjunto completo de registros.
- Depois da propagação do DNS, confira uma mensagem nova com o analisador de cabeçalhos e o email health check.
- Coloque os registros num ciclo de vigilância, semanal na mão ou com monitoramento contínuo. Trocas de chave e migrações de DNS quebram o alinhamento em silêncio.
Corrigir falha de DMARC no email quando o SPF passa
- Leia o Authentication-Results de uma mensagem que falhouAbra a mensagem marcada como spam, escolha Mostrar original ou Ver código-fonte da mensagem e localize o bloco Authentication-Results. Procure o domínio dentro de spf=pass, depois de "domain of". Esse é o domínio que o SPF realmente verificou. Normalmente é o da plataforma, não o seu.
- Compare com o domínio no campo FromSe o domínio do spf=pass pertence à sua plataforma de envio, e o seu endereço From usa o seu próprio domínio, a falha está no alinhamento do SPF. O registro SPF em si está funcionando bem.
- Verifique a linha DKIM para o segundo caminhoLeia o dkim= no mesmo bloco, e o domínio do d= dentro do cabeçalho DKIM-Signature. O DMARC passa quando qualquer um dos caminhos passa e alinha. Por isso uma assinatura válida no seu próprio domínio salva a mensagem mesmo quando o SPF não alinha.
- Corrija o caminho quebrado na plataformaAtive o recurso que a plataforma chama de custom sending domain ou authenticated domain. Publique todos os registros que ela fornecer: o subdomínio de return path para o alinhamento do SPF, e os registros DKIM para o alinhamento da assinatura. Os passos de publicação estão no guia de configuração do DMARC.
- Envie um teste novo e confiraEspere a propagação das mudanças de DNS, cerca de uma hora. Envie uma mensagem nova para um endereço real. Confirme com um analisador de cabeçalhos que o dmarc agora mostra pass, e que os domínios do envelope e da assinatura são os seus.
Perguntas frequentes
Por que o DMARC do seu email falha se o SPF passa?
Porque o DMARC não lê o veredito do SPF. Ele lê o domínio que o SPF verificou, e pergunta se esse domínio combina com o domínio no seu campo From. Quando sua plataforma envia pelo domínio de bounce dela, o SPF passa para a plataforma e o DMARC falha para você. Isso se chama falha de alinhamento, e é a falha de DMARC mais comum que existe.
Qual é a diferença entre o alinhamento de SPF e o de DKIM em um email?
O alinhamento do SPF compara o domínio do envelope, o do Return-Path, com o domínio do From. O alinhamento do DKIM compara o domínio do campo d= da assinatura com o domínio do From. Qualquer um dos dois, com a própria verificação passando, satisfaz o DMARC. O alinhamento relaxed aceita correspondência por subdomínio. O alinhamento strict, definido com aspf=s ou adkim=s, exige correspondência exata.
O que o p=quarantine faz quando o DMARC de um email falha?
Ele diz aos receptores para colocar as mensagens que falham na pasta de spam ou lixo eletrônico em vez de rejeitá-las. O p=none pede apenas relatórios. O p=reject pede que os receptores recusem o email. Os receptores tratam a política publicada como um conselho forte, não como uma ordem, então os resultados variam um pouco por provedor.
Encaminhar um email pode causar falha de DMARC mesmo com seus registros corretos?
Sim. Um encaminhador ou uma lista de discussão reenvia a mensagem com o envelope dele, então o SPF deixa de rodar para o seu domínio. Rodapés de lista também mudam o corpo, o que quebra a assinatura DKIM. Sua cópia enviada alinha enquanto a cópia encaminhada falha. Essa quebra fica do lado do encaminhamento, que é o problema que os receptores criaram o ARC para contornar.