Email Abuse Taxonomy

When an abuse report reaches your desk, the first job is to classify it: what kind of abuse is this, who is the victim, and who is the actor? Those three answers decide which playbook you follow.

Each entry below defines one abuse type, names its victim, lists the detection signals you can see from the ESP's side (not the receiver's), identifies the typical actor, and links to the guidance for the response. For triage priorities and the remediation loop itself, see Abuse Desk Operations.

The actor axis

The same outbound symptom, spam pouring out of your IP addresses, has four very different causes, and each needs a different response. Getting the actor wrong is the most expensive mistake in triage:

What separates the first two is a pattern of earlier valid use, the test for telling compromised accounts from malicious ones in Compromised Accounts. Analyse the metrics carefully before you assume a mechanism: what looks like a compromise is often abuse of trial signups, and the reverse is also true.

Master table

Spam / UBE

Definition (Spamhaus): Unsolicited Bulk Email. Unsolicited means the recipient has not granted verifiable permission. Bulk means the message is part of a larger collection of substantively identical messages. Both conditions must hold: "spam is an issue about consent, not content." Spam is the parent category. Most other types listed here are spam with an aggravating characteristic, such as deception, malware or fraud.

• Victim: the recipients. Because ESPs are judged on their overall traffic, every other customer on shared IP addresses or domains is also a victim (Multi-Tenant Architecture).
• ESP signals: spikes in the FBL complaint rate, spam-trap hits, rising rejections and deferrals at major receivers, blocklistings, and unusual bounce profiles when a list is imported. For thresholds and corrective actions, see Metrics & Benchmarks.
• Actor: an intentional customer (bought lists, no consent) or a negligent customer (list hygiene that has decayed). Tell it apart from a compromise by comparing with the account's usual behavior.
• Response: the remediation loop in Abuse Desk: validate the report, notify the customer citing the terms of service, remediate, suspend, terminate. Prevent it through Customer Vetting. For incidents driven by spam traps, see Spam-Trap Incident Response.

Phishing (including spear phishing and BEC)

Definition: mail that impersonates a trusted party to steal credentials, payment data or money. Spear phishing targets specific individuals with researched pretexts. Business email compromise (BEC), as the FBI's Internet Crime Complaint Center (IC3) describes it, is the sophisticated end: the attacker impersonates an employee, a vendor or an executive (through spoofing, lookalike domains or a mailbox that has actually been compromised) to trigger fraudulent transfers of funds. The Anti-Phishing Working Group (APWG) describes it as impersonating a trusted party to trick an employee into sending money or privileged assets. BEC often involves no malicious URL or attachment at all. It is pure social engineering, which content filters cannot catch.

• Victim: two victims, the impersonated brand (damage to its reputation, and DMARC problems) and the defrauded recipient.
• ESP signals: hostile or deceptive URLs in customer content (hits on the phishing list of SURBL, or on Spamhaus DBL and HBL; see URL & Content Filtering), and takedown notices from brand-protection firms and trusted reporters. On the hosting side, look for phishing kits on customer sites: the Hosting Abuse BCP notes that phishing is almost always run through compromised end-user accounts with outdated scripts. Pure BEC rarely passes through an ESP in volume, because it is low-volume and targeted. Credential-phishing campaigns against your own customers, run to set up account takeovers, certainly do.
• Actor: a fraudulent signup (intentional) or a compromised customer account or site. The actor is external when only your brand is imitated (see the next entry).
• Response: P2 in the abuse desk priority tiers, because malicious activity ranks above spam. Suspend the sending mechanism immediately, then decide whether the account is compromised or fraudulent. Phishing aimed at your customers to collect their ESP credentials feeds into Compromised Accounts.

Brand spoofing and lookalike domains

Definition: an external attacker sends mail as a brand without touching the brand's infrastructure. The attacker either spoofs the exact domain (a forged From address, which an enforced DMARC policy defeats) or uses cousin or lookalike domains (typos, added terms such as "-login", other top-level domains). A lookalike domain authenticates perfectly as itself, and so passes DMARC without trouble.

