I've spent the last few months working on something I wish I'd had years ago. I kept running into the same issue: CI green, production mail broken. TLS handshake failures, DKIM alignment mismatches, SPF soft-fails ... the stuff that only surfaces when real mail servers are involved. Most test tools (Mailpit, MailHog) are catch-alls. They confirm "an email was sent" but don't validate the protocol. They also aren't designed for network-exposed environments: no auth, unprotected Web UI, easy to enumerate messages.
VaultSandbox is my attempt at fixing that. It's a self-hosted SMTP gateway (AGPLv3) that validates SPF, DKIM, DMARC, and rDNS on every incoming message. You keep your production email provider (Postmark, SendGrid, SES) in tests and you just change the recipient domain. No mocking, no config changes. There are client SDKs (Node, Python, Go, Java, .NET), plus a Web UI and a CLI for manual testing.
Some technical details:
Deterministic Tests Instead of polling or sleep loops, the SDKs use Server-Sent Events (SSE) so test assertions trigger the moment the mail hits the gateway.
Minimal infrastructure footprint Built with NestJS and Angular, with no external database dependency to keep the container footprint small and easier to reason about.
Post-Quantum Encryption I use ML-KEM-768 for the encryption layer. Incoming mail is encrypted immediately using a client-generated public key and the plaintext is discarded. The server only ever stores encrypted message data and cannot decrypt it. I chose PQ because I wanted to build something I wouldn't have to revisit in five years. If it handles large PQ keys reliably, everything else is easy.
Quick start: https://vaultsandbox.dev/getting-started/quickstart/
Site: https://vaultsandbox.com
I'd love feedback, especially on whether AGPLv3 would be a blocker for something you'd self-host in dev.
Thanks for the upvotes so far!
I would love to dig into the actual developer experience side. One of the main reasons I built this was to kill the sleep(5) or polling loops in CI by using Server-Sent Events (SSE) in the SDKs, so tests react instantly.
For those of you managing large test suites:
- Does your current team rely on mocks/Mailtrap style catch-alls, or do you just trust that the protocol (TLS/DKIM) works?
- How are you currently handling PII in dev/test email logs? (This is why I went with encryption for zero-plaintext storage on the server).
Any feedback would be really useful, since until now I have gotten none and as a solo dev it gets to a point that you do not know if it is a good idea or not.
Thanks again,
> especially on whether AGPLv3 would be a blocker for something you'd self-host in dev
AGPL3 shouldn't be a blocker for use with this sort of tool unless:
▪ someone is very paranoid about GPL infection (that is to say that they, or their bosses, have been taken in by some of the fear-mongering over the years)
▪ or they are intending to make the feature available as part of the their product/service (if it is a mail related/adjacent tool and they want to use this as a built-in self-test module) rather than just using it internally, in which case they might be subject to the full terms of the licence due to effectively directly linking the code.
To alay the concerns of that first group, perhaps include in you documentation a paragraph explaining that simply using it in a dev environment, with no redistribution, does not constitute linking.
If someone tells you "no one will use it commercially if you use GPL"¹, you always have the option (assuming all the code is yoursor contributors have signed over their relevant rights) of dual licencing GPL and commercial.
--------
[1] this usually means "I want to sell this with my service but don't want to pay or otherwise give back, please use a more permissive license so I can do that"
I can not include anything GPL or AGPLv3 with my MIT license WeKan Open Source kanban, where I have added and removed over 4 million lines of code.
I have discontinued version of WeKan where was GPLv2 licensed Gantt Chart component, because it infected WeKan license to be GPLv2.
There has been some other kanban, that first changed from MIT to GPL, and then from GPL to some source-available license or propietary.