Hacker News new | past | comments | ask | show | jobs | submit login
Mandrill’s Betrayal (dangrossman.info)
323 points by jjude on Mar 1, 2016 | hide | past | web | favorite | 150 comments

Big win for Mailgun, huge loss for MailChimp. They just stabbed developers in the back.

Take note kids: this is a shining example of how not to market such a large product/service change.

What a fiasco. Directly going against their About Page, failing to update their pricing page to indicate the change.. it's all bad.

I'm in the camp of everyone else where the TOS change is forcing my startup leave.

The net negative effect is that I'll likely start moving off of MailChimp for marketing emails as well. They've already broken my trust.

Their pricing model is a sham anyways: paying for list maintenance is utter BS. It's a small multi-kilobyte file if you're not actually using it.

I've taken to exporting and clearing certain lists at intervals to keep costs down. In reality, I should simply never have done user data collection with MailChimp to begin with.

I imagine there was some kind of crisis happening behind-the-scenes... That's the only explanation I see for the overnight policy change and lagging updates on the site. Either that or total incompetence.

Interestingly, their (former) competitors are taking full advantage of the outrage by running ads on Twitter and LinkedIn aimed at Mandrill customers who've been screwed.

"Screwed over by monkey business?" Please tell me someone in some advertising department thought of this.

Almost! I got a twitter ad for "Monkey throw a wrench in your email system?"

I wonder if they found certain types of Mandrill users were destroying their deliverability metrics and were starting to cause issues with major email providers and their spam factors. These ESPs can't exist with poor desirability, so they have to put protecting that ahead of a lot of other things that might get them more customers.

Considering how good Mandrill's delivery was, I'd be surprised if this were the case. Even still, there are better solutions - cut the free tier off, for example!

"These ESPs can't exist with poor desirability"

I think you meant deliverability. But maybe we should all switch to calling it desirability.

That may have been an autocorrect or may have been my mind not functioning correctly, but yes.

This is my theory too. There must be something very broken in mailchimp's management. I can't believe that something this knuckle headed would come out of our well functioning management team.

This is where we're at too. We've long been evangelizing Mailchimp and Mandrill in our product, and as a result have sent plenty of customers their way. In fact, our product almost relies on them as a pair.

Now, because of the ToS, we have to remove it from our product and port our users somewhere else...and fast.

We also have to port our own servers to another service, and fast.

I remember the day we finally had enough subscribers to actually start paying Mailchimp money, and now all I can think about is how much disdain I have for them. Unless they reverse course on this issue, we will be shouting "down with Mailchimp" from the rooftops to all of our customers.

> We also have to port our own servers to another service, and fast.

Once you've done that you should look at what other services you rely significantly upon and see about mitigating the risk there by having an alternative ready to go (or even sharing the load).

At a previous startup we realised we relied wholly upon Mandrill and so reimplemented the sending code so that half of the emails went out via Mandrill and the other half by SendGrid. A stunt like the above just requires a quick reconfigure to make all emails go via the alternative provider whilst we (with less panic) add another new alternative provider to share the load. It also helps build up a positive reputation before cutting over straight away.

