Outbound Email Abuse: Compromised Senders and Spam

When an attacker takes over a mailbox, an SMTP credential or an email API key, the first thing many do is send: spam, phishing to your contacts or fake invoices, all from your trusted domain and infrastructure. The result is a user locked out of sending, partners receiving fraud from a real address, and your domain or IP addresses landing on blocklists that take days to clear. This guide covers how outbound abuse shows up, the sending limits and alerts in Microsoft 365 and Google Workspace, how to detect abuse of service accounts and transactional email keys, how to contain and unblock a restricted sender safely, and how to recover from blocklisting. It is written for email administrators, SOC analysts and incident responders; the Email Security Guide covers inbound protection and authentication at overview level.

Key takeaways

A sending block is an incident, not a helpdesk ticket. Microsoft states that a sender exceeding outbound limits is an indicator of compromise, so secure the account before you unblock it.
Know your platform's limits and alerts. Exchange Online allows 10,000 recipients per day and 30 messages per minute per mailbox; Google Workspace allows 2,000 messages per day for a standard user; both block senders who exceed them.
Set tighter limits than the defaults. Custom outbound spam policies in Microsoft 365 accept per-hour and per-day limits from 0 to 10,000; most users need a fraction of the default.
Non-human senders are the blind spot. SMTP relay accounts, application mailboxes and email API keys (for example Amazon SES or other transactional services) are abused the same way, often without the alerts that protect user mailboxes.
Fix the cause before asking for delisting. Blocklist operators such as Spamhaus delist only after the network owner shows the problem is fixed, and removal is always free.

How outbound abuse happens

Outbound abuse is mail sent from your accounts or infrastructure that you did not authorise. It usually follows credential theft (phishing, password spraying, infostealer logs, token theft) and serves three goals: monetising the account through spam, reaching new victims through trusted internal and partner relationships, and fraud such as invoice redirection.

Source	Typical pattern	Why it is hard to spot
Compromised user mailbox	Burst of phishing to contacts and the global address list; inbox rules hide replies	Mail comes from a real user with valid SPF, DKIM and DMARC
Legacy SMTP AUTH or app passwords	High-volume spam over authenticated submission from unfamiliar IP addresses	Bypasses MFA; app passwords are not revoked by a password reset
Application or shared mailbox used by a script	Volume spike from a mailbox nobody reads	No owner watching; often exempt from conditional access
Transactional email API key (cloud email service)	Quota checks, new sending identities, then bulk or targeted fraud	Sits outside the mail platform's user alerts; key may be in code or CI logs
Web form, contact form or open relay	Abuse of a form that sends mail to arbitrary addresses	Traffic looks like normal application use

The TruffleNet campaign illustrates the API key route: hosts testing stolen AWS keys called the SES GetSendQuota API to see how much mail each key could send, and in one compromised account an attacker created sending identities for hijacked domains and used one in a fake vendor invoice.

Sending limits and platform controls

Platform limits are the last line of defence and the first signal. Values below are as documented by each vendor on 8 November 2026; vendors change them, so confirm in their documentation before relying on a number. Platforms are listed alphabetically.

Control	Google Workspace	Microsoft 365 (Exchange Online)
Per-user volume limit	2,000 messages per day for standard accounts; 1,500 for mail merge; 500 for trial accounts; rolling 24 hours	10,000 recipients per day (rolling 24 hours); 30 messages per minute
Tenant-wide external limit	Separate limits for SMTP relay and Groups	Tenant External Recipient Rate Limit (TERRL), based on licence count; trial tenants 5,000 external recipients per day; onmicrosoft.com domains 100 external recipients per day
What happens when exceeded	User cannot send for up to 24 hours, but can still receive	User added to Restricted entities; messages rejected with NDR 5.1.8 "Access denied, bad outbound sender"

Availability: Google notes that sending limits can change without notice and that forwarded mail has a separate 10,000 message limit. Microsoft does not publish its outbound spam thresholds, and sends outbound mail judged as spam through a lower-reputation "high-risk delivery pool" to protect its main IP addresses.

Microsoft 365 outbound spam policy settings

Limits: values from 0 to 10,000 (0 means the service default) for RecipientLimitExternalPerHour, RecipientLimitInternalPerHour and RecipientLimitPerDay on Set-HostedOutboundSpamFilterPolicy, scoped to users or groups with a HostedOutboundSpamFilterRule.
Automatic forwarding rules: Automatic (system-controlled, the default), On or Off. Microsoft recommends choosing an explicit value; Off blocks external forwarding by inbox rule and SMTP forwarding but not internal forwarding.
Action when reached: restrict until the following day (default, resets at UTC midnight), restrict until an administrator removes the block (BlockUser), or alert only.
Alerts: the default alert policies "Email sending limit exceeded", "Suspicious email sending patterns detected" and "User restricted from sending email" notify the TenantAdmins group. Route them to the SOC, not just global administrators.

