A guide to smtp4dev

Before sending emails out to your customers or prospects, it’s critical that you perform thorough email testing. However, how you approach testing is dictated by the number, complexity, and nature of the aspects of your emails that you need to test. The choice of the specific tool to facilitate email testing is not always straightforward.

In this article, we’ll cover smtp4dev, an easy-to-set-up email testing application for individual developers.

What is smtp4dev?

Smtp4dev is an open-source service that emulates an SMTP email server for email testing and debugging purposes. Also known as a ‘fake’ or ‘dummy’ SMTP server, smtp4dev functions as a regular SMTP server, but instead of sending your outgoing emails, the server intercepts and saves them. Once saved, you can inspect the emails through a web interface to make sure that they’re correct before sending them on to real users.

How does smtp4dev work?

Every application that sends emails uses the SMTP protocol under the hood. The email travels from its SMTP client (e.g. the Gmail client that you access in a web browser) to the domain’s SMTP server (in this case, it would be Gmail’s SMTP server). The server may then either send the email directly to the recipient’s client or pass the email on to another server (which may then pass it on further and so on) until the email reaches its recipient. That’s the standard procedure for sending emails.

Smtp4dev essentially listens for outgoing emails from port 25. But instead of passing emails on to other servers like a regular SMTP server, the emails are intercepted and displayed in a web interface. All you need to do is to configure your application’s SMTP host to your local machine running smtp4dev. After that, all emails that you send will show up in smtp4dev’s web interface where you can manually inspect them. Let’s look at a concrete example of how this can be done.

First, you’ll need to run smtp4dev. The easiest way to do this is with Docker. For those unfamiliar with Docker, all you need to know is that it’s a tool that packages software into containers and allows them to be used in different environments in a manner similar to virtualisation. We’ll type the following command to run smtp4dev with Docker:

docker run --rm -it -p 3000:80 -p 26:25 rnwood/smtp4dev:v3

• –p 3000:80 specifies that TCP port 80 (the HTTP port) in the Docker container is mapped to port 3000 in your local machine that’s running the Docker image.
• –p 26:25 specifies that port 25 (the SMTP port, i.e. the port to which emails are typically sent) in the container is mapped to port 26 in your local machine. This means that your tests must send emails to port 26 in order for smtp4dev to capture them.

Now that smtp4dev is running and listening, we can execute this Python script and send an email to port 26 of our fake SMTP server located at localhost:

import smtplib

sender = 'sally@email.com'
receiver = 'patty@email.com'

title = 'Grocery list'

body = 'Eggs, milk and lembas'

email = f'''from: {sender}
to: {receiver}
subject: {title}

{body}'''

smtp = smtplib.SMTP(host='localhost', port=26)
smtp.sendmail(from_addr=sender, to_addrs=receiver, msg=email)

When the script finishes execution, the email instantly shows up in the interface located at localhost:3000.

And that’s it! In the viewer, you can inspect your sent email’s content, headers, and attachments.

When is smtp4dev useful?

Smtp4dev is useful whenever you need to test your email functionality during development, which is something most applications require at one point or another. Whether it’s for sign-up confirmations or password resets, you should always run tests against your production data and make sure that your emails contain relevant information and are being displayed correctly to avoid plaguing real customers with sub-optimal emails.

You might be wondering if smtp4dev is worth all the hassle when you can simply send all tests to a throwaway email address. However, while simple and reasonably efficient, there are two key reasons why using a real SMTP server is not ideal:

• It might negatively impact your future email deliverability. Unpolished emails that you send during testing often contain triggers (such as malformed HTML code) that might get your email flagged as spam. Your deliverability will suffer greatly if you choose to continuously send your emails to a dummy account and these start getting classified as spam.
• It’s slow. Sending an email through a real SMTP server does not guarantee instant delivery. In fact, it might take minutes for an email to be delivered, not to mention the time required to navigate to the inbox (or the spam folder if that’s where your mail ends up) or to refresh the client for every modification that you make.

In contrast, smtp4dev is designed for testing, so emails sent to it are delivered right away and do not risk being flagged as spam. Its interface allows you to more efficiently examine your email than you would in an inbox.

That’s why smtp4dev and fake SMTP servers are the way to go for testing email flows.

What are the limitations of smtp4dev?

Smtp4dev can be a great addition to your tests, but its web interface is somewhat limited in its functionality. For example, smtp4dev does not parse HTML elements, so emails containing HTML are displayed as plaintext. Additionally, there’s only a single view of the email; there are no options to see how an email would be displayed by different email providers.

Another limitation of smtp4dev is that it doesn’t help you examine and troubleshoot deliverability. For example, if you want to find out how your email is perceived by spam filters, you’ll need to use other tools.

What other email testing tools can you use?

One of the simplest email testing solutions is to configure the SMTP settings in your application to save emails to a folder rather than sending them to a server. But while this might be an acceptable solution for some, it’s generally a better idea to test your application as close as possible to its intended usage. In other words, unless your application’s actual purpose is to save emails in a folder, it’s a better idea to test emails through an SMTP server and view them as they would be displayed to a real user.

With that said, there are a few other testing options besides smtp4dev. We’ll cover a few below.

Papercut

Papercut is another local email testing tool. Papercut’s advantage over smtp4dev is in its HTML support. But beyond that, it’s more limited in its functionality and lacks features for secure email connection such as SSL/TSL authentication. Moreover, Papercut is only available in Windows.

MailCatcher

MailCatcher is a fake SMTP server with an interface and functionality that are similar to smtp4dev’s, with the added feature of showing emails as they would be displayed by different clients. However, unlike smtp4dev which has support for all three major operating systems, MailCatcher has no Windows support.

Manage your testing pipeline with Mailosaur

Mailosaur is a hosted option for covering most testing bases, including test automation, management of SMTP servers, and deliverability. If you are looking for more than what smtp4dev and similar tools can do, check out our email testing documentation to learn more about using Mailosaur to test your emails.