Establish which report and observation window you are reading
Record the reporting organization, report identifier, covered domain and beginning/end of the reporting period. Normalize timezones before comparing with business activity. Reports can arrive later than the observation window and can overlap with other exports. Distinguish a new reporting interval from another copy of the same report.
Use an appropriate reporting tool or authorized parser, preserving the original record when needed. Confirm the supported report version instead of assuming every XML export or dashboard label is identical. Avoid uploading business reporting data to an unfamiliar public service; source addresses and domain relationships can reveal operational information.
Read fields as separate observations
The connecting source, grouped message count, visible From identity, raw authentication results and DMARC evaluation play different roles. A passing raw DKIM result for a provider domain is not necessarily a passing aligned business-domain result. Read the identities alongside the labels rather than concluding that any occurrence of pass means the intended configuration is complete.
The count belongs to the grouped observation in the report. It is not a count of unique people, compromised accounts or all messages the business sent. Keep the reporting organization and window attached when comparing counts, and do not sum duplicate exports as independent activity.
| Field or group | Question it helps answer | Limit to retain |
|---|---|---|
| Reporter, report ID and date_range | Which observation and time window is this? | Arrival time and observation time can differ. |
| source_ip and count | Which connecting source and message group were observed? | An IP is not automatically a named business sender or attacker. |
| header_from and envelope/signing identities | Which domains were involved? | Visible and authenticated identities may differ. |
| auth_results | What SPF/DKIM results were recorded for which identities? | A raw pass is different from alignment. |
| policy_evaluated and reasons | What DMARC evaluation and handling context was reported? | Reported disposition is not inbox placement. |
| Published policy context | Which policy was observed for the evaluation? | A policy may change during or around a reporting period. |
Map the source to a business system before changing policy
Group observations by the likely sending platform and confirm ownership with the business or provider. Include website forms, invoice services and other third parties. Infrastructure names and IP ownership can support a hypothesis but do not establish that the business authorized a particular message route. Keep known, unknown and under-investigation groups distinct.
For a legitimate source that fails alignment, request a controlled received-message example and compare the provider's supported configuration. For an unknown source, investigate context before authorizing or labeling it. Do not expand SPF solely to remove a red row in a dashboard; an improved-looking chart is not a justified trust decision.
Choose the next check from the result and its limits
If an aligned DKIM signature passes while SPF does not supply alignment, DMARC may still pass. If raw authentication passes but neither identity aligns, investigate the intended domain configuration. If the source is a forwarding or intermediary path, compare its actual message behavior rather than treating it as a new direct sender.
A receiver may report handling influenced by local policy or other context. Read relevant reasons and report-version semantics. A reported reject or quarantine observation should not be restated as a complete delivery history, and a pass does not prove that an authorized account or business request was legitimate.
Build a triage register instead of an automatic enforcement rule
For each material group, record the business owner, evidence window, identities, alignment result, uncertainty and next action. Assign an owner to obtain a sample, correct configuration, confirm a retired source or investigate suspicious use. A useful register separates a confirmed correction from a proposal that has not been tested.
Before using the reports to support stronger policy, review which senders or receivers may be absent and whether periodic systems have been checked another way. The none-to-reject guide turns that evidence into readiness and hold criteria. Report reading alone is not authorization to change the domain's enforcement.
Verify corrections and maintain the reporting boundary
After a supported configuration change, verify fresh controlled messages from the affected source and review later reports for comparable periods. Preserve the original issue and new result so a later owner can understand what changed. Reporting delay and coverage mean an immediate empty dashboard is not proof that the correction resolved every route.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with business-email and digital-infrastructure services. Our Israeli technical knowledge connects report fields to a sender inventory, appropriate technical checks and an accountable next step. Share the domain and reporting question first; private reports and message evidence need an agreed handling scope.
