You are confusing "clean rejects on SMTP level" with "backscatter". If your server accepts the email first, then scans it, and then decides it is spam, it's to

You are confusing "clean rejects on SMTP level" with "backscatter". If your server accepts the email first, then scans it, and then decides it is spam, it's too late. Then it has only the choice between ignoring and backscatter, because it can't reliably inform the real sender - the TCP/IP connection is already closed and the email's sender is almost certainly forged. However, if your server scans the email during the SMTP transfer, and rejects it with a clean error code, the sender gets a clean error message and its the sender who is responsible to inform the client. Note that there's another downside of this approach which is why you don't find this early-reject very often in the wild: The receipient has no chance to get the email, not even by scanning their spam folder. So the sender has to understand the error message and to send a "less spammy" email, or he can't get in contact to the receipient at all. For some professions, this might be a no-go, as this means missing potential customers just because they use a bad email client which sends spammy-looking emails. However, if you don't have this "type" of customers, early-rejecting on SMTP level is a perfect solution. We're using this configuration for years on our mail servers, it works pretty well and we've never, ever had to send backscatters. Yet every sender whose email was classified as spam has been correctly notified about this issue.