How do ISPs participate in anti-abuse groups?

ISPs sit in an awkward spot. They run the pipes that spammers ride on, and they run the mailboxes that get hit. So they have to play on both sides of the abuse fight, and the way they do it is mostly through industry groups, shared data feeds, and a handful of real humans on abuse desks.

The big one is M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group). Comcast, Verizon, Orange, Deutsche Telekom, Charter, AT&T, the major mailbox providers, and most of the serious blocklist operators all sit at the same table three times a year. Meetings are closed-door on purpose. You sign an NDA, you share what you are seeing on your network, and you walk out with a clearer picture of what the rest of the industry is dealing with. That is where a lot of the best-practice documents come from, and it is where ISP abuse engineers actually meet the blocklist operators they will need to email at 2am during an incident.

The second piece is the abuse desk itself. Every ISP is supposed to honour abuse@theirdomain.tld per RFC 2142. The bigger ISPs run that as a real team that triages complaints, opens tickets against compromised customer accounts, kills outbound spam from infected machines, and answers escalations from places like Spamhaus and SURBL. The smaller ones run a script and a shared inbox. This is the contact point blocklist operators and other postmaster teams use when they need something cleaned up fast.

For data sharing, ISPs feed and consume a few specific things:

• Feedback loops (FBLs). When a customer hits "this is spam" inside the ISP's webmail, the complaint gets shipped back to the sending network in ARF format so they can suppress the recipient. This is how MBPs share spam data with senders at scale.
• Spamtrap and honeypot data. ISPs run dead addresses on their own domains and feed the hits to blocklist operators like Spamhaus and SpamCop. That is part of why blocklists work the way they do.
• DMARC aggregate reports. ISPs that act as mailbox providers (Gmail, Yahoo, Outlook count here, but so do Comcast and Cox) generate the rua reports defined in RFC 7489 so domain owners can see who is spoofing them.
• Postmaster portals. Postmaster tools and contact forms give senders a way in without needing a personal contact.

Third piece, the standards work. The same engineers who run abuse desks tend to sit on IETF working groups (DMARC, ARC, MARC, the ongoing email authentication updates) and on M3AAWG committees that produce the BCP documents the rest of the industry treats as ground truth. When you read "M3AAWG Sender Best Common Practices," the authors list is mostly ISP and mailbox provider engineers.

The dual role matters because the same network that hosts your inbox is also hosting the SMB whose WordPress site just got compromised and is now firing phishing at 4,000 emails an hour. The abuse team has to shut down outbound spam from their own customers, or upstream networks will start nullrouting them. So the motivation is not altruism. If an ISP gets a reputation for harbouring spammers, peers depeer them, blocklists list their IP ranges, and their actual paying customers stop being able to send mail. That is the lever that keeps participation honest.

If you want to see how this connects to the rest of the picture, the main anti-abuse networks answer covers the groups themselves, and how ISPs, ESPs, and blocklists communicate covers the day-to-day messaging between them.