Por que uma linha do seu relatório DMARC exibe spf=fail mesmo com o domínio protegido e a mensagem chegando normalmente à caixa de entrada? Para cada fonte de envio, um relatório DMARC agregado lista o resultado do SPF. Ele soma o resultado do DKIM e a decisão realmente aplicada pelo servidor receptor. Um SPF com falha associado a um DKIM alinhado com sucesso não quebra nada: a especificação DMARC valida assim que um dos dois mecanismos se alinha com o domínio visível no cabeçalho From.
Esse é exatamente o tipo de linha que preocupa à toa quando as campanhas caem no spam e a ferramenta de e-mail marketing ainda assim mostra uma taxa de deliverability toda verde. Se os fundamentos da autenticação de e-mail (SPF, DKIM, DMARC) ainda não estão claros, o protocolo DMARC explicado estabelece a base antes de avançar. Este guia foca em um único ponto: ler um relatório agregado campo por campo e distinguir uma linha normal de um alerta real.
Onde o relatório chega e em qual formato
O relatório agregado é enviado para o endereço declarado na tag rua= do registro DNS _dmarc, geralmente uma vez por dia e por provedor receptor (Google, Microsoft, Yahoo). Os detalhes das tags DNS que controlam esse envio estão no artigo sobre as tags do DMARCbis a corrigir antes da mudança de 2026; este artigo parte do princípio de que o DNS já está configurado. Cada mensagem chega como anexo compactado, um arquivo XML dentro de um pacote .zip ou .gz. Antes de ler, é preciso descompactá-lo, ou usar um analisador que faça isso sozinho.
A MailerCheck diferencia em 2024 os relatórios agregados dos relatórios forenses: os primeiros resumem a atividade de autenticação em um determinado período, os segundos detalham uma falha específica e raramente são implementados pelos provedores de e-mail (MailerCheck, 2024). Nada sensível trafega nesses relatórios. Quase todo o monitoramento de DMARC depende, portanto, do agregado. É também a política DMARC que Gmail e Yahoo exigem desde 2024 para domínios que enviam mais de 5.000 mensagens por dia. O agregado continua sendo a principal ferramenta para verificar sua aplicação.
A estrutura do XML, campo por campo
O arquivo XML se organiza em três blocos. report_metadata identifica o remetente do relatório (org_name, email, período coberto). policy_published reproduz a política DMARC publicada pelo seu domínio no momento da análise. O bloco record contém uma ou mais linhas row, cada uma correspondendo a uma combinação única de fonte e resultados.
Para interpretar uma linha sem se perder, a ordem de leitura importa.
- Identificar a fonte: source_ip indica o endereço IP que realmente enviou a mensagem; cruze com um reverse DNS para saber se é o seu ESP, um relay terceiro ou um IP desconhecido.
- Observar o volume: count mostra o número de mensagens associadas a essa combinação exata durante todo o período do relatório.
- Ler a decisão aplicada: disposition (none, quarantine ou reject) no bloco policy_evaluated, a decisão efetivamente tomada pelo servidor receptor.
- Comparar dkim e spf em policy_evaluated: esses dois valores indicam o resultado de alinhamento, diferente do resultado bruto do protocolo.
- Verificar auth_results para o resultado bruto de cada mecanismo e o domínio efetivamente signatário ou declarado.
Essa distinção entre alinhamento (policy_evaluated) e resultado bruto (auth_results) é a origem da maioria das confusões. Um SPF tecnicamente válido no domínio de envelope pode exibir fail em policy_evaluated porque esse domínio não corresponde ao domínio visível no cabeçalho From. É exatamente esse mecanismo que explica o caso a seguir.
As 4 combinações DKIM x SPF e seu veredito DMARC
Um relatório agregado revela 4 configurações recorrentes. Cada uma conta uma história diferente sobre o que aconteceu entre o seu servidor de envio e a caixa do destinatário.
| DKIM | SPF | Resultado DMARC | Causa mais frequente |
|---|---|---|---|
| Pass, alinhado | Pass, alinhado | Pass | Envio direto a partir da infraestrutura declarada no DNS |
| Pass, alinhado | Fail | Pass, via DKIM | Forwarding, lista de distribuição, encaminhamento de caixa de e-mail |
| Fail | Pass, alinhado | Pass, via SPF | Relay que não assina a mensagem ou assinatura quebrada no caminho |
| Fail | Fail | Fail | Usurpação do domínio ou fonte de envio mal declarada no DNS |
Somente a 4ª linha exige correção imediata. As 3 primeiras fazem parte do funcionamento esperado da especificação, cada uma com sua própria leitura.
SPF com falha, DKIM com sucesso: motivo para preocupação?
Não, na maioria dos casos. O SPF verifica o endereço MAIL FROM, transmitido pelo comando de mesmo nome no diálogo SMTP logo após a troca inicial de EHLO, ou seja, o endereço de envelope. O DKIM assina o conteúdo da mensagem com uma chave privada vinculada ao domínio remetente, uma assinatura que viaja com a mensagem independentemente do servidor que a retransmite depois. Quando um destinatário encaminha um e-mail para outra caixa ou quando uma lista de distribuição redistribui uma mensagem aos assinantes, o servidor de retransmissão se torna o novo IP de envio. O SPF, que verifica o IP em relação ao registro do domínio de origem, falha mecanicamente. Já a assinatura DKIM permanece intacta enquanto o corpo e os cabeçalhos assinados não forem modificados no caminho.
O Spamresource documentou em novembro de 2025 uma rejeição da Microsoft que ilustra bem essa mecânica, no sentido inverso: uma mensagem com DKIM pass e DMARC pass foi bloqueada porque o SPF, esse sim, falhou.
550 5.7.515 Access denied, sending domain doesn’t meet the required authentication level. Spf= Fail, Dkim= Pass, DMARC= Pass
O código de status estendido 5.7.515 sinaliza aqui uma exigência específica da Microsoft, uma camada adicionada acima do próprio resultado DMARC. Desde maio de 2025, a Microsoft exige que remetentes de grande volume passem simultaneamente pelos 3 mecanismos (SPF, DKIM, DMARC), mesmo quando a própria especificação DMARC se contenta com um único alinhamento bem-sucedido (spamresource.com, 2025). O SPF fail identificado nesse caso específico veio, segundo o mesmo artigo, de um encaminhamento para uma caixa hospedada fora dos servidores Microsoft. É um ponto importante antes de explicar a um CMO que a open rate está caindo: o DMARC pode exibir pass no seu relatório e, ainda assim, deixar algumas mensagens bloqueadas por uma regra específica do provedor receptor.
Duas coisas diferenciam esse caso de um problema de configuração real a corrigir. Primeiro, o volume: algumas linhas isoladas com count baixo, distribuídas entre IPs variados, correspondem mais a forwarding individual do que a uma campanha inteira. Segundo, a fonte: um reverse DNS nesses source_ip geralmente aponta para um provedor de e-mail de uso geral ou um servidor de lista de distribuição, nunca para a sua própria infraestrutura de envio. Um SPF fail repetido nos seus próprios IPs de envio, sem nenhum forwarding identificável, aponta para outra causa: o limite de 10 consultas DNS do registro SPF, que vale verificar antes de concluir rápido demais que se trata de um simples encaminhamento.
Armadilhas comuns na leitura de um relatório agregado
Primeira armadilha: confundir o resultado bruto de auth_results com o resultado de alinhamento de policy_evaluated. Um SPF pode passar tecnicamente no domínio de envelope e, mesmo assim, falhar no alinhamento porque esse domínio difere do From visível, um cenário frequente entre remetentes que usam um IP pool compartilhado em um provedor terceiro.
Segunda armadilha: tratar um único relatório como prova definitiva. Os grandes provedores (Google, Microsoft, Yahoo) enviam relatórios diários. Um incidente pontual pode aparecer em um único dia e desaparecer no seguinte. Verifique count e disposition ao longo de pelo menos uma semana antes de tirar conclusões.
Terceira armadilha: ignorar o campo org_name do bloco report_metadata. Ele identifica quem produziu o relatório, útil para identificar um provedor secundário que aplica sua própria política de filtragem além da sua, independentemente dos feedback loops de provedores de e-mail aos quais você já está inscrito.
O que isso muda para a sua deliverability
Um relatório limpo, com disposition em none ou quarantine coerente nas linhas não terceirizadas, confirma uma sender reputation estável do lado da autenticação. Isso não é a mesma coisa que o monitoramento pós-envio habitual: o open rate ou o bounce rate mostra o efeito do lado do destinatário, enquanto o relatório DMARC mostra a causa do lado do servidor receptor, antes mesmo de a mensagem chegar a uma caixa de entrada. Um não substitui o outro. O Postmaster do Gmail e o equivalente da Microsoft, o SNDS (Smart Network Data Services), oferecem uma visão semelhante do lado da reputação de IP, a ser cruzada com os mesmos source_ip identificados no relatório.
Depois de confirmar que a autenticação está limpa por vários dias, a próxima variável que pesa na reputação é a limpeza da lista enviada. Uma taxa de hard bounce alta prejudica a sender reputation tão certamente quanto um SPF mal alinhado, e nenhuma linha do relatório DMARC revela isso. Passar uma amostra da próxima lista por uma verificação antes do envio permite saber se o entrave vem da autenticação ou da list hygiene.
O que o relatório agregado não cobre
Um relatório DMARC não diz nada sobre o conteúdo da mensagem, sobre a taxa real de reclamação do lado da caixa de entrada, nem sobre domínios parecidos (typosquatting) que nunca publicaram registro DMARC e, portanto, escapam totalmente desse mecanismo de reporting. Passar para p=reject bloqueia a usurpação direta do seu domínio, um pré-requisito técnico para ativar o BIMI em seguida. Isso não tem nenhum efeito sobre um domínio visualmente parecido registrado por terceiros. As 5 coisas que o DMARC não consegue fazer detalham esses pontos cegos além do reporting.
Guarde seus relatórios por várias semanas antes de ajustar a política. É a única forma de distinguir um sinal real de um ruído passageiro. Um relatório DMARC agregado conta o trajeto real de uma mensagem, linha após linha, até a caixa de entrada.
