Use reports as evidence, not a sender verdict
Read a DMARC aggregate report as receiver-grouped authentication evidence, then compare failing rows with known mail streams before changing policy.
A DMARC aggregate report groups a receiver’s observations by period, source IP, count, authentication and reported action. It is not a delivery list or proof of a human sender. A failing row may reflect an authorised misconfiguration, forwarding or spoofing; compare it with known mail before changing policy.
This guide assumes the domain owner has already requested aggregate reports in a DMARC record and receives them at an authorised mailbox or reporting service. Do not change a live reject or quarantine policy solely because one new row appears; first identify its source and effect on real mail.
Handle the report file safely
Reports often arrive as XML inside a compressed attachment. Keep them in an access-controlled location and use a trusted parser or reporting service approved for the data. Do not upload reports to an unknown online checker: source IPs and domain information may be commercially sensitive. Preserve the original file and note the reporting organisation, report ID and received time. If a parser rejects malformed XML or unknown extensions, do not silently treat missing fields as a pass.
RFC 9990 is the current aggregate-report format and obsoletes the original RFC 7489 report specification. Existing senders and tools may still use older compatible fields, so follow the actual report and the receiving service’s documentation rather than assuming every report is identical.
Read interval, policy and aligned results
In report_metadata, note who generated the report, its ID and the date_range. The range is expressed as UTC epoch seconds and describes the reporting interval, not the precise send time of each message. In policy_published, read the domain and observed policy. Compare that with the domain’s intended DMARC record; a report may cover a time when the policy changed.
For each record, note source_ip and count: they describe a group of messages seen from a connecting IP, not a unique sender or mailbox. Read policy_evaluated for the DMARC-aligned SPF and DKIM outcomes and disposition. Then inspect the authentication identifiers and raw results where present. Raw SPF or DKIM pass for a different domain does not necessarily produce DMARC alignment with the visible From domain.
Investigate patterns before changing policy
Group rows across several reports by source IP, sending domain, count and authentication result. Compare known staff mail, website forms, invoicing and third-party senders with the inventory maintained by their owners. For a legitimate source that fails alignment, inspect a real message’s full headers and the service’s current SPF or DKIM configuration before making a change. For an unknown source, investigate cautiously: cloud providers share IP ranges, forwarding can change the connection path, and reverse DNS alone is weak attribution.
If an unfamiliar IP contributes many failing messages, compare its interval and authenticated domains with a known vendor's headers before labelling it spoofing or authorising it in SPF.
The current RFC 9990 report schema includes none, pass, quarantine and reject. pass means no DMARC action on a message that passed under an enforcing policy; none means no DMARC policy action, commonly under a monitoring policy or override. The reported disposition does not settle final delivery because other filters can still act. Do not infer that every counted message reached an inbox or that every rejected row was malicious. Look for high-volume or business-critical failure patterns and affected senders before tightening DMARC.
Make a bounded correction and verify it
If a known sender fails, ask its owner for the actual sending identity and current vendor instructions. Correct only the relevant SPF or DKIM path, preserving one SPF policy at each name and any working selectors. Then send a fresh representative message, check its Authentication-Results header and watch subsequent aggregate reports. A report may arrive later than the test, so use the direct header for immediate feedback.
Where the source is unknown, retain evidence and seek help from the mail operator; do not authorise an IP simply to turn a red row green. Escalate a sudden surge or suspected abuse with the report ID, interval, counts and sanitised sample headers if available. Restrict report access and avoid forwarding raw attachments broadly. Keep the domain’s policy change record so future reports can be interpreted against the correct version.
Common questions
Is a source IP the human sender? No. It is the connecting mail system seen by the receiver and may represent many users or a forwarder.
Does SPF pass mean DMARC pass? Only if the SPF-authenticated domain aligns, or aligned DKIM passes.
Why do counts differ from our sent-mail total? Reports cover the messages observed by that receiver in its period and may group them differently.
Does pass disposition promise inbox delivery? No. It records no DMARC action on passing mail under an enforcing policy; other filters still decide delivery.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.