I imagine it happens to many companies.
Correct. I see this as well. Outside of highly motivated campaigns it is drowned out in a sea of actual, legitimate, back and forth communication with real customers - and fat-fingered reports from customers who miss or misunderstand the various buttons in their webmail clients.
Detection of burst in abusive behaviour requires no technical help beyond what customer service needs (deserves to have available, imho), anyway.
providers like Yahoo and Verizon who do not adequately vet their
customers
You do not need to worry about the difference between report sources yourself. Amazon has been in the business for some time. They know good and well which sources of feedback are of which value in judging whether the abuse report merits any action on their side, as do most bigger players that receive varying levels of quality feedback.
the SES abuse metric
.. is a somewhat helpful indicator, not a scary threat. It is an incomplete view into the metrics available to the service provider. And it is always of marginal value if calculated for senders so small that a single dedicated bad actor can significantly skew the data. (Some other big players decide to not even show you such metrics when they would not mean much due to low volume.) Depending on what support contract you have, replying to inquiries about exceeding certain thresholds with a generic "we applied mitigation #3 from your list" could be more time- and cost-effective than presenting the facts & results of your inquiry to a random support rep assigned to review your account.
how to deal with this scenario generally
You can approach this like any other DoS vector. Someone is submitting cheap requests, and your job is to ensure they do not overwhelm your resources or your service providers. You do not need (and cannot) entirely eliminate it, but you can tune the cost to the attacker and the cost to you until the leverage is no longer threatening.
Verify if and when you need to, not as a mandatory step in establishing any relationship. Do not address a symptom (abuse metrics with 3rd parties), rather address the root cause (dysfunctional communication with your prospective customers).
You sending messages can only be exploited to the degree that Amazon cares about, if you
- send worthless messages right when someone inputs the recipients on your page and you
- send worthless messages in an order of magnitude of volume that you could not support (with real customer service people) anyway.
So do neither of those two. The second is easily done with appropriately scoped (by region, by source network, ..) rate limiting. The first deserves some explanation, as to why this is best viewed less as a technical problem, but rather a procedural problem:
If you have an excessive amount of people who sign up to your services that you do not follow up with in any meaningful way.. you got bigger problems than that the share of reported messages being noticed by email providers. The scenario where the email abuse metrics become an issue should be well beyond the point where your own business goals are an issue. Ask yourself what the relationship with newly interested parties should look like, and move the part where you verify their email address back beyond the point where this kind of abuse is cheaper to execute than to combat. Remember that collecting the email address as a unique user handle without immediately establishing a strong proof of control is not much of an issue, so long as both confirmed and unconfirmed recipients are always offered an easy way out when you do send messages to the specified mailbox. There are a few edge cases around timeouts and duplicates, but they have all been solved before (e.g., by Stack Exchange). Technicalities should not distract you from focusing on the actual (business) relationship with the newcomer.
