A DMARC report becomes useful when you can connect its sending sources to the systems your business actually uses. Compare the report with your mailbox, website and business-app inventory, identify legitimate routes that need attention, and give each unresolved group an owner. Do that before making a domain-policy decision.
This guide concerns aggregate reports. If reporting has not been set up, ask the person responsible for your domain to explain the proposed recipient, access arrangements and review process. Do not replace an existing policy with a sample record from an article just to obtain reports.
Know what the report can show
Aggregate DMARC reports group observations made by receiving systems. They can show a source IP address, message count, authentication results, relevant domains and the reported policy outcome over a time period. A reporting service may turn the underlying XML into a dashboard.
The report describes what that receiver observed. It is not a complete list of everything your business sent, and a count is not a count of unique customers. A reported authentication pass also does not establish that a message reached an inbox.
The current DMARC aggregate-reporting standard defines the report structure. Keep the reporting organisation and period attached to any row you copy into a support case so the provider can understand its context.
Start with the sender inventory beside the report
List your recognised services before classifying the sources. Use the multiple-sender checklist to include normal mailboxes, website notifications, invoicing and booking tools. For each route, keep the visible From domain, envelope-sender domain, DKIM signing domain and the person responsible.
Provider names and IP labels can help investigation, but they do not prove that a particular account or application belongs to you. Shared infrastructure, forwarding and unfamiliar infrastructure names can make a source hard to recognise. Ask the provider to match a fresh message and account to the reported stream.
Classify a group as confirmed legitimate, confirmed retired, unexplained or awaiting provider evidence. An “unknown” label is a question to investigate, not permission to add an address to SPF.
Read alignment as well as the raw authentication result
DMARC checks whether a passing SPF or DKIM identity aligns with the domain in the visible From address. The underlying test can pass for a third party’s domain while failing to provide alignment for your business. Ask your administrator to interpret both the authentication domains and the report’s DMARC evaluation.
A DMARC pass can be supported by either an aligned SPF pass or an aligned DKIM pass; the two underlying tests do not both have to pass for that result. The DMARC standard sets out this relationship. When a dashboard shows a single red or green badge, open the detail before deciding what needs changing.
Turn a suspicious row into a specific question
Consider this hypothetical example: a business recognises a stream as its invoicing platform, but the report shows a DMARC failure. SPF passed for the platform’s own domain, and there is no passing DKIM signature aligned with the business From domain.
The next question for the invoicing provider is whether domain authentication has been completed and enabled for that account. Ask it to identify the supported signing setup, the current account status and a fresh message that demonstrates the intended result. Authorising an unfamiliar source IP in your main SPF record would not, by itself, establish the missing alignment.
Keep this case separate from an unexplained stream that fails both checks. That second group needs investigation against the inventory and message evidence; it should not inherit the invoicing platform’s proposed fix.
Create an action list with an owner for each group
- Known service, expected results: record the evidence and retain it as a comparison for future changes.
- Known service, failed or misaligned results: open a case with that service and give the DNS administrator its verified requirements.
- Apparently retired service still sending: ask its business owner what job is still running before removing records or access.
- Unexplained source: preserve the row and period, investigate its relationship to your services, and keep it unauthorised unless legitimacy is established.
- Expected service absent: check whether it sent during the period, whether the receiver participates in reporting and whether you are looking at the right domain.
For each open item, write the next action and who will return with evidence. A failure percentage without a sender, business job or accountable person is difficult to turn into a repair.
Review enough business activity to cover occasional senders
Choose a review period that includes the workflows you need to protect. A daily website notification and a monthly statement run need different opportunities to appear. Check occasional routes directly rather than assuming a quiet report proves they are configured correctly.
After a provider makes an agreed change, retain a fresh-message result and compare later reports covering new activity. Keep older and newer periods separate. If a customer still reports junk placement or rejection, use the message-level diagnostic steps to investigate that example.
Leave any proposal to alter domain policy with the responsible mail and DNS administrators, supported by the remaining legitimate-sender cases and the business impact. Reports inform that decision; they do not choose an enforcement setting automatically.
Keep reporting access under business control
Aggregate reports contain operational information about mail traffic. Store them where the business can control access, and check who receives them before introducing a reporting supplier. Detailed failure reports are a separate mechanism and can disclose more information; they are outside the aggregate-review task here.
Include the reporting destination, account owner and handover arrangements in your business website account audit. If a new website or booking workflow is planned for a Formby, Freshfield or L37 business, describe its notification requirements in the project enquiry so responsibility for the new sender can be agreed.
