DMARC reporting

DMARC reporting is a routing and diagnosis loop. Identify every service sending for the domain, separate authentication results from receiver action, and decide what needs fixing or investigation. Do not look only at failures. Aggregate reports also include mail that fully passed DMARC, so the source inventory can include healthy-looking senders.¹ They can reveal forgotten senders and broken authentication. Read each report for who used the domain, how authentication performed, and what the receiving system did with the result.

Confirm the report feed

Make sure reports reach a destination you can inspect before interpreting them. A missing or incomplete feed weakens every later conclusion.

DMARC can be set up to receive regular reports from email servers that receive email from your domain.² The rua tag specifies where aggregate daily summary reports should be sent.³ Once the DMARC record is in place, participating mailbox providers send daily aggregate reports to that destination.⁴

Check that the destination is monitored, that reports cover the period you expect, and that the senders you care about appear in the feed. If reports are not arriving, fix collection before explaining authentication results.

Separate report types

DMARC has two report types: aggregate reports and forensic reports.⁵ Aggregate reports show which emails authenticate against SPF, DKIM, and DMARC and which do not.⁶ They contain limited detail about individual messages, but can help identify possible authentication issues or malicious activity.⁷

Individual failure reports, also called forensic reports, are copies of individual email pieces that fail the DMARC check.⁸ They are not always available because of privacy concerns, volume concerns, or the view that they are unnecessary for accurate DMARC deployment.⁹

Use aggregate reports to establish the sending picture. Use a forensic report for detail on a particular failure when the receiving system provides one. If that detail is unavailable, work from the source, authentication, and receiver-action information in the aggregate report.

Read aggregate reports in work order

Move from identity to result to consequence. This keeps a high pass rate or a large failure count from hiding who is responsible for the traffic.

Build the source inventory

Group the observed traffic by server or service. DMARC reports identify the servers or third-party senders sending mail for your domain and show their pass or fail status.^{10, 11}

For each source, record whether you recognize it, need to confirm it, or need to investigate it. Continue until every meaningful source has a disposition: recognized, awaiting confirmation, or open for investigation.

Check authentication and coverage

Compare what each source sends with its authentication results. Reviewing report information helps you understand which messages sent from your domain are passing SPF, DKIM, and DMARC authentication.¹² Reports also show what percentage of messages from your domain pass DMARC.¹³

Use the percentage as a health signal, then return to the source breakdown. Reports can show how much legitimate mail traffic is covered by DMARC and help troubleshoot problems.¹⁴ Identify the source behind the failing traffic, whether it is expected, and whether the failure affects delivery. The pass rate should be explainable by source, not just quoted as a total.

Isolate failures

Treat each failure as a separate case. A report can identify which servers or services are sending messages that fail DMARC,¹⁵ and a configured DMARC reporting tool will report alignment issues.¹⁶

For a recognized sender, investigate its authentication setup and alignment. For an unknown sender, investigate whether the traffic represents possible abuse. DMARC reports can help identify possible authentication issues and malicious activity involving messages sent from a domain.¹⁷ Keep these paths separate so a configuration problem is not treated as a spoofing incident and a suspicious source is not treated as routine maintenance.

Read receiver action

For each source, check what the receiving system did with the unauthenticated message. DMARC reports show whether the receiving server takes no action, quarantines, or rejects unauthenticated messages from your domain.¹⁸

Compare that action with what you intended for the domain. Then decide whether the source needs correction, further investigation, or a policy change. DMARC reports give administrators information for deciding how to adjust policy when legitimate mail fails authentication or illegitimate mail is attempted.¹⁹

Close the loop

A review is complete when every source has an owner, an explanation, or an open investigation. Keep it recurring so new senders and new failures enter the same process.

Regularly review aggregate reports to monitor where mail from your domains is coming from and to check for unintentional DMARC failures.²⁰ If DMARC is already set up, review the reports to check that messages are being authenticated effectively and delivered as expected.²¹

Keep a separate watch for fraudulent messages. DMARC reports can show how many fraudulent messages are being sent and where they are sent from.²² Keep a recognized source in routine monitoring when it passes and delivery works as expected. Leave an unknown or repeatedly failing source open for investigation until you can explain the traffic.

What not to do

• Do not turn on DMARC without requesting reports. The source recommends always using reports when turning on DMARC for a domain.²³
• Do not use the total pass percentage as a substitute for a source inventory. Reports identify the servers and third-party senders using the domain.¹⁰
• Do not build the process around forensic reports being available. Privacy concerns, volume concerns, and deployment choices can make them unavailable.⁹
• Do not adjust policy before checking whether failing traffic is legitimate mail or an illegitimate attempt. Reports provide the information used to make that decision.¹⁹