Abuse

Abuse in email systems is the use of email, or of the infrastructure that carries it, for malicious or unlawful purposes: spam, phishing, malware, forged senders, and attacks against the mail servers themselves. It is the umbrella term for everything an abuse desk has to deal with.

One thing matters more than the definition: abuse is judged by the receiving side. It does not help that you consider your own bulk mail legitimate. If enough recipients complain, receiving systems treat the traffic as abuse and your IP address becomes subject to IP blacklisting.

What counts as email abuse?

• Spam — unsolicited bulk email. The defining property is the combination of unsolicited and bulk; a single unwanted message is not spam, and a large mailing to people who asked for it is not either.
• Phishing — messages that impersonate a trusted party to obtain credentials, payment data or a wire transfer. Business email compromise (BEC) is the targeted variant, often with no attachment or link at all.
• Malware distribution — attachments or links that install ransomware, loaders or credential stealers.
• Spoofing — forging the From: header or the envelope sender of a domain you do not control. This is what SPF, DKIM and DMARC exist to make detectable.
• Directory harvest attacks — probing a mail server with generated addresses to find out which ones exist, usually visible as a flood of RCPT TO commands answered with 550.
• Mail bombing and subscription bombing — flooding one address, often by signing it up to thousands of newsletters at once, to bury a real message such as a purchase confirmation.
• Relay and infrastructure abuse — using an open relay, an open proxy or a stolen SMTP credential to send someone else’s mail through your server.

What does a spam message look like?

Classic advertising spam is easy to recognise, and the technical envelope is usually more revealing than the text:

Return-Path: <bounce-9f21c@mailer-93.example.net>
Received: from mailer-93.example.net ([192.0.2.25])
	by mx1.example.org with ESMTP; Tue, 04 Aug 2026 08:11:02 +0000
From: "Financial Freedom" <no-reply@mailer-93.example.net>
To: undisclosed-recipients:;
Subject: Get rich quick!

Are you tired of living paycheck to paycheck? With our new program you
can earn big money from the comfort of your own home. Just sign up and
follow our simple instructions.

Act now and start making money today!

A To: header addressed to nobody in particular, a throwaway sending domain and a Return-Path that does not match the visible sender are all typical.

What does a malware email look like?

Malware mail is deliberately unremarkable. It imitates routine business correspondence, because that is what people open without thinking:

From: "Accounts" <billing@acme-invoices.example>
To: <office@example.org>
Subject: Invoice 2026-4417 attached

Hello,

Please find attached the invoice for the goods you ordered.
Let us know if there are any issues.

Thank you,
Acme Corporation

Content-Type: application/zip; name="invoice_2026-4417.zip"
Content-Disposition: attachment; filename="invoice_2026-4417.zip"

The archive contains an executable or a macro-enabled document rather than the PDF the filename suggests. Because the text is plausible, content scoring alone catches this unreliably — attachment type policies and sender authentication checks do more work here than keyword filtering.

Where does abuse from legitimate infrastructure come from?

Most outbound abuse from an otherwise well-run mail server is not a customer who decided to become a spammer. In descending order of frequency:

1. A compromised mailbox. Stolen or brute-forced SMTP AUTH credentials, used to send through your submission service. The giveaway is authenticated traffic from an unusual country at an unusual hour.
2. A hijacked web form. A contact or “tell a friend” form without rate limiting that lets an attacker inject recipients and body text.
3. A misconfigured relay. A server that accepts mail for domains it does not host, usually the result of an over-broad mynetworks or ACL entry.
4. A compromised web application on the same host, sending directly through the local mail transfer agent.

What happens when abuse comes from your network?

The consequences arrive in a predictable order: complaints to your abuse desk, then spam trap hits, then a listing of the individual IP address, then a listing of the surrounding range, and finally rejection of your legitimate mail by large mailbox providers. Recovering from the last stage takes considerably longer than preventing the first.

A second-order effect is backscatter: when spammers forge your domain as the sender, bounce messages for mail you never sent come back to you, and the reputation damage happens without any compromise on your side at all.

How is abuse reported?

Reports travel over three channels: free-text mail to the abuse@ address of the responsible network, machine-readable ARF reports from mailbox providers’ feedback loops, and automated feeds from blocklist operators and CERTs.

If you operate mail infrastructure, all three need somewhere to land. An abuse@ address that bounces, or a feedback loop nobody has enrolled in, means you learn about a compromise from a blocklist entry instead of from a report you could have acted on days earlier. What is and is not permitted on your systems belongs in an acceptable use policy, so that enforcement has something to point at.