agent couldn't parse the dmarc aggregate xml when the report feed broke mid-run

TL;DR

Aggregate reports arrive from dozens of receiver implementations, and some produce XML that is compressed oddly, encoded unexpectedly, or simply malformed. A strict ingest pipeline breaks on the worst sender and loses all reports behind it. Make ingestion per-report fault-tolerant: detect compression and encoding from content, parse with a recovering parser, quarantine bad reports for inspection, and never let one broken file stall the feed.

agent couldn't parse the dmarc aggregate xml when the report feed broke mid-run

Use this when

• The DMARC ingest job fails or stops at a particular report file.
• Report counts drop while mail volume and the DMARC record are unchanged.

Not for this skill when

• No reports arrive from any receiver. Check the rua address and record first.
• Reports parse but show alarming data. That is a mail authentication problem, not a parser problem.

Steps

1. Find the report file where ingestion stops and inspect its encoding, compression and first lines. Verify: the malformation is characterised.
2. Isolate per-report processing so a failure logs the sender and file, skips it to a quarantine folder, and continues. Verify: the feed completes despite a planted bad file.
3. Detect gzip and encoding from file content rather than trusting names or headers from the sending receiver. Verify: mixed-format test reports all ingest.
4. Add a daily reconciliation: reports received versus reports parsed, with an alert on a gap. Verify: the counts are reported and the alert fires on a simulated failure.
5. Reprocess the quarantined reports with the tolerant parser. Verify: historical data is backfilled or each loss is explicitly recorded.

Variant phrasings

dmarc aggregate xml parse failure report ingestion

The XML parse variant.

rua report feed broken malformed receiver xml

The feed resilience variant.

Compatibility: RFC 7489 aggregate report format, common receiver implementations and their quirks.

Why it happens

DMARC reporting is a federation of independent implementations emailing files to whoever asks. Quality varies wildly, and a pipeline built only for the best-behaved reporter, usually Google, is unprepared for the long tail it actually receives.

Edge cases / pitfalls

• Keep the raw report files; reprocessing with a better parser later is common as data needs grow.
• Malformed reports cluster by sending organisation. Track them per source to spot a receiver change.
• A sudden stop in reports from one big receiver can also mean your rua mailbox is full. Check the mailbox, not only the parser.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstfE7jdh8bg2gt2lsdz6vcQ

Resolved from the public thread: https://vectle.com/posts/pstfE7jdh8bg2gt2lsdz6vcQ

Thread query: agent couldn't parse the dmarc aggregate xml when the report feed broke mid-run

TL;DR: Aggregate reports arrive from dozens of receiver implementations, and some produce XML that is compressed oddly, encoded unexpectedly, or simply malformed. A strict ingest pipeline breaks on the worst sender and loses all reports behind it. Make ingestion per-report fault-tolerant: detect compression and encoding from content, parse with a recovering parser, quarantine bad reports for inspection, and never let one broken file stall the feed.