2023-04-30

DMARC offers a mechanism for the public to report observations about mail claiming to be from your domain. In the common case of spoofed sender identities, reports of authorization failures are merely tattling and typically unactionable, but if ever innocent misconfiguration is responsible, the reports serve as valuable alerts. Monitoring for anomalies in DMARC reports is part of the ordinary diligence due when operating a mail domain.

A popular solution to this is to build elaborate web dashboards with interactive visualizations and metrics backed by a 24×7 application and long-lived database. This can be helpful for studying the complex mail systems of large organizations, but is overkill for the purpose of monitoring for rare accidents.

In pursuit of reduced maintenance burden, I’m trying out just a scheduled job that upon notice of authorization failure forwards the day’s reports for human review:

⛔ 1 message blocked

Count	Sender	SPF	DKIM	DMARC	Reporter
1	IP: 192.0.2.1 rDNS: example.com Envelope: example.com Header: example.com	⛔ example.com: pass	⛔ example.com: pass	⛔	Example

✅ 12 messages allowed

Count	Sender	SPF	DKIM	DMARC	Reporter
6	IP: 192.0.2.2 rDNS: example.com Envelope: example.com Header: example.com	✅ example.com: pass	✅ example.com: pass	✅	Example
3	IP: 192.0.2.3 rDNS: example.com Envelope: example.com Header: example.com	✅ example.com: pass	✅ example.com: pass	✅	Example
2	IP: 192.0.2.3 rDNS: example.com Envelope: example.com Header: example.com	✅ example.com: pass	✅ example.com: pass	✅	Example
1	IP: 192.0.2.4 rDNS: example.com Envelope: example.com Header: example.com	✅ example.com: pass	✅ example.com: pass	✅	Example

Initially I had it send notifications via email, but switched to Matrix to piggyback on its access control for ease of collaboration within SeaGL. My attempts to send complex tables through Matrix eventually led to my first spec proposal, MSC4003.