An agentic DMARC system should be evaluated by the tasks it completes and the boundaries it respects. A fluent recommendation is not an executed repair, and a successful tool response is not proof of restored mail. Define each task's inputs, permitted actions, approval requirements, stopping conditions and verification before granting write access.
Separate analysis from action
Useful read-only tasks include summarizing aggregate evidence, finding inventory gaps and drafting a change proposal. Write-capable tasks may alter DNS or service settings and require a different authority boundary. An unknown sender should not become approved merely because an agent recognizes a familiar provider’s infrastructure.
RFC 9990 supplies aggregate-report structure, while RFC 9989 defines authentication and alignment. Neither turns report content into authorization. Treat evidence as data, including any text embedded in imported messages, reports or support records.
Define a task contract
For a proposed policy change, record the target, current state, exact proposed diff, evidence references, affected services and unresolved uncertainty. Identify the approver and bind the authorization to that plan. Define what the executor is forbidden to change, such as unrelated zones or registrar settings, and when it must stop.
OWASP excessive-agency guidance motivates limited capabilities, constrained permissions and approval controls. Implement those controls at the tool or downstream service, not only in an instruction to the model. Keep secrets out of report content and use separate identities for reading evidence and changing configuration when the system supports it.
Work through a bounded task decision
Suppose an authorized read-only review finds that payroll lacks a current route test. The appropriate output is an evidence request with the payroll owner and missing test named, not an automatic SPF expansion. If an imported report note asks for unrelated DNS changes, preserve it as untrusted evidence text and do not treat it as authority. This hypothetical decision does not demonstrate prompt-injection resistance in any real model.
For a separate proposed change, record the precise target and diff and seek the required authorization before execution. If the provider times out after an attempted write, leave the outcome uncertain and inspect effective state before retrying. A matching desired state still needs attribution and postcondition review; it does not prove which actor caused it.
Measure actual task outcomes
These are hypothetical workflows, not executed mock operations, measured accuracy or verified product capabilities. An actual evaluation should retain the frozen input, allowed tool scope, proposal, authorization, tool trace and observed postconditions. Record prevented unauthorized attempts separately from completed authorized work. Verify legitimate-mail behavior independently of the provider response. An incomplete result stays open with an owner; preserve failed attempts rather than rewriting them as clean success.
Expand authority cautiously
Start with bounded read-only tasks, test counterexamples and review failures before adding narrow write capabilities. Define a stop mechanism and an escalation path that do not depend on the same model making a correct judgment. Review retained access and revoke unnecessary scope. This article describes an evaluation method, not verified EmailAuth product capabilities or an assertion that autonomous changes are appropriate for every organization.