Relatório DMARC: como ler e o que corrigir

O que é um relatório DMARC?

Um relatório DMARC é o retorno que um servidor de e-mail receptor envia ao dono do domínio sobre as mensagens que diziam vir desse domínio. A especificação do DMARC publicada pelo IETF define dois tipos. Os relatórios agregados vão para o endereço da tag rua do seu registro DMARC e resumem todas as mensagens que o receptor viu, agrupadas por IP de envio e resultado. Os relatórios de falha (muitas vezes chamados de relatórios forenses) vão para o endereço da tag ruf e descrevem mensagens individuais que falharam. Você só recebe relatórios se o seu registro pedir por eles. Um registro como v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com publica a política e solicita relatórios agregados. Sem rua, os receptores continuam aplicando a sua política, mas não contam nada para você. O relatório cobre o que o receptor viu, não tudo o que você enviou. Um domínio que só manda e-mail para usuários do Gmail e da Microsoft recebe relatórios desses dois receptores e de mais ninguém. Se você ainda não publicou um registro, comece pela configuração do DMARC, com as tags do registro TXT em _dmarc e as correções mais comuns.

Com que frequência os relatórios DMARC chegam e em que formato?

A especificação do DMARC permite que o dono do domínio solicite um intervalo de envio com a tag ri, e o intervalo padrão é de um dia. Os receptores podem manter relatórios diários independentemente do que você pedir, e a maioria faz isso. Cada relatório chega como um e-mail com um anexo compactado, geralmente gzip (.xml.gz) ou zip, contendo um arquivo XML. O nome do arquivo costuma trazer o domínio do receptor, o seu domínio e os timestamps de início e fim. Os timestamps estão em segundos Unix epoch, em UTC, então um relatório que "começa à meia-noite" pode não começar na meia-noite do seu fuso horário. Um detalhe pega muita gente quando os relatórios vão para outro domínio, como o de um serviço de monitoramento. A especificação do DMARC exige que o domínio de destino publique um registro TXT em seudominio.com._report._dmarc.dominiodeles.com para confirmar que aceita os seus relatórios. Se esse registro não existir, os receptores que seguem a especificação descartam o endereço rua externo sem aviso, e a sua caixa de relatórios simplesmente fica vazia.

Como ler um relatório DMARC agregado, campo a campo

Um relatório agregado tem três partes: report_metadata (quem enviou e o período coberto), policy_published (o seu registro DMARC do jeito que o receptor o viu) e um ou mais elementos record. É nos elementos record que está o trabalho de verdade.

Elemento XML	O que contém	O que verificar
report_metadata / org_name, date_range	O receptor que enviou o relatório e os timestamps Unix de início e fim	Qual provedor de caixa postal o relatório cobre e qual dia
policy_published / p, sp, pct, adkim, aspf	Sua política, política de subdomínios, porcentagem e modo de alinhamento (r relaxado, s estrito)	Se bate com o que você acha que publicou. Um erro de digitação no DNS aparece aqui
row / source_ip	O IP que entregou as mensagens	Faça a consulta reversa para identificar o serviço: seu Workspace, o Brevo, um CRM ou algo desconhecido
row / count	Quantas mensagens daquele IP tiveram o mesmo resultado	Pondere as linhas pelo volume. Uma única mensagem de um IP estranho geralmente é encaminhamento
policy_evaluated / disposition	O que o receptor fez: none, quarantine ou reject	Deve corresponder ao seu p=, a menos que o receptor tenha decidido diferente
policy_evaluated / dkim, spf	O resultado alinhado ao DMARC: pass só se o domínio autenticado corresponder ao seu domínio do From	Pelo menos um dos dois precisa passar para o DMARC passar
identifiers / header_from	O domínio do endereço From visível	Subdomínios aparecem aqui separadamente
auth_results / dkim (domain, selector, result)	A verificação DKIM bruta, incluindo o domínio de assinatura d= e o seletor	Um pass para o domínio de um fornecedor não conta para o DMARC
auth_results / spf (domain, result)	A verificação SPF bruta no domínio do remetente do envelope (Return-Path)	Um pass para um domínio de bounce que não é seu não alinha

O erro de leitura mais comum é tratar auth_results como o veredito. Não é. Veja uma linha em que auth_results mostra spf pass, mas policy_evaluated mostra spf fail. O SPF passou para algum domínio, normalmente o domínio de bounce do próprio serviço de envio, só que esse domínio não corresponde ao seu domínio do From. Então, para o DMARC, o SPF não vale nada, e a mensagem só passa no DMARC se o DKIM estiver alinhado.

