Mailpit Hosting

How Mailpit works

Mailpit acts as an SMTP capture server and a web interface for intercepted messages. A development application submits mail to the listener, and Mailpit stores the result for inspection rather than treating the message as ordinary production delivery. Testers can review HTML, plain text, headers, raw source, MIME attachments, search results, tags, and client-oriented previews from the browser.

The catalogue protects the web interface with the admin user and a generated password, stores messages in /data/mailpit.db, and configures the SMTP listener to accept any authentication credentials over insecure connections. The public application service points at the web interface; reaching the SMTP listener from another workload still requires a supported network path and should not be assumed to be public.

Key Mailpit features

Mailpit can support automated integration tests through its API and can analyse links or HTML when the required components are available. It is useful for confirming that an application produced the intended recipient, subject, template, attachment, and headers. A captured result does not prove that a real mail provider will accept the message or that every client will render it identically.

This deployment is a test inbox, not an outbound mail service. Application email is disabled across the hosting service services, and the package does not provide a production SMTP relay, sender reputation, domain authentication, bounce processing, complaint handling, or recipient delivery. The accept-any SMTP setting also means the listener must not be exposed to untrusted networks.

Mailpit vs Mailtrap Email Sandbox

Mailpit provides a self-hosted SMTP capture service, inspection interface, and testing API. Mailtrap Email Sandbox is a managed product with provider-hosted inboxes, team features, email analysis, and plans tied to its service. Mailtrap separates sandbox testing from its Email API or SMTP product for messages intended for real recipients.

Mailtrap may suit teams that want a maintained hosted account, collaborative inboxes, vendor-managed connectivity, and commercial support. Mailpit fits developers who want the test mailbox under their own domain and can manage network reachability. Neither sandbox should be presented as proof of final production delivery.

Who uses Mailpit

Developers can inspect account messages during feature work, QA teams can verify templates and attachments, and automated tests can query captured mail. A small internal staging environment may also use separate tags or recipient patterns to organise several test flows.

Mailpit is not suitable for customer campaigns, password messages that must reach real users, transactional delivery, marketing consent management, or reputation testing on a production route. Operators remain responsible for keeping test data free of unnecessary personal information and removing messages that should not be retained.

Self-hosting Mailpit: requirements and cost

Mailpit resource use depends on captured message volume, attachment size, retention, search activity, API tests, concurrent browser users, and SMTP ingestion rate. PostgreSQL and MariaDB are Not required; the catalogue uses the local /data/mailpit.db store. The software has no separate application charge, while large attachments and long test histories can consume storage quickly.

On AvaHost, Mailpit uses Plan 1 at €2. The hosted Mailpit package includes one-click deployment, a custom domain with automated HTTPS, automatic application updates, and scheduled backups. Use the generated web-interface password and restrict any route to the SMTP listener because the catalogue permits accept-any authentication over insecure SMTP. The package exposes the testing UI, not a public production relay, and application email remains disabled. Confirm network connectivity from each test workload without publishing port 1025 to untrusted senders.