A sudden increase in reported DMARC failures is a reason to investigate, not a diagnosis. It can reflect a broken legitimate sender, a new impersonation attempt, changed receiver coverage or duplicate ingestion. Start by preserving the observation and finding out which of those explanations the evidence supports.
The workflow below separates report quality, sender authorization, authentication and business impact. It does not assume access to message content or promise that every failure has a unique cause visible in aggregate data.
Freeze a useful incident snapshot
References: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
Save the reporting interval, receiver organization, report identifier, policy domain and affected record counts. Preserve the original report within the organization's approved access and retention controls. Record ingestion time separately from the interval described by the report, since a late arrival can create a dashboard spike today for traffic seen earlier.
Confirm that report retries or reprocessing have not been counted twice. Compare the current and previous windows using equivalent coverage. Record whether the alert means more failed messages, a higher proportion, a new source or a changed disposition. Those are different observations.
Isolate the smallest meaningful affected group
References: RFC 9990 §3.1.1.8, RFC 9990 §3.1.1.10, RFC 9990 §3.1.1.11.
Group by reported source IP, author domain, evaluated SPF and DKIM identities, receiver and policy configuration where available. Keep the aggregate count with each group. Avoid converting one report row into one message or treating an infrastructure owner's name as proof of customer authorization.
Check whether the failure affects all traffic from a known application or only a route, receiver or time slice. Match the result to deployment and DNS change records. A common timestamp narrows an investigation but does not prove causality.
Separate authentication from alignment
References: RFC 9989 §5.3.5, RFC 6376 §6.1.2.
Inspect both SPF and DKIM outcomes and their alignment with the author domain. A passing authentication result under a service's unrelated identity does not supply an aligned path. Conversely, a failing SPF path does not make DMARC fail when an aligned DKIM signature passes.
Illustrative case: an invoice application changes to an unrelated return-path while its DKIM selector points to a missing key. Assume an applicable valid policy, an established absent key rather than a timeout, no other passing aligned signature, and completed SPF checks. Both aligned paths are unavailable in the example, so the observed failures are plausible. The supported repair is to restore the intended signing or envelope configuration after verification, not to add arbitrary IPs until the graph turns green. This is a synthetic diagnostic scenario, not a live incident.
Establish authorization and impact
Ask the known application owner to confirm the route and expected volume. Use controlled received messages, sending logs and customer-impact evidence when available. Redact unnecessary content before sharing evidence. If nobody can establish authorization, retain an unknown-source classification rather than legitimizing the source through DNS changes.
Prioritize disrupted password resets, invoices or essential notices using actual impact evidence. A large stream of apparently unauthorized failures under enforcement may need abuse analysis, while a small legitimate failure may require immediate service recovery. Keep those workstreams distinct.
Repair the supported cause and verify
Make the smallest authorized change supported by the diagnosis. A domain-wide policy rollback weakens enforcement for unrelated mail and should not be the default response to an unexplained graph. If a temporary exception is justified, document its scope, approver, risk, owner and expiry.
Send a new controlled message through the affected route and inspect trusted receiver authentication results. Then confirm that subsequent comparable reports support recovery, allowing for reporting delay. Close with the cause, change, evidence and remaining coverage limits. If the cause remains uncertain, say so and name the next test rather than recording a guessed fix as proven.
Bound the conclusion and next action
For the fictional invoice regression, obtain the exact signing selector and domain, authoritative lookup evidence and trusted receiving result before choosing a repair. A no-key observation is not evidence that unrelated IP authorization fixes the message. No DNS lookup, incident repair or mail test was executed.