Long story short (because cat videos wait for no one):
- days of sending emails through random servers are long gone
- you’ll pay between $1 and $10 for sending 10,000 transactional emails
- most services have the same base feature-set that’ll satisfy 99% of developers
- if you want free, host your app on Amazon EC2 and send 62,000 emails a month for $0
- jump to the comparison table
Although email is far from the only communications channel (and for many people, it’s becoming not the preferred one), it is still the primary communications channel for any web app. You can implement SMS, push notifications, FB messenger and 10 other channels but you’ll surely have email too.
With customers comes a need to send a lot of emails, and believe it or not, sending emails is neither easy nor free. That’s why transactional email service providers exist – to facilitate and aid in sending a large number of user triggered, personalized emails and to maximize their deliverability. As with any service on the Internet, we have plenty of choices when it comes to picking a transactional email provider. We found 15 of the most popular ones and compared their features and prices.
Transactional vs promotional/marketing/newsletter emails
Wikipedia defines transactional emails as ones that “are usually triggered based on a customer’s action“. That’s one of two basic staples of transactional emails with other one being – personalization.
Marketing emails (newsletters) are not personalized. Yes, you’ll often hear about segmenting and A/B testing and tagging, but in the end, the same email gets sent to thousands of subscribers. Maximum customization you can get in the email’s copy is
Transactional emails are (or should be) very personalized. For instance, a password reset/recovery email is a great example. It’s user triggered (a password reset action is triggered) and personalized – it contains a unique password reset link specific to the targeted user.
I’ll just send emails from my server
While technically entirely possible and quite easy, sending emails from a server that’s not specialized for that task is futile at best and quite frankly stupid. Why? Because 90% of your emails will end up in SPAM if they ever even get to the customers’ mailbox.
Have you ever had problems receiving emails from WordPress? New accounts, comments that need moderating, password reset emails (you can regain access to WP even if reset password doesn’t work) and such not getting through? That’s because WP is sending those transactional emails using the same server it uses to host the site. A server not optimized and made for sending emails.
Although this sounds like an ad for transactional email providers, it’s not. Sending emails that get delivered and opened, tracking them, getting stats and figuring out why things don’t work, requires a lot of moving parts. If you insist on doing things on your own, you’ll end up creating yourself a full-time job. Appealing? I think not!
I’ll use Gmail! It’s simple and free!
Using Gmail as the outgoing mail server while developing & testing is a perfect solution. We use it all the time. Everyone has a Gmail account, it’s free, simple and googling “how to send emails with Gmail via PHP” lands you on a helpful Stackoverflow article so you can copy/paste the code.
So, what’s the problem? Limitations and features. Since Gmail is not intended for this use, you’ll soon get the dreaded “you have reached a limit for sending emails” message. The exact limit is unknown, but it’s a few hundred a day at best. Again, since Gmail was not built for this purpose, you won’t know how many emails were delivered or opened, or how many links users click in those emails.
Isn’t there a free option?
No. Period. There isn’t. If you want a proper service, you have to pay for it. As it’s visible from the comparison table below, you can send about 5,000 emails a month for free. However, as soon as you’re over the limit, you need to pay per sent email.
Prices vary, mostly depending on the volume you need, but a rough calculation you can always use is $1 per thousand sent emails.
If your app is hosted on Amazon EC2 you can send 62,000 emails a month for free.
Transactional email services comparison table
|Service Name||Free Emails
Price Per 10k Emails
Price Per 10k Emails
Fixed Monthly Price
|A/B Testing||Inbound Emails
Free emails /mon – the number of emails you can send for free per month. Additional limitations apply. On Amazon SES for instance, the emails have to be sent from an EC2 hosted application. In other words, read the fine print.
Lowest tier 10k emails price – the highest (starting) price you’ll pay for sending 10,000 emails.
Highest tier 10k emails price – the lowest listed prices you’ll pay for sending 10,000 emails. Custom prices, for even more substantial volumes, go way lower so don’t be afraid to ask.
Lowest tier fixed monthly price – some services charge monthly some only require pre-purchasing email credits.
Dedicated IP /mon – monthly price for a dedicated IP address. Some say it’s better to have it, some it’s better not to have it – you be the judge.
A/B testing – since doing it on an application level requires some code it’s nice to have this feature built into the service.
Inbound emails processing – transactional emails are often sent from a “firstname.lastname@example.org” email. Rest assured that doesn’t prevent users from replying, so you need to have a mailbox for it too or, as done in most cases, forward it to your ticketing solution. However, if you don’t want a classic mailbox, you can have the API ping you whenever an email comes in and process it.
All services have API and SMTP support. Use the API if you ask me. They also have support for email templates stored on their end as well as “email opened” stats (which, understandably, only work if it’s an HTML email) and “link clicked” stats.
A note or two on some services
I haven’t tested or used all the service listed above. However, for those that I have here are a few notes.
Amazon – the big kahuna. Not the easiest to set up but they have everything under one roof. If you ever get the chance to grow truly big, you’ll be glad you’re on Amazon. Prices can be tricky but use their calculator, and you’ll be fine. If you have the time to traverse a steep learning curve, Amazon will serve you well.
SendGrid & Campaign Monitor – the mix&match options. Unlike other services which are transactional only oriented and more-less boil down to an API, these two are marketing platforms too. Think of them as MailChimp + a transactional API. Since we all send newsletter-alike emails at some point, I’d give them a go as a one-stop-shop solution.
Mailgun – the non-PayPal option. I had every intention of signing up a few years ago. Mostly due to their “The Email Service For Developers” tagline. However, they don’t accept PayPal, and none of my four credit cards were good enough for them. Support turned me down too, so I never got a chance to try the service. I see that PayPal is still not an option.
Mandrill – the no longer affordable option. Mandrill is what powers MailChimp. It’s their transactional email service. It was private for a time, then public, cheap and not so much advertised. Then they completely separated it from MailChimp and raised the prices. Some claim they have a higher deliverability rate than others, but I can’t confirm it.
What do you use? Recommend me something!
We use Postmark. Been using them for years and everything works as advertised. Plenty of features, decent prices, frequent updates, and friendly support. There might be better or cheaper services out there, but we never felt the need to switch. Please note that this is not a sponsored post in any way nor do I think they are the best thing since sliced bread. However, they are the service we use for our SaaSes and WordPress sites.
I don’t think you’ll make a mistake choosing any of the services above. I also know it’s tough to know what you’ll need in a year when you’re just starting. In the beginning, you want to save money, and later on, you want to save time. Switching services is never fun, but all these transactional email services have robust APIs, so it’s not the end of the world.