It’s easy to look at Amazon SES and sigh. Thousands of low-end customers sending mail from a shared IP pool? Amazon already knows that trick never works! Just one spammer will ruin the reputation of those IP addresses, resulting in ongoing delivery problems for everyone who uses the service.

It is possible that Amazon can build the systems and human processes to keep spammers out; certainly sounds like they want to. Constant Contact managed that with their shared IP pools, but they’re still constantly working to keep things clean. So is MailChimp, who last year publicized some of how their system works—not a small investment at all.

Like any new service, Amazon SES will have to balance constant growth and the features their customers are demanding against features needed for abuse prevention. The market for an easy outbound mail API “in the cloud” may well be gigantic; it’s pretty obvious that email is the last thing that the latest social/cloud/whatever startup entrepreneur wants to think about.

When the next hot site discovers that deliverability isn’t ever guaranteed—indeed, when they discover that deliverability is even a word (which is still debatable)—will they blame Amazon, or will they blame the mailbox provider who rejected the message?

Mailbox providers never want to block mail that their users actually want to receive, so they’re already in a tough situation. If Amazon SES or another cloudy shared-IP outbound email service becomes popular—and I think it could—then mailbox providers will each have to choose: let that mail in and risk the spam (and worse), or block it and risk upsetting customers? Would blocking it force Amazon to change their architecture to give each customer a unique IP address (which they really can’t do anymore), or will someone start screaming about censorship? Who’ll blink?

It doesn’t have to be contentious. There’s another way. We have the technology.

Amazon says that messages can be signed with DKIM before they’re injected into SES. That’s probably not as easy as API-minded folks might like, but at least it’s an option.

Now imagine: there’s this wild new mailstream spurting and sputtering from shared IPs. Some is spam, some isn’t, and some of each of those are signed with DKIM. All the mailbox providers (or their spam filter vendors) need is a DKIM-based domain reputation system! The big mailbox providers have already been experimenting with this, and a few have built things; now the rest will need to catch up.

So, no, I don’t think Amazon is intentionally playing chicken. But they could: Amazon could require injected messages to be signed with DKIM, or even sign them themselves, perhaps using the sender’s AWSAccessKeyId or another unique identifier in the i= value so that different senders can be held apart. Differentiation is the real key here; DKIM is simply a convenient, standard way to accomplish it.

And if that game of chicken did commence? This time, I might just bet on the cloud.

This article was originally published on Return Path’s Received: blog.