(This wasn't about splitting the emails amongst free tiers to keep it free, we were far away from moving up to a paid tier even with all emails going through one provider.)

We're doing the same. I re-wrote our code over the weekend from sending solely through Mandrill, to splitting our traffic 50/50 between SendGrid and SparkPost. I'm going to implement a similar strategy for some other external services we rely on and I've open sourced the Go code [1].

This also has the benefit that if one service goes down, we can automatically fallback to the other with (hopefully) no downtime. Most email providers have a limit to what you can send until you're established with them, so using another provider as a standard backup isn't feasible, as suddenly sending 1,000's of emails a day will see the account get suspended pretty quickly.

Plus, if one of them goes out of business or changes their terms with little notice, like Mandrill, we should have a bit more time to work around it as at least one service will work.

[1]: https://github.com/dchesterton/go-service

Great minds, we did the same thing though, we always sent 100% through mandrill just to be able to investigate delivery issues more simply, quick change and send grid is up and elasticmail.com is looking good

Even if they reverse course (or just delay it for a bit longer to give their users more time to switch), I think people are going to be shouting "down with Mailchimp" for quite some time. It's really hard to trust someone after they've screwed you thoroughly.

Same problem, same sentiment I now have about Mailchimp/mandrill.

Just spent the morning migrating our mailing services to SES.

Now I'm going to have to rewrite our incoming mail parser, since I hooked into their API's for all that. What a mistake that decision was.

Thanks, after reading this I was just looking for a service to migrate to from Mandrill, and Mailgun looks great!

fyi, i use sendgrid, it has a pretty good free tier.

It's way worse than just the TOS change. Mandrill has a lot of advanced features (webhooks, reporting, AB testing, templates, etc). Some companies may be able to switch to SES or mailgun in a day, but more advanced integrations could take weeks. We're stuck with either pulling people off critical project in order to meet their ridiculously short deadline, or pay insane bills (the new price is over 4x the price we signed up for).

I emailed their founders and never received a reply.

Lesson learned: do not take a dependancy on MailChimp for any reason.

Agreed, I'm surprised the 4x price increase is not mentioned more often. Personally I can understand moving away from a free offering, especially if they're having trouble with spammers, but to quadruple pricing out of the blue? For sites, like mine, built around a huge amount of transactional email (scheduling group gaming sessions and notifying your group by email), a 4x increase is essentially no different than just shutting down. They have their reasons, and now I have mine, to never use a mailchimp product again.

This is where I am at. This is insanity.

Other mail services can do the same. It's funny we have not fixed the problem of free mail, i.e. any one should be able to run a mail server anywhere and expect delivery of their mail. We should just do a better job of filtering spam and bad users, but mail should still be able to leave any server and be delivered to any other address.

Just to be clear: I'm happy paying a premium for all the great features services like SendGrid/Mandrill offer. We knew about cheaper services like SES, or the ability to roll our own, but we didn't want to re-invent the wheel.

I'm not happy about them quadrupling their prices, with a ridiculously short deadline to avoid it.

The real kicker: will Mailchimp drop support completely later on... next month? I've no confidence in them anymore. We're moving asap.

Some head-to-head comparisons of Mailgun and SendGrid, for those trying to find an alternative provider.

- Free Tier: Up to 10k emails/mo with Mailgun, up to 12k with SendGrid.

- Low Volume: To send 100,000 emails/mo on a shared IP, you'll pay $45 with Mailgun or $20 with SendGrid.

- High Volume: To send 300,000 emails/mo on a dedicated IP, you'll pay $204 with Mailgun or $199 with SendGrid.

- Deliverability: In today's InboxTrail comparison, Mailgun shows 62.5% inboxing, SendGrid shows 97.5%. [1]

If you need any help with your integration, I'd be happy to put you in touch with the right people on our team. My email's in my profile.

Disclosure: I'm a SendGrid engineer.

[1] https://www.inboxtrail.com/compare

- Mailgun’s prices scale much better than Sengrid. 700,000 emails per month w/ Mailgun $316.50 vs w/ Sendgrid $399

- All paid accounts are given unrestricted access to all Mailgun features. Sendgrid feature gates by plan

- Mailgun has no punitive overages, with Sendgrid you’ll pay as high as $1 per 1000 emails for exceeding your plan. https://sendgrid.com/mkt/assets/pdfs/1-16_SendGrid_Compariso...

Disclosure: I work for Mailgun

- After Mailgun's $59 surcharge per dedicated IP (which customers will need, given your shared pool deliverability record), you'll find SendGrid's high volume prices scale pretty closely.

- We do offer plans without subuser management and whitelabeling. That's so we can be a cost-effective choice for startups and low-volume senders, which I'd argue is a good thing! Pro customers always get every feature we have to offer, including a dedicated IP.

- Overages rarely happen. In the specific case he's describing, it's nearly always going to make sense to pay $10 for 60,000 more emails.

The Mailgun spam rate of 37.5% [1] seems both awful and unusual as no other provider seems to suffer from this. Does anyone know if this data is flawed, or what's the story here?

[1] As reported by https://www.inboxtrail.com/compare

We are working on this based on what we have discovered so far, there appears to be a content issue that's impacting deliverability. We have ruled out any issues with the IP address these messages are being sent from. Our lead reputation engineer going through this and we've not been successful in reaching out to the inboxtrail team yet.

Disclosure: I lead product development for Mailgun.

Though you definitely still have space for improvements. I have a Mailgun account and:

1. I didn't configure my MX so you don't track delayed (asynchronous) bounces. It should be your responsibility as an email provider to use an appropriate Return-Path so spam complaints/bounces reach back to the client in this situation.

2. I opened ticket #212817 a while ago (September) about how a MITM could capture emails and replay them by injecting duplicate Subject/From/To headers (article here: https://wordtothewise.com/2014/05/dkim-injected-headers/) but this still isn't fixed today :(

That said, we're very happy with the service :), one of the killer features is how easy it is to manage wildcard sub-domains (compared to the pain it is with Mandrill).

On issue #1, we're going to update the language around this in our control panel and put together better documentation. In reality, having MX records are important to allow for sender address verification [1], which many SMTP servers require.

On issue #2, Thanks and apologies for the slow response, This ticket slipped under our radar.

To give you a quick answer: we'll look into the approach you described in your blog post as well as RFC 6376. It seems legit but we'll need to do some more testing to ensure that deliverability does not suffer due to changing how we sign messages. If deliverability does suffer, we can always make this something that is an optional security setting that can be toggled, like how you can enable and disable TLS certificate validation now.

Our security engineer will take a look and reach out to you with more details in the ticket.

[1] https://en.wikipedia.org/wiki/Callback_verification

Thank you for replying. Glad you guys are considering this :)

