Mailpit locally, a real inbox on staging: where each one fits

Updated October 16, 2026 · Zyntra

Mailpit is the right tool on your machine and in CI jobs where the app sends over SMTP: it catches every message and nothing leaves. It cannot see mail your app sends through a provider's HTTP API, or anything the provider adds on the way. Where those matter, on staging, test against a real inbox that receives what your provider delivers.

What Mailpit does

Mailpit is an SMTP server for testing with a web UI and an API, shipped as one binary or a Docker image. By default it listens for SMTP on port 1025 and serves the UI and API on 8025. Point your app's SMTP settings at it and every email shows up there, never reaching a real recipient unless you turn on its relay or forwarding.

What it can't see

  • Mail sent through a provider's API. If the app calls the provider over HTTPS rather than SMTP, nothing passes through Mailpit unless you add a separate SMTP transport for tests, which is then a different code path from production.
  • Provider-side templates. When the provider renders the template from data you send, the email Mailpit could show is not the one users receive.
  • What the provider changes. Click-tracking redirects, added headers, DKIM signatures.
  • Delivery itself. A suspended account, a sandbox flag left on, a domain that fails authentication: all invisible locally.

Use both

Local and unit-level CIMailpit. Fast, offline, free, nothing leaves the network.
Staging E2EA real inbox. The app sends through its production provider setup; the test reads what arrived.
ProductionNeither. Monitor your provider's delivery events instead.

The test code can stay the same in both places if the "read the latest email for this address" step sits behind one small function with two implementations.

Questions

Can Mailpit relay to a real inbox?
Yes, it can relay or forward through an external SMTP server you configure. At that point you are testing your relay setup, not your app's provider.

Sources