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.
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!
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.
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.
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.
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.
- 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?
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.
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.
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.
> 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.
> 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.
> 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.
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.
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."
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
- 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 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.
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.
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.
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.
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.
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.
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.
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.
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.