Email Abuse Taxonomy

The abuse desk's first job on any report is classification: what kind of abuse is this, who is the victim, and who is the actor? Those three answers select the playbook. This article is the classification layer for the KB's abuse cluster — each entry defines the abuse type, names the victim, lists the detection signals visible from the ESP's chair (not the receiver's), identifies the typical actor, and points to the article that owns the response. Triage priority ordering and the remediation loop themselves live in Abuse Desk Operations.

The actor axis

The same outbound symptom (spam pouring off your IPs) has four materially different causes, and the response differs for each — misclassifying the actor is the most expensive triage error:

Actor class	Description	Response posture
Intentional customer	The account holder is the abuser — signed up to abuse, or drifted into it	Enforce: suspend/terminate; fraudulent accounts get no data retrieval and no tip-off (Abuse Desk)
Compromised customer	Legitimate account under attacker control (credentials, API key, hacked CMS)	Recover: contain, restore to owner, secure against re-compromise (Compromised Accounts)
Negligent customer (conduit)	Customer isn't sending abuse, but their unprotected asset (form, script, sloppy list buying) makes them a vector	Educate + mandate controls; escalate to enforcement if they refuse to remediate
External	Attacker never touches a customer account — abuses your brand, your signatures, or third-party forms from outside	Monitor, report, take down; the ESP's own infrastructure may be victim, not source

The differentiator between the first two is a pattern of previous valid use — the compromised-vs-malicious test in Compromised Accounts. Careful metric analysis before assuming the mechanism: what looks like compromise is often trial-signup registration abuse, and vice versa.

Master table

Abuse type	Primary victim	Key ESP-side signals	Typical actor	Response owner
Spam / UBE	Recipients; ESP's shared reputation	Complaint/FBL spikes, trap hits, blocklistings, bounce spikes	Intentional or negligent customer	Abuse Desk · Customer Vetting
Phishing (incl. spear/BEC)	Impersonated brand + defrauded recipients	Hostile URLs in content, trusted-reporter/brand takedown notices, DBL/SURBL PH hits	Intentional (fraud signup) or compromised customer	Abuse Desk (P2) · URL & Content Filtering
Brand spoofing / lookalike domains	The brand; its customers	DMARC reports showing unauthorized sources; lookalike signup attempts at vetting	External (or fraud signup using the lookalike)	Brand Protection · DMARC
Snowshoeing	Filters/receivers; ESP IP space	Customer requesting many IPs/domains, rotating identities, CSS listings	Intentional customer	Spamhaus Deep Dive · Customer Vetting
List bombing	One targeted mailbox	Fleet-wide signup bursts to one address/domain, confirmation-mail floods	External, via negligent customers' forms	Subscription Bombing
Malware / ransomware distribution	Recipients' machines	Attachment scanning hits, SURBL MW, urgent trusted-reporter notices	Compromised customer or fraud signup	Abuse Desk (P2) · Compromised Accounts
419 / advance-fee and fraud content	Recipients (financially)	Content heuristics, low volume + webmail-style sending, complaint text	Intentional (fraud signup) or compromised account ("stranded traveler")	Abuse Desk · Compromised Accounts
Backscatter	Forged-address holders; the bouncing ESP	Outbound bounce volume to never-sent-to addresses; Backscatterer-type listings	Nobody — a misconfiguration; external spammer supplies the forged addresses	Abuse Desk — backscatter
DKIM replay	The signing domain (customer or ESP)	Complaints/blocks for mail you have no send record of; one message ID seen at massive receiver scale	External (needs only one signed message)	DKIM Replay Attacks
Account takeover / compromised sending	The customer; then everyone sharing infrastructure	Behavior break vs account baseline: new geo/UA, sudden volume, new content/recipients	Compromised customer	Compromised Accounts
API-key abuse	The customer; shared pools	API-only sending anomalies with no dashboard logins; leaked-key intel; new API integration preceding trap/complaint spikes	Compromised customer (leaked credential)	Compromised Accounts · Spam-Trap Incident Response
Affiliate spam	Recipients; the advertiser's brand; ESP reputation	Vetting answers (third-party-managed programs), redirector-heavy content, complaint rates far above the customer's own streams	Intentional or negligent customer (via affiliates)	Customer Vetting · Consent Methods
Cold email / consent-less outreach	Recipients; ESP reputation	Small-batch "personalized" bulk, purchased B2B lists, deliberate volume-splitting across accounts/domains	Intentional customer (often self-identifying as legitimate)	M3AAWG Position on Cold Email
Harvesting / scraping	Address owners; then whoever mails the list	Upstream of the ESP: list uploads dense in role accounts, traps, invalid addresses	External harvester; intentional/negligent customer as buyer	Consent Methods · Spam Traps
Open relay / proxy abuse	Whole receiving ecosystem; the relay operator	Third-party-origin traffic through customer infrastructure; SBL/XBL-type listings of customer hosts	External abuser via negligent customer's misconfiguration	Compromised Accounts · Blocklists & Spamhaus
SMS / messaging ridealong	Message recipients on the other channel	Scripted abuse of web→SMS/notification features; per-feature volume anomalies	External via scripting, or compromised account	Compromised Accounts (Web Messaging BCP material)

