DEV Community: Inael Rodrigues

Why Most Temp Email Services Are Privacy Theater (And How to Fix It)

Inael Rodrigues — Wed, 29 Apr 2026 19:15:30 +0000

We've all been there: a website forces you to register just to read one article or download a PDF. So you search for "temporary email," click the first link, use the address, and move on.

But have you ever stopped to think about who owns that "temporary" address?

Most people use these services for privacy, but most of these services are actually Privacy Theater. Here is why, and how we should be building them instead.

1. The Proxy Problem

The majority of top-ranking temp mail sites don't actually run an email server. They use APIs from commercial providers like Mailgun, SendGrid, or AWS SES.

When an email arrives at your "private" temporary address, it first lands on the servers of a multi-billion dollar corporation. They parse it, log it, and likely use it for their own internal telemetry. Only then is it forwarded to the temp mail site's frontend.

If you're using temp mail to avoid tracking, but the email is being tracked by the world's biggest tracking engines before it even reaches you, are you really gaining privacy?

2. The Retention Liability

Many services keep your "temporary" emails for hours or even days. While convenient, this is a massive privacy risk. If the service's database is breached, months of user data - including confirmation codes, personal invites, and sensitive links - are exposed.

A true privacy tool should be "memoryless."

3. The Lack of Auditability

Privacy tools are built on trust. Yet, almost none of the popular disposable email services are open source. You have no idea if they are selling your data, keeping logs of which IP requested which email, or training AI models on your incoming messages.

How to Build Real Privacy

When I built DarkEmail, I decided to tackle these issues head-on:

Control the Infrastructure

Instead of using a third-party API, we run our own SMTP receiver (using Mailpit) on a dedicated VPS. No one sees the email except our code and the user.

Aggressive TTL

We use a strict 1-hour Time To Live (TTL) in Redis. After 60 minutes, the message is physically deleted from the server. Not hidden, not archived - deleted.

Open Source Everything

Trust shouldn't be blind. We've made our entire stack public on GitHub. Anyone can audit our code, see exactly how we handle data, or even host their own version.

The Future of Disposable Identity

In an era of aggressive tracking and "walled garden" signups, temporary identity tools shouldn't just be convenient; they should be robust.

We need to move away from "privacy theater" tools that just hide your email from one company while giving it to another. We need infrastructure that we can audit and trust.

What's your take? Do you care about the infrastructure behind your privacy tools, or is convenience the only metric that matters?

Check out the project: DarkEmail
Audit the code: github.com/inael/tempmail

I'm Inael Rodrigues, building tools for a more private web.

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

Inael Rodrigues — Wed, 29 Apr 2026 19:11:33 +0000

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:

Privacy Leak: A third-party provider sees every email body passing through.
Lack of Control: You can't control the real retention or the raw SMTP headers.
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 ]

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.

Building Privacy-First Applications: Why Developers Should Care About Temporary Email

Inael Rodrigues — Tue, 03 Feb 2026 13:35:35 +0000

What is Temporary Email?

Temporary email (also called disposable email or burner email) provides you with a fully functional email address that:

Receives real emails
Requires no registration
Auto-expires after a set time
Keeps your real identity private

Think of it as localhost for email - perfect for development and testing, not meant for production personal use.

Real-World Use Cases for Developers

1. API Testing Without Spam
When testing email-related features, you need real email addresses that actually receive messages:

import requests

# Using temporary email for API testing
test_email = "random123@darkemail.school"

response = requests.post('/api/auth/register', json={
    'email': test_email,
    'password': 'securePassword123'
})

# Check if verification email was sent
# Visit darkemail.school to see the incoming email

2. CI/CD Pipeline Testing
Automate your email verification tests without maintaining a list of real emails:

# .github/workflows/e2e-tests.yml
name: E2E Tests

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Run registration tests
        env:
          TEST_EMAIL_DOMAIN: "darkemail.school"
        run: |
          npm run test:e2e

3. Evaluating Third-Party Services
Before committing to a new tool or service:

# Instead of:
curl -X POST https://api.newservice.com/signup \
  -d "email=mypersonal@email.com"  # 🚫 Now they have your email forever

# Do this:
curl -X POST https://api.newservice.com/signup \
  -d "email=eval-test@darkemail.school"  # Evaluate without commitment

4. Webhook Development
Testing email webhooks becomes trivial:

// Testing Mailgun/SendGrid webhook handling
app.post('/webhook/email', (req, res) => {
  const { from, to, subject, body } = req.body;

  console.log(`Email received at ${to}`);
  // Process webhook...

  res.status(200).send('OK');
});

// Send test emails to your temporary address
// and watch your webhook handler in action

Security Considerations

When TO Use Temporary Email:

Testing and development
Downloading resources/ebooks
Evaluating new services
Gaming site registrations
Newsletter trials

When NOT TO Use:

Banking or financial services
Professional/work accounts
Accounts you need to recover
Two-factor authentication backup

My Recommended Workflow

Here's how I've integrated temporary email into my development process:

// utils/testHelpers.js
const generateTestEmail = () => {
  const timestamp = Date.now();
  const random = Math.random().toString(36).substring(7);
  return `test-${timestamp}-${random}@darkemail.school`;
};

// In your tests
describe('User Registration', () => {
  it('should send verification email', async () => {
    const testEmail = generateTestEmail();

    await registerUser({ email: testEmail });

    // Manually verify at darkemail.school
    // or integrate with their API
    expect(response.status).toBe(201);
  });
});

Tools I Use

For my temporary email needs, I've been using DarkEmail - it's a free service built specifically with privacy in mind. What I like about it:

No registration required - just generate and use
Clean, developer-friendly interface
Fast email delivery - usually under 10 seconds
Works with most services - including those that block common disposable domains

Privacy Best Practices for Developers

Beyond using temporary email, here are practices I follow:

Compartmentalize: Use different emails for different purposes
Audit Regularly: Check what services have your real email
Use Aliases: For services you trust but want to track
Read Privacy Policies: Especially for services handling user data
Implement Privacy by Design: In your own applications

// Good: Let users know what you'll do with their email
const PrivacyNotice = () => (
  <p className="text-sm text-gray-500">
    We'll only use your email for account recovery.
    No marketing emails. Ever.
  </p>
);

Conclusion

Temporary email isn't just a convenience tool - it's a privacy practice that every developer should adopt. It protects your personal information, reduces inbox clutter, and makes testing workflows significantly easier.

Next time you're about to enter your real email into yet another service, ask yourself: "Do I really need to give them my actual email?"

The answer is usually no.

What about you? How do you handle email privacy in your development workflow? Share your tips in the comments! 👇

Try DarkEmail - Free Temporary Email for Developers