Mandrill’s Betrayal
dangrossman.info
dangrossman.info
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.
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.
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.)
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.
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.
I think you meant deliverability. But maybe we should all switch to calling it desirability.
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.
I emailed their founders and never received a reply.
Lesson learned: do not take a dependancy on MailChimp for any reason.
I'm not happy about them quadrupling their prices, with a ridiculously short deadline to avoid it.
- 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.
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.
[1] As reported by https://www.inboxtrail.com/compare
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
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.
Disclosure: I lead product development for Mailgun.
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 #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.
I don't work for them.
- 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
- 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.
Firstly:
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.
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...
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.
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?
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.
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.
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.
> "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."
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.
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.
It's explicitly stated to be OK in their own FAQ:
https://mandrill.zendesk.com/hc/en-us/articles/206251597-Wha...
> 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 also doesn't appear to state that presently.
For instance:
https://mandrill.zendesk.com/hc/en-us/articles/206251597-Wha...
> 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.
https://www.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."
So, their About page is currently explicitly condoning violating their own Terms of Service.
> What types of email can I send with Mandrill?
> But you can send any legal, non-spam email through Mandrill, too.
It seems like this change is to avoid being on the hook for those non-{legal, non-spam} emails.
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.
They even used to note that you could build products that compete with MailChimp using Mandrill.
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.
I've never gone over my free allocation even when I have a dozen or so side projects up and testing.
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.
If you'd like to talk about more specifics, please reach out at anytime josh [at] mailgun [dot] com.
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).
http://blog.mandrill.com/we-are-making-domain-verification-m...
"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.
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.
At Redokun we use Postmark. It proved to have a good deliverability and the UI is very good.
It still does not support multiple admin roles per account.
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 can no longer use it to send mail on behalf of your users, as in a contact form processor or white labeled service.
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.
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.
SES is in a separate set of IP ranges, and their feedback loops with major ISPs lets Amazon manage their reputation much more closely.
Mandrill was way better, but now it looks like we need to move again. (And our complaint % on Mandrill was somewhere around 0.01%)
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.
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.
> Use Mandrill to send automated one-to-one email like password resets and welcome messages, as well as marketing emails and customized newsletters.
and:
> you can send any legal, non-spam email through Mandrill, too
https://mandrill.zendesk.com/hc/en-us/articles/206251597-Wha...
edit (more details): The free tier allows up to 100,000 emails
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.
This sort of behaviour should be absolutely frowned upon, in any industry.
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.
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 :)
Does anyone have any experience with Sendy.co? And how it would compare with mailgun for deliverability?
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.
Part of me hopes they go bankrupt.
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 sales team did not answer to several inquiries last autumn so some of my clients switched from Mailgun to Mandrill last autumn.
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.
My email's in my profile - let me know if you need the details.
Quick strawpoll: are others in that boat too?
Now, Sendgrid vs Mailgun?
- 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.
Code: MANDRILL-TO-PEPI
Great! This is probably the best FREE alternative for Mandrill.
I'd rather pay for something sustainable.
No one gets 100% deliverability, and highest inbox rate for all senders requires serious proof.
If you can't afford those prices, your business has bigger problems.