A DMARC report is feedback from receiving mail systems about messages that claimed to use your domain. It helps you see which sources are sending, whether they passed SPF and DKIM, whether those results aligned with the visible From domain, and how the receiver applied your policy. For a small business, reports are most useful as a sender-inventory and change-detection tool—not as a technical spreadsheet to ignore.
Aggregate reports versus forensic reports
Aggregate reports are the common type. They summarize mail volume and authentication outcomes over a period, usually in XML format. Forensic or failure reports can contain more message-level detail but are less consistently available and require more privacy care. Most businesses start with aggregate reports and do not need forensic reporting to implement a sensible DMARC policy.
How a domain requests reports
A DMARC TXT record at _dmarc.yourdomain.com can include a reporting address using the rua tag. For example, a record may request aggregate reports at an owned mailbox or specialized service. Use a reporting destination that someone actively monitors and secure it appropriately. Reports can expose useful information about sending infrastructure and traffic patterns.
What an aggregate report can show
Reports can identify the source IP, number of messages, evaluated domain identities, SPF and DKIM results, DMARC alignment, and the receiver’s policy disposition. They are not always a perfect list of every message or sender, but repeated patterns are valuable. A new source might be a legitimate CRM, agency, helpdesk, or an unauthorized sender worth investigating.
Start with a sender inventory
Before reading reports, list the services your business expects to send mail: employee mailboxes, newsletters, CRM, billing, support, website forms, and transactional platforms. For each, record an owner and the expected signing or return-path domain. This makes it easier to classify a report source as known, unknown, retired, or misconfigured.
Understand alignment
DMARC does not merely ask whether SPF or DKIM passed. It asks whether one of those passing identities aligns with the visible From domain. A report may show a technical pass for a vendor domain while DMARC still fails. Review email authentication explained and the DMARC implementation checklist before changing policy.
Use reports to progress safely
Many businesses begin with p=none to collect evidence without requesting enforcement. As legitimate sources are tested and aligned, they can move to quarantine and then reject if appropriate. Do not jump to a strict policy because a report looks mostly clean; investigate business-critical exceptions such as invoices, account notices, or an infrequently used vendor first.
When a report needs action
Investigate a source that is unknown, fails alignment, appears after a vendor change, or sends unexpected volume. Confirm the source with headers, account owners, and provider documentation. Do not automatically authorize an unfamiliar IP or remove it without evidence. A report is a starting point for a controlled decision.
Choose the right reporting workflow
A simple domain may use a dedicated report mailbox and periodic review. Multiple domains or agency clients may need a reporting tool that parses XML, labels sources, stores history, and routes alerts. See DMARC monitoring tools for evaluation criteria. Public DNS monitoring remains useful because a broken record can affect protection before reports reveal the result.
Run Beacon’s free domain check to confirm the public SPF, DKIM, and DMARC records before configuring an ongoing report workflow.