Relatório DMARC: como identificar as origens de envio

Comece a leitura do relatório DMARC pelo domínio, pelo período e pelo provedor que enviou o arquivo. Em seguida, veja quais endereços IP se conectaram a esse provedor, quantas mensagens cada linha representa e em quais grupos o alinhamento falhou. Assim, você consegue investigar o que saiu dos serviços da empresa e o que ainda precisa ser identificado.

Imagine que uma loja envie campanhas e confirmações de pedido pelo mesmo domínio. No teste de alinhamento, as campanhas passam e os avisos de pedido falham. Ao cruzar os registros com os envios da loja, a equipe consegue encaminhar o ajuste a quem mantém os avisos e separar as origens que continuam sem identificação.

O que o relatório DMARC agregado reúne

DMARC é um protocolo que permite verificar o uso do domínio visível no remetente de um e-mail. O relatório agregado é um arquivo XML enviado por um provedor que recebeu mensagens usando esse domínio. Para solicitar esse arquivo, o responsável pelo domínio indica o destino no campo rua do registro DMARC. Os provedores que enviam relatórios agrupam os resultados por período. Assim, o arquivo descreve o que aquele receptor observou, conforme a RFC 9990 sobre relatórios agregados DMARC.

Antes de somar as linhas, confira o nome da organização que fez o relatório, o identificador report_id e o intervalo date_range. Em seguida, confirme o domínio em policy_published e o From de cada linha. Além disso, se o mesmo arquivo chegar duas vezes, compare o identificador junto com o emissor e o domínio. Quando confirmar que se trata do mesmo relatório, conte uma cópia, seguindo o critério de identificação de relatórios duplicados da RFC 9990.

Campos do relatório DMARC para identificar uma origem

IP, contagem e domínio do remetente

Primeiro, localize source_ip, o endereço do servidor que se conectou ao receptor. Já count informa quantas mensagens aquela linha representa. Antes de juntar linhas do mesmo IP, confira se os demais campos coincidem. O From e a avaliação de autenticação podem variar entre elas. Além disso, um fornecedor pode usar a mesma infraestrutura para mais de uma conta.

Na seção identifiers do XML do DMARC, leia header_from, o domínio visível no endereço do remetente. Depois, cruze o IP, o período e o domínio com os registros de envio da ferramenta de campanha, da loja ou do site. Se o IP aponta para um fornecedor, ainda vale conferir se a conta da empresa aparece nos registros do envio.

Autenticação, alinhamento e ação do receptor

O SPF verifica se o servidor está autorizado a enviar pelo domínio técnico da mensagem. Por sua vez, o DKIM verifica uma assinatura digital associada a um domínio. No relatório DMARC, auth_results reúne os resultados dessas verificações e os domínios avaliados. Já os campos spf e dkim dentro de policy_evaluated mostram a avaliação dessas vias para o DMARC. Quando pelo menos uma via tem pass ali, o requisito de autenticação alinhada é atendido naquele grupo. Com fail nas duas vias, o grupo não atende ao critério de alinhamento da RFC 9989.

Em seguida, leia disposition, a ação indicada no relatório para aquela linha. Uma linha pode apresentar os dois campos de alinhamento com fail e ainda trazer none, por exemplo, quando a política observada é p=none. Se a ação divergir da política para uma falha, procure reason e confira o contexto com o responsável técnico. Para entender por que um domínio de autenticação pode ser diferente do From, consulte o guia de alinhamento DMARC por SPF e DKIM.

Exemplo de triagem de 2.000 mensagens

Considere um relatório DMARC de um único receptor para loja.example.com, de 5 de novembro de 2026, em UTC, sob a política p=none. Imagine três grupos que somam 2.000 mensagens. Ao cruzar o arquivo com os registros internos, a equipe vincula dois grupos a serviços da loja. O terceiro continua sem confirmação.

Nesse cenário, 1.800 mensagens passaram pelo alinhamento via DKIM. As outras 200 aparecem com falha nas duas vias, o que representa 10% das 2.000 mensagens do relatório. Dentro desse grupo, 160 vieram de um serviço confirmado, o equivalente a 80% das falhas. Como os avisos de pedido fazem parte da operação da loja, a equipe pode tratar esse envio com o responsável pelo serviço enquanto investiga a origem das outras 40 mensagens.

Participação entre as falhas de alinhamento

Serviço de pedidos confirmado · 160

As mensagens desse serviço representam 80% das 200 falhas. Encaminhe a linha ao responsável pelos avisos.

Origem pendente · 40

Essas mensagens representam 20% das falhas. Use o IP, o domínio e o período para investigar a origem.

Descrição do gráfico

A barra inteira representa 200 mensagens sem alinhamento no relatório de um receptor durante um dia. O trecho maior corresponde a 160 mensagens de confirmação de pedidos, 80% das falhas. O outro trecho corresponde a 40 mensagens cuja origem ainda precisa de confirmação, 20% das falhas. No relatório completo, as 200 falhas representam 10% de 2.000 mensagens.

A linha das confirmações de pedido

No XML do relatório DMARC, a linha das 160 mensagens fica assim. O SPF bruto passou para bounce.envio.example.net, o domínio técnico do prestador. Entretanto, policy_evaluated registra falha nas duas vias para loja.example.com. Desse modo, o pass do SPF bruto mostra o que o receptor conseguiu autenticar. Para conferir como o resultado chega ao relatório, veja a leitura dos campos no Microsoft Learn.

<record>
  <row>
    <source_ip>198.51.100.34</source_ip>
    <count>160</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>loja.example.com</header_from>
    <envelope_from>bounce.envio.example.net</envelope_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>bounce.envio.example.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Ficha para registrar cada origem

Use uma linha do relatório DMARC por vez. Primeiro, anote o serviço identificado ou o IP observado. Depois, guarde o identificador e o período do arquivo junto com o registro. Se a mesma origem aparecer em outras linhas, preserve a distinção entre as avaliações antes de consolidar o volume.

Serviço ou IP, domínio do From, receptor e ID do relatório
Período e número de mensagens da linha
Identificação da origem e evidência usada
SPF e DKIM dentro de policy_evaluated
Ação em disposition e motivo, se disponível
Hipótese a conferir, responsável e data da próxima revisão

Conferência do relatório DMARC antes de mudar a política

Quando um serviço confirmado aparece com falha no relatório DMARC, reúna o domínio do From, o domínio aprovado em SPF ou em DKIM e uma amostra de envio do próprio serviço. Em seguida, peça ao responsável que confira a configuração e registre a hipótese a testar. Após um ajuste autorizado, observe uma nova mensagem e compare relatórios posteriores do mesmo receptor e do mesmo fluxo. Além disso, guarde as duas evidências para explicar o que mudou.

Se o IP estiver fora do inventário, verifique se há um fornecedor ainda sem registro, um serviço antigo ou um intermediário. Afinal, o servidor que se conectou pode ter encaminhado a mensagem. Nesse caso, preserve a evidência e confirme com os responsáveis antes de autorizar a origem ou atribuir a falha a uso indevido.

Por fim, leve à discussão sobre a política os fluxos confirmados, os testes e as pendências. Um relatório DMARC de um único dia pode deixar de fora serviços que enviam com pouca frequência. A avaliação de efeitos sobre envios legítimos faz parte da adoção do DMARC na RFC 9989. Para colocar essa revisão na rotina das campanhas, consulte nosso guia de e-mail marketing.

Perguntas frequentes sobre o relatório DMARC