What to Do if Your Email Is Hacked: A Full Recovery Plan

Do not index

Your replies are bouncing, customers are reporting suspicious messages, and a finance contact says the payment instructions in a recent thread don't match what was agreed. Then an unfamiliar sign-in alert appears. The immediate temptation is to change the password and move on. That response is incomplete.

A hacked mailbox creates two separate recovery problems: regaining control of the account and repairing the sender identity attached to the business. The first protects access, messages, recovery methods, and connected applications. The second protects inbox placement, domain reputation, authentication, and revenue. This guide explains what to do if your email is hacked, including what to revoke beyond the password and how to recover after fraudulent mail has already been sent.

Table of Contents

Why a Hacked Mailbox Is Two Problems at Once The mailbox and the sending identity Why standard checklists fail First Hour Containment You Should Do From a Clean Device Secure the recovery environment first Reset access in the right order What to Revoke Beyond the Password Reset Preserve forwarding evidence before removal Sender Identity and Reputation Recovery for Business Domains Audit authentication before resuming volume Read the headers and delivery signals Who to Notify, What to Preserve, and When to Involve Authorities Preserve the timeline Notify people without extending the attack Report financial and criminal impact Common Mistakes That Make a Hacked Email Harder to Recover Prevention, Post-Incident Monitoring, and When to Call in Experts Know when internal recovery isn't enough

Why a Hacked Mailbox Is Two Problems at Once

A compromised mailbox can impersonate its owner, expose sensitive conversations, reset other accounts, and redirect payments. It can also send credible messages from a legitimate address, making recipients more likely to trust malicious links or altered bank details.

Regaining login access does not mean the business has recovered. Legitimate messages may still land in spam because inbox providers evaluate the sending identity and recent behavior separately from the user's ability to sign in. A new password cannot erase fraudulent sending, complaint signals, suspicious volume, or changed domain settings.

The mailbox and the sending identity

The account recovery track covers:

Active sessions and sign-in tokens

Passwords and reused credentials

Recovery phone numbers and addresses

Multifactor authentication devices

OAuth applications, app passwords, and delegated access

Forwarding rules, filters, and automatic replies

The sender recovery track covers:

SPF, DKIM, and DMARC configuration

Unauthorized sending sources

Bounce and complaint patterns

Domain and IP reputation

Blocklist status

Customer and supplier communications

The FBI's 2024 Internet Crime Report recorded 859,532 complaints involving suspected internet crime and reported losses exceeding $16 billion, a 33% increase from 2023. Phishing and personal-data breaches were among the three most frequently reported categories. Containment therefore has to address both account control and the sender identity attached to the business. The email deliverability full guide explains how authentication, reputation, and engagement affect inbox placement.

Why standard checklists fail

Typical consumer checklists from mailbox providers focus on changing the password, signing out devices, and enabling multifactor authentication. Those actions matter, but they often omit connected applications, persistent sessions, mailbox delegation, hidden forwarding, and the organization's sending infrastructure.

That gap creates a false recovery signal. A user may log in again while an attacker still receives copied messages or retains access through an application token. Recipients may also continue treating recent messages as suspicious, damaging trust and reducing the chance that future campaigns reach the inbox.

A password reset addresses access. Sender reputation requires its own inspection, correction, and monitoring.

First Hour Containment You Should Do From a Clean Device

If an attacker still controls the laptop or phone used for recovery, a password reset can expose the replacement credential too. Start with a trusted device that shows no sign of malware, and keep the suspected device away from recovery links, MFA approvals, and new passwords.

Secure the recovery environment first

Disconnect the affected computer or phone from the network if infection is possible. Do not use it to open account-recovery messages or enter replacement credentials.

Run a fully updated antivirus and endpoint-malware scan on every computer and mobile device that accessed the mailbox. A keylogger or infostealer can capture a new password immediately, turning a correct reset into another credential leak.

For a consumer account, the owner can perform the scan and recovery. In a business environment, an administrator should suspend suspicious sign-in activity or block the affected user while the endpoint is investigated. If the identity synchronizes from on-premises directory services, reset the password there and perform the reset twice to reduce pass-the-hash exposure.

Reset access in the right order

After the devices are clean, follow this sequence:

Change the mailbox password. Use a unique value that has never been used elsewhere, and store it in a password manager.

Sign out every active session. A password reset may leave browser sessions or tokens active.

Re-enroll multifactor authentication. Remove unknown authenticators and use phishing-resistant MFA where available.

Replace recovery methods. Delete unfamiliar phone numbers, backup addresses, aliases, and app passwords.

Revoke third-party access. Remove unknown OAuth applications, connected accounts, and integrations.

Rotate reused passwords. Change credentials on every other service that used the same or a similar password.

Verizon's 2025 Data Breach Investigations Report analyzed 22,052 real-world security incidents and 12,195 confirmed breaches. Compromised credentials were an initial access vector in 22% of reviewed breaches, and in the median infostealer case only 49% of a user's passwords across services were distinct. Treat the mailbox password as one credential in a wider identity system. Account access and sender reputation require separate recovery work.