• Victim: the brand and its recipients. The ESP is also a victim when its own brand, or its customers' domains, are imitated to phish credentials.
• ESP signals: DMARC aggregate reports from customers that show unauthorized sources (DMARC Aggregate Reports), signups during vetting that use lookalikes of known brands (a classic sign of a fraudulent signup; see Customer Vetting), and hits from certificate transparency and domain registration monitoring.
• Actor: external. In the variant an ESP sees, a fraudulent customer registers the lookalike domain and asks you to authenticate it. This is why customer domain authentication checks belong in onboarding.
• Response: Brand Protection and Domain Management covers the domain inventory, defensive registration, monitoring and the takedown paths. DMARC enforcement handles spoofing of the exact domain.

Snowshoeing (IP and domain)

Definition (Spamhaus): spreading spam thinly across many IP addresses and domains to dilute the reputation of each identity and stay under filter thresholds. It uses "ranges and domains with poor or frequently changing identification," and the spammer uses the IP addresses legitimately (they are not botnets). The domain variant rotates newly registered domains in the same way.

• Victim: filters and receivers, which the spammer evades. The ESP is also a victim, because its IP space and its tools for delegating domains are consumed, and so are its other customers when CSS listings hit shared ranges.
• ESP signals: during vetting, prospects who request an unusually large number of IP addresses or sending domains for their volume, anonymized WHOIS records, many previous ESPs, and any hint of changing infrastructure to evade a listing (an explicit warning sign in the Vetting BCP). In operation, frequent domain changes, sending that stops and starts to spread metrics across platforms, and Spamhaus CSS listings ("many frequently-changing domains is itself the signal").
• Actor: an intentional customer, by definition. Snowshoeing is a deliberate setup and never an accident.
• Response: see the Spamhaus Listings Deep Dive for how the listing works and how to get delisted. Terminate rather than remediate, because a snowshoe operation has no legitimate configuration to restore. Prevent it through vetting and a model of tiered rights, in which new accounts do not get large sets of IP addresses or domains.

List bombing / subscription bombing

Definition: a denial-of-service (DoS) attack against one mailbox. A script submits the victim's address to thousands of unprotected signup forms, and the flood of legitimate confirmation and welcome mail buries the inbox, often to hide notifications of fraud.

• Victim: the owner of the targeted mailbox. Secondary victims are the form owners (their lists are poisoned and receive trap submissions) and the ESP (Spamhaus listed ESP sending IP addresses during the 2016 wave).
• ESP signals: unusual signup rates to a single address or domain across many customers' forms on the platform, floods of confirmation messages to one address, and a sudden start with no gradual ramp.
• Actor: an external attacker. Customers with unprotected forms are negligent conduits.
• Response: Subscription Bombing & Signup-Form Abuse gives the full playbook: detection signatures, requirements for CAPTCHA and confirmed opt-in (COI), suppression of each targeted address during an attack, and coordination across the industry.

Malware / ransomware distribution

Definition: mail that delivers malicious payloads, either as attachments (droppers, documents with macros) or as links to sites that host exploits or downloads. This includes the delivery of ransomware and recruitment into botnets.

• Victim: the recipients' machines and organizations. The ESP's reputation collapses quickly, because distributing malware triggers the harshest responses from receivers and blocklists.
• ESP signals: hits from scanning outbound attachments for malware (the Web Messaging BCP says to restrict the types of files that can be uploaded and to scan them for malware), SURBL malware or Spamhaus HBL hits on linked domains, and urgent notices from trusted reporters and computer emergency response teams (CERTs). On the hosting side, look for malware placed on customer sites (P2 in the hosting tiers).
• Actor: rarely a deliberate ESP customer, since mainstream ESP tools are a poor channel for malware (attachments are limited and content is inspected). Usually the actor is a compromised customer site or account, or a fraudulent signup abusing free-tier sending.
• Response: P2 in Abuse Desk. Stop sending immediately, with no remediation window for the traffic itself. Then decide whether the account is compromised or fraudulent, as described in Compromised Accounts. For detection in content, see URL & Content Filtering.

419 / advance-fee and other fraud content

Definition: fraud in which the content itself is the crime. Examples are advance-fee fraud (called "419", after the section of the Nigerian Criminal Code on fraud), which promises a large payoff for an upfront fee; lottery and inheritance scams; fake jobs and overpayment fraud; romance scams that develop over time; and the "stranded traveler" plea, sent from a hijacked account to its own contacts.

