SMTP Server for Testing: Cloud-based or Local?

SMTP server for testing

You are developing a web or a mobile application, and one of its knotty features is mass-email delivery. Probably, you have already flooded your own inbox with several hundreds of test emails or even sent a couple of nasty messages to your real customers, and afterward concluded to use an SMTP server for testing email sending.

We have already described how a fake SMTP server can save your time and nerves. Now here is another important question: how to set up an SMTP server for testing? There are multiple mail testing tools for developers to choose from, but in general, there are three main approaches. Let’s have a look and review the key things to consider when choosing a solution that fits your needs.

Fake SMTP as a SaaS

The easiest way is to adopt a ready-to-use cloud-based fake SMTP. Mailtrap offers this type of service, which in fact is a SaaS. It provides the following advantages:

1. Usability. With a zero development time, you get a dummy SMTP. It doesn’t require any additional installations or dependencies: the only thing you need to do, is to copy SMTP credentials and embed them into your development environment.
2. Independence. It’s a self-contained product, so you don’t need to have/buy/maintain any additional infrastructure. The only thing required is a web browser. And we’re pretty sure you’ve already got one 🙂
3. Technology agnostic. Since Mailtrap provides an SMTP protocol, it is compatible with any SMTP library in any programming language.
4. High availability. It’s accessible 24/7: Mailtrap’s uptime is 99.9% (average data from May 2014 till September 2018, available on http://status.mailtrap.info)
5. High performance. You don’t need to monitor server resources and worry about ensuring their optimal usage. Mailtrap takes care of it entirely, seamlessly processing hundreds of millions of your emails.
6. Additional features. Being not just a tool but rather a solution designed to solve a list of tasks, Mailtrap offers POP3, email forwarding and inbox sharing options, provides an inbox email address, spam and blacklist reports, etc.
7. User and team management. If you work on several projects, collaborate with different teams or customers, the ability to quickly sort and find emails becomes essential. Mailtrap lets users group inboxes into companies as well as share selected data with other users.
8. Support. If you have questions or doubts about using the product, you won’t stay alone: the Mailtrap tech support team is there to help. There is also the option to give feedback and propose new features.
9. It is free for personal use. The free plan provides features for sending, viewing and analyzing test emails; enough for small projects which don’t require team engagement.

Try Mailtrap for Free

Though a cloud-based dummy SMTP server offers a comprehensive list of useful features, and we at Mailtrap truly believe in what we do and love our product, there are some cases when it might be not the right choice.

1. You need to, no… you must! store your data locally only. It’s quite a common security concern for large enterprises, financial institutions, etc. when full control over any type of data is crucial. None of the cloud-based solutions can satisfy this requirement.
2. You require some very specific settings or just are an adept of an open source software. Mailtrap offers access to the email testing functionality via its API, but it’s still closed source software.
3. You are a bootstrapper, developing several projects but every dollar is critical. To enjoy the full list of Mailtrap’s capabilities and get most of its advantages, you should buy the appropriate subscription plan.

Test mail server installed locally

The second type of a server for email testing is a local SMTP server for testing. If you lean towards this type of email test tool, we would like to draw your attention to Mailhog, a popular open source solution. What benefits does it offer?

1. Full control and advanced security even for testing emails. All data is stored locally, and you are able to manage each type of configuration.
2. Flexibility in usage. Once you’ve installed it, you can do whatever you want. You can place it on your servers in your closed network and therefore limit the access, and at the same time you can modify the system according to your toughest requirements, hence it’s open source.
3. Straightforwardness. Mailhog is developed with Golang, this way it’s quite easy to use and still can handle high loads.
4. No investments, It’s free.

But here are some downsides that should be considered:

1. SMTP setup issues. It’s not a ready to use solution, so before you can move forward with your primary task – testing emails – you should spend some time and effort on configuration. Sometimes it necessitates some DevOps tricks, so installation requires particular technical expertise. As a result, the entry barrier for using this type of software is a bit higher.
2. Additional infrastructure is required (AWS Elastic, Digitalocean, Docker, Heroku, etc.). SMTP server installed locally still needs to be deployed somewhere, so it leads to additional expenses. Yes, those platforms offer free tiers, but they are not always a good fit. For instance, private Docker repositories are available in paid plans only. And you know, the more elements you use, the higher the chances that something might go wrong.

One more piece of history or advice here: Mailhog was inspired by MailCatcher, as its developers state.

Probably, the only case when Mailcatcher would work better is with Ruby on Rails infrastructure. Mailcatcher was built on Ruby, so in this instance, it’s much easier to use. Overall, it’s pretty difficult to set it up, and, furthermore, it demonstrates quite low performance. But Mailcatcher was the first tool of this type in the market, so it truly deserves to be mentioned.

Learn why The Software House replaced other solutions with Mailtrap and streamlined their email testing processes from our case study.

Dummy SMTP on desktop

Finally, there is the third option: a desktop application.

This is also a good choice for cases when you need to test emails without a web browser or to install a dummy SMTP server as a desktop application. It can be FakeSMTP or DevNull SMTP, both written in Java.

They provide minimum functionality and limited GUI to work with emails as well as no options for sharing and also require Java to be installed on your machine.

Wrapping Up

There are no perfect tools, just the right solutions for specific needs. In order not to be disappointed with a poorly fitting technology, define your expectations first. Which features are critical and which are just nice to have? Do I have any limitations or need to stick to a particular technology?

Hopefully, this post helped you to figure out how to send test emails painlessly while getting the functionality you expected.