We had issues every few months because the server we were assigned would be added to a RBL. Customers would notice, we'd talk to Mailgun and they would move us to another server. rinse, repeat.

The only way to avoid this was to get a dedicated IP which is an additional $59 / month.

I'm not sure why Mailgun couldn't detect this themselves, maybe they do now.

Email from Mailgun's shared IPs is being flagged as spam by Hotmail and AOL, which may indicate insufficient warmup with those services (e.g. Hotmail is not familiar with some of their shared IPs yet, and suspects them of sending spam until proven otherwise).

Methodology: a mock verification email with properly structured markup, a verification button, and no marketing content, sent to each provider. https://www.inboxtrail.com/compare#how

Disclosure: I'm not in any way financially linked to SendGrid.

A startup I used to work at used SendGrid. I have nothing but good things to say about the experience. I liked it better than Mandrill, which I've used more recently.

I have been using SendGrid for a side project. Can't recommend it enough.

SparkPost gives you 100k emails/m for free.

I don't work for them.

Very happy with SparkPost. Love their webhooks and their advanced content substitution engine.

Mailchimp has a made a terrible mistake.


Before, you could get "up to 12k emails per month" for free.

Now, you get 2k free sends once (for dev), and then have to pay $9.95/mo.

This all sounds actually great, so far (although, I think $4.95/mo would have been a better bottom-tier plan - the goal is to get rid of users that don't pay anything but send 12k emails per month). $9.95/mo is affordable to any startup, and it's sustainable (vs paying accounts having to cover the cost for the hundreds of thousands of users sending millions of emails for free).

The mistake they made was in doing anything else besides this. If they had simply changed the pricing like this, but left everything else alone, they would double their profit in 5 minutes while only pissing off the customers that aren't ever going to pay anyway.

Instead, they did what they did, and now they're no better than TWTR.

Couldn't agree more. I was sending a couple of thousand emails a month with mandrill for free. Would have happily paid 9.95 a month. But when I got their email, and read their blogpost, it was completely unclear what I had to pay. The message I got from them was, "sorry, don't want your business."

With this, and Kimono, in one week, I am moving to amamzon ses, though it has very few reporting features. Sorry Sendgrid/Mailgun, but TWICE burnt, and all that...

Sendgrid has been in the game for a long time and has it as their core business (unlike mandrill). So I wouldn't be too afraid of them closing down overnight.

100% agree. I'm in the exact same boat. I'm moving to SES as well for the same reasons.

> the goal is to get rid of users that don't pay anything but send 12k emails per month

I agree, but you even understate the problem. If your API-based SaaS offers a free plan, then you can't actually enforce any caps on that plan. Anyone who uses your service can just register N free accounts and multiplex their load across them, to get as much usage out of your SaaS as they like. (Yes, even if you make them register with a credit card and deduplicate by card number; registering a bunch of Visa gift cards that don't have to maintain a balance is essentially "free.") The only real way to get around this—besides eliminating your free plan—is full-on "submit your birth certificate" KYC.

Of course, this doesn't apply if your SaaS is delivered as a web service or a fancy thick client, where the raison d'être is mostly in the UX—it's hard to multiplex that. But when your service is just an API, it's dead simple.

It's not about sealing a security hole. It's about increasing the cost and decreasing the value for abusers, to reduce the amount of abuse to a sustainable level.

For the people debating the "If it's bulk email, why not just use Mailchimp?" question, consider the Trello use case: Someone updates a ticket and there are 4 people subscribed for notifications. In that case, it sends the same email to 4 people.

According to the AUP, it's against the rules to send "emails directed to a number of individuals with the same content"

Are we really going to say that someone like Trello should be using Mailchimp for that?

There is a fine line. As long as it's a notification email, I don't think anybody can have issues. I guess what they resent is BULK emails send through mandrill.

I agree in a practical sense. I doubt Mailchimp has a problem with the case I've described.

I just think the wording of their AUP is too vague. If taken at face value, it invalidates a lot of legitimate use cases. That just means all their customers have to bend that rule a bit, and nobody knows just how far they can bend it. It's a shitty place to be as a customer.

This exactly!

> They’re merging it into MailChimp, but updated the TOS and AUP with immediate effect in ways that essentially banned what was the service’s raison d’être: sending bulk mail programmatically.

I thought the idea behind Mandrill was to send transactional emails, i.e. not bulk emails. In fact bulk emails are specifically what Mailchimp is designed for. Sounds like people were using Mandrill in an attempt to get around some of Mailchimp's pricing structure, and now that has come to an end.

That said, I will agree that the change has come rather abruptly.

Mailchimp doesn't exactly do "bulk emails", they do newsletters.

There are lots of things that fall in between say a weekly email to 5k people (typical newsletter email) and a password reset (typical transactional email) that people used Mandrill for and now are rightly pissed.

I have a friend with a service that sends out 10k-ish customized mealplans each week to their paying customers (each email is fairly unique given where they are at in the customer cycle, preferences, tracking, etc.)

