# Papercut SMTP: a desktop SMTP sink for catching test email > Papercut SMTP listens on localhost, accepts every message your application sends, and shows it in a viewer instead of delivering it. It is a development tool, and the documentation is explicit that it is not a mail server for production. **ChangemakerStudios/Papercut-SMTP** — Papercut SMTP -- The Simple Desktop Email Server - Repository: https://github.com/ChangemakerStudios/Papercut-SMTP - Stars: 3,339 · Forks: 304 - Language: C# - License: Apache-2.0 - Published: 2026-09-24 · Updated: 2026-09-24 · Language: en - Canonical page: https://hysenlabs.com/en/projects/changemakerstudios-papercut-smtp ## The problem Papercut SMTP solves, and who has that problem Any application that sends mail needs a way to check what it actually put on the wire. Pointing a test at a real SMTP provider is slow, costs quota, and risks mailing a customer. Mocking the mail client hides the message: you assert that a function was called, not that the headers are right or that the attachment survived encoding. Papercut SMTP sits between those two options. It is a local SMTP server that accepts a connection, receives the message, and stops there. The README is blunt about the last part: mail is "caught, displayed instantly, and never delivered anywhere." The viewer shows body, HTML, headers, attachments and the raw message. The intended user is a developer working on a Windows desktop, or anyone running the Docker image, who needs to see the real bytes of a generated email. That includes people debugging template rendering, checking MIME structure, or verifying that a library sets the headers they expect. ## How the receiver works: a local SMTP endpoint plus a viewer The repository is a .NET solution. The Dockerfile shows the service being built from Papercut.Service.csproj, with separate projects for Papercut.Core, Papercut.Infrastructure.Smtp, Papercut.Message and Papercut.Rules. The SMTP side lives in Papercut.Infrastructure.Smtp, and the message model in Papercut.Message. The desktop application is WPF, which is why the topics list includes wpf and why the installers are Windows executables. The flow is short. Your application opens an SMTP connection to the local endpoint. Papercut accepts the message and hands it to the viewer, which renders it. Nothing is forwarded to a remote host. The service build also embeds an Angular web UI, built in a separate Docker stage from src/Papercut.Service/Web and copied into the .NET build output as Web/Assets, which is what you see at the web address when you run the container. There is a rules project in the tree, Papercut.Rules, so the codebase has a place for message handling logic beyond display. The README does not describe the rule set in the text shown here, so treat that as something to read in the documentation rather than assume. ## Installing Papercut SMTP on Windows and sending a first message The README offers two install paths. The desktop installer is linked for 64-bit, 32-bit and ARM64, and WinGet is the alternative, with the caveat that the package "may lag behind the latest release." After installation the README says Papercut is immediately listening on 127.0.0.1:25. Install with WinGet: ```powershell winget install ChangemakerStudios.Papercut-SMTP ``` Run the application, then configure your code to send to localhost on port 25. The README points to a page with copy-paste configuration for .NET, Node, Python, PHP, Java and Ruby, so the exact client code depends on your stack. The check that matters is simple: send one message and confirm it appears in the viewer with the headers and body you expected. The repository also carries an examples directory with small projects such as SendEmailTest, SendEmailWithPdfAttachment, SendEmailWithTls and SendRichEmailTest, plus a shared SmtpClientHelper.cs and an appsettings.json. Those are the concrete starting points if you want a working sender rather than a snippet. ## Running the Docker image and its web UI The Docker path changes the ports. The README gives this command: ```bash docker run -d -p 8080:8080 -p 2525:2525 changemakerstudiosus/papercut-smtp:latest ``` After that, the web UI is at http://localhost:8080 and SMTP listens on localhost:2525. Note that this is not port 25; if your application is configured for the default SMTP port, you have to change it to 2525 when you use the container. The image is built on mcr.microsoft.com/dotnet/aspnet:10.0, with the Angular UI compiled in a node:26-alpine stage. The Dockerfile passes /p:SkipAngularBuild=true to the .NET build because the UI assets arrive as a copied artifact, which is a detail worth knowing if you build the image yourself and wonder why the front end is not compiled in the SDK stage. A docker-compose.example.yml exists in the repository for a compose-based setup. ## Where Papercut SMTP is the wrong tool The name is the trap. Papercut is a receiver for development, not a mail transfer agent. It does not deliver, so anything that depends on a message arriving at a real inbox, such as a deliverability test, a spam score check, or an end-to-end test through a third-party provider, cannot be done with it. The documentation frames it the same way, with a page titled "How It Works" that the README describes as covering "what Papercut is (and isn't)." If you need a relay that forwards to a real server, or an SMTP endpoint that strangers on the network can reach, this is not that product. The Docker example also publishes the web UI on port 8080 with no authentication shown in the command. That is fine on a laptop. It is not a configuration you want on a shared host, and the README does not present it as one. Finally, the desktop application is Windows-only. The installers are Windows executables and the UI is WPF. A macOS or Linux developer can use the container, but the desktop viewer is not available to them. ## Papercut SMTP compared with MailHog and Mailpit The obvious alternatives are MailHog and Mailpit, which occupy the same niche: a local SMTP sink with a web interface for reading captured messages. The difference in approach is packaging and surface area. MailHog and Mailpit are distributed primarily as a single Go binary or container with a browser UI, which suits headless Linux and CI. Papercut ships a Windows desktop application with a native viewer as its main product, and the container is a second distribution path built from the same service code. That matters when you pick one. If your team lives in a terminal on Linux and wants one binary, the Go tools are a shorter path. If you develop on Windows and want a window that stays open while you work, with attachments and raw source a click away, Papercut is built for exactly that. The two are not interchangeable in workflow even though they do the same job on the wire. Papercut also carries something the others do not advertise in the same way: an optional Model Context Protocol server, so an AI agent can list messages, assert on bodies and headers, verify attachment content, and clean up between test runs. That is a different integration story from a web UI a human reads. ## The MCP server, licence, and what upgrades cost you The MCP server is part of the Papercut Service and is off by default. The README says to enable it with the EnableMcpServer setting, then connect with: ```bash claude mcp add --transport http papercut http://localhost:8080/mcp ``` The endpoint sits on the same host and port as the web UI, so if you already run the container you are one setting away from it. The README points to a dedicated MCP page for setup and the full tool reference, which is where the list of available tools lives; the README text shown here does not enumerate them. On licensing, the project is Apache-2.0. That is a permissive licence, and the practical consequence is that you can use Papercut inside a commercial development workflow without the copyleft obligations of a GPL-style licence. This is a description of the licence identifier, not legal advice; read the LICENSE file if the distinction matters to your organisation. Upgrade cost is low by design. The desktop installer always points at the latest release, and WinGet may lag, so the installer is the path that keeps you current. Releases are tagged and the repository keeps ReleaseNotes.md and ReleaseNotesCurrent.md, which is where you check what changed between versions such as 7.6.2, 7.7.2 and 7.8.0. The last push to the repository was on 2026-08-23, and the most recent release listed is 7.8.0 from 2026-08-15. ## Conclusion Adopt Papercut SMTP if you write or test code that sends email and you want to read the raw message without a real mail account. Do not adopt it as a production relay or as a mail server for real users; the README describes it as a development receiver and the Docker image exposes the web UI without authentication in the documented example. Before you commit to it, verify three things: that your test suite can reach 127.0.0.1:25 or the Docker port 2525, that your CI can run the container, and whether the MCP server is the integration path you want, since it is off by default and enabled through the EnableMcpServer setting. ## FAQ ### What is Papercut SMTP? It is a desktop email viewer with a built-in SMTP server for development. Your application sends to a local port, and Papercut catches and displays the message instead of delivering it. ### How do I install Papercut SMTP? Download the Windows installer for x64, x86 or ARM64 from the latest release, or run winget install ChangemakerStudios.Papercut-SMTP, which the README notes may lag behind the latest release. A Docker image is also published as changemakerstudiosus/papercut-smtp. ### How do I set up Papercut SMTP? Run the application and it listens on 127.0.0.1:25, then point your application at that address. With the Docker image, the README maps SMTP to localhost:2525 and the web UI to http://localhost:8080. ### How do I use Papercut SMTP? Configure your application to send mail to the local endpoint and send a test message. The viewer then shows the body, HTML, headers, attachments and raw message content. ### Is Papercut SMTP safe? It never delivers mail anywhere, so it cannot leak a test message to a real recipient. The README's Docker example publishes the web UI on port 8080 without showing authentication, so treat that configuration as local development only. ## Sources - [ChangemakerStudios/Papercut-SMTP on GitHub](https://github.com/ChangemakerStudios/Papercut-SMTP) - [Issues](https://github.com/ChangemakerStudios/Papercut-SMTP/issues) - [License: Apache-2.0](https://github.com/ChangemakerStudios/Papercut-SMTP/blob/develop/LICENSE) - [README](https://github.com/ChangemakerStudios/Papercut-SMTP/blob/develop/README.md) - [Releases](https://github.com/ChangemakerStudios/Papercut-SMTP/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/en/projects/changemakerstudios-papercut-smtp