DEV Community

Inael Rodrigues
Inael Rodrigues

Posted on

Building a Production Temporary Email Service with Mailpit, Vercel and Redis

#privacy #email #webdev #typescript

Temporary email services (disposable email) are often seen as simple "10-minute mail" scripts. However, building one that is reliable, secure, and doesn't rely on third-party SMTP proxies (like Mailgun or SES) is a great engineering challenge.

In this post, I'll walk you through the architecture of DarkEmail, an open-source project I've been maintaining for a year.

The Problem with Proxy-based Temp Mails

Most temporary email services you find today are just frontends for commercial SMTP providers. They use APIs from Mailgun, AWS SES, or SendGrid to receive mail. While easy to set up, this has three major drawbacks:

  1. Privacy Leak: A third-party provider sees every email body passing through.
  2. Lack of Control: You can't control the real retention or the raw SMTP headers.
  3. Fragility: Commercial providers often block "disposable email" use cases. If they flag your account, your service dies instantly.

I wanted a service where I controlled the entire pipeline—from the MX record to the Redis storage.

The Architecture

Here is how DarkEmail works:

[ Sender ] → MX: smtp.darkemail.school → [ Mailpit on VPS ]
                                               ↓
                                       [ Vercel Webhook ]
                                               ↓
                                     [ Redis (Upstash) ]
                                               ↓
                                     [ React Frontend ]
Enter fullscreen mode Exit fullscreen mode

1. The SMTP Receiver: Mailpit

Mailpit is an amazing tool written in Go. Usually used as a development SMTP server, it's robust enough to accept real inbound SMTP traffic.

I host Mailpit on a small VPS. I configured the MX records of darkemail.school to point directly to this VPS IP. Mailpit listens on port 25 and accepts all incoming mail for any address at that domain.

2. The Bridge: Custom Webhook

Mailpit has a built-in webhook feature. Every time a message arrives, it sends a JSON payload to a configured URL. In my case, this hits a Vercel Serverless Function (api/mailpit-webhook.js).

This function is responsible for:

  • Parsing the multi-part email (headers, body, attachments).
  • Sanitizing the HTML to prevent XSS.
  • Extracting the "To" address to use as the Redis key.

3. Storage: Redis with TTL

For a temporary email service, storage is ephemeral by design. I use Redis (via Upstash) with a 1-hour TTL (Time To Live).

When a message is saved, it's assigned an expiration. After 60 minutes, Redis automatically deletes the key. This ensures:

  • Zero permanent retention: We don't keep your data longer than needed.
  • Low Liability: If the database were ever breached, it would only contain the last hour of traffic.
  • Cost Efficiency: No need for massive disks; memory is recycled constantly.

4. The Frontend: React + Vite

The frontend is a React SPA built with Vite. It polls the API every few seconds (or uses WebSockets/SSE in the Pro version) to show new messages instantly.

Since it's a global service, I implemented proper i18n with URL routing (/pt/, /en/, /es/, /ru/) to ensure good SEO across different languages.

Key Engineering Decisions

Inbound Only

DarkEmail only receives mail. It never sends. Allowing outgoing mail from a disposable email domain is a recipe for disaster—your domain will be blacklisted by every SPAM filter in 24 hours.

No Registration

Privacy shouldn't require an account. You just open the site, and a random address is waiting for you.

Open Source

I believe privacy tools must be auditable. You can find the full source code on GitHub: github.com/inael/tempmail. You can even self-host your own instance using the Docker setup provided.

Challenges & Future

The biggest challenge is Mailpit as a single point of failure. If the VPS goes down, mail is bounced. I'm currently looking into a multi-region setup with secondary MX records.

Also, I'm validating a Pro Tier with:

  • Persistent unified inbox (save addresses forever).
  • Custom aliases.
  • Browser extension for auto-filling codes.

Conclusion

Building DarkEmail was a journey into SMTP, serverless orchestration, and privacy-first design. If you're interested in building something similar, check out the repo and let me know your thoughts!

Try it out: darkemail.school
GitHub: inael/tempmail

I'm Inael Rodrigues, founder of IT Booster. I build tools for privacy and developer productivity.

Top comments (0)