It's deeply tied into the rest of their infrastructure and Mandrill worked great for them, but Mailchimp definitely does not as it's not a newsletter.

Or imagine something like a system that alerts people when X band announces a concert date in Y town. Lots of people subscribe to get an email notification about that so it's 1 email to 500 people in Duluth. Not exactly a newsletter, not exactly transactional.

> Or imagine something like a system that alerts people when X band announces a concert date in Y town. Lots of people subscribe to get an email notification about that so it's 1 email to 500 people in Duluth. Not exactly a newsletter, not exactly transactional.

That is bulk email, fyi.

> I have a friend with a service that sends out 10k-ish customized mealplans each week to their paying customers (each email is fairly unique given where they are at in the customer cycle, preferences, tracking, etc.)

This was still a bulk email based on when I talked to Mandrill about it when I initially set it up.

> Thanks for getting in touch! It's primarily designed to support transactional emails, you can send any legal, non-spam message through Mandrill as long as it maps 1:1 with a human interaction and/or alert from an automated event.

That is a literal quote I had from the support ticket when I created my Mandrill account. Both you and the OP didn't follow what I [or the Mandrill/Mailchimp employee I talked to] interpreted the ToS as.

Similarly the OP seems to be the same usecase:

> They’re merging it into MailChimp, but updated the TOS and AUP with immediate effect in ways that essentially banned what was the service’s raison d’être: sending bulk mail programmatically.

They told you it was for transactional email. I'm not sure how you concluded that meant "bulk mail" was okay.

> They told you it was for transactional email. I'm not sure how you concluded that meant "bulk mail" was okay.

It's explicitly stated to be OK in their own FAQ:


> you can send any legal, non-spam email through Mandrill, too

and on http://mandrill.com/about/

> Use Mandrill to send automated one-to-one email like password resets and welcome messages, as well as marketing emails and customized newsletters.

It must have changed from when I first signed up. The original ToS, etc. didn't state that.

It also doesn't appear to state that presently.

For instance:


> Mandrill is an email infrastructure service designed to help applications or websites that need to send transactional email like password resets, order confirmations, and welcome messages.

> Any bulk email should be sent through MailChimp, rather than Mandrill.

Yes, they changed it after it was tweeted at them.


MailChimp is designed for sending newsletters to predefined lists, not bulk mail in general. They're not the same thing.

If you've built a monitoring tool that needs to notify 5 employees that their server has just gone down, you needed Mandrill, not MailChimp. These mails are "transactional" the same way a password reset is: they're programmatic responses to some event. They're also bulk, and if all 5 employees get the same message, now prohibited.

Mandrill was always for programmatic mail of any kind, not just one-to-one. Bulk mail was all over their sales material and knowledgebase. The context that separated Mandrill from MailChimp was that the mail is programmatic or automatic, rather than a newsletter you pre-write for a pre-made list. Their raison d’être was to provide reliable e-mail delivery for developers, regardless of what you were sending, up until last week.

Good explanation of the difference, thanks.

> I thought the idea behind Mandrill was to send transactional emails, i.e. not bulk emails.


"Use Mandrill to send automated one-to-one email like password resets and welcome messages, as well as marketing emails and customized newsletters."

So, their About page is currently explicitly condoning violating their own Terms of Service.

Oh, and the pricing page that's live right now is a bald faced lie. I wouldn't trust much/anything from these guys.

Not sure if that's really true. Non-bulk marketing and newsletter emails are a thing.


> What types of email can I send with Mandrill?

> But you can send any legal, non-spam email through Mandrill, too.

Additionally, > View our Terms of Use for extra details.

It seems like this change is to avoid being on the hook for those non-{legal, non-spam} emails.

That is largely correct.

It was intended as a purely transaction / alerting / etc. mail platform and not for bulk/marketing emails.

However, I never went over the free limits with that sort of mail which I suspect was the problem. My guess is 90% of the revenue was people using it for bulk email and so they figure forcing them to MailChimp isn't a major loss.

This has to be the goal of the change. Move people who into paying mailchimp customers who are taking advantage of mandrill. The issue is they alienate all the people who's problem set doesn't fall into mailchimp's offering. Who knows what that percentage is but my guess is over 80%, so they understand they are screwing over the majority to make a profit off the minority. This is from Ben at mandrill:

> "I can say today that–believe it or not–there is a subset of Mandrill customers who want combined functionality and pricing, so it’s not as illogical as it seems on the surface (also, we’ve lost many more potential customers like these by having two separate products and brands). There’s another subset who want a utlitarian service provider, and who would understandably find the new pricing unsuitable."

Yeah but when I originally signed up I was told that was the purpose back in 2013.

They explicitly allowed customers to use Mandrill for any type of email, transactional or "bulk".

They even used to note that you could build products that compete with MailChimp using Mandrill.

What pissed me off the most about this change is that Mandrill was specifically marketed as a separate product, something they believed in. We had no reason to suspect MailChimp didn't actually care for the market they were operating in.

