An AI-generated DMARC recommendation should be an inspectable argument. It should tell the operator what was observed, what is inferred, what remains unknown and what action is justified. Confidence wording alone is not evidence, and a polished explanation must not hide missing sender ownership or incomplete reporting coverage.
Preserve the evidence chain
Retain report identity, reporting receiver, interval, source address, count, identifiers and authentication outcomes. Attach the relevant service-register entry and approved change history when available. RFC 9990 describes aggregate observations; those observations do not establish that every sent message was seen or that a source address belongs to a particular business application.
Use an evidence reference for each material claim. Distinguish a report's observed authentication result from the agent's explanation of why it happened. If a mail sample and provider configuration disagree, preserve both rather than choosing whichever supports the proposed fix. Identify the freshness of each observation and the scope of the missing information.
Make uncertainty actionable
A useful recommendation states plausible alternatives and the next discriminating test. For example, a shared IP with an unfamiliar signer could represent a new service, an indirect path or unauthorized use. Ask for account-specific configuration and an owner decision before authorizing it. Do not turn a numerical confidence score into a business approval.
Define allowed outputs such as investigate, request_owner_confirmation, prepare_diff and escalate. Permission to analyze does not imply permission to publish records or send external messages. OWASP's excessive-agency guidance supports minimizing tool authority; the output schema and guard checks here are a local design rather than a vendor capability claim.
Prepare concrete counterexamples before testing
A proposed evaluation set should include a report note requesting an unrelated write, provider-name-only attribution, missing evidence, conflicting owner records and a supported read-only recommendation. For the unrelated write, the expected boundary is no mutation and a scoped evidence-only response. For missing ownership, the expected output is a specific evidence request rather than invented approval. Define these expectations before seeing the system’s answers.
These are test-design categories, not a supplied adversarial corpus or executed validator. Construct concrete authorized inputs and labels, version them and submit them through the actual agent’s normal ingestion and permission boundary. Retain responses and tool effects, including refusals, unexpected actions and uncertain outcomes. A deterministic schema check can test declared fields but cannot establish model accuracy or prompt-injection resistance. Add cases from authorized failure records without copying unnecessary personal content.
Deliver a bounded decision
State what can safely happen now, who must decide the unresolved question and what evidence would change the recommendation. For an authentication failure, distinguish alignment from raw SPF or DKIM pass, as RFC 9989 requires. Do not promise delivery improvement from an untested DNS edit. Review the actual tool trace as well as the explanation: a cautious answer does not compensate for an unauthorized side effect.
Primary reading: OWASP LLM06 2025 Excessive Agency, RFC 9990 DMARC Aggregate Reporting, RFC 9989 DMARC.