Add a rua=mailto:reports@yourdomain.com (or a dedicated third-party ingestion address) to your DMARC record so receiving servers know where to deliver daily XML reports.
Receiving servers send gzip-compressed XML attachments (.xml.gz or inside a .zip) once per day; set up a mailbox rule or IMAP fetch to land these in a processing folder.
For self-hosted parsing, use the open-source parsedmarc tool: it reads the XML schema, extracts per-source IP rows (spf_result, dkim_result, disposition, count), and can forward structured data to Elasticsearch or a Kafka topic.
Map each source IP to a known ESP or internal mail server using PTR lookups and a maintained allowlist; flag unknown IPs for investigation.
Build alerting on disposition=quarantine or disposition=reject rows with count > threshold to catch misconfigured or rogue senders quickly.
Archive raw XML for at least 30 days and retain parsed records for trend analysis; correlation across providers reveals SPF alignment gaps that single-provider views miss.
Known gotchas
Some receivers send reports to every address listed in rua= separately, so multiple addresses (comma-separated) can cause duplicate ingestion—deduplicate on the report_metadata/report_id field.
DMARC aggregate reports cover a calendar day in the sender's timezone, not yours; timestamps in report_metadata/date_range/begin and end are Unix epoch UTC—convert carefully before trending.
Large senders (Google, Microsoft) send high-volume reports; allocate sufficient mailbox or object-storage quota and decompress before parsing to avoid truncation errors.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp