Separate incident containment from reputation recovery
A compromised sending account creates two connected problems. An unauthorized actor may still have access, and recipients or providers may have learned to distrust the resulting mail. Stopping the actor is the first priority, but it does not establish that delivery reputation has recovered. Treat containment, restoration of legitimate sending and recipient outcomes as separate stages with separate evidence.
This article is a proposed recovery framework, not an incident report. No account, credential, message trace, blocklist entry or provider dashboard was inspected. Any security action must be carried out by an authorized responder using the applicable provider procedure. A publication draft cannot serve as permission to reset credentials, revoke access, delete mail or contact affected recipients.
Contain the access path before increasing traffic
Microsoft’s compromised-account guidance, updated 17 July 2026, recommends blocking access during investigation and addressing persistence, not just changing a password. It includes session, authentication-method, application-consent, role and forwarding reviews. Those are Microsoft-specific response areas; an actual environment needs the corresponding authorized steps and evidence. Do not send new secrets into a mailbox the attacker may still access. Microsoft compromised-account response.
Name an incident owner and record the time each containment action actually completed. Keep planned actions, submitted actions and verified outcomes distinct. A successful password change is not evidence that every token, connected application or forwarding rule has been addressed. Preserve relevant logs under the organization’s incident-handling process before retention limits or remediation changes erase the context needed to understand the event.
Define what was affected
Build a bounded incident window from the earliest supported suspicious activity to the latest verified unauthorized action, with uncertainty clearly stated. Identify affected accounts, sending streams, outbound infrastructure and recipient populations. A single compromised user may share infrastructure with legitimate applications, while a compromised integration can reach more than one visible mailbox. Do not infer the full scope from one folder or one alert.
The impact record should separate unauthorized messages from legitimate messages that were delayed, rejected or filtered because of the incident. Retain counts with a denominator and source: affected recipients out of what population, during which interval, at which provider? Unavailable telemetry is a limitation, not a zero. Avoid distributing personal message contents beyond the people authorized to investigate.
Check authentication without treating it as innocence
Mail sent through a compromised legitimate service may still pass SPF, DKIM and DMARC. Domain authentication evaluates defined identity relationships; it does not establish that the human request or message content is trustworthy. Repair a real authentication defect if one exists, but do not claim that publishing a stricter policy erased the earlier sending behavior. RFC 9989, sections 4.4 and 11.
Conversely, do not assume every failed message after the incident is a reputation rejection. Preserve the complete SMTP response and stage, the actual sending identity and the current route. A permanent recipient error, temporary resource issue and provider restriction need different handling. Reply classes alone are not proof of a shared cause. RFC 5321, section 4.2.1.
Restore the provider permission separately
A secured account may remain restricted from sending. Microsoft places removal from its Restricted entities workflow after investigation in its recovery guidance. That step is distinct from downstream providers deciding how to treat new mail. Do not remove restrictions merely to test whether a compromised account can send again before the security owner has approved restoration. Microsoft compromised-account response.
Where an external list is involved, use its current owner-verified remediation route and a supported cause-and-action record. Where a receiver applies its own reputation restriction, follow that receiver’s process. Do not submit the same generic claim to unrelated operators, buy purported guaranteed recovery or move to fresh identities to evade an unresolved abuse problem.
Reintroduce wanted traffic under measured conditions
Define the smallest legitimate sending population that can demonstrate the restored business function. Use authorized recipients and ordinary expected content, not a large blast intended to “warm” an account by force. Google’s sender guidance favors consistent, gradually increased volume and monitoring of responses, complaints and reputation. That is receiver-specific guidance, not a promise of a fixed recovery period. Google sender guidelines.
Record the original queue state before releasing delayed mail. Some notifications may be obsolete, and some may already have been accepted despite an uncertain client-side outcome. Assign one owner to retry decisions so the application and mail platform do not create competing copies. After final positive completion following message data, the accepting SMTP server owns transport responsibility; inbox placement is still a separate observation. RFC 5321, section 4.2.5.
Use a fictional recovery timeline as a worksheet
In a fictional incident, the security team first documents containment, then verifies that no known unauthorized access path remains, and only later approves a small legitimate sending cohort. The mail team records provider acceptance and any continuing deferrals. A subsequent review compares recipient complaints and permitted placement observations with the pre-incident baseline. These are proposed milestones, not executed actions or elapsed-time promises.
The timeline must retain adverse findings. If acceptance improves while complaints remain high, recovery is incomplete. If a dashboard lacks enough data, mark the metric unavailable. If unauthorized activity recurs, return to containment rather than increasing volume to chase a better delivery percentage. Different receivers may recover differently, so do not average away one still-affected customer population.
Close with evidence, not a clean-looking dashboard
Set closure criteria with the security and business owners: containment evidence, restored authorized operation, controlled delivery results and a defined monitoring interval. Any recipient or incident communication needs separate approval and accurate scope. No fixed number of days or successful test can guarantee future reputation.
Show incident containment and a measured delivery/reputation recovery timeline. This exact catalogue requirement remains open. The recovery map below is a documentary plan. Actual incident containment, provider applicability, legitimate-message results and a measured reputation timeline are absent and must not be represented as completed.