Now MailChimp have come out and said something along the lines of "Sure, it made us lots of money. But we never really cared about you or your use case. So we're killing the product."

It is for this reason I have lost respect for MailChimp. Quite frankly, they can't be trusted.

As a replacement consider mailgun (http://www.mailgun.com). I have used their free tier before when I had to send mail for a side project.

+ 1

We use Mailgun at work, and I can attest to its consistency and performance in inbound mail processing. Our webhook is consistently hit within about 1 second when I send a test email to our app's email.

I will say that Mailgun's UI could use a little bit of help. There are a number of things that make it feel half baked, but in terms of functionality, as aforementioned, it's not lacking.

We were, hitherto, considering the possibility of using Mandrill for outbound mail, only because they seemed to offer more spam folder avoidance knowledge and analytical data, while Mailgun was (and is) surely preferable for inbound... that switch will never happen now.

Great feedback. Our UI is definitely something that could use some attention and is a big priority for us this year. We've made some big hires that are 100% focused on making it a great experience.

If you'd like to talk about more specifics, please reach out at anytime josh [at] mailgun [dot] com.

+1 for mailgun. Their API is awesome and they even offer things click tracking (also in their API).

Another vote for Mailgun. I use them for all my side projects, monitoring, error reports, basically everything gets hooked into my FastMail account with all the right aliases I need, and it works very well.

I've never gone over my free allocation even when I have a dozen or so side projects up and testing.

Wow. Thank you guys for the suggestion. I really like that the first thing I see on the Mailgun landing page is sample code for calling the API, and the second thing I see is a pricing calculator.

+1 for Mailgun! Reliable and really developer friendly mature API.

It's interesting, 5 months ago we made the switch to Mailgun because we were afraid of this day.

Basically, MailChimp didn't like Mandrill sending mass emails from the beginning. As far as I remember (5 months ago) Mandrill only allowed you to send emails one by one but Mailgun lets you send 1K emails at once.

That, plus the fact that they changed their policy for verifying domains with no notice which affected many users (not us).


"This is a breaking change for us, we didn't have any notice at all?! Very poor customer service!" -- Adam Curtis (Mandrill user, 7 months ago)

Lucky for us we made the switch many months ago!

FYI, I'm sad to see that MailChimp (as a company) cannot see how two divisions in the same company can compete. Like Amazon hosting Netflix and also competing with Netflix. IMO, Amazon management is smart enough to keep these two divisions separate enough so either one that'll do a better job will succeed.

We were using Mandrill's email to HTTP feature for delivering inbound emails into our web services. The cutover period for needing to be a paying Mailchimp is April 27th, so we had two months to convert. Luckily it took less than a day to build and test the same functionality using Amazon SES, so we've already converted away. To be fair, it was functionality we were using completely for free, so I expected it to happen sooner rather than later.

I was going to use Mandrill/Mailchimp until this fiasco. I discovered SendGrid, which has quite a lot of great features. Their free tier is pretty generous with 12k emails a month. I recommend them to people looking for an alternative to Mandrill.

Mailgun & SendGrid are good solutions. This is a script that may help you migrate over quickly and uses both API's so you are not locked into just one https://github.com/gosmartsolutions/mandrill-alternative

In a previous job we tried to mimic Mediums "email only - no password" login infrastructure using mandrill. Whereby a user clicks 'login', a session token is generated and a link sent in an email, the user clicks it and is then logged in - no password needed. sounds great...

It turned out that in production, even after all the hoops that were there to be jumped the bounce rate was around 5% and some of the messages that did get through took around ~15 mins to turn up in the users inbox.

I don't think much of this is Mandrills fault but up to that point i had little inkling of how bad email is for communicating en mass.

Email is not supposed to be necessarily near real time, I think (not an expert though). Not sure of the details at the protocol level, but my guess is that it may work differently from HTTP, due to being older, and invented in the time of UUCP, IBM email, etc., some of which involved store-and-forward techniques, mail queue files, etc. (I've used UUCP email back in the day, at one company I worked at. We used to have to dial up the other city's modem and then go through a slightly arcane dance of Unix commands to send the email on its way, or receive email from other branch offices. Fun times ... When it first became available, I remember using it a good amount to download tech articles from various sites via Internet-over-email methods, such as ftp to rtfm.mit.edu via email :) There was even a chapter about that in a Dummies book. And there's an Internet FAQ about it at faqs.org, or there was.

Ah, might be worth pointing out my earlier proposal[0] in the HN discussion when the Mandrill announcement happened. I was surprised by the response I got, with >300 people leaving their email address. A number of providers emailed me as well, so I'm still planning to send out whatever I get to everyone on Thursday.

[0] https://news.ycombinator.com/item?id=11173325

Everybody talk about Mailgun, but there are other valuable alternatives: Sendgrid, AWS SES, Postmark.

At Redokun we use Postmark. It proved to have a good deliverability and the UI is very good.

We love Postmark - they're a bit more expensive but the service is great and the product is rock solid.

Postmark is super unreliable for large volume - their servers are down periodically and their email is periodically delayed for hours.

It still does not support multiple admin roles per account.

I've never used them for large volume actually. Are you using them via SMTP or API? I'm asking because I've never seen a single API call fail with them, but maybe it's about the volume like you said.

For large volume sending, I'd probably use AWS SES. In the past, I've used it for sending 150-200K/transactional emails per day and the service was very robust.

On the other hand, I've seen Mandrill increase the number of failed API calls with a lower sending volume.

You know what else is super unreliable? The account you are posting under. Enjoy your hellban!

This has impacted our platform as well. While the Mandrill API is still operational at the moment, the immediate change in TOS means that we were technically in violation of the terms before we were even notified that there was a change.

> You can no longer use it to send mail on behalf of your users, as in a contact form processor or white labeled service.

I switched my MVP to AWS SES yesterday after having used Mandrill for transactional emails for about a year. I almost decided to just pay the $20/mo for a MailChimp plan because of SES's documentation and setup complexity and the annoyance of the sandbox (you can only send mail to and from pre-verified email addresses while in the sandbox).

However, I filed the support ticket to get out of the sandbox, requesting 2.5K daily emails. They approved it several hours later with 50K daily emails (!), so they are quite generous there - I was worried I'd have to keep an eye on the number of emails I'm sending, but the amount they gave me gives a nice buffer.

edit: Just to add, I'm one of those people that would religiously open spam emails and look for the relay, and if they're reputable like Mandrill or SendGrid, I'd go to their abuse page and report the email by pasting the email headers. Extrapolating from how many spam mailing lists I got added onto by recruiters, I can see how MailChimp employees' time could get sucked up investigating a lot of these spammers who probably slummed off the free or low cost tiers, and could damage their bounce rates.

So I can't totally blame them for this move w.r.t. Mandrill, and I still plan on using MailChimp when I have a need to send marketing emails to my users.

Doesn't any email originating form an AWS server get big marks against it from most spam filters?

EC2's IP range is scorched earth, yes.

SES is in a separate set of IP ranges, and their feedback loops with major ISPs lets Amazon manage their reputation much more closely.

True, but we switched from SES to Mandrill because of delivery problems from SES.

Mandrill was way better, but now it looks like we need to move again. (And our complaint % on Mandrill was somewhere around 0.01%)

I think most generic EC2 instances you'd spin up are hopelessly blacklisted, but I would hope that SES would be less affected by that since AWS would keep its address ranges separated from the EC2 wild west.

But after Googling SES deliverability it seems like SES may have suffered a slight amount from some lax spam reporting standards - the results seem a bit stale so not sure how valid it is any more. Hopefully using DKIM and SPF will help lessen the blow.

This indignation seems a bit oversold. Part of that is quoting the bulk prohibition on Mandrill without quoting the explanation that immediately follows:

Mandrill is designed for transactional email. Please use MailChimp for your bulk sending needs.

Anyone who was using Mandrill for bulk mailing will now need to use MailChimp, which should have been the case anyway. Maybe someone misunderstood the different purposes of the two services, but misunderstanding happens, and it's a two-way street.

Part of the indignation is that Mandrill's About page still says:

> Use Mandrill to send automated one-to-one email like password resets and welcome messages, as well as marketing emails and customized newsletters.



> you can send any legal, non-spam email through Mandrill, too


Not necessarily. Mailchimp is incredibly overpriced for what it does once you get past the lowest price levels. Signing up for Mandrill or Sendgrid or Mailgun, then using one of dozens of self-hosted newsletter options (some free, some one time paid with support) is much more cost effective. For really high volume just install your own licensed PowerMTA server from Port25, which is what Mandrill runs on anyway if I'm not mistaken.

The part of the service that you're paying for with Mailchimp is the actual delivery management, which virtually any of the existing transactional email systems including SES can undercut on price almost overnight.

That's one reason I never touched Mandrill because the low end pricing model didn't make sense for a company like Mailchimp with such a high price point for it's own services.

Wow good to know I am not the only one upset at this. This will be big for the bootstrapped business I run. Have a lot of clients on mandrill and need to move them away slowly. This is going to be a long process with multiple clients. Thank you Mandrill!! /s

I feel like SparkPost should get a mention here: https://www.sparkpost.com

edit (more details): The free tier allows up to 100,000 emails

Thanks for the mention jdstafford - I'm on the application development team at SparkPost - we'd love to have you give our service a try. We've got a Slack community up at http://slack.sparkpost.com - feel free to jump in and say hi!

No doubt. You all support CharmCityJS which is awesome. I was actually using mandrill for a side project and will be switching to sparkpost. Thanks for the reply.

I'd stay away - far away - from sparkpost. We've been a volume user with sendgrid for years and recently started a test with sparkpost (well before the Mandrill thing), thinking it would be a good backup solution over our inhouse alternative. Suddenly this weekend, we're getting 403 rejections thru the sparkpost API. We were thinking it was an issue on our side and spent some time verifying it wasn't us. When we asked Sparkpost customer support to look into it, they eventually came back saying our Sparkpost account was suspended by their compliance team -- this with no indication or warning (and with us sending very low volume to known-good users in this test). fyi, our sendgrid reputation score is >98 and blacklist-free. We know how to maintain a good sender rep. Sparkpost CSE says their Compliance team is overwhelmed and maybe we'll hear back in a couple of days. Are you kidding me? We had high hopes for Sparkpost until this. Now, I can't see how we can possibly trust them, which is ironic to say the least.

Check out the Sparkpost Mandrill migration guide: https://www.sparkpost.com/mandrill-migration-guide

They must be popping bottles in the Mailgun offices today. :)

