Free Transactional Email Services – The Best Alternatives to Mandrill and Co
metachris.com
metachris.com
Specifically, we have some webhooks set up so whenever someone emails blah@example.com, mandrill posts that data to a known URL on my webapp (processing inbound email events like replies and so on).
Mandrill also "supports" a handlebars language on their end, so I can have a handlebars outbound template and pass in a big data structure (with repeats and conditional rendering).
I caveat supports, because their API doesn't support nested arrays (an array of objects which in turn contain an array property, for example) and their API silently ignores any camelCased variables. There's a couple of other weirdnesses to mandrill's handlebars, but on balance it's handy to allow my designers to change the layouts to some outbound emails without having to push those template changes to the web application itself (previously, we used handlebars to render a big HTML blob on the server side which got pushed into to the email).
I can live without a rich view template language, but not really without inbound webhooks. I know Amazon SES can be made to handle this with their Lambda service or via Amazon SNS (my webapp doesn't run on EC2, so it is a tad more complicated), and I had been working through a lot of the other providers to see who supports what, because woah is mandrill going to be a lot more expensive now.
I use Mailgun and it supports this.
Sendgrid's is also, I think, just included at no extra charge.
[1] https://documentation.mailgun.com/quickstart-receiving.html
I've previously used Mandrill for inbound, which has a lot of problems that I'd rather not enumerate. But that was at a much higher scale, so many of those problems I wouldn't have seen yet even if Mailgun has them.
Sendgrid supports all of these features, and we work really hard to make inbound event webhooks a first class feature (some of our customers base their entire business models on our inbound webhooks and stats). I hate sales pitches in HN comments so if you'd like to learn more or have any questions my email is under my profile.
Have you looked into other alternate providers?
So, I'm trying SendGrid for transactional messages and sticking with Mailchimp for onboarding emails (a sequence of messages sent a few days apart to new contacts with consent of course).
Sendgrid was seamless to adopt. We'll see about deliverability.
Would they mind that I used the free tier in this way? Are there any downsides?
The reason is privacy. I don't want Gmail (or other free email services) scanning, analyzing, and saving away my email. I think the "transactional email services" in the featured article would be more private since their motivations and they way they make money are different than Gmail.
Mailjet added an Inbound API called ParseAPI. Even if the name is different they are able to process inbound emails :-)
https://www.mailjet.com/feature/parse-api/
Quite an handy list tho. Great work!
We're also beta testing a tool to automate this migration. Please reach out to api at mailjet dot com to be involved in it.
Thanks for putting this list together, quite helpful.
3 months of exclusive free unlimited transactional emails.
If you are a paid Mandrill customer you can get a 40% discount of your current spends with Mandrill.
Read More: http://www.pepipost.com/index.php/mandrill-alternative/
https://sendyhost.com/mandrill-alternatives-245/
We have compared:
Mandrill PostMark Sparkpost Mailgun Sendgrid Amazon SES PepiPost
And we have chosen Mailgun and Sendgrid as alternative to mandrill. With AMazon SES also for high volumes. Sparkpost has some problems for transactional emails but you can read all the info on the post.
Maybe it can help others. Cheers!
They respond quickly.
Edit: Looks like you can, but Google says it's "not recommended." Also, you need to be a paying Apps member to use the service from what I can tell. Not sure if you can if you aren't a paying member.
Scroll down to Step 6, where it shows "Any addresses (not recommended)"
Apparently, it works, but with some notable caveats, like: "If the envelope sender is not in one of your domains, the system changes the envelope sender from user@[domain you don't own] to postmaster@[your domain]"
The issue would likely be the limit on messages per day. Google spells this out for paying Apps members (https://support.google.com/a/answer/2956491#sendinglimitsfor..., see "Limits Per Customer")
They don't say what the limit is if you're using SMTP relay as a regular gmail user. I suspect it's much lower.
Check that here: http://whatismyipaddress.com/blacklist-check
However, deliverability has become really difficult. It seems during the ten years since I last ran my own e-mail, it has become an oligopoly. I have SPF, DKIM, DMARC and reverse DNS, my IP is not on any blacklists, and still my e-mail ends up spam listed in both Gmail and Hotmail. It seems to be getting a worse treatment by Hotmail but it's hard to say due to the small volume.
It is getting better but slowly, it seems.
I had some issues with Gmail but adding rDNS IPv6 and enlisting into DMARC fixed it.
I sent about 125k per week, 80% gmail, no serious issues (I would known cause users pay for email's content).
mxtoolbox.com
I wish Mailchimp had given more notice. Even services which have went into complete shutdown (ie: not merged into another product) have often given more notice than this.
I've built SO many systems that use the Mandrill API in one way or another (forgot password mails, for example). A lot only send out a couple of mails a month but having to change them all over really sucks. Especially when I was always raving about Mandrill in the past to clients.
Of course my real problem at this moment is Mandrill just plain works already, and I'm not sure if it is worth spending engineering time shifting to a different provider instead of just paying the premium. TBH, the biggest issue is the feeling of Impending Doom I get from the mandrill discussion. [1] seems to indicate that the transactional email of mandrill really just doesn't fit in the corporate culture of mailchimp. So it's not just the change in pricing that worries me, I'm concerned about a future where there's a lack of innovation and support in the product itself, and I'm still locked in to paying more for less because I don't want to spend the time moving providers. Sunk costs and all that.
0: https://www.sparkpost.com/blog/my-promise-to-developers-spar... 1: http://blog.mailchimp.com/important-changes-to-mandrill/
Yandex: https://domain.yandex.com/domains_add/
Zoho Mail: https://www.zoho.com/mail/zohomail-pricing.html
Edit: Appears both have limits on outbound emails/day. 500 for Yandex, 200 for the Zoho free plan.
Considered moving to Mandrill for a while, to reduce the cost (they had a free tier) but never ended up doing it. Now I'm happy we never did, since they just axed/reshaped their service :)
(on dedicated IPs, it's worth mentioning that reputation is moving from IP to domain, with DKIM et. al., so it's not as important as it used to be)
Reasons that come to mind:
- Fear of improperly configuring your mail server, contributing to spam/relaying spam.
- Fear of ending up in people's spam boxes?
postfix + opendkim + smtp + tls + spamassassin + fail2ban is not too difficult a setup to achieve...
Sending them such that they don't get spam-canned is way more difficult than you're admitting. It can take months or years to get decent accept rates, all of which can be lost by a simple misconfiguration.
Parsing received emails if you want to do anything programmatic with them is also very difficult. The specs for email are vague, and even then many providers break them regularly. Want to strip quoted replies or signatures? Now you have a machine learning team, too.
Simply put, sending and receiving email is way cheaper to pay someone dedicated to the task to do. You have to get to a very large scale before it's worth doing yourself.
They provide a fairly easy to use api, and a graphical user interface to monitor sends, they automatically stop sending if a user requests so you don't get marked as span. Of course that happened to us twice, one time the user then inquired why they weren't getting the email alerts....
For us our public facing information website, was controlled by the business dept, not the same as our functional site, done by the engineering side on AWS (before AWS had mail...). So it allowed us to send from the main domain without being put right in the spam folder.
I used Mandrill for a small non-profit site, very low volume, so I'll be moving to probably one of these providers.
When it comes to side-projects, mail servers fall into that area where they're distant enough from the thing I'm building to warrant just outsourcing that activity, especially with the number of transactional email providers offering free tiers.
Yes, here's the reason people don't run their own servers!
> is not too difficult a setup to achieve...
Yes it is, for a lot of people. Not to mention security patches for all this software.
Add that to the fact that Google reportedly is reportedly aggressively classifying mail from new servers as spam (your point 2) and you greatly increase the transaction cost required for people to run their own mailservers.
If I was running a mail service company of some sort then of course it's easy enough to do this. Unfortunately time, effort, focus and money is best spent elsewhere in the company. Maybe one day, but for now it's far easier to scratch out 3 of the 4 resources by throwing money at the companies that do this sort of work.
Especially when you start looking at features like email->HTTP POST request with parsing built in.
I've run my own mail server for quite a while and might do it again for inbound, but sending just is annoying to monitor and keep up.
Setting up a mail server is often worth it, but requires experience that about 0.01% (being generous) of the developer community has.
I'm assuming that the issue you're referring to is triggered by the presence of a Sender header. The Sender header is present in the emails that SendGrid sends for the site in question.
The Return-Path and From address are at the domains that I specified (e.dnscheck.co and dnscheck.co).
Perhaps this is something that has recently changed, or is only an issue with certain configurations.
Companies that provide these services have to spend countless hours stopping spammers using their services to send mail. But they do it for your benefit, despite the small costs.
Sending email is cheap, and any reasonable business is probably having sending email as one of its lowest costs. We really should be grateful to most of these companies to work so hard on our behalf to keep it that way.
And what about individuals?
> We really should be grateful to most of these companies to work so hard on our behalf to keep it that way.
I don't think so. They are also keeping it hard to run your own mail server. Plus, they get to have access to tons of other people's emails, which is a terrible idea. What's the point of introducing SMTP-STS when you then create some few central entities that hold all the keys?
Running a mail server is a lot of work, and you have a lot of responsibility when it comes to securing it to make sure it doesn't become a source of unauthorized spam.
Hu? How is that more difficult than making sure that your $mailservice account doesn't become a source of spam?
I once sent a companies first newsletter after 14 years to about 300,000 people using our Sendgrid plan and a self-hosted PHP newsletter tool that we'd paid for (the name escapes me). The first several hundred bounces happened and they froze our deliveries, called us up and grilled us about where we got our email list. Once we proved the origin they let everything go again and didn't have another problem.
It was a little shocking at first but at the same time, it's good to know how aggressively they work to protect deliverability. You don't get that by running your own and it's an even bigger deal if you have user generated content triggering messages.
It's more that the big feudal lords don't accept trade from small freeholders.
I don't run a huge website, but am sending ~50k transactional emails per month and am using Mailgun for this, and with the dedicated IP (which was required to overcome deliverability issues we had) ~it's $75 per month.
That's quite a lot of cost for the email I send.
I've actually thought about splitting my email into several buckets and using different providers and price points depending on how much I value it.
* Password resets and nopassword login emails to go through the costliest and with the highest deliverability guarantee
* Notifications to go through some mid-tier provider that is cheap and has acceptability (maybe Amazon SES?)
That said... this is a premature optimization for me, the cost of the IP address for the highest deliverability means that I may as well pump all my email through that until such a time that I'm sending ~500k per month when it will start being more cost effective to split it out.
Runs: https://www.lfgss.com/ http://forum.islington.cc/ forum.raphacycling.club http://forum.espruino.com/ and lots of other forums.
Basically an alternative to Discourse, phpBB, vBulletin, etc. With some differences to make it simpler, cleaner, mobile friendly, etc.
I've gone through your article @medium and I really got a lot of useful tips out of it.
We are working on a similar startup and we've gone quite a distance. Whether we believe we crossed the hard period or not, we really need to learn from every possible experience that can help us in our journey.
I would be surprised if they let a bunch of spam out before shutting down your account, they all seem to watch your behavior pretty close.
I've never thought of that attack vector before.
not allow cross site form filling (using CSRF Cross site request forgery protection) would probably help a lot in that regard. And sleep 2. Your users can wait a couple seconds.
A column for incoming API yes/no would be awesome as well.
Seems like for transactional email, this would work great and give you quite a high free usage level each month.
Honestly, Mandrill's pricing with 0.2$/1000 mails puts you at 200 $ for sending 1 million e-mails, which corresponds to maybe 1-2 hours of developer time. Designing, building and maintaining a system that sends mail through 4-6 different APIs will likely be much more expensive.
There are companies in the world that pay developers less than $100/hr - $200/hr.
In fact, there are companies in the USA where developers get paid $20/hr.
[1] http://www.openspf.org/FAQ/Common_mistakes
[2] http://stackoverflow.com/questions/14261214/too-many-dns-loo...
Unless you want to send your friend a birthday reminder once a year, do not invest time (and money) into Sendgrid. Once you start growing, they will cause you a serious headache once dropped and need to move on while you operating.
And yes their stats looks fancy but are useless. I also pointed few flaws in their stats that make them look my spam rate much higher than it really was - no response.
With a free plan that allows you to send 1,000 emails a month.
(Disclaimer: I work for SMTP2Go).
This isn't to say domain verification is a bad thing, but depending on how it's done, it's not always the first thing you can tick off on a project.
truly, these are challenging times for spammers
They run SaaS bookings for companies. They (and their clients) want them to come from reservations@companyname.com so people can reply easily to their reservation and go to them. Current options look like setting up something like reply-companyname@saasplatform.com and then have a hook send it to the actual address, which seems like a bit of hassle, but maybe this is the cost of progress on spam.
Asking non-tech clients to configure DKIM/SPF is a problem for them.
And since Sparkpost lets you validate the domain using a DNS record, you can just add it along with the DKIM/SPF.
Yes, they did. I'm the tech guy for a small cultural society, and their emails sent with Mandrill did get dropped by Gmail and other servers before I configured the SPF/DKIM records.
There's a reason why even Mandrill mandates SPF/DKIM for new accounts: https://mandrill.zendesk.com/hc/en-us/articles/205582267-Abo...