triage agent quarantined legitimate dmarc aggregate reports after misreading them as phishing attachments

TL;DR

Teach the agent that DMARC report mail is infrastructure, not user content: identify aggregate reports by their sender patterns, subject shape, and XML or zip attachment structure, route them to the report processor before any phishing verdict runs, and keep them out of quarantine unless a separate check shows tampering. These reports arrive as opaque attachments that look exactly like the lure attachments the agent was built to distrust, so without an explicit early rule the agent eats the evidence it needs.

triage agent quarantined legitimate dmarc aggregate reports after misreading them as phishing attachments

Use this when

• DMARC aggregate reports from major receivers are found in quarantine or in the agent incident queue.
• The report attachments are standard XML, often zipped or gzipped, from known reporting domains.
• Your DMARC reporting or the agent campaign view shows gaps matching the quarantined reports.

Not for this skill when

• Reports are missing because receivers stopped sending them. That is a rua or verification problem, not agent triage.
• A report like attachment really was malware in a user report. Keep normal detonation for user submitted items.

Steps

1. Pull a quarantined report and record why the agent scored it: which features fired and at what stage of its pipeline. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the scoring features that caught the report are listed
2. Define the report recognition rule from stable traits: reporting sender domains, subject containing the domain and report ID pattern, and an XML report attachment with a DMARC root element after decoding. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the recognition rule is written with at least two independent traits required
3. Insert the rule before phishing scoring so matched mail goes straight to the report processor and is logged as a report, not an incident. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: a test report is routed to the processor with no incident created
4. Add a negative test: a user reported phish with a random zip attachment must still go through full triage and detonation. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the negative test is scored and detonated normally
5. Backfill the processor with the reports recovered from quarantine for the affected period. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the report timeline shows the recovered reports ingested

Why it happens

DMARC aggregate reports are machine mail with unusual traits: bulk senders, compressed XML attachments, and subjects full of IDs and domains. To a content triage agent trained to fear attachments from bulk senders, a report is indistinguishable from a lure without explicit domain knowledge. The bug is an ordering problem as much as a classification problem: infrastructure mail must be recognised by the pipeline before the suspicious content stage ever sees it.

Variants and edge cases

triage agent quarantined dmarc aggregate reports misreading phishing attachments

The exact misclassification wording.

dmarc reports quarantined by agent recognise report mail routing

The routing fix variant.

agent flags dmarc xml zip attachments as phish allowlist reports

The attachment trait variant.

Compatibility: RFC 7489 DMARC aggregate report format, agent pipeline rule ordering, report processors.

Edge cases to check:

• Validate the XML against the DMARC schema even on the trusted path; routing early is not the same as trusting blindly.
• Keep the reporting mailbox separate from user report intake so the recognition rule never applies to user submitted mail.

Provenance

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