Don’t send from the cloud?

Over at MailChimp, Ben Chestnut writes about their frustrations from sending mail from the cloud.  The idea is that the cloud is great for computing but not for sending out mail.  Here are some excerpts:

Amazon EC2 is great for massive computing in the cloud. We’ve used it to run 61 trillion data comparisons for Omnivore. But it’s not-so-great for mass email marketing.

It seems that the mail server admins at some popular domains (e.g.,,,, and have their servers configured to consider all mail from reddit to be spam. This is because Trend Micro has marked Amazon’s entire EC2 network as a “dial-up pool”, and the aforementioned domains subscribe to Trend Micro’s list and block all mail from anyone on said list. We’ve written to Trend Micro explaining that we’re actually neither a spammer nor an individual end user, but rather an honest website [] that’s kind of a big deal, and they sent us a form letter explaining how to configure Outlook Express and encouraging us to ask our ISP for further information. We’ll try to figure something out as soon as time allows.

While it is true that sending mail from the cloud is more difficult, I wouldn’t write it off completely.  After all, my own organization here at Microsoft (Forefront Online) sends mail from the cloud.

The reason others advise against this is that the cloud is a pool of shared resources.  Organizations use a common set of servers, and they also use a common set of outbound IP addresses from which to send mail.  If one of the actors in the common set of IPs is malicious, either intentionally or not, they can end up getting the entire set of IP addresses blocked.  Thus, Customer A may be doing everything right but it won’t matter if Customer B is misbehaving.  Maintainers of RBLs frequently do not differentiate between owners of dedicated IP space (like a corporation) and owners of shared IP space.  If they do list the shared IP space, it can lead to a lot of headaches (sometimes more than they are worth).  This is why people advise against sending from the cloud – it’s hard to prevent outbound spam and overzealous DNSBL maintainers can impact your delivery through no fault of your own. 

This is what happened with Amazon’s EC2 – “spammers” signed up for their service and used it to send outbound spam.  Reddit used the same servers to send outbound mail.  They couldn’t deliver because receivers caught on to Amazon’s abuse of service and decided to throttle their connections.  This leads to collateral damage.

I wouldn’t advise not using cloud sending.  However, it is more difficult to do.  Here are my thoughts:

  1. Cloud vendors need to do outbound spam scanning and do something with the mail that is considered abusive.  We route it through a different set of IPs if we determine that it is spam, and we do pretty aggressive monitoring looking for senders who are abusive, intentional or not (we have both).  When we find them, we shut them down.  Thus, cloud vendors need to be aware that they have a user base that is prone to “pwnage” and proactively detect it and mitigate it in advance.

  2. DNSBL maintainers and receivers of mail need to cut cloud vendors some slack.  At the very least, if the cloud vendor can demonstrate that they are actively trying to clean up their act, then good faith efforts should be rewarded.  Seriously, nobody of good repute wants to send spam.  And sometimes stuff gets by us.  We will turn off the guys who are being abusive, so give us a break!
  3. It makes sense for cloud vendors to identify, somehow, the downstream users.  DNSBLs work via the assumption that an IP is a good identifier.  This is still true but the connecting IP is not necessarily the one you want to look at every time.  You might need to traverse headers looking for something, or better yet, use an identification technology such as DKIM to differentiate between end customers.  I doubt anyone would block based upon a DKIM validation (ie, banned organizations) due to the computational overhead, but it does help when doing analysis after the fact.

That’s the way I see things.  Seriously, Amazon ought to give me a call about how to clean up their act.  I (and my team, too) have tons of experience when it comes to maintaining your outbound reputation in a shared-tenant environment.

Comments (3)

  1. "The Cloud" is a generic term. To advise not to send or to send email from "the cloud" is a little ambiguous. I'd certainly advise NOT sending from Amazon's cloud. That isn't what it is designed to do. Find yourself a good email host, which may or may not use 'cloud' technology (whatever that may be) and go for it.

  2. Al Iverson says:

    Dumb question, but why send the mail at all if you've determined that it is spam? Sending it from a different IP feels a little weird or sneaky or something.

  3. tzink says:


    Content filters are not perfect, and filtering outbound mail is prone to false positives, especially newsletters.  The idea of sending it through another pool of IPs is that the mail is still getting delivered.

    The question of what to do with mail flagged as spam is a difficult one because false positives occur.  Do you silent drop?  If so, how do you notify the end user?  Bounce the mail?  If so, how does the end user get their mail through?  In the end, we made the decision to interfere with the mail as little as we could while taking action on offending users.

Skip to main content