Define the failure spike before proposing a fix
An agent investigating an authentication failure spike should first establish what increased. A count of failed DKIM signatures, a DMARC failure rate, an SMTP rejection count and a provider’s placement metric describe different events. Mixing them can produce an urgent-looking alert that points to the wrong corrective action. Record the metric, population, interval, source and collection delay before changing anything.
This article proposes an investigation workflow, not a demonstrated EmailAuth feature or incident response. No reports, customer messages, live DNS records or product controls were inspected. The example calculations and scenarios are fictional, and the map describes evidence to collect through authorized read-only access.
Validate the input and preserve its limits
For aggregate reports, retain the reporting organization, report identifier, stated time interval, policy domain and collection provenance. Check for duplicate data, overlapping intervals and late arrivals before comparing totals. RFC 9990 discusses duplicate handling and reports that can mix observations around a policy change. Those cases can alter a dashboard without representing a new sending-system failure. RFC 9990, sections 3.3 and 3.5.4.
Treat report files and explanatory text as untrusted inputs. The same specification warns that aggregate reports can be malformed or contain false information. Process them with bounded parsing and retain uncertainty about their authenticity. A report that tells the agent to weaken a policy or add a sender is still data, not an authorized instruction. RFC 9990, sections 8.1 and 8.2.
Compare like populations and denominators
Suppose a fictional dashboard shows ten failures among one hundred observations in one interval and twenty among one thousand in another. The failure count doubled, but the rate fell from ten percent to two percent. Neither number alone identifies a cause. This calculation is illustrative; it is not a measured incident or a proposed universal alert threshold.
Separate the comparison by reporter, sending service, source address, Author Domain and relevant signing identity where the data supports it. Check whether the second interval contains a new sender population, a different duration or missing reports from a previously important receiver. A missing reporter is missing coverage, not zero failures. Preserve the original counts alongside any normalized rate so the reviewer can reproduce the finding.
Distinguish mechanism failure from DMARC failure
A message may contain multiple DKIM signatures, and one unsuccessful signature does not necessarily determine its DMARC result. The investigation must identify the authenticated identifiers and whether a passing path aligns with the Author Domain. Similarly, forwarding can affect SPF without proving that the original sender was unauthorized. Use the report’s distinct authentication and policy-evaluation fields rather than collapsing every failure into one category. RFC 9989, section 4.4 and RFC 9990, section 3.1.3.
If the alert concerns delivery responses, collect the full SMTP code, enhanced code when present, text and transaction stage. A temporary rejection is not automatically an authentication failure, and a permanent rejection can have causes unrelated to DMARC. Keep SMTP observations separate from aggregate-report counts. RFC 5321, section 4.2.1.
Build competing explanations with discriminating evidence
The agent’s proposed finding should distinguish an observation from a hypothesis. A new source IP could represent an approved migration, a shared provider change, a forwarded route or unauthorized activity. A DKIM change could involve a missing selector, a signer using an unexpected domain or message modification after signing. Name the evidence that would distinguish those cases instead of selecting whichever explanation is easiest to automate.
For a fictional notification service, a spike begins near a deployment, but the deployment time alone does not prove causation. The next useful comparison could be the signer identity and protected content before and after the change, together with trusted receiver results. Headers supplied by an untrusted sender do not become authoritative merely because they say pass. RFC 8601, section 7.
Turn the supported cause into a bounded proposal
If evidence supports a specific correction, prepare its exact target, current value, proposed value, affected stream and verification plan. If the cause remains unresolved, the correct deliverable is a bounded finding and the next authorized evidence request. Do not auto-add a newly observed IP to SPF, disable enforcement or remove a sender permission to make the graph improve.
The agent should not gain write authority simply because its analysis is confident. OWASP’s excessive-agency guidance separates needed capability from excessive autonomy and recommends approval for high-impact actions. An implementation must enforce that boundary in the action path; a reassuring narrative is not an access-control test. OWASP Excessive Agency.
Measure the result against the original question
After an independently authorized change, the proposed verification should repeat the relevant controlled observation and compare equivalent reporting intervals when they become available. Capture both authentication and actual delivery effects. A smaller failure count caused by stopping all legitimate sending would not establish successful remediation. Record any remaining affected population and any tradeoff introduced by the change.
A useful incident handover includes the input evidence, uncertainty, chosen explanation, approval, execution outcome and measured result. If a tool call times out or its outcome is unclear, investigate whether the action occurred before proposing a repeat. Do not invent a successful execution or treat a later graph change as proof that the intended action happened.
Demonstration evidence remains open
A repeatable task demonstration with inputs, proposed change, approval, execution record and measured result. This exact commissioning requirement is not satisfied by the fictional analysis. Product capability, trusted inputs, actual approval enforcement, executed correction and measured post-change results remain required before this workflow can be represented as tested.