I hated this change, and switched to Mailgun immediately. I never liked mailchimp at all, and this sealed the deal.

Quick comical irony break: the heads-up email Mandrill sent us about this went to our spam folder.

I just noticed this when I logged in to check on a Mandrill template this morning. Couldn't believe it is an immediate TOS change without any sort of grandfathering or timeline for existing customers - that's a terrible way to handle things, never mind the rapid shutdown.

Doesn't instill a lot of confidence in me as a Mailchimp user. I'll be looking at alternatives for both transactional email and newsletters ASAP.

I co-run https://emailoctopus.com (an email marketing service which uses Amazon SES), and over the past few days we've seen a huge increase in signups. The fallout from this email seems large - these people aren't just moving away from Mandrill, but are also dropping MailChimp at the same time.

I really hope their customers completely abandon them. We have - switched to Sendy and SES for newsletters, and investigating what to do with our transactional emails.

This sort of behaviour should be absolutely frowned upon, in any industry.

I've had a Mandrill account for about 3 years, and a Mailchimp account for about 4. I just cancelled my Mailchimp account and listed the reason as how poorly they handled this situation and how they screwed a customer over. I can't in good conscience support a company that could do this. I'll take my business elsewhere.

Was very disappointed with Mandrill as I've been using them reliably for the last couple of years.

