Email as a Service – Part 1

Introduction

You are building next generation shopping website but you don’t want to spend a lot of time building and maintaining email service because that is not core of your business. Or you are working on next greatest and latest task management app and want the ability to receive tasks via email, so users of your app are connected in more ways. You don’t want to invest your money and time in setting up email servers, but the day your app goes viral, you want to avoid sleepless nights scaling your email service. You need, what is called as “Email as a Service” served from the cloud.

Features of Email as a Service

Like most cloud services, having your email delivery and sending hosted in the cloud means almost unlimited scalability. But why would you need to a service for this? What makes it so special that you can’t do it yourself? We look at some prominent reasons:

SMTP hosting

Getting your email delivered sounds easy, but there are factors which need to be accounted for. Things like spam prevention, bounces and SPF records need to be taken care of. Especially when sending on large scale, you can easily be marked as spammer if this isn’t done right. EaaS providers make sure they don’t get blacklisted. Bouncing is another big issue. You want to make sure it is tried multiple times, but you also don’t want your mail server to overload after getting thousands of bounces.
And then the real technical stuff, like DKIM (DomainKeys Identified Mail) which validates your domain (or from your EaaS provider) as a legit sender. SPF, to make sure the email you send is actually form your domain. Or ESP Feedback Loops, when a receiver does mark you as a spammer and wants to get of your list. All things which need to be right when operating on a large scale, but take a lot of effort to manage yourself.

Inbound mail

Receiving inbound mail on a large scale is quite challenging as well, you don’t want to use a no-reply email address but you don’t want a mail clog either when everyone starts replying.
But that’s only after your send something yourself. But what if you want to make inbound email part of the features of your app? Task management apps use inbound mail their customer can add a task by sending a simple mail. Content management apps can allow users to mail text and attachments to put it on their website. Translation apps can have the input delivered by email, and send the translated piece back to the submitter. I think you get the point by now, the possibilities are endless.

Scalability

Sending a few hundred mails a day should work, but what if you app becomes so popular you need to start sending thousands of mails an hour? Scalability is one of the main reasons for using Email as a Service. When developing your app, you always aim for success. With that in mind, you need to build your infrastructure for success. So if your app hits off, you want to celebrate, instead of having to worry about your email infrastructure. You probably build your application and database infrastructure with scaling in mind already, and that area of scaling alone will cause you enough headaches when you become the next Facebook. And you can always start with an entry plan, to keep your costs low. The costs will scale with your usage.

Analytics

Numbers can be fun, and you definitely want to know how much of your emails are actually read. But parameters like click tracking, unsubscribe rates and bounces are valuable information about the quality of your list and app effectiveness. And with the help of API’s, you can get this data integrated in your app, or make a custom management dashboard. This is something your regular SMTP servicer can’t come up with. Sure you can find a log to see how much emails are send, and maybe even how much you receive. But that’s it. Ad especially open rates (how much of your emails are read) are an important indication for the usage of your app. Maybe you are sending too much emails, causing low open rates and even cancellations for your app?

Integration

You don’t want to spend lots of time to get it to actually work, so a nice set of API’s is always provided. EaaS providers take great lengths to make sure that integrating their service in your app is a breeze. You can use SMTP to start easy, but if you want the full package you can use API’s and use JSON to communicate with it.  Documentation is often extensive, because of the flexible use of the API’s . But the Email as a Service providers benefit from you sending as much emails as you need, so you can be sure there’s always an API that fits your requirements.

Pricing

After reading though all the possibilities, you might think that Email as a Service can be quite expensive. Well, it doesn’t have to be. Major providers like Sendgrid, Mailgun and Postmark price mostly per 1.000 emails. And all have an free entry plan for you to get familiar with their services. Once your app hits off  you’ll be looking at prices ranging from $1,50 per 1.000 mails at starter level, to $0,10 per 1.000 mails when you are sending millions of mails per month.

Rounding up

Email as a service is definitely something which fits in the modern way of app development, where scaling for success is an important factor. But since email delivery – both outbound and inbound – has its own set of rules, outsourcing it can certainly benefit you in the long run. If email is a key part of your app, it’s really worth considering. In my next article I will do a comparison of some of the big players in this game (Sendgrid, Mailgun and Postmark) and see what makes them a good fit.