Howdy,

Disclaimer: I haven’t reviewed the latest or current drafts in detail, so 
please take this as general feedback rooted in practical implementation 
experience.

I'll keep this brief.

From the early days of DKIM reporting, I was never a strong believer in the 
concept. I supported proposals that aimed to decouple reporting from DMARC 
enforcement logic. That said, I’ve long included reporting addresses in my 
public DMARC policies and have maintained dedicated storage for any reports 
received for our customers and our support system.

Over time, I’ve consistently found these reports to be:

Difficult for humans to read and interpret, and

Lacking key data points needed to make them practically useful.

In my view, the most valuable reports are those indicating failures (under 
p=reject or p=quarantine), or potential issues under p=none. But due to 
uncertainty in the data's usefulness, I’ve historically avoided applying 
automated rejection based on them—favoring logging and analysis instead.

Now that I'm revisiting and analyzing these archived reports, I find my 
original assessment still holds true: the information is insufficient to draw 
actionable conclusions or to automate protections confidently.

What would a useful “ad hoc” default report include?

Something that enables immediate visibility for sysadmins and automation 
agents—without requiring an XML viewer:

The reporting entity (domain/IP)

Total number of failures

Date/time ranges of the failures

List of MX (verifier) domains reporting failures, with associated client IPs

DKIM policy that was evaluated

Because this isn’t the default structure, I’m now working on a project to 
extract meaningful insights from these XML reports through custom parsing.

In summary:

Default DMARC reports should be designed to help sysadmins, operational staff, 
and automated agents quickly identify protection gaps and make informed 
adjustments. We’re not quite there yet.

All the best,
Hector Santos


_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to