Choosing limits

Population	Suggested approach	Trade-off
Most staff	Custom policy with external hourly and daily limits set from observed peak usage plus headroom, action BlockUser	Occasional false positives during campaigns; handle with a documented exception
Executives and finance	Same tight limits plus alerting; these accounts are prime targets for invoice fraud	Requires fast unblock process for genuine urgent sends
Marketing and bulk senders	Move bulk mail to a dedicated sending service and subdomain rather than raising mailbox limits	Extra platform to govern; keeps corporate domain reputation separate
Application and relay accounts	Per-account limits sized to the application, dedicated identities, no interactive sign-in	Needs an inventory of which app uses which account
Small organisation	Keep defaults but turn on all three alerts and disable external auto-forwarding	Higher ceiling before a block, but minimal admin effort

Where identity fits: service accounts and email API keys

Many outbound abuse cases start with a non-human credential rather than a person. SMTP relay accounts for printers and line-of-business apps, mailboxes used by scripts, OAuth applications with Mail.Send permission and transactional email API keys can all send as your domain.

Inventory every sender: list all identities permitted to send as your domains, including third-party services in SPF and DKIM records. Unknown senders in DMARC aggregate reports often reveal forgotten ones. See the DMARC, SPF and DKIM Guide.
Retire basic SMTP authentication: replace username and password submission with OAuth or connector-based relay restricted by IP address or certificate. See the Legacy Authentication and ROPC Retirement Guide.
Scope and store API keys properly: give email service keys send-only permissions, restrict them to specific sending identities and source networks where the service allows, keep them in a secrets manager and rotate them. Watch cloud audit logs for quota checks and new sending identities from unfamiliar principals.
Treat OAuth Mail.Send grants as privileged: review applications with permission to send as any user. See the Consent Phishing and Illicit OAuth Grants Guide.

Detecting compromised senders

Platform blocks fire late, after hundreds or thousands of messages have gone. Earlier detection comes from combining sign-in, mailbox and mail flow signals.

Signal	Where to find it	What it suggests
Outbound volume far above the sender's baseline, or many new external recipient domains	Message trace, mail flow reports, Gmail log events	Spam or phishing run from a compromised account
New inbox rules forwarding externally or moving mail to Notes, Junk Email or RSS Subscriptions	Get-InboxRule -IncludeHidden, unified audit log	Attacker hiding replies and bounces (ATT&CK T1564.008, T1114.003)
External forwarding newly set on the mailbox	Get-Mailbox ForwardingAddress, DeliverTo	Data collection or persistence
Surge of non-delivery reports to one sender	Mailbox, message trace	Sending to harvested or invalid addresses
Sign-in from an unfamiliar country, ASN or legacy protocol shortly before a send burst	Identity provider sign-in logs	Account takeover (T1078.004)
Complaint feedback loop reports or spam trap hits	Feedback loop alias, provider postmaster tools	Recipients marking your mail as spam
Quota checks or new verified identities on a cloud email service	Cloud provider audit logs	Stolen email API key being prepared for use

External reputation signals

Feedback loops: enrol your sending IP addresses and domains in mailbox provider complaint feedback loops, which send reports in the Abuse Reporting Format (RFC 5965). RFC 6449 recommends a unique alias per loop and working abuse@ and postmaster@ role addresses.
Spam rate: Google's sender guidelines ask senders to keep the spam rate reported in Postmaster Tools below 0.10% and avoid ever reaching 0.30%.
Blocklist monitoring: check your egress IP addresses and domains against major lists. Spamhaus ZEN combines the SBL, XBL (compromised hosts) and PBL; status can be checked at check.spamhaus.org.

Metrics that show control is working

Time to contain: minutes from first abnormal send to account disabled or sessions revoked.
Messages sent before containment: volume per incident, trending down as limits tighten.
Restricted sender events: count per month, and the share confirmed as compromise versus legitimate overuse.
Blocklist days: days per quarter any corporate IP address or domain was listed.
Complaint rate: complaints divided by delivered messages per provider, as RFC 6449 recommends.
Sender inventory coverage: share of non-human senders with an owner, scoped credential and per-account limit.

Containment and safe unblocking

Microsoft's guidance is explicit: secure the account first, then remove the restriction. Unblocking an account the attacker still controls restarts the campaign and deepens blocklisting.