O que fazer com os relatórios DMARC?

Os relatórios só ajudam se cada linha for parar em uma categoria. Agrupe por source_ip, some o count de cada grupo e depois trabalhe com estes casos:

1. 1 Serviço seu, pass alinhado em DKIM ou SPF: resolvido. Anote a faixa de IPs e o seletor DKIM para reconhecê-lo da próxima vez.
2. 2 Serviço seu, fail alinhado: o serviço está enviando em nome do seu domínio sem assinar por ele. A causa mais comum é o DKIM ainda assinado com o domínio d= do fornecedor, porque a sua chave DKIM personalizada nunca foi publicada ou ativada. Corrija o DNS antes de mexer no p=.
3. 3 Encaminhador ou lista de e-mail conhecidos, SPF fail, DKIM às vezes pass: o encaminhamento muda o IP que entrega a mensagem, então o SPF quebra, e rodapés de lista ou tags no assunto também podem quebrar a assinatura DKIM. Isso não tem como ser corrigido do seu lado. Contagens pequenas assim são normais.
4. 4 IP desconhecido, os dois falham, contagem relevante: alguém está fazendo spoofing do seu domínio, ou alguma equipe contratou uma ferramenta sem avisar ninguém. Pergunte internamente antes de classificar como abuso.
5. 5 Linhas com header_from em subdomínios que você não usa: candidatas a uma política sp=reject assim que o domínio principal estiver limpo.

Passar de p=none para quarantine só é seguro quando todas as fontes legítimas já estão há algum tempo na primeira categoria. Se você endurecer a política enquanto um CRM ou uma ferramenta de faturamento ainda está na categoria dois, o e-mail dessa ferramenta vai para o spam ou é rejeitado. Os relatórios das últimas semanas são a forma de descobrir isso. Antes de alterar qualquer registro, entenda como DKIM, DMARC e SPF dependem um do outro. Você pode conferir o que está publicado agora com o verificador de SPF, DKIM e DMARC.

DMARC no Google Workspace: o que os relatórios mostram

Se o seu domínio roda no Google Workspace, separe dois papéis. Como remetente, o seu registro DMARC fica no seu provedor de DNS, como um registro TXT em _dmarc.seudominio.com. O Admin Console do Workspace não o cria para você. O e-mail enviado pelas caixas do Workspace aparece nos relatórios de outros receptores com faixas de IP do Google como source_ip. Se você ativou o DKIM do Workspace, ele aparece com uma assinatura DKIM usando o seletor google e d= o seu domínio, que é o seletor padrão na documentação de administração do Google. Se o DKIM foi gerado, mas nunca ativado com Iniciar autenticação, essas linhas mostram DKIM assinado por um domínio do Google e um fail de DKIM alinhado. Como receptor, o Gmail envia para você relatórios agregados com org_name google.com. O artigo de ajuda do Workspace "Sobre os relatórios DMARC" descreve os relatórios agregados. Não conte com relatórios de falha (ruf) do Gmail. Uma configuração comum no Workspace é e-mail pelo Workspace mais um serviço de envio separado, como o Brevo, no mesmo domínio. Nesse caso você vai ver dois grupos de linhas, cada um precisando do seu próprio DKIM alinhado. O registro em si e a ordem de implantação estão no nosso guia de registro DMARC e implantação no Google Workspace.

Qual ferramenta usar para ler relatórios DMARC?

Ler o XML bruto funciona para um domínio com dois remetentes e pouco volume. Quando vários receptores passam a enviar relatórios todos os dias, você vai querer algo que interprete os arquivos e agrupe as linhas. As opções abaixo são as citadas nos resultados de busca atuais sobre o tema. A comparação se limita a como cada tipo de opção funciona, sem limites específicos de conta.

