Os relatórios DMARC mostram parte do tráfego observado por destinatários participantes: origens, autenticação, alinhamento e tratamento. Ajudam a investigar falsificação e erros de provedores e a avaliar políticas restritivas, mas não garantem sozinhos que seja seguro aplicá-las.
Publicar um registro e direcionar rua= a uma caixa não basta. Sem analisar o XML, os problemas ficam sem investigação. Revise as bases com e-mail empresarial para pequenas empresas e e-mail com domínio próprio. Compare os relatórios com seu inventário: eles não cobrem necessariamente todos os remetentes nem todo o tráfego.
Colete os relatórios, identifique os sistemas e corrija o alinhamento. Examine os encaminhamentos: DKIM válido e alinhado pode permitir que DMARC passe, mas isso não dispensa conferir a rota. Endureça a política com testes, não apenas taxas favoráveis.
O que são relatórios DMARC?
Destinatários participantes enviam informações após avaliar mensagens que declaram seu domínio como remetente. Autenticação, alinhamento, IP de origem e decisões ajudam no trabalho de segurança e entregabilidade, com cobertura parcial.
Existem duas categorias principais.
Os relatórios agregados geralmente são solicitados com rua e chegam em XML. Agrupam tráfego por destinatário, IP, resultados e disposição. Ajudam a investigar se Google Workspace, Microsoft 365, SendGrid, Mailchimp, uma aplicação ou outro servidor envia com seu domínio, sem identificar automaticamente o responsável por cada IP.
Os relatórios de falhas, solicitados com ruf, podem detalhar mensagens conforme os gatilhos configurados e a implementação, não necessariamente apenas falhas DMARC. O suporte é limitado, e a privacidade restringe o conteúdo. Use-os como complemento, não como base única.
Os relatórios ajudam a responder:
- Quais origens observadas enviam com meu domínio?
- SPF ou DKIM passa com alinhamento?
- Que tráfego observado é colocado em quarentena ou rejeitado?
- O que pode ser afetado por
p=quarantineoup=reject?
Como funcionam os relatórios DMARC?
Você publica um TXT em _dmarc.yourdomain.com com política e destinos dos relatórios. Os destinatários participantes podem enviar seus dados. Um destino externo pode exigir autorização DNS do domínio que recebe os relatórios; confira essa configuração.
Este exemplo usa monitoramento com alinhamento estrito opcional:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"Solicita monitoramento e relatórios agregados a dmarc@example.com. As opções adkim=s e aspf=s exigem correspondência exata dos domínios. São opcionais e podem afetar remetentes que funcionam com alinhamento relaxado entre subdomínios do mesmo domínio organizacional; não são a melhor escolha universal.
Tags importantes:
v=DMARC1: versão obrigatória.p=: tratamento solicitado para falhas DMARC.rua=: destino dos relatórios agregados.ruf=: destino dos relatórios de falhas.pct=: percentual solicitado de aplicação a mensagens que falham, não respeitado igualmente por todos.adkimeaspf: modos de alinhamento DKIM e SPF.
A RFC 7489 define formato e lógica. Por isso os relatórios costumam chegar como XML compactado, não como um painel diretamente legível.
O conteúdo dos relatórios agregados
Eles resumem tráfego observado por organização, IP, volume, autenticação e disposição. Diferencie resultados brutos de SPF e DKIM dos resultados avaliados para a política, que incorporam o alinhamento.
Normalmente incluem:
- O destinatário que informa, como Google ou Microsoft.
- O período coberto.
- O IP de origem.
- A quantidade de mensagens observadas.
- O resultado SPF.
- O resultado DKIM.
- O alinhamento SPF ao From visível.
- O alinhamento DKIM ao From visível.
- A disposição DMARC: none, quarantine ou reject.
Nem toda falha SPF indica configuração errada: encaminhamentos mudam o IP. Se DKIM conserva os dados assinados, passa e está alinhado, DMARC pode passar.
Destinatário: gmail.com
IP de origem: 198.51.100.24
Quantidade: 842
From do cabeçalho: example.com
SPF: fail
DKIM: pass
DMARC: pass
Disposição: none
O padrão é compatível com encaminhamento que preserva DKIM. Confira rota e alinhamento; autenticação válida não prova que o conteúdo seja seguro ou legítimo.
Destinatário: outlook.com
IP de origem: 203.0.113.77
Quantidade: 314
From do cabeçalho: example.com
SPF: fail
DKIM: fail
DMARC: fail
Disposição: quarantine
Investigue: remetente legítimo mal configurado, novo provedor, modificações de intermediários ou falsificação são possíveis. O relatório não determina automaticamente uma causa.
Relatórios agregados ou de falhas
Agregados dão uma visão ampla, porém parcial, das origens e destinatários participantes. Os de falhas detalham algumas mensagens quando disponíveis. Nenhum substitui inventário, testes e revisão de fluxos críticos raros.
| Tipo | Solicitação | Dados | Uso principal | Situação em 2025-2026 |
|---|---|---|---|---|
| Agregado | rua=mailto:... | Resumos XML, normalmente diários, por origem, autenticação e disposição | Inventário observado, alinhamento e avaliação de políticas | A base de dados usual de muitas equipes |
| Falha / forense | ruf=mailto:... | Detalhes de mensagens, frequentemente parciais ou ocultados | Investigar falhas e abusos específicos | Suporte irregular; muitos grandes destinatários enviam poucos ou nenhum |
Um provedor de análise deve explicar a diferença e ajudar a agir sobre os resultados, não apenas exibir gráficos.
Como ler os relatórios com eficiência
Comece pelas origens de maior volume, relacione-as com sistemas conhecidos e corrija falhas legítimas. Não descarte volumes pequenos quando representam processos críticos ou pouco frequentes.
Procedimento prático:
- Examine as origens com maior volume observado.
- Identifique o sistema: Google Workspace, Microsoft 365, marketing, aplicação, suporte ou origem desconhecida.
- Confira se SPF ou DKIM passa com alinhamento ao From visível.
- Corrija falhas legítimas antes de mudar a política.
- Investigue origens desconhecidas antes de classificá-las como abuso: podem ser encaminhamentos ou relays compartilhados.
Volume ajuda a priorizar, mas uma fatura ocasional ou recuperação de acesso também pode ser essencial. Considere a importância de cada fluxo.
| Resultado observado | Possível explicação | Ação |
|---|---|---|
| SPF pass, DKIM pass, DMARC pass | Autenticação válida e alinhada | Documentar a origem; não comprova conteúdo seguro |
| SPF fail, DKIM pass, DMARC pass | Encaminhamento ou diferença na rota SPF | Verificar DKIM alinhado e sua preservação |
| SPF pass, DKIM fail, DMARC pass | SPF alinhado permite passar apesar da falha DKIM | Investigar e corrigir DKIM |
| SPF fail, DKIM fail, DMARC fail | Abuso, configuração ou alteração da rota | Examinar origem e mensagem |
| IP desconhecida com volume | Serviço não inventariado, relay, encaminhamento ou abuso | Identificar antes de considerar bloqueio |
As correções podem incluir:
- Adicionar a autorização SPF adequada de um remetente legítimo.
- Ativar e verificar DKIM no provedor.
- Configurar um return-path próprio para ajudar no alinhamento SPF.
- Usar um subdomínio para separar um serviço quando necessário.
- Revisar encaminhamentos e preservar assinaturas sem depender só de SPF.
Estas consultas ajudam a verificar a publicação:
dig TXT _dmarc.example.com +short
dig TXT example.com +short
dig TXT selector1._domainkey.example.com +shortSe houver erros DNS, consulte os registros DNS obrigatórios e o guia de mensagens que chegam ao spam do TrekMail, sem atribuir tudo ao XML.
Problemas que os relatórios podem revelar
Relatórios ajudam a detectar autenticação incompleta de provedores, falta de alinhamento, alterações de encaminhamentos e políticas sem acompanhamento. Compare sempre com a configuração real.
Um serviço novo pode enviar com seu domínio sem SPF ou DKIM devidamente configurado. Um IP desconhecido é uma pista, não prova de falsificação.
SPF também pode passar para o domínio do envelope sem alinhar com From. Sem DKIM válido e alinhado, DMARC falha. Isso ocorre com marketing ou suporte sem domínio de devolução personalizado.
Depender só de SPF complica encaminhamentos. Se DKIM falta ou é invalidado, pode desaparecer a autenticação alinhada. Consulte configuração e correção do encaminhamento para avaliar rotas indiretas.
Publicar p=none e acumular relatórios sem ler não corrige configurações nem solicita bloqueio.
Passar cedo demais a p=reject pode afetar mensagens legítimas. Verifique remetentes habituais e excepcionais antes das restrições.
O papel do TrekMail
Relatórios ajudam se você consegue aplicar correções. O TrekMail pode coordenar domínios e verificações DNS conforme o plano, mas os serviços externos ainda precisam de revisão.
Um ambiente disperso exige gerenciar várias hospedagens, SMTPs separados e relatórios em uma caixa compartilhada, além de manter o inventário dos novos remetentes.
Um fluxo coordenado pode reunir hospedagem multidomínio, configuração SPF/DKIM/DMARC, verificações DNS, SMTP próprio ou gerenciado, caixas, encaminhamento e migração conforme os recursos disponíveis. A hospedagem de e-mail multidomínio explica o modelo.
O TrekMail oferece domínios próprios, caixas IMAP, catch-all, encaminhamento e migração IMAP compatível conforme o plano, com API nos planos correspondentes. Para Nano, consulte SMTP próprio. Planos pagos que o incluem podem usar SMTP gerenciado; o Starter é anunciado a partir de $3.50 por mês. O Nano é oferecido gratuitamente sem cartão, e os planos pagos podem incluir avaliação de 14 dias com cartão exigido. Confira as condições vigentes.
Relatórios não corrigem nada automaticamente: dão pistas. Coordenar configuração e testes pode facilitar as intervenções.
Quando passar de p=none a quarantine ou reject?
Relatórios mostram autenticação alinhada no tráfego observado, mas não garantem que todos os remetentes estejam prontos. Complete o inventário e teste processos críticos antes de considerar quarantine e reject.
Os registros representam etapas alternativas: publique apenas o adequado, não todos ao mesmo tempo.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=25"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"O percentual solicita cobertura das mensagens que falham, não aplicada igualmente por todos. Revise vários ciclos e processos raros, confirme autenticação alinhada e confira a preservação de DKIM pelos encaminhamentos quando depender dele.
O Google exige SPF ou DKIM para remetentes gerais a contas pessoais do Gmail; para remetentes em massa, ambos e DMARC com o alinhamento aplicável. Consulte as perguntas frequentes sobre diretrizes para remetentes do Gmail.
Conclusão: incorporar relatórios à operação
Relatórios mostram origens e resultados observados e ajudam a decidir o que investigar e corrigir. Inclua-os na revisão periódica com inventário e testes, em vez de deixá-los em uma caixa ignorada.
Com muitos domínios e provedores, coordenar ferramentas pode ajudar. Conforme o plano, o TrekMail oferece hospedagem multidomínio, armazenamento compartilhado, migração IMAP, SMTP próprio ou gerenciado e configuração de autenticação. Confira a opção gratuita ou os preços do TrekMail conforme suas necessidades, sem presumir que uma plataforma garante uma política segura.