• Victim: the recipients, financially. The volume is usually low compared with UBE. What makes this type serious is the harm each message can do.
• ESP signals: content heuristics and long-lived filter signatures (these scams are decades old and their wording barely changes), complaint text that describes the scam, and low-volume accounts sending mail styled as personal messages to scattered recipients. For the stranded-traveler variant, look for an established account that suddenly mails its whole contact list.
• Actor: an intentional fraudulent signup, or a compromised account for the customized variants. The Compromised User ID BCP classes stranded-traveler scams as "permanent credential, customized exploit," which always need human intervention.
• Response: triage in Abuse Desk. Fraud reports can also arrive through law enforcement, and those outrank spam in the queue. Fraudulent accounts are terminated without the courtesy steps.

Backscatter generation

Definition: misdirected bounces. A server accepts a message with a forged return address and then bounces it to that innocent address, instead of rejecting the message during the SMTP session. In volume, the bounces are themselves UBE, and the operator that sends them gets blocklisted.

• Victim: the holders of the forged addresses (often the real users of a spoofed brand), then the ESP that generates the bounces, through blocklists focused on backscatter and through reputation damage.
• ESP signals: outbound delivery status notifications (DSNs) or auto-replies to addresses you never delivered mail to, complaints about "bounces for mail I never sent", and listings on DNSBLs that target backscatter.
• Actor: none in the usual sense. Backscatter is a misconfiguration: accepting mail and bouncing it later, autoresponders without safeguards, or challenge-response systems. The external spammer who forges your customers' addresses supplies the trigger but never touches your systems.
• Response: Abuse Desk: backscatter describes the mitigations: reject during the SMTP session, Bounce Address Tag Validation (BATV), suppress bounces based on SPF, and clean the queue. For how bounces work, see DSNs.

DKIM replay

Definition: an attacker obtains one message with a legitimate DKIM signature (for example, through a free trial or a signup confirmation sent to a mailbox the attacker controls) and sends it again, unchanged, to millions of recipients. Every copy carries a valid signature, so the reputation of the d= domain is spent on mail that the domain never sent to those recipients.

• Victim: the signing domain. That is the ESP itself when customers sign with domains the ESP shares among them, or otherwise the customer's own domain. The recipients are secondary victims of the spam.
• ESP signals: the defining anomaly is reputation damage with no matching sending records. You receive complaints and blocks for messages, recipients or volumes that do not appear in your logs, see a single Message-ID at huge scale in receiver feedback, or see domain reputation collapse on a stream whose own metrics look clean.
• Actor: external. The attacker only needs to receive one signed message, and a free-tier signup is enough. This is why replay is specifically an attack on ESPs with self-service trials.
• Response: DKIM Replay Attacks covers the mitigations and their tradeoffs: a short x=, separate selectors and keys for each stream, oversigning, and controls on trial accounts. Key hygiene is covered in DKIM Key Rotation. Vetting trial signups limits the attacker's access to freshly signed mail (Customer Vetting).

Account takeover / compromised sending

Definition: a legitimate customer account that is fully or partly under unauthorized control (a "compromised user account" in the words of the Compromised User ID BCP). The attacker uses it to send spam, phishing or fraud through the reputation the customer has earned and through the ESP's infrastructure.

• Victim: first the customer (its reputation, data and contacts), then every tenant that shares its IP addresses or domains, then the recipients.
• ESP signals: a break from the account's own usual behavior. Examples are logins from new locations or from places too far apart to travel between, unfamiliar user agents, sudden changes in volume or in the set of recipients, new kinds of content, deleted sent mail, and changed forwarding or reply-to settings. Other signals are a surge of FBL complaints on an account with a clean history, and intelligence from credential dumps that names customer email addresses.
• Actor: a compromised customer, by definition. The test for a pattern of earlier valid use separates this from abuse at registration.
• Response: Compromised Accounts & Outbound Abuse covers the whole lifecycle: detection feeds, the mitigations for the four types of compromise, forcing users to authenticate again, and handling repeat compromises. Reports often arrive through the abuse desk. For how FBLs work, see Complaint Feedback Loops.

API-key abuse

Definition: abusive sending through stolen or leaked API credentials rather than through an interactive login. The keys may have been committed to public repositories, taken from compromised customer servers, or phished. API-key abuse is a subtype of account takeover (ATO) with its own detection profile. It is listed separately because API traffic bypasses the login anomalies that most ATO detection relies on. This split reflects the practice of sending platforms (vendor security guidance on revoking leaked keys, and secret scanning of the kind GitHub offers), not a category formally defined by M3AAWG.

• Victim: the customer that owns the key, and the shared infrastructure.
• ESP signals: sending through the API with no matching activity in the dashboard, new source IP addresses or ASNs on the API path, notifications from secret scanning (keys leaked in public repositories), and a new or changed API integration just before a spike in trap hits or complaints. Spam-Trap Incident Response lists that last signal explicitly as a reason to vet the customer again. Volume patterns unlike the integration's history are another signal.
• Actor: a compromised customer (leaked credential). Distinguish this from an intentional customer who scripts abuse through their own key, which is ordinary spam sent over an API.
• Response: Compromised Accounts. This applies the "temporary or permanent credential" model to machine credentials. Revoke the key immediately (a password reset is not enough, because the key survives password changes), issue replacement keys with limited scope, and audit what the key touched. To prevent it across the platform, give new accounts tiered rights, with API access restricted until tenure and reputation justify more (Customer Vetting, fraud-prevention practices), and enforce limits for each tenant to contain the damage (Multi-Tenant Architecture).

Affiliate spam

Definition: spam sent by third-party affiliates who promote a customer's or an advertiser's offer for a commission. The advertiser may be entirely legitimate. The abuse comes from affiliates whose lists and methods nobody vetted. The Vetting BCP identifies this category as a historical source of abuse, and notes that programs a company runs itself are riskier than those run by reputable third-party networks.

• Victim: the recipients (who never consented to the actual sender), the advertiser's brand, and the ESP if either the affiliate mail or the traffic to the promoted landing pages touches its infrastructure. "Spamvertising on network" has its own line in the hosting abuse tiers.
• ESP signals: vetting answers that admit to affiliate programs, content full of redirectors and tracking chains that lead to third-party offers (URL & Content Filtering covers redirectors), complaint and trap rates far above those of the same customer's streams to its own list, and Spamhaus DBL listings of the promoted domains even when your sending IP addresses stay clean.
• Actor: an intentional customer (who knowingly buys traffic driven by spam) or a negligent customer (who runs a program without policing its affiliates). The affiliates themselves are outside the relationship with the ESP, and that gap in accountability is exactly what makes the category dangerous.
• Response: Customer Vetting (extra scrutiny at onboarding, and questions about how the program is managed). Consent Methods explains why affiliate lists produce complaint profiles close to those of purchased lists. Enforce through the standard abuse desk loop, and hold the customer answerable for its affiliates.

Cold email / consent-less outreach

Definition (M3AAWG, Nov 2025): unsolicited email from senders who are otherwise legitimate and identifiable, seeking a business relationship with recipients who have no prior relationship, connection or consent. It is sent with deceptive tactics to imitate one-to-one mail: small randomized batches, lookalike or throwaway domains, and technically valid authentication used as camouflage. M3AAWG's position is that cold email delivered deceptively is spam.

M3AAWG's Sender Best Common Practices (Version 4.0, August 2026, section 4.5) summarizes the position more broadly: it describes cold email as abusive without the qualifier about deceptive delivery, and refers readers to the position paper for the full details.

• Victim: the recipients, and the ESP. Cold email operations deliberately spread volume across accounts, subdomains and providers to avoid detection. They use up shared reputation and, at the account level, look much like snowshoeing.
• ESP signals: many small "personalized" sends built on the same template, purchased or scraped B2B lists (role accounts, no evidence of opt-in), rapid creation of domains or subaccounts, integrations with sending tools marketed for "outbound sequences", and complaint rates that are modest in absolute terms but extreme for the volume.
• Actor: an intentional customer, usually one who sincerely argues that the mail is legitimate. That is why the M3AAWG position exists: it gives abuse desks an industry consensus answer to "but it's not spam, it's sales outreach."
• Response: M3AAWG Position on Cold Email sets out the argument about the definition and the detection indicators. Enforcement is driven by policy (a prohibition in the acceptable use policy, and screening during vetting) through Customer Vetting and the Abuse Desk. For why consent cannot be transferred, see Consent Methods.

Harvesting / scraping

Definition: collecting email addresses without consent, by crawling websites, scraping platforms and breach dumps, or generating addresses from dictionaries, to build or sell lists. The abuse an ESP encounters comes later: a customer mailing a harvested list.

• Victim: the address owners, then the customer who mails the list and the ESP. Harvested lists are full of pristine spam traps (planted precisely to catch harvesters), invalid addresses and role accounts.
• ESP signals: at list import, a high share of role accounts, implausible spreads of domains, and no opt-in metadata. At the first send, high hard-bounce rates together with pristine trap hits. That combination is the signature, since pristine traps point almost uniquely to harvested or purchased data. Another signal is a customer who cannot produce evidence of opt-in for addresses you spot-check (the audit technique used in trap incidents).
• Actor: the harvester is external. The actor the ESP has to deal with is the intentional or negligent customer who bought or scraped the list.
• Response: Consent Methods places harvesting at the bottom of the range of acquisition methods, and every acceptable use policy prohibits it. Spam Traps and Spam-Trap Incident Response cover the incident that reveals it. CAN-SPAM increases the penalties for sending to harvested lists (CAN-SPAM).

Open relay / proxy abuse

Definition: third parties route mail through infrastructure that should not relay it for them. The classic case is an SMTP server that accepts mail from anyone to anyone (an open relay). Modern equivalents are open proxies, hacked webmail or PHP mailer scripts, and misconfigured cloud instances that relay without authentication.

• Victim: the whole receiving ecosystem, because the relay hides where the abuse came from, and the relay operator, whose IP addresses get listed. Spamhaus lists them on the SBL or XBL, and the PBL exists precisely because end-user IP space should not send mail directly to mail exchangers (Blocklists & Spamhaus).
• ESP signals: this is mostly a category for hosting providers. Look for customer virtual or dedicated servers sending mail that never passed through the ESP's submission path, anomalies in traffic analysis during network self-scans, blocklistings of customer host IP addresses, and complaints that attribute mail to customer infrastructure the customer does not recognize.
• Actor: an external abuser exploiting a negligent customer's misconfiguration or unpatched software. This is the core scenario of the Hosting Abuse BCP, where outdated content management systems and scripts are the main route to compromise.
• Response: the baseline for preventing abuse at hosting providers in Compromised Accounts (contractual requirements to patch, web application firewalls (WAFs), and a separate IPv6 address range for each customer so that blocks can be precise), the remediation loop in Abuse Desk, and how delisting works in the Spamhaus Listings Deep Dive.

SMS / messaging ridealong

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

• Victim: the recipients on the other channel. SMS spam costs more and intrudes more per message than email, and carriers penalize the platform severely. The platform's relationships with carriers and aggregators play the role that blocklists play in email.
• ESP signals: unusual volume for a single feature (messages sent, invitations issued) compared with the audited resource baselines that the Web Messaging BCP prescribes, patterns of registration abuse feeding the feature, identical payloads across many accounts, and short messages full of URLs.
• Actor: external, through scripted signups, or compromised accounts. The actors are the same as for email abuse: the channel differs, but the playbook does not.
• Response: Compromised Accounts. The three layers of defense in the Web Messaging BCP (access to the user interface, content filtering and distribution controls) were written for exactly this surface. Apply rate limits to "almost all web services accepting or relaying user-generated content." Compliance regimes on the carrier side (for example, 10DLC registration in the US) are outside the email scope of this reference. The entry is here because the abuse arrives through the same accounts and forms that the email side polices.

Using the taxonomy

For a report that has not been classified yet, follow this sequence:

1. Identify the abuse type from the signals above.
2. Place it in the abuse desk priority tiers. Child sexual abuse material (CSAM) and threats outrank everything, and malicious activity (phishing, malware) outranks spam.
3. Identify the actor class before you choose between recovery and enforcement. The courtesy steps you owe a compromised customer are exactly the steps you must deny a fraudulent one.
4. Hand the case to the guidance for that type.

Several types often occur together: account takeover leading to phishing, harvesting leading to spam and then a trap incident, or a fraudulent signup leading to snowshoeing. Classify the case by the mechanism you must shut off, not by the content you observed.