Opção	Como funciona	Indicada para	Onde para
XML bruto em um editor de texto	Descompacte o anexo e leia os elementos record manualmente	Um domínio, um ou dois serviços de envio, uma verificação rápida	Sem tendência ao longo do tempo e sem agrupamento entre receptores. Lento com mais de algumas linhas
MxToolbox DMARC Report Analyzer	Cole ou envie um único relatório e receba uma visão interpretada (um parser de XML, segundo o título da página)	Entender um relatório que você acabou de receber	Funciona relatório por relatório e não coleta sozinho o seu fluxo diário
Monitoramento DMARC hospedado (por exemplo, Postmark DMARC, EasyDMARC, PowerDMARC, dmarcreport.com)	Você aponta o rua para o endereço do provedor, que coleta, interpreta e resume os relatórios ao longo do tempo	Monitoramento contínuo de vários remetentes e receptores antes de passar para quarantine	O provedor recebe os dados dos seus relatórios, e um rua externo exige o registro de autorização do provedor. Planos e recursos variam, então confira a documentação de cada fornecedor
Sua própria caixa postal mais um script	O rua aponta para uma caixa que você controla, e você interpreta o XML com o seu próprio código	Equipes que querem manter os dados dos relatórios internamente	Você constrói e mantém sozinho a interpretação e o armazenamento

Seja qual for a escolha, nenhuma dessas ferramentas muda o que o receptor decide. Elas mostram o que aconteceu. As correções continuam sendo feitas no seu DNS e nas configurações de domínio de cada serviço de envio.

Como os envios do EmailFlow OS aparecem nos seus relatórios DMARC

O EmailFlow OS funciona na sua própria infraestrutura, então o tráfego dele aparece nos seus relatórios como tráfego seu. Você grava um único vídeo e faz o upload no EmailFlow OS. Depois conecta a sua conta Brevo e o seu domínio de envio e importa a sua lista de prospects para o EmailFlow OS. O EmailFlow OS personaliza essa única gravação para cada destinatário, não para cada empresa, e envia cada versão a partir da sua própria caixa de entrada, pela sua própria conta Brevo e pelo seu próprio domínio de envio. Não existe remetente compartilhado da plataforma. Por isso, nos relatórios agregados, esses envios aparecem sob o seu domínio header_from, com os IPs de envio do Brevo como source_ip. Se eles passam no DMARC depende da chave DKIM que você publicou para o Brevo no seu domínio. Se ela estiver configurada e alinhada, as linhas caem na categoria um. Se não, caem na categoria dois, como qualquer outro serviço mal configurado. Os seus relatórios são a forma de conferir isso antes de enviar em volume. Saiba mais sobre como o EmailFlow OS trata o e-mail com vídeo personalizado por IA a partir do seu próprio domínio na página inicial.

Perguntas frequentes

? Por que não estou recebendo nenhum relatório DMARC?

Há três causas comuns. O seu registro DMARC não tem a tag rua. O endereço rua está em outro domínio que não publicou o registro TXT de autorização exigido pela especificação do DMARC para endereços de relatório externos. Ou o registro está quebrado, por exemplo com dois registros v=DMARC1 em _dmarc, o que os receptores tratam como se não houvesse registro nenhum. Os relatórios costumam chegar diariamente, então espere pelo menos um dia depois de qualquer correção.

? Qual é a diferença entre relatórios rua e ruf?

Os relatórios rua são agregados: resumos diários em XML agrupados por IP de envio e resultado, sem o conteúdo das mensagens. Os relatórios ruf são relatórios de falha sobre mensagens individuais que falharam e podem incluir cabeçalhos ou partes da mensagem. Relatórios agregados são enviados amplamente. Muitos grandes receptores enviam poucos ou nenhum relatório de falha, em parte por causa dos dados pessoais envolvidos.

? Um relatório DMARC significa que meu e-mail chegou na caixa de entrada?

Não. O campo disposition só mostra se o receptor aplicou a sua política DMARC: none, quarantine ou reject. Uma mensagem com disposition none e passes alinhados ainda pode ir para o spam por causa de reputação, conteúdo ou reclamações. Os relatórios DMARC cobrem autenticação, não posicionamento na caixa de entrada. Para isso existem ferramentas separadas, como o Google Postmaster Tools ou testes com seed list.

? Um fail de DMARC no relatório é sempre spoofing?

Não. Falhas também vêm de encaminhamentos, que quebram o SPF e às vezes o DKIM. Também vêm de listas de e-mail que modificam as mensagens e dos seus próprios serviços enviando sem uma chave DKIM alinhada ao seu domínio. Confira primeiro o source_ip e o domínio d= do DKIM. Trate como spoofing apenas quando o IP não pertencer a nenhum dos seus serviços nem a encaminhadores conhecidos.