Spam / UBE

Definition (Spamhaus): Unsolicited Bulk Email — unsolicited meaning the recipient has not granted verifiable permission, bulk meaning the message is part of a larger collection of substantively identical messages. Both conditions must hold; "spam is an issue about consent, not content." This is the parent category — most other entries in this taxonomy are spam plus an aggravating characteristic (deception, malware, fraud).

• Victim: recipients; and — because ESPs are judged on aggregate — every other customer on shared IPs/domains (Multi-Tenant Architecture).
• ESP signals: FBL complaint-rate spikes, spam-trap hits, rising rejects/deferrals at major receivers, blocklistings, abnormal bounce profiles on list import. Thresholds and corrective actions: Metrics & Benchmarks.
• Actor: intentional customer (bought lists, no consent) or negligent customer (decayed hygiene). Distinguish from compromise by baseline behavior.
• Response: Abuse Desk remediation loop (validate → notify with ToS citation → remediate → suspend → terminate); prevention via Customer Vetting; trap-driven incidents via Spam-Trap Incident Response.

Phishing (including spear phishing and BEC)

Definition: mail impersonating a trusted party to steal credentials, payment data, or money. Spear phishing targets specific individuals with researched pretexts. BEC (business email compromise) — per FBI IC3 — is the sophisticated end: impersonating an employee, vendor, or executive (via spoofing, lookalike domains, or an actually compromised mailbox) to trigger fraudulent fund transfers; APWG frames it as impersonation of a trusted party to trick an employee into sending money or privileged assets. BEC often involves no payload URL or attachment — pure social engineering — which defeats content filters.

• Victim: dual — the impersonated brand (reputation, DMARC pain) and the defrauded recipient.
• ESP signals: hostile/deceptive URLs in customer content (SURBL PH, Spamhaus DBL/HBL hits — URL & Content Filtering); takedown notices from brand-protection firms and trusted reporters; hosting-side, phish kits on customer sites (the Hosting Abuse BCP notes phishing is almost always run through compromised end-user accounts with outdated scripts). Pure BEC rarely transits an ESP at volume — it's low-volume and targeted — but credential-phish campaigns against your own customers to seed account takeover absolutely do.
• Actor: fraud signup (intentional) or compromised customer account/site. External when only your brand is imitated (see next entry).
• Response: P2 in the abuse-desk priority tiers (malicious activity ranks above spam); immediate suspension of the sending mechanism, then the compromised-vs-fraudulent fork. Phishing of your customers to harvest ESP credentials is an input to Compromised Accounts.

Brand spoofing and lookalike domains

Definition: an external attacker sends as a brand without touching its infrastructure — exact-domain spoofing (forged From, defeated by enforced DMARC), or cousin/lookalike domains (typos, added terms like "-login", alternate TLDs) that authenticate perfectly as themselves and thus sail past DMARC.