What to Revoke Beyond the Password Reset

A password reset closes one route into the mailbox. It does not remove access that an attacker established through tokens, connected applications, forwarding rules, or delegated permissions.

Start with the account's identity controls:

Active sessions and tokens: Sign out every session and revoke suspicious access-session tokens.

MFA registrations: Remove unfamiliar authenticators, phone numbers, and security keys.

OAuth grants: Delete unknown connected applications and review permissions approved recently.

App passwords and SMTP credentials: Revoke credentials that bypass normal interactive sign-in.

Delegated access: Check assistants, shared mailboxes, send-as permissions, and mailbox delegates.

Recovery settings: Replace unfamiliar backup addresses, aliases, and recovery methods.

These checks cover access that a password change can leave intact. An attacker may still read messages through a connected CRM, help-desk system, cloud storage account, or SMTP application. An active browser session can provide another route, while a forwarding rule can copy new mail after the inbox appears normal.

Review the mailbox and account security pages for forwarding, filters, automatic replies, connected accounts, recent security events, and approved applications. Business administration centers may also expose organization-wide session invalidation, transport rules, audit logs, and policy controls. The labels differ, but inspect every path that can read, send, or redirect mail.

Preserve forwarding evidence before removal

Forwarding rules require controlled cleanup. Record the destination, rule name, creation or modification time, affected messages, message headers, and related sign-in events. Then disable the suspicious rule while investigating, block the affected user's login, reset credentials, revoke relevant access-session tokens, and remove the rule after evidence is preserved. This sequence follows guidance from the Cybersecurity and Infrastructure Security Agency.

The destination can show which information the attacker targeted, such as invoices, password resets, customer conversations, or internal security alerts. A sudden external forwarding address also helps identify the incident's scope and supports notification decisions.

Inspect transport and routing rules, mailbox delegation, inbox filters, automatic replies, and connected applications. Personal account owners should review the equivalent settings through their security and mailbox controls. Administrators should check both the affected mailbox and organization-wide policies.

Account compromise and sender reputation are separate recovery problems. “Password changed” does not mean “attacker removed.” If fraudulent mail was sent, preserve the evidence and treat every unauthorized sending path as a reputation risk before restoring normal activity.

Sender Identity and Reputation Recovery for Business Domains

A mailbox compromise can turn into a domain-wide delivery problem. If an attacker sends phishing messages, fraudulent invoices, or bulk mail, recipients and inbox providers may distrust legitimate messages from the organization. Treat account access and sender reputation as separate recovery tracks.

Restrict outbound sending from the affected mailbox while the incident is contained. Coordinate the pause with the email service provider so transactional messages do not fail unexpectedly. Before restoring normal volume, confirm which systems are authorized to send for the domain and remove any unapproved source.

Audit authentication before resuming volume

Inspect the domain's SPF, DKIM, and DMARC records for unauthorized changes. Check for unfamiliar include mechanisms, altered reporting addresses, rogue sending sources, and signing keys that no longer match approved infrastructure. Review both the DNS records and the systems that publish or use them.

A simplified SPF record might look like:

example.com TXT "v=spf1 include:authorized-sender.example -all"

A DMARC record might look like:

_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

These are illustrative syntax examples, not drop-in records. Verify every authorized sender before publishing a restrictive policy. Rotate DKIM keys if the signing environment may have been exposed, then test legitimate transactional and marketing messages. Confirm that they authenticate, align with the visible From domain, and continue reaching their intended recipients.

The SPF, DKIM and DMARC explained guide explains how these controls support domain alignment and authentication. Authentication alone does not guarantee inbox placement. Broken authentication gives receiving systems another reason to distrust messages, making reputation recovery harder.

Read the headers and delivery signals

Compare suspicious messages with legitimate mail from the same domain. Focus on the fields that expose identity, routing, and authentication changes:

Signal	What to inspect	Why it matters
`Authentication-Results`	SPF, DKIM, and DMARC outcomes	Shows whether the message authenticated and aligned
`From` and envelope sender	Visible address versus return path	Exposes identity mismatches and bounce-routing changes
`Received` chain	Sending path and timestamps	Helps identify unauthorized infrastructure or unusual routing
`ARC` results	Forwarding and authentication context	Helps interpret messages that passed through intermediaries
Spam indicators	Provider warnings or filtering markers	Shows how receiving systems classified the message

Review bounce logs, complaint patterns, and provider dashboards. Check blocklist status through reputable DNS-based lists, but use a listing as a diagnostic signal, not a complete reputation verdict. A domain can have clean authentication and still experience poor inbox placement after recipients react to fraudulent mail.

Restore volume in controlled stages. Watch bounces, complaints, authentication failures, and blocklist changes before increasing activity. Password recovery closes one access path. Reputation recovery requires proof that every sending identity and business mail stream is under control.

Who to Notify, What to Preserve, and When to Involve Authorities

Evidence disappears quickly when an incident team starts deleting messages and rules. Preserve the record before cleanup, then communicate through channels the attacker can't access.

