Define a report importer before defining a dashboard
A DMARC XML analyser receives potentially hostile files, not inherently trustworthy statistics. Its first responsibility is to control what it accepts and how much work an input can trigger. Only after safe ingestion should it interpret report fields, correlate records or calculate rates. A parser crash or rejected attachment is a collection problem, not an authentication failure by the reported domain.
This article proposes that pipeline but implements none of it. No report was imported, decompressed or evaluated, and no EmailAuth analyser capability is asserted. The exact working-tool gate remains: Implement and test the promised function. An article, mock-up or specification alone is not a working tool.
Classify the input and bound expansion
Record the source channel, receipt time, declared media type, original filename and a controlled artifact identifier. Treat filename and media type as claims to validate, not proof of safe content. Accept only the documented report formats and compression methods supported by the intended implementation. Define a rejection path for unsupported archives rather than extracting arbitrary nested content.
Set separate limits for incoming bytes, expanded bytes, compression ratio, processing time, memory, nesting and record count. Enforce limits during streaming and decompression, not only after a large object has been built. If a container format is supported, handle member paths and counts safely and do not extract user-selected paths into application directories. The exact thresholds are an implementation decision requiring tests, not universal DMARC constants. OWASP file-upload controls.
Harden every XML processing stage
The proposed importer should reject document type declarations where supported and prevent external entity resolution, external DTD retrieval and unnecessary XInclude. Schema validation and stylesheet processing need their own external-resource restrictions; securing only the initial parser is insufficient. Use trusted local schemas selected by application logic, not a network location supplied by the document.
Treat an unsupported security setting as a configuration failure rather than silently continuing with partial protection. Disable unnecessary network and filesystem access in the processing environment and test the actual parser version and options. Blocking external entities does not by itself prevent resource-exhaustion attacks. OWASP XML External Entity Prevention.
Python illustrates why version labels alone are inadequate. Its live documentation, labelled Python 3.15.2 when reviewed, explains that XML behavior depends on the Expat library and whether the interpreter uses a bundled or system copy. It warns about older Expat versions and several resource attacks. This is a documentation example, not a finding about an installed runtime or a recommendation that one default configuration makes all XML safe. Python XML security.
Interpret the current schema without disguising compatibility
RFC 9990, published in May 2026, defines current DMARC aggregate reporting. Its XML namespace is urn:ietf:params:xml:ns:dmarc-2.0, while the optional version element, if present, has value 1.0. Those labels describe different things; do not rewrite one to match the other. Retain the detected schema and namespace beside the parser version. RFC 9990 schema description.
If an importer supports legacy or vendor-specific variants, declare the compatibility path and its limitations. Do not silently label a transformed legacy document as an untouched current-format report. Preserve unknown extension data appropriately or document why it was ignored, while keeping resource limits active. Format validation and semantic validation are separate stages: a well-formed XML document can still have unusable reporting dates, missing required fields or unsupported values.
Current RFC 9989 describes DMARC itself; RFC 9990 describes aggregate XML, and RFC 9991 describes failure reports about individual messages. Failure reports may include sensitive headers or message content and do not belong in the aggregate XML path merely because their subject mentions DMARC. Classify them separately and obtain the appropriate privacy approval. RFC 9989 and RFC 9991.
Retain provenance through deduplication and analysis
Preserve the reporting organization, report identity, policy domain, reporting interval, arrival time and raw-artifact reference. Record parsing and transformation versions. An identical byte hash can identify an exact duplicate file, but it does not resolve every case of overlapping or revised data. RFC 9990 permits receiver choices for handling duplicates; the analyser must state its policy and show how it affects totals.
Separate raw SPF and DKIM results from the DMARC-related alignment results and reported disposition. Avoid counting rows as messages when a row carries a message count. Also avoid treating valid XML as authenticated truth: RFC 9990 explicitly warns that reports can contain forged information intended to influence decisions. Preserve confidence and corroboration limits rather than automatically authorizing senders or changing policy from imported statistics. RFC 9990 duplicate and security guidance.
Make rejection and recovery reviewable
A rejected input should produce a bounded error with a reason category, parser version and artifact reference, without dumping private contents into ordinary logs. Quarantine under approved access controls, record whether any partial data was retained, and ensure partial records cannot silently enter production totals. A later reprocessing run should identify its changed parser or policy and preserve the earlier outcome.
The commissioning evidence is still absent: A malicious-and-malformed fixture suite with resource limits, expected results and recovery behaviour. Required cases would include oversized expansion, prohibited external references, deep nesting, invalid schema, duplicate identifiers and interrupted processing. These are proposed cases, not payloads executed or tests passed. Sources were reviewed on 8 November 2026. Security review, implementation evidence, independent checking, visual inspection and owner release remain open.