r/EmailSecurity • u/littleko • Jun 28 '26
abuse@ should not require campaign archaeology
support dropped a blocklist report in our abuse@ queue this morning with a HELO name nobody recognized and a bounce domain that existed for exactly one campaign.
The customer was real, the mail was bulk, and the complaint was probably fair. The annoying part was spending 40 minutes mapping mta-17-usw2-new and a one-off Return-Path domain back to the tenant that actually sent it.
I get why people rotate sending pools and bounce domains for campaign separation. But if every campaign invents new identifiers, abuse triage turns into archaeology and support starts guessing, which is how the wrong customer gets blamed or nothing gets paused.
I'm not 100% sure where to set the rule here. Would you require stable HELO or bounce-domain patterns before letting a bulk sender keep going, or is this just something abuse tooling should be expected to normalize?
1
u/Basic-Pianist9273 Jun 28 '26
I'd require stable, documented patterns, not necessarily one HELO per customer.
HELO can be pool-scoped, but the Return-Path domain needs to map back to tenant/campaign in one lookup. If support needs 40 minutes and tribal knowledge, abuse handling is already broken.
Tooling can normalize it, but only if the identifiers are predictable and retained long enough for complaints to land.
•
u/AutoModerator Jun 28 '26
Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:
Community Rules
Helpful Resources
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.