I did a bit of research as soon as the news was announced. And found Sendgrid the most on par with what Mandrill was offering.

It seems a tad slow, but it's ok. Someone mentioned SparkPost, but quite a few emails from them were going to SPAM folders.

I work on SparkPost's app dev team - I know you've decided on another route but would love to understand what you were seeing. If you'd be willing to share details with developers@sparkpost.com or on http://slack.sparkpost.com we'd really appreciate it.

Additionally, we have an awesome deliverability team over here and we work very closely with our users to diagnose and resolve problems like this efficiently. They'd be happy to chat with you about inbox placement should you decide to re-investigate :)

I second for Mailgun. Works perfectly well.

Very underrated service. The level of control that their inbound email system allows is impressive.

I feel bad for the people forced to switch due to various reasons. The Mailgun guys were always extremely helpful when we used them and often went way above and beyond in helping us debug mail issues. Also, their webhook API is great when you need to accept large attachments.

Another alternative when looking for the absolute lowest price is sendy.co. It's a self hosted solution that connects with Amazon email services.

Does anyone have any experience with Sendy.co? And how it would compare with mailgun for deliverability?

It has been great for me. Set it up on a DO droplet, somehow worked my through the Amazon setup and voila, my own sendy instance! It's tracking is excellent. And the guy behind it responds quite promptly to any issues. I'd say go for it.

Thanks for the feedback! How many emails are you sending out a month? And do you do any newsletters?

If you're looking for a hosted alternative to Sendy, can I suggest you check out a project I've been working on for the last year or so?


What a mess and no way to treat the 'power' users who value you most (i.e. developers).

I've always found MailChimp's editor to be a complete and utter nightmare to use, for formatting — it's so buggy — not to mention random shut-downs of other sub-services (such as the advanced editor).

They really need to sort out their developer evangelism.

Can someone explain to me why they would do this ? I cannot think of a reason why they would stop providing this service.

They've making an 80/20 decision. Make the service better for the 20% of users that produce 80% of your revenue and price everyone else out. They don't want to be the startup economies dumb email tube. They want to be a high margin service for companies with more marketers or designers than programers.

Indeed. But instead of gracefully transitioning like a sensible company would - i.e. slowly phasing the two together, teeing up alternatives for customers, giving plenty of advanced notice and warning etc, they've gone full nuclear.

Part of me hopes they go bankrupt.

@bwest from SendGrid is working on an API to API migration script and I believe is looking for some more users to test it out. See Tweet here: https://twitter.com/bwest/status/704704023589289984

Does any other provider (Mailgun? SendGrid?) support EU standard clauses and send them on request? Mandrill does this. EU startups are out of options otherwise.

We (Mailgun) have a process to support EU model clauses that has allowed us to continue supporting most of our EU customers. There are a lot of nuances to all of this, so it's best to talk to someone on our team who has expertise and access to our legal team to come up with a plan for you.

