Aggregate reports arrive as gzipped XML, daily, from every participating receiver. The question is not whether to parse them yourself — it is what you lose by not having a copy.
Three arrangements
| What it gives | What it costs | |
|---|---|---|
| Processor only | Parsing, history, trend lines, sender identification | No independent copy. When the contract ends, so does the history. |
| Mailbox only | A complete archive you own | Raw XML nobody will read. In practice this is the same as having no reporting. |
| Both | Analysis now, and an archive that outlives the vendor | A mailbox that fills up, and a second destination in the record |
Both is the right answer for any domain you would be unhappy to lose the history of, and it is what the more careful public records do. HMRC sends to a processor, a departmental mailbox and a cross-government collector; Cloudflare sends to a processor and to rua@cloudflare.com.
Practical limits
- Two destinations is the safe maximum. Some receivers cap the number they will honour and do so without telling you. A record with five addresses may be delivering to two of them.
- Order is not priority. Nothing in the specification says the first address is preferred, so do not rely on it.
- Each external destination needs its own authorisation record in its own zone.
- A size limit can be expressed —
rua=mailto:x@example.com!10masks receivers not to send reports above 10 MB. It is rarely needed and rarely honoured.
If you keep a mailbox
Give it its own address rather than a person’s, exclude it from mailbox size alerts, and make sure it is not itself subject to a filter that quarantines mail from unknown senders — which is exactly what a report from a receiver you have never corresponded with looks like.
The archive matters more than it seems
The first question during a spoofing incident is usually “when did this start?”, and the answer lives in reports from months ago. A processor trial that expired, or a vendor you left, takes that answer with it unless you kept a copy.