Safely Test Local Email Sending in .NET Applications

Safely Test Local Email Sending

When developing code locally and plugging in email-sending capability, it’s really important that we isolate our environments from the outside world so that we don’t end up sending emails to both systems and people. Below, I’ll show you two of my preferred ways of maintaining visibility of all emails that are sent from code, allowing us to safely test local email sending.

An important note before we begin, though: It’s good practice to not use any kind of production data in local development environments, so you should always make sure that any datasets are anonymised and obfuscated — or, better still, that it’s completely removed so that there’s no risk of accidentally misusing it. In the UK, you’re legally obliged to look after your customers’ data: the General Data Protection Regulations apply to both individuals and businesses and you could be landed with hefty fines if you unwittingly mishandle it.

Let’s take a look at my top solutions to safely test local email sending.

Save All Outgoing Emails to a Folder (Pickup Directory)

You can configure a Pickup Directory to write outgoing mail from an application to a specified folder. This avoids sending real emails while still letting you verify that they’re being generated correctly. The emails will be saved in a .eml format that you can easily open with applications like Microsoft Outlook or your built-in client.

To hook it up, modify the configuration of your application (usually via the web.config) to look similar to the following:

<configuration>
  <system.net>
    <mailSettings>
      <smtp deliveryMethod="SpecifiedPickupDirectory">
        <specifiedPickupDirectory pickupDirectoryLocation="C:\MailPickup\" />
      </smtp>
    </mailSettings>
  </system.net>
</configuration>

This configuration will likely be different to what you want to use when you promote your code changes to an internal test or production environment. It’s best to either make the local changes manually, or apply a config transform for other environments to ensure emails sent using a real SMTP server.

Does specifiedPickupDirectory work with Kestrel?
Yes, it works with apps running in Kestrel (.NET Core / .NET 5+). The key is that you’re using the System.Net.Mail.SmtpClient library.

A real, working SMTP configuration would look more similar to the below, once you move to other environments:

<smtp deliveryMethod="Network">
  <network host="smtp.server.com" port="587" userName="abc" password="abc" enableSsl="true" />
</smtp>

The Pickup Directory method is a simple and useful choice because:

• No SMTP server is needed — whether that be locally or hosted elsewhere.
• Testing is safe — accidentally sending real emails is avoided.
• Debugging is easy — opening .eml files in Outlook or other common mail apps.
• It’s fast and lightweight — using IIS’s in-built functionality and configuration.

If you need to test an actual integration and features such as DKIM, SPF, or TLS, this solution might not cut it.

Read more about the SMTP Element and Pickup Directory in Microsoft Learn’s documentation.

Setting-up a Local SMTP Server

If you do decide that you’d like a local SMTP server, but want something lighter than a traditional or bulky setup, Papercut is a great choice. You can grab the install from the project’s Github repo.

Unlike the Pickup Directory I covered earlier, Papercut listens on an SMTP port (usually 25) just like a real email server. That means you can test the full pipeline without worrying about delivery. The app will sit in your system tray and let you know with a balloon when it’s received a new message, which it displays in a friendly interface.

Once you’re up-and-running, you can send a test email to yourself to make sure things are working and that it’s ready to plug into your application. Open a PowerShell window and run the following:

Send-MailMessage -From "app@dev.local" -To "dev@dev.local" -Subject "Test Email" -Body "Sending emails to a local (safe!) SMTP server is really useful.`n`nGive it a try!" -SmtpServer "localhost"

You should then see a notification, which clicking should show the message you sent:

Using Papercut from an application is as easy as changing the SMTP server to point to ‘localhost’. In your web.config, you’d use something like this:

<configuration>
  <system.net>
    <mailSettings>
      <smtp deliveryMethod="Network">
        <network host="localhost" port="25" enableSsl="false" />
      </smtp>
    </mailSettings>
  </system.net>
</configuration>

And for .NET Core:

"Smtp": {
  "Host": "localhost",
  "Port": 25,
  "EnableSsl": false
}

Papercut supports both HTML and plain text emails, as well as a raw view that’s excellent for debugging markup:

Summary

Testing email functionality doesn’t have to be complicated and you can safely test local email sending really easily with the right tools. De-risk using the Pickup Directory method to store .email files on disk, or spinning up a local, lightweight SMTP server with Papercut. Both approaches help you test email features confidently and securely — without ever touching a real inbox.