It would be interesting to see in this article two features that I find are pretty rad that mandrill supports: inbound email processing and api-side templating.
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.
Mailgun has a great inbound api [1]. You can set up routing rules to let them post the email as json (or just forward it) to a specified url. The json also includes fields for the extracted quoted parts and signature. The latter is based on some machine learning, which other providers don't have afaik.
I would second Mailgun for inbound email. Granted, my use-case is very low-volume, but it works great and the email parsing seems to be pretty good.
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.
Ooooh, that would be pretty handy. I've been relying on good old "please reply above this line" to parse inbound emails, precisely because I didn't want to muck around with ML to infer user intent (I reeeeally wish quotes, the reply-date separator, and signature blocks were standardized somehow). If there's a reliable improvement to this functionality provided by my email service, that's 100% a feature I'm willing to pay for. Thanks.
(I'm an engineer on Sendgrid's Events & Stats team, but don't speak for my team or Sendgrid)
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.
> It would be interesting to see in this article two features that I find are pretty rad that mandrill supports: inbound email processing and api-side templating.
I really feel sad for the close down of Mandrill, although we are not affected as we are also paid MailChimp user, so we can merge our accounts. However, we are considering moving away MailChimp due to this, just don't like the way they do business.
We're in the same boat. It feels like Mandrill is a second class product to MailChimp. We've also started facing massive deliverability issues to some providers (like Hotmail and friends) that are proving very hard to correct.
We used constant contact and Mandrill at the small non profit I'm on the board at. This move basically killed the idea of moving to Mail Chimp. It was kinda a bait a switch. We use very low volume so be willing to pay a little, but moving to an fairly expensive plan for transactional isn't going to happen.
It looks to me like Mailchimp but not Mandrill are (for now) keeping their small-scale pay-as-you-go plans. But, they force you onto a larger plan if you try to merge your Mailchimp and Mandrill accounts. If I'm not misreading it, it's US$70 per month minimum -- too much for the nonprofit folks I serve.
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.
Could I use the free tiers of these services as a personal email service as an alternative to, say, Gmail? I'm using my own mail client (like SeaMonkey or Thunderbird) and I have my own domain name.
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.
Most (all?) don't have POP3/IMAP for incoming mail (they use webhooks for your web app) so you could send email through these but not easily receive it.
The problem with having your own mailserver is mostly that google and hotmail won't accept your mail. So you could have your own POP3/IMAP server, and only send outgoing mail through the transactional service.
Yeap, that's me. I have it configured as a smart host[1] on my self-hosted exim server, so I can change it in just one place, without touching the email clients. Came in handy recently :)
Perhaps there is a hack where you could configure the receive hook to forward the JSON object to some other free service (like the cloud databases) and then configure your desktop/mobile app to pull from there?
Many of these services are targeted explicitly on sending transactional email, e.g. user does something in an app and an email is sent in response. I doubt personal email usage would be covered. Also, they won't give you an 'inbox' like you would get with Gmail.
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.
My question is, of the options listed, who's got the best deliverability to Gmail users? As a small mail server operator, that's always been my biggest challenge.
I want to encourage everybody to set up their own e-mail infrastructure, as it's both fun, rewarding and useful.
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.
They should all work well with Gmail, since it's the most popular recipient, and all popular solutions have deliverability statistics. I'd guess that using Gmail itself via its SMTP service [1] would be the most reliable overall.
But can we use that for arbitrary domains that aren't operating under the Google Apps system? Been looking but haven't found the answer so far.
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]"
My experience with these providers is limited to Mailgun, but after I followed their instructions of setting SPF and DKIM records, I never had any issues with Gmail delivery. Hotmail however sometimes flags my messages as spam. I also never had any issues with delivery delays. When I send a mail using Mailgun, it ends up in my inbox within a second.
I actually had an idea to provide A/B testing of transactional email providers, with feedback on deliverability (using their own stats). Would that be a valuable service to anyone?
Wow, and on top of everything else, sparkpost just upgraded their free tier from 10k/mo to 100k/mo sends. That's pretty huge, as 100k/month gets you a lot of runway before you need to really start paying for things. Plus, the CEO promises to keep honoring the 100k threshold for anybody who signs up under that plan, even if they have to lower it again in the future. [0]. I'll have to check them out.
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.
I agree, Sparkpost is the best option I've seen so far. I've moved most stuff to it.
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.
Moved from Mandrill to Sendgrid for SMTP... had delivery issues, likely my fault. Moved to Sparkpost, NO problems. Much easier interface and onboarding for SMTP.
A couple more options not mentioned. I suspect these were left out because they are thought of more as online/web oriented. However, both support using your own domain, SMTP-SSL-TLS/IMAP/ETC.
We've used Postmark for a while, it's worked great.
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)
Receiving emails isn't that hard. But that's not all you're getting into.
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.
Well, that's just it, you listed 6 dependencies required to setup a mail server. Then there's the time and effort required to keep everything running.
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.
And on top of that, you have a clear separation of responsibility where marketing can do all the A/B testing of the different emails all by themselves, without any effort. It's a great way to reduce bottlenecks in your organisation by separating responsibilities.
Correct, fear of ending up in spam. There's a pretty decent chance you'll get terrible deliverability running your own mail server. Mail services (Gmail, et al) treat new email senders/IPs as 1 step above known spammers.
As someone who used to work at a startup that used Postmark to send alerts, I think its just easier for our small company of less than 12 people.
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.
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.
> postfix + opendkim + smtp + tls + spamassassin + fail2ban is not too difficult a setup to achieve
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.
... and then the IP range my server is in lands on a spam blocklist and I have to migrate all that elsewhere to get around it, or try to get new IPs from my provider until I end up somewhere "clean".
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.
As someone who created a reasonably popular SMTP server you basically just listed why it's hard. That plus the problems of sending (ever end up in a blacklist? It's not fun).
Setting up a mail server is often worth it, but requires experience that about 0.01% (being generous) of the developer community has.
This is a bit misleading. For example, in serious use you need the domain whitelabeling on Sendgrid which requires the monthly $75 plan. Otherwise you get the 'sent via Sendgrid' message in most email clients. I'm not sure about those other providers.
Are you sure that's still the case? I recently switched one of my site's transactional mail from a free Mandrill account to a free SendGrid account, and have not seen this issue.
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.
It's weird how 'the cloud' has put people into the mindset where email isn't just a complementary service that runs alongside the web server and just works. Nope. Sign up for a third party service and if you're serious pay for it.
Spam has made this a bigger deal. Many cloud ip addresses are untrusted by email filters and ip reputation is a big deal. Companies like Sendgrid will actively safeguard and report on those reputations as well as working to prevent abuse by their users.
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.
The problem with running email yourself is keeping it working. Given the choice of dealing with IP blacklists at block level or paying a few quid a month is a no brainer for lots, before you factor in the other benefits of 3rd party mail (scheduling, templating, integration of campaign primitives like un-subscribing, analytics etc)
I think it's less "the cloud" and more about things like SPF, Domain Keys, spam filtering, etc. It's not trivial any more to spin up your own mail server.
This is exactly why services like RDS, Redshift, S3 and others are killing it. People don't want to deal with the finer details of running a server of any kind, they just want the service it provides.
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.
Besides the obvious and easily preventable case of someone setting up an open relay, there is plenty of risk associated associated simply with the presence of a SMTP server. The providers out there will require you to setup DKIM, SPF records and have a decent password associated with your account...if you're running the box yourself, this all suddenly becomes optional.
> It's weird how 'the cloud' has put people into the mindset where email isn't just a complementary service that runs alongside the web server and just works. Nope. Sign up for a third party service and if you're serious pay for it.
It's more that the big feudal lords don't accept trade from small freeholders.
It's not good that it sucks to run your own mail server. It actually sucks. But it is reality because spam burned the world.
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.
> Sending email is cheap, and any reasonable business is probably having sending email as one of its lowest costs.
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?
What Amazon SES might lack in terms of fancy features, it probably makes up for in pricing and stability. We've been using it for over four years and haven't experienced a single problem in that time.
Not only is it dirt cheap, it's so easy to do everything right to maintain a good reputation. If you're using Route 53, it's one click to set up DKIM. It's also painless (and cheap) to handle bounce notifications programmatically.
I wonder how many of the people who chime in with "AWS is so expensive" every time AWS is discussed, use Mailgun or one of those other really expensive mail providers? Incidentally, have you had a problem with delivery to e.g. gmail, because there are several old articles that claim SES is blacklisted?
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.
Hello buro9
I believe you're one of the co-founders. Are you open to share more of your plan for your startup?
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 just finished the work today of migrating from Mandrill to SendGrid. I can't speak for the other providers, but so far it has been a fairly painless process. The client libraries for Node are similar enough between the two that I didn't have to put a ton of thought into refactoring.
If you like the idea of self-hosting your transactional email server, check out Cuttlefish[1][2] - it's a slick open-source solution for this. We spun it up with a dedicated IP and gradually warmed it up to ~13k emails/day over several days. It's been smooth sailing and incurs no additional monetary costs.
Do any of such delivery services provide some kind of a DoS prevention for their users or is it always up to the user to implement such prevention mechanism? For a normal usage the prices are very attractive, but it could only take one rogue script that automatically registers new users on a site (which results in a registration email) for the bill to become large.
What I mean is a script that for example creates a large number of users using a form that is exposed by my web page (not protected by captcha for usability). This would result is my backend issuing large number of API calls to send user registration confirmation emails.
I know postmark has a credit system, and when you run low they email you. The rates are low enough that it would take a huge volume to cost you.
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.
Ah that makes sense. The last webform I made I tied to a Celery work queue to send my email. Would be 1 flag to limit the send email tasks to "1 / second" or something, which would at least limit damage.
I'm wondering whether Sendgrid or Mailgun are overkill for my use-case. I've got no interest in sending email but I've got a number of devices at home that send email via SMTP when something goes wrong (router, NAS). I'd like to write something that takes the POST from whatever webhook and sends it to PushBullet or similar.
Something that is missing/would be nice to add: with Mandrill I could pay to get a dedicated IP address (ensuring that I don't get impacted by other parties on the platform). Do these other services offer that?
I cannot speak for the other services, but I know that Sendgrid offers this as an option. I use them for transactional emails on a couple of Magento sites.
The number of DNS lookups for SPF records is limited to 10 [1] so that that could be a technical issue that needs to be worked around [2] depending on how many SPF records each service adds:
Sure you could do that, but I think the maintenance cost would by far outweigh any price advantage you could get.
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.
No reason. It's probably a good idea to implement that even if you don't need the volume, so you can quickly switch if an offering changes or has issues (downtime, delivery problems for an important provider, ...)
Wait until you get to customer support. Sendgrid is a joke. The only solution was a chargeback that they didn't fight.
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.
Sure, you can install Postfix or sendmail and run your own mail server. That's a tremendous administrative hassle, though, which is why these services sprang up in the first place.
I'm a novice to transactional email; what sorts of use cases would make not verifying a domain name an (ethically) good thing? I can't think of a case where that wouldn't scream "spam", but I'm not sure about that. =)
verification of some sort should be a requirement, but in some cases domain verification is harder to do than a single email address verification. I don't always have control over the DNS (which is always how I've seen domain verification done), and getting access to it, or having someone change it for me, might take days or weeks (or get done wrong, or whatnot). I'm dealing with a couple of clients right now where any change request like that takes 2 weeks - that's just standard policy. But... we can verify "foo@company.com" as a single address immediately.
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.
I was saying that sometimes you can't update any of that quickly, but you can - via amazon ses, for example - validate a single address. Doing that will allow you to get past at least part of a project's set up and keep moving until you can get dns issues updated. it's not a 'never do it', but 'that can come a bit later without being a roadblock' issue, imo.
But email is all externalities. Is the convenience of you being able to send email more important than the anti-spam management of "yes, we actually own this thing"? (icebraining's points regarding DKIM and SPF are more practical and, IMO, accurate, but the collective problem is more interesting to me.)
Such as my business which provides a SaaS service and email is one of the features. Small business customers don't always have the ability to update DKIM/SPF, especially is using GMail for example for email.
Amazon SES doesn't require domain verification unless you want to be able to send from arbitrary email addresses for that domain. If you have a known set of senders, you can verify just those email addresses (which works the usual way: email is sent and you click a link).
I don't know why this is getting downvoted. A bunch of people in our coworking space have this exact problem.
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.
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.
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.