• Victim: the brand and its recipients. The ESP is a victim too when its own brand or its customers' domains are imitated to phish credentials.
• ESP signals: customer DMARC aggregate reports showing unauthorized sources (DMARC Aggregate Reports); vetting-time signups using lookalikes of known brands (a classic fraud-signup tell — Customer Vetting); certificate-transparency and domain-registration monitoring hits.
• Actor: external. The ESP-side variant is a fraudulent customer registering the lookalike and asking you to authenticate it — which is why customer domain authentication checks belong in onboarding.
• Response: Brand Protection — Domain Management owns inventory, defensive registration, monitoring, and the takedown paths; DMARC enforcement handles the exact-domain case.

Snowshoeing (IP and domain)

Definition (Spamhaus): spreading spam output thinly across many IPs and domains to dilute per-identity reputation and stay under filter thresholds — "ranges and domains with poor or frequently changing identification," sent from IPs the spammer uses legitimately (not botnets). The domain variant rotates freshly registered domains the same way.

• Victim: filters and receivers (evasion), plus the ESP whose IP space and domain-delegation tooling gets consumed — and neighbors, when CSS listings hit shared ranges.
• ESP signals: at vetting — prospects requesting unusually many IPs or sending domains relative to volume, anonymized WHOIS, multiple prior ESPs, any hint of changing infrastructure to evade a listing (an explicit red flag in the Vetting BCP); in operation — frequent domain swaps, stops-and-starts to dilute metrics across platforms, Spamhaus CSS listings ("many frequently-changing domains is itself the signal").
• Actor: intentional customer, by definition — snowshoeing is premeditated architecture, never an accident.
• Response: Spamhaus Listings Deep Dive for the listing mechanics and delisting; terminate rather than remediate — a snowshoe operation has no legitimate configuration to restore. Prevention is vetting plus the tiered-rights model (new accounts don't get IP/domain fleets).

List bombing / subscription bombing

Definition: a DoS against one mailbox — scripted mass submission of the victim's address into thousands of unprotected signup forms so the flood of legitimate confirmation/welcome mail buries the inbox, often to mask fraud notifications.

• Victim: the targeted mailbox owner. Secondary: the form owners (list poisoning, trap submissions) and the ESP (Spamhaus listed ESP sending IPs during the 2016 wave).
• ESP signals: fleet-wide signup-velocity anomalies to a single address or domain across many customers' forms; per-address confirmation floods; abrupt onset without ramp.
• Actor: external attacker; customers are negligent conduits via unprotected forms.
• Response: Subscription Bombing & Signup-Form Abuse owns the full playbook — detection signatures, CAPTCHA+COI mandates, per-address suppression during attacks, cross-industry coordination.

Malware / ransomware distribution

Definition: mail delivering malicious payloads — attachments (droppers, macro documents) or links to exploit/download sites — including ransomware delivery and botnet recruitment.

• Victim: recipients' machines and organizations; the ESP's reputation collapses fast, as malware distribution triggers the harshest receiver and blocklist responses.
• ESP signals: outbound attachment/malware scanning hits (the Web Messaging BCP: restrict upload types and malware-scan them); SURBL MW / Spamhaus HBL hits on linked domains; urgent notices from trusted reporters and CERTs; hosting-side, malware drops on customer sites (P2 in the hosting tiers).
• Actor: rarely an ESP customer's intent (mainstream ESP tooling is a poor malware channel — attachments are limited and content is inspected); usually a compromised customer site/account or a fraud signup abusing free-tier sending.
• Response: Abuse Desk P2 — immediate stop-send, no remediation window for the traffic itself; then the compromised-vs-fraudulent fork in Compromised Accounts. Content-side detection context: URL & Content Filtering.

419 / advance-fee and other fraud content

Definition: fraud where the content itself is the crime — advance-fee ("419", after the Nigerian Criminal Code section covering fraud) promises of large payoffs for an upfront fee; lottery/inheritance scams; fake-job and overpayment fraud; romance-scam progressions; the "stranded traveler" plea sent from a hijacked account to its own contacts.

• Victim: recipients, financially. Volume is usually low relative to UBE — the harm-per-message is what elevates it.
• ESP signals: content heuristics and long-lived filter signatures (this genre is decades old and semantically stable); complaint text describing the scam; low-volume accounts sending person-to-person-styled mail to scattered recipients; for stranded-traveler variants, an established account suddenly mailing its whole contact list.
• Actor: intentional fraud signup, or a compromised account for the customized variants — the Compromised User ID BCP classes stranded-traveler scams as "permanent credential, customized exploit," always requiring human intervention.
• Response: Abuse Desk triage (fraud reports can also arrive via law-enforcement channels, which outrank spam in the queue); fraudulent accounts get the no-courtesy termination path.

Backscatter generation

Definition: misdirected bounce traffic — a server accepts a message with a forged return address, then bounces it to the innocent forged address rather than rejecting at SMTP time. At volume the bounces themselves constitute UBE and get the bouncing operator blocklisted.

• Victim: holders of the forged addresses (often a spoofed brand's real users); then the generating ESP, via backscatter-focused blocklists and reputation damage.
• ESP signals: outbound DSN/auto-reply volume to addresses you never delivered to; complaints about "bounces for mail I never sent"; listings on backscatter-oriented DNSBLs.
• Actor: none in the usual sense — it's a misconfiguration (accept-then-bounce, unguarded autoresponders, challenge-response systems). The external spammer forging your customers' addresses supplies the trigger but never touches your systems.
• Response: Abuse Desk — backscatter owns the mitigations (reject at SMTP time, BATV, SPF-gated bounce suppression, queue scrubbing). Bounce mechanics: DSNs.

DKIM replay

Definition: an attacker obtains one legitimately DKIM-signed message (e.g., via a free trial or a signup confirmation to an attacker mailbox) and retransmits it verbatim to millions of recipients — every copy carries a valid signature, so the d= domain's reputation is spent on mail it never sent to those recipients.

• Victim: the signing domain — the ESP itself when customers sign with ESP-shared domains, or the customer's own domain. Recipients are secondary victims of the spam.
• ESP signals: the defining anomaly is reputation damage with no matching send records — complaint and block feedback for messages, recipients, or volumes absent from your logs; a single Message-ID observed at massive scale in receiver feedback; sudden domain-reputation collapse on a stream whose own metrics look clean.
• Actor: external. The attacker needs only the ability to receive one signed message — a free-tier signup suffices, which is why replay is specifically an attack on ESPs with self-service trials.
• Response: DKIM Replay Attacks owns mitigations and tradeoffs (short x=, per-stream selectors and keys, oversigning, trial-account controls); key hygiene in DKIM Key Rotation. Trial-signup vetting reduces the attacker's access to fresh signed mail (Customer Vetting).

Account takeover / compromised sending

Definition: a legitimate customer account fully or partially under unauthorized control (the Compromised User ID BCP's "compromised user account"), used to send spam, phishing, or fraud through the customer's earned reputation and the ESP's infrastructure.

• Victim: the customer first (reputation, data, contacts), then every tenant sharing IPs/domains, then recipients.
• ESP signals: behavior break against the account's own baseline — logins from new geographies/impossible travel, unfamiliar User-Agents, sudden volume or recipient-set changes, new content categories, deleted sent-mail, altered forwarding/reply-to; FBL complaint surges on a historically clean account; credential-dump intelligence naming customer emails.
• Actor: compromised customer — by definition. The pattern-of-previous-valid-use test separates this from registration abuse.
• Response: Compromised Accounts & Outbound Abuse owns the whole lifecycle — detection feeds, the four compromise-type mitigations, forced re-authentication, re-compromise handling. Intake often arrives via the abuse desk; FBL mechanics in Complaint Feedback Loops.

API-key abuse

Definition: sending abuse through stolen or leaked API credentials rather than interactive login — keys committed to public repositories, harvested from compromised customer servers, or phished. A subtype of account takeover with its own detection profile, called out separately because API traffic bypasses the login-anomaly signals most ATO detection leans on. Categorization note: this split is practitioner practice at sending platforms (vendor security guidance on leaked-key revocation, GitHub-style secret scanning), not a formally defined M3AAWG category.

• Victim: the key-owning customer; shared infrastructure.
• ESP signals: sends via API with no corresponding dashboard/interactive activity; new source IPs/ASNs on the API path; secret-scanning notifications (public-repo key leaks); a new or changed API implementation immediately preceding trap-hit or complaint spikes — an explicit re-vetting trigger in Spam-Trap Incident Response; volume patterns unlike the integration's history.
• Actor: compromised customer (leaked credential). Distinguish from an intentional customer scripting abuse through their own key — that's plain spam with an API transport.
• Response: Compromised Accounts — this is the "temporary/permanent credential" model applied to machine credentials: revoke the key immediately (never just password-reset — the key survives password changes), issue scoped replacement keys, audit what the key touched. Platform prevention: tiered rights for new accounts (restricted API access until tenure/reputation earn more — Customer Vetting, fraud-prevention practices) and per-tenant enforcement to contain the blast (Multi-Tenant Architecture).

Affiliate spam

Definition: spam sent by third-party affiliates promoting a customer's (or advertiser's) offer for commission. The advertiser may be entirely legitimate; the abuse rides on affiliates whose lists and methods nobody vetted. The Vetting BCP flags the category as a historical abuse vector; do-it-yourself programs are riskier than those run by reputable third-party networks.

• Victim: recipients (no consent with the actual sender), the advertiser's brand, and the ESP if either the affiliate mail or the spamvertised landing traffic touches its infrastructure ("spamvertising on network" is its own line in the hosting-abuse tiers).
• ESP signals: vetting answers admitting affiliate programs; redirector- and tracking-chain-heavy content resolving to third-party offers (URL & Content Filtering — redirector handling); complaint/trap rates far above the same customer's house-list streams; Spamhaus DBL listings of the promoted domains even when your sending IPs stay clean.
• Actor: intentional customer (knowingly buying spam-driven traffic) or negligent customer (program without affiliate policing). The affiliates themselves are external to the ESP relationship — which is exactly the accountability gap that makes the category dangerous.
• Response: Customer Vetting (extra scrutiny at onboarding, program-management questions); Consent Methods for why affiliate lists carry near-purchased-list complaint profiles; ongoing enforcement through the standard abuse-desk loop with the customer answerable for their affiliates.

Cold email / consent-less outreach

Definition (M3AAWG, Nov 2025): unsolicited email from otherwise legitimate, identifiable senders seeking a business relationship from recipients with no prior relationship, connection, or consent — deployed with deceptive tactics (small randomized batches, lookalike/burner domains, technically valid authentication as camouflage) to mimic one-to-one mail. M3AAWG's position: deceptively delivered cold email is spam.

• Victim: recipients; and the ESP, because cold-email operations deliberately distribute volume across accounts, subdomains, and providers to dilute detection — consuming shared reputation while structurally resembling snowshoeing at the account level.
• ESP signals: many small "personalized" sends with template cores; purchased/scraped B2B lists (role accounts, no opt-in evidence); rapid domain/subaccount creation; sending-tool integrations marketed for "outbound sequences"; complaint rates modest in absolute terms but extreme relative to volume.
• Actor: intentional customer — usually one who sincerely argues legitimacy, which is why the M3AAWG position exists: to give abuse desks an industry-consensus answer to "but it's not spam, it's sales outreach."
• Response: M3AAWG Position on Cold Email owns the definitional argument and detection indicators; enforcement is policy-driven (AUP prohibition, vetting-time screening) via Customer Vetting and the Abuse Desk. Consent non-transferability: Consent Methods.

Harvesting / scraping

Definition: collecting email addresses without consent — crawling websites, scraping platforms and breach dumps, dictionary-generating addresses — to build or sell lists. The abuse an ESP meets is downstream: a customer mailing a harvested list.

• Victim: the address owners; then the mailing customer and the ESP, because harvested lists are dense in pristine spam traps (planted precisely to catch harvesters), invalid addresses, and role accounts.
• ESP signals: at list import — role-account density, implausible domain distributions, no opt-in metadata; at first send — high hard-bounce rates plus pristine-trap hits (the signature combination; pristine traps almost uniquely indicate harvested/purchased data); customers unable to produce opt-in evidence for spot-checked addresses (the trap-incident audit technique).
• Actor: the harvester is external; the ESP's problem actor is the intentional or negligent customer who bought or scraped the list.
• Response: Consent Methods (harvested is the bottom of the acquisition spectrum; universally AUP-prohibited); Spam Traps + Spam-Trap Incident Response for the incident that reveals it; CAN-SPAM aggravates penalties for harvested-list sending (CAN-SPAM).

Open relay / proxy abuse

Definition: third parties routing mail through infrastructure that shouldn't relay for them — classically an SMTP server that accepts mail from anyone to anyone (an open relay), plus the modern equivalents: open proxies, hacked webmail/PHP-mailer scripts, and misconfigured cloud instances relaying without authentication.

• Victim: the whole receiving ecosystem (the relay launders the abuser's origin), and the relay operator, whose IPs get listed (Spamhaus SBL/XBL-class listings; the PBL exists precisely because end-user IP space shouldn't emit direct-to-MX mail — Blocklists & Spamhaus).
• ESP signals: mostly a hosting-side category — customer VPS/dedicated hosts emitting mail that never transited the ESP's submission path; traffic-analysis anomalies in network self-scans; blocklistings of customer host IPs; complaints attributing mail to customer infrastructure the customer doesn't recognize.
• Actor: external abuser exploiting a negligent customer's misconfiguration or unpatched software (the Hosting Abuse BCP's core scenario: out-of-date CMS/scripts as the primary compromise route).
• Response: Compromised Accounts hosting-prevention baseline (contractual patching requirements, WAFs, per-customer IPv6 addressing for surgical blocking); Abuse Desk remediation loop; delisting mechanics in Spamhaus Listings Deep Dive.

SMS / messaging ridealong

Definition: abuse of non-email messaging capabilities attached to email-adjacent platforms — web→SMS gateways, e-card and invitation senders, "share this article" features, in-app notification and comment systems, REST messaging APIs. The M3AAWG Web Messaging BCP treats these as one attack surface with webmail: any feature that relays user-supplied content to a recipient the user chooses will be scripted for spam once email-path filtering makes it the cheaper channel.

• Victim: recipients on the other channel (SMS spam is costlier and more intrusive per message than email; carrier-side penalties for the platform are severe). The platform's carrier/aggregator relationships play the role blocklists play in email.
• ESP signals: per-feature volume anomalies (messages sent, invites issued) against the audited-resource baselines the Web Messaging BCP prescribes; registration-abuse patterns feeding the feature; identical payloads across many accounts; URL-heavy short messages.
• Actor: external via scripted signups, or compromised accounts — same actor fork as email abuse; the channel differs, the playbook doesn't.
• Response: Compromised Accounts — the Web Messaging BCP's three-layer defense (UI access, content filtering, distribution controls) was written for exactly this surface; rate-limit "almost all web services accepting or relaying user-generated content." Carrier-side compliance regimes (e.g., 10DLC registration in the US) are out of this KB's email scope; the taxonomy entry exists because the abuse arrives through the same accounts and forms the email side polices.

Using the taxonomy

Triage sequence for an unclassified report: (1) identify the abuse type from the signals above; (2) place it in the abuse-desk priority tiers — CSAM and threats outrank everything, malicious activity (phishing, malware) outranks spam; (3) resolve the actor class before choosing between recovery and enforcement — the courtesy steps owed a compromised customer are exactly the steps that must be denied a fraudulent one; (4) hand off to the owning article. Several types routinely co-occur (ATO → phishing; harvesting → spam → trap incident; fraud signup → snowshoeing): classify by the mechanism you must shut off, not the content observed.