Additionally, the landscape will change on this once Privacy Shield, the successor to Safe Harbor, is enacted. It will offer stronger protections and guarantees to EU customers without the need to have model clauses signed between entities.

Our sales team sales [at] mailgun [dot] com can talk to you about your specific situation.

Your answer is ambigious. Refering to privacy shield is of no help.

Your sales team did not answer to several inquiries last autumn so some of my clients switched from Mailgun to Mandrill last autumn.

I'm not sure why there was a disconnect with our sales team, but I'm happy to help. Could you e-mail me with more details? josh [at] mailgun [dot] com

The model clause process is not trivial and often requires work between the legal teams from Mailgun and the respective EU company. We've gone through the process and can definitely help any of our existing or prospective customers get through it, though. Every business is a little different, so we'd need to talk through the specifics.

Straight from our lawyer: SendGrid offers EU Model Clauses upon request.

My email's in my profile - let me know if you need the details.


Interesting that my mandrill dashboard shows I can send 62000 emails "absolutely free". I'm on the free tier.

I want to use AWS SES, but the lack of a dashboard (like Mandrill had) is a dealbreaker.

Quick strawpoll: are others in that boat too?

Amazon is the safest bet for me given their resources and reputation. For my uses I can live with their rudimentary dashboard for now knowing they'll likely improve it over time. My service sends about 1500 emails a day.

Bummer. We were huge users of Mandrill. Never loved the UI, but it got the job done.

Now, Sendgrid vs Mailgun?

What a strange decision. They are murdering an amazingly successful business.

Goodbye Mailchimp. $500 per month soon to be spent elsewhere.

Did they promise never to do this or something?

Pepipost - Free SMTP alternative to Mandrill


- Free plan and send up to 25,000 emails each month. Free forever. - No credit card required. - DKIM is not required (Domain Verification: (a.) Meta Tag Validation, (b.) File Creation - System can verify the domain based on the presence of a file in the root directory of the domain.). - Pay only for emails that are not opened by your customers.

* 3 Months Free Unlimited Transactional Emails + 25k emails per month free forever. * Use the below code while signup with Pepipost.


Great! This is probably the best FREE alternative for Mandrill.

I'd want to see deliverability numbers, and "free forever" is probably what got Mandrill into this situation. They had to roll back that promise. No credit card required means spammers just register a new account for every 25k emails they want to send.

I'd rather pay for something sustainable.

Hello, Pepipost build on a very clear philosophy to encourage good senders and fight against SPAM, hence Pepis follow a strict on-boarding and delivery processes for both Paid and Free customers. This helped in achieving 100% deliverability with highest Inbox placement rate for all good senders.

[citation needed]

No one gets 100% deliverability, and highest inbox rate for all senders requires serious proof.

We have 100% deliverability with clients who sends emails on double optin database. You are right for other senders there will be ups and downs in rate, based on the database.


We detached this subthread from https://news.ycombinator.com/item?id=11204520 and marked it off-topic.

She made herself a liability with her own inappropriate behavior. I'm not defending the chuckleheads she had a problem with, but I'm not holding her up as some sort of vigilante hero.

Oh good grief, not this again.

The ethicality/morality of a potential supplier is a legitimate consideration for many organisations, and in some cases is written into the organisation's policies.

For example, WWF procurement[1]:

> "We monitor and select goods and services carefully to avoid those that are harmful or damaging to both the user and the environment."

> "we require suppliers to complete an environmental and ethical questionnaire"

Whether you agree with the behaviour, disagree, or even don't care, it's a legitimate question to raise when talking about alternative suppliers.

[1] http://www.wwf.org.uk/about_wwf/other_publications/environme...

I'm absolutely for more ethical companies (though clearly there is a long road ahead), it's the specific example of Adria Richards, which often generates an endless series of venomous posts, that I object to.

Not to mention the way the case is summarized by parent is, let's say, highly debatable.

Yeah, we shouldn't mention bad company behavior on a thread about... bad company behavior.

You knew it was coming.

We were relying on Mandrill to send a lot of emails. The problem with Mailgun, Sendgrid and others is that they're too expensive, which means they're unaffordable by our bootstrapped startup. Is there any service that has pricing similar to Mandrill?

Mailgun and Sendgrid are too expensive? How so? Mailgun offers 10k emails/month totally free, and it's $0.0005/email or less after that. Sendgrid will give you 40k emails for $10/month, or 100k emails for $20/month.

If you can't afford those prices, your business has bigger problems.

Hi nakodari - SparkPost is matching Mandrill's pricing and offers 100k/mo free plan. Check out our migration guide: https://www.sparkpost.com/mandrill-migration-guide

Elastic email seems like an excellent substitute for "cheapest per email cost" type email needs. They are a front runner candidate for me in a lot of use cases.

Also elasticmail.com, so far it looks like we'll implement sparkpost and elasticmail for redundancy.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact