Tools like Mailhog or Mailpit are great for local testing, but they still require setting up Docker, handling ports, SMTP configs, storage, and sometimes a reverse proxy to make them accessible remotely.
MailFrom dev is different in that:
No setup — just plug in SMTP credentials and start testing
Accessible by teams — no need to expose local ports or share tunnels
Built for collaboration — multiple teams can each have their own SMTP credentials and isolated inboxes out of the box
Built-in automations — you can set up auto-forwarding or manually forward emails to clients or colleagues to easily share your tests
Would love to hear your thoughts if you’ve used Mailhog/Mailpit in a team setting!
Great work, Daniele! Sandbox SMTP is a lifesaver for staging. How are you handling edge cases like bounces or spam-folder simulations? Any plans to plug directly into CI/CD workflows?
Right now, all emails sent to the SMTP server with valid credentials (and within burst limits) are accepted and stored for inspection.
Edge cases like bounces and spam-folder behavior are definitely important, especially for more advanced testing scenarios. I'm already exploring ways to simulate rejections and bounced messages — possibly as configurable options — so developers can test those flows too.
I'm also thinking about adding an API to query delivered messages, especially for use in CI/CD workflows — no ETA yet, but it's something I'll sure do.
About
I built Mailfrom.dev to make that painless mainly because I needed it and other players in the market are way too expensive for a solo dev that just needs to share access to a stage environment to its client.
7 Comments
How is this different from an OSS service like mailhog/mailpit?
Great question!
Tools like Mailhog or Mailpit are great for local testing, but they still require setting up Docker, handling ports, SMTP configs, storage, and sometimes a reverse proxy to make them accessible remotely.
MailFrom dev is different in that:
No setup — just plug in SMTP credentials and start testing
Accessible by teams — no need to expose local ports or share tunnels
Built for collaboration — multiple teams can each have their own SMTP credentials and isolated inboxes out of the box
Built-in automations — you can set up auto-forwarding or manually forward emails to clients or colleagues to easily share your tests
Would love to hear your thoughts if you’ve used Mailhog/Mailpit in a team setting!
Good stuff.
Thank you, every feedback is much appreciated
Passed it on to my team, as soon as they give me some feedback, will post.
Great work, Daniele! Sandbox SMTP is a lifesaver for staging. How are you handling edge cases like bounces or spam-folder simulations? Any plans to plug directly into CI/CD workflows?
Right now, all emails sent to the SMTP server with valid credentials (and within burst limits) are accepted and stored for inspection.
Edge cases like bounces and spam-folder behavior are definitely important, especially for more advanced testing scenarios. I'm already exploring ways to simulate rejections and bounced messages — possibly as configurable options — so developers can test those flows too.
I'm also thinking about adding an API to query delivered messages, especially for use in CI/CD workflows — no ETA yet, but it's something I'll sure do.