Preserve the timeline

Capture:

Sign-in timestamps, IP locations, user agents, and impossible-travel alerts

Suspicious forwarding destinations and mailbox rules

Message headers from fraudulent and legitimate messages

Sent, deleted, archived, and draft messages

OAuth grants, app passwords, delegated access, and MFA changes

Bounce notifications and provider complaint signals

Keep the original messages where possible. Headers can help the mailbox provider, investigators, insurers, and internal administrators separate genuine account sends from domain spoofing.

Notify people without extending the attack

Contact recipients through a different trusted channel, such as a phone call, a separate mailbox, or an independently controlled company notice. Identify the unsafe subject lines, approximate sending window, links, attachments, or payment instructions. Don't ask recipients to reply to the compromised thread until the mailbox is confirmed safe.

Finance teams, suppliers, and customers need a specific warning about payment-redirection attempts. Any bank-detail change or urgent transfer request received during the exposure window should be verified through a previously known channel. If transactional or marketing mail may have been affected, coordinate with the sending provider before resuming campaigns.

For organizations assessing coverage and incident-response obligations, ABS Insurance Brokers cyber cover can provide relevant context on cyber insurance considerations. Coverage doesn't replace containment, evidence preservation, or notification decisions, but early documentation can support those conversations.

Report financial and criminal impact

The FBI advises victims to notify relevant financial institutions immediately, submit a complaint to the Internet Crime Complaint Center at ic3.gov, contact a local FBI field office when appropriate, and notify local law enforcement. Businesses should also involve legal, privacy, compliance, and insurance contacts when exposed information or financial instructions create reporting obligations.

The purpose isn't merely administrative. Prompt notification can help protect recipients, stop fraudulent transfers, preserve evidence, and limit further damage to brand trust.

Common Mistakes That Make a Hacked Email Harder to Recover

The most expensive mistake is treating the incident as a password problem. The following shortcuts regularly turn a contained compromise into a prolonged deliverability problem.

Changing the password before scanning the endpoint: A keylogger or infostealer can capture the replacement credential. Scan and update the device first.

Deleting forwarding rules immediately: That removes evidence and may hide the attacker's destination. Disable the rule, record it, block access, revoke tokens, then remove it. CISA specifically recommends this order in its mailbox remediation guidance.

Ignoring reused passwords: The attacker may move from the mailbox into financial, cloud, or administrative accounts. Rotate every affected credential and use unique values.

Trusting the breach email itself: A forwarded copy can omit useful headers or preserve an unsafe link. Verify the message through an independent channel and retain the original evidence.

Pausing mail without coordinating with the provider: Abruptly stopping a transactional stream can create its own customer-service and revenue problems. Restrict the compromised source while preserving necessary operational mail.

Assuming a successful login proves recovery: Unknown sessions, OAuth grants, app passwords, delegates, and recovery methods can keep access alive.

Leaving DMARC in monitoring mode during an active incident: Reporting helps visibility, but the organization still needs a deliberate enforcement decision based on verified legitimate senders.

Resuming full volume immediately: Sending normally before complaint and bounce signals settle can reinforce negative reputation signals at major inbox providers.

A company can recover account access and still lose inbox placement. That gap is why recovery needs both identity containment and sender-side review, rather than a single checklist owned by one person.

Prevention, Post-Incident Monitoring, and When to Call in Experts

Recovery lasts when you keep watching the controls an attacker could reuse. Store credentials in a password manager, assign every account a unique password, and use hardware-backed MFA wherever the account and environment support it. Hardware security keys provide the strongest practical barrier against another stolen-password login.

After remediation, monitor sign-in alerts, OAuth grants, forwarding rules, recovery methods, and authentication reports. Review forwarding addresses, inbox rules, connected accounts, automatic replies, delegated access, OAuth applications, and transport rules. Check sign-in logs for unfamiliar IP addresses and impossible-travel patterns before deleting evidence. Keep an incident record so later changes can be compared with the clean baseline.

Know when internal recovery isn't enough

Bring in deliverability or security specialists when:

Persistent bounces continue after the mailbox and endpoint are clean

A blocklist listing returns after removal

Suspicious sessions or forwarding rules reappear

Complaint signals remain high

Transactional or marketing volume needs a controlled ramp

SPF, DKIM, DMARC, routing, or provider configuration changed unexpectedly

A blacklist checker can show whether a sending host or domain appears on monitored lists. It cannot explain every reputation change or confirm which infrastructure is safe to restore. Authentication checks have the same limit. Review SPF, DKIM, and DMARC alignment across every legitimate sender, especially after a business-domain compromise.

The recovery plan has five jobs: secure the person, revoke every persistence path, preserve evidence, warn affected recipients, and repair sender identity. Account access, authentication, reputation, and revenue are connected, but restoring one does not restore the others.

MailAdept combines AI agents with human deliverability experts to investigate compromised sending identities, review SPF, DKIM, DMARC, mailbox-related reputation damage, and build a monitored recovery plan. Still facing deliverability issues? Get a free deliverability audit.