Disable or contain: disable the account until the investigation ends where possible; otherwise reset the password (twice for Active Directory synchronised accounts) and do not send the new password by email.
Kill sessions and side doors: revoke sign-in sessions (Revoke-MgUserSignInSession), delete app passwords (a reset does not revoke them), remove unfamiliar MFA methods and devices, and review consented applications and role assignments.
Remove persistence in the mailbox: delete malicious inbox rules (including hidden ones), external forwarding and altered signatures.
Scope the damage: run message trace for the suspicious window, export the recipient list, and identify internal recipients who may have clicked. Notify external recipients who received fraud or phishing.
Check history: run the Blocked Sender History diagnostic (aka.ms/senderhistory) to see previous listings and the account's MFA state.
Unblock: in the Defender portal go to Email & collaboration, Review, Restricted entities, select the mailbox and Unblock, or use Get-BlockedSenderAddress and Remove-BlockedSenderAddress. Microsoft says restrictions are normally lifted within one hour and no later than 24 hours. Google Workspace users regain sending after the suspension period.
For API keys and relay accounts: revoke and reissue the key, remove any sending identities or domains the attacker added, and review billing for unexpected volume.

See the Business Email Compromise Response Playbook when the abuse involved fraud or payment redirection.

Blocklist and reputation recovery

Situation	Who acts	Recovery steps
Your own mail server IP on an IP blocklist	Your network team or ISP	Stop the source, confirm volume is back to baseline, then request removal through the operator's process; for the Spamhaus SBL only the responsible network or hosting company can request removal
Cloud mail platform shared IPs	The provider	Provider manages its pools; your job is to contain the account so the provider does not keep restricting it
Domain reputation drop at a mailbox provider	Your email team	Stop abuse, keep authentication aligned, send only to engaged recipients, and watch postmaster tools until spam rate falls
Spam trap hits on a sending service	Marketing owner and email team	Audit list sources, suppress unengaged and undeliverable addresses, require reconfirmation where needed (M3AAWG spam trap guidance)

Never pay for delisting: Spamhaus states removal never costs anything and paid removal offers are scams.
Explain the fix: operators and ISP abuse desks expect a short account of what happened and what changed (account secured, limits tightened, legacy authentication disabled).
Separate streams: sending marketing or bulk mail from a dedicated subdomain and service limits the damage when one stream is abused.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	SI-8 Spam Protection	Spam protection at entry and exit points, including outbound
NIST SP 800-53 Rev. 5	SI-4 System Monitoring; AC-2 Account Management	Monitoring send behaviour; owning and disabling accounts
NIST SP 800-53 Rev. 5	IR-4 Incident Handling	Treating restricted senders as incidents
NIST CSF 2.0	DE.CM-03, DE.AE-02	Monitoring technology usage and analysing adverse events
CIS Controls v8.1	Control 9 Email and Web Browser Protections	Email platform hardening and filtering
ISO/IEC 27001:2022	A.8.16 Monitoring activities; A.5.26 Response to information security incidents	Detection and response
MITRE ATT&CK	T1078.004 Cloud Accounts; T1586.002 Compromise Accounts: Email Accounts; T1534 Internal Spearphishing; T1114.003 Email Forwarding Rule; T1564.008 Email Hiding Rules	The techniques behind most outbound abuse from compromised mailboxes

Common failure patterns

Unblocking on request: the helpdesk removes the restriction because the user needs to send, the attacker still holds a session or app password, and the account is blocked again within hours with more damage done.
Alerts nobody reads: the default outbound alerts go only to global administrators' mailboxes and are never triaged.
Password reset as the whole response: sessions, app passwords, inbox rules, forwarding and added MFA methods survive a reset unless removed one by one.
Raising limits for convenience: lifting the daily limit for a team that sends newsletters from mailboxes, instead of moving bulk mail to a proper service, raises the ceiling for any attacker too.
Forgotten machine senders: relay accounts and email API keys with no owner, no limits and no alerting, as the TruffleNet quota checks against stolen cloud keys show.
Chasing delisting first: asking blocklist operators for removal before the source is fixed leads to relisting and slower future removals.

Practitioner checklist

Create custom outbound spam policies with external and daily limits sized from real usage and action set to block until an administrator reviews.
Route "Email sending limit exceeded", "Suspicious email sending patterns detected" and "User restricted from sending email" alerts to the SOC queue.
Turn off automatic external forwarding by default and approve exceptions individually.
Write an unblock runbook that requires session revocation, app password removal, MFA review and inbox rule clean-up before any restriction is lifted.
Inventory every non-human sender (relay accounts, app mailboxes, OAuth apps with Mail.Send, email API keys) with owner, scope and limits.
Disable basic SMTP authentication and legacy protocols wherever possible.
Enrol in mailbox provider feedback loops and postmaster tools, and monitor egress IP addresses and domains on major blocklists.
Send bulk and marketing mail from a separate subdomain and service.
Track time to contain, messages sent before containment and blocklist days each quarter.

Standards and references

Related NHI Mgmt Group resources: Email Security Guide · Email Identity and BEC Guide · DMARC, SPF and DKIM Guide · Top 10 Email Security Threats

Outbound Email Abuse: Detect Compromised Senders and Recover Reputation