How to Write a DMARC Report Your Security Team Can Act On
A DMARC report should do more than prove that email authentication is configured. It should help security professionals identify impersonation attempts, trace legitimate sending services, and decide which domains or systems require attention first.
The most useful reports connect technical evidence with business impact. Instead of presenting raw authentication results, they explain what happened, how confident the team can be, and what action will reduce risk.
Define the decision the report must support
Start by stating the report’s purpose in one sentence. For example, the goal might be to assess readiness for a stricter DMARC policy, investigate unauthorized email sources, or measure progress toward full domain protection.
This decision determines which data deserves emphasis. A policy-readiness report needs alignment rates and legitimate sender coverage, while an incident-focused report should highlight unfamiliar infrastructure, failed authentication, message volume, and affected domains.
Include the reporting period, domains covered, DMARC policies observed, and the systems that supplied the data. Clear scope prevents readers from treating a limited sample as a complete view of email activity.
Separate evidence from interpretation
A security team should be able to distinguish what the report proves from what it suggests. Evidence may include source IP addresses, sending organizations, message counts, SPF results, DKIM results, alignment status, and the applied DMARC disposition.
Interpretation explains why those facts matter. A large volume of messages failing both SPF and DKIM may indicate spoofing, a forgotten SaaS integration, or a forwarding problem. The report should identify these possibilities without presenting an assumption as a confirmed incident.
Use consistent terminology for pass, fail, neutral, unknown, and unverified results. Teams can review findings faster when the same labels carry the same meaning across reporting periods. The DMARC guidance can help establish a reliable foundation for authentication terminology and policy analysis.
Present the data in an operational format
Raw XML is valuable for machines, but it is difficult to use during a security review. Summarize the most important fields in a readable format, then retain links or references to the original records for investigation.
| Finding | Evidence to show | Likely meaning | Immediate owner |
|---|---|---|---|
| Unknown sender | IP, organization, volume, dates | Possible spoofing or undocumented service | Security and domain owner |
| SPF failure | SPF result, envelope domain, source | Sender is not authorized or alignment is broken | Email administrator |
| DKIM failure | Signing domain, selector, result | Signature is missing, invalid, or altered | Messaging or application team |
| High-volume legitimate failure | Sender identity, volume, policy result | Business service may be misconfigured | SaaS or application owner |
| Repeated abuse pattern | Sources, targets, frequency | Persistent impersonation attempt | Security operations |
Use thresholds that match the organization’s risk tolerance. For example, a previously unseen source sending thousands of messages deserves faster review than a single failed message from a known forwarding service.
Charts can show trends, but every visual should answer a question. A line chart might show whether aligned traffic is improving; a ranked source list can reveal which services generate the most failures.
Prioritize findings by risk
A useful report ranks issues instead of giving every anomaly equal weight. Consider message volume, authentication failure type, domain sensitivity, sender reputation, recurrence, and whether the source is recognized by the business.
A practical severity model might classify findings as critical, high, medium, or informational. Critical items could include high-volume spoofing of a finance or executive domain. Medium findings might involve a legitimate vendor that sends without DKIM alignment. Informational items may simply document a known forwarding path.
Each priority should include a reason. “High risk” is less actionable than “High risk because 42,000 messages claiming to use the payroll domain failed both checks and originated from an unrecognized network.”
Assign ownership and measurable actions
Every significant finding needs an owner, a due date, and a verification method. Security operations may investigate suspicious infrastructure, while messaging administrators update DNS records and application teams configure DKIM signing for approved services.
Write actions as outcomes rather than vague instructions. “Review vendor authentication” is weaker than “Confirm whether Vendor X sends for the payroll domain, publish its DKIM selector, and verify aligned messages in the next reporting cycle.”
Record the expected result and the condition for closure. A finding can be marked resolved when aligned traffic reaches an agreed threshold, an unauthorized source stops appearing, or the domain owner confirms that the sender was decommissioned.
Recommendations for a repeatable reporting process
Use the same reporting format every cycle so changes are easy to detect. A consistent process should include:
- State the reporting period, domains, policy settings, and data sources.
- Rank findings by business impact, message volume, and confidence.
- Separate known legitimate senders from unverified or suspicious sources.
- Assign each action to a named team with a deadline and success measure.
- Compare current results with earlier reports to show whether risk is declining.
Automation can make this workflow faster for large domain portfolios. Bulk checks and developer integrations can collect trust signals before a report reaches the review queue; the developer verification tools are useful when teams need to connect domain checks with internal workflows.
A report becomes valuable when it leads to a decision, a responsible owner, and a measurable follow-up. Use Trusted Sender Score to examine domain reputation and authentication signals, then turn the resulting evidence into a focused security review that protects legitimate email and exposes impersonation sooner.