Absortio

Email → Summary → Bookmark → Email

VaultSandbox | Production-Like Email Testing Without Mocks

https://vaultsandbox.com/ Jan 9, 2026 06:35

Extracto

Keep your provider and your config. Just swap the recipient to validate real TLS, DNS, and SPF/DKIM entirely inside your VPC. Works with Postmark, SendGrid, SES, and more.

Resumen

Resumen Principal

VaultSandbox se posiciona como una solución innovadora para validar la funcionalidad de correo electrónico transaccional en entornos de desarrollo y CI/CD, superando las limitaciones de los mocks y las pruebas tradicionales. Su propuesta de valor central es permitir la validación completa de la entrega de correo electrónico (incluyendo TLS real, DNS auténtico y **verificaciones

Contenido

Keep your provider and your config. Just swap the recipient to validate real TLS, DNS, and SPF/DKIM entirely inside your VPC.

Works with Postmark, SendGrid, SES, and more.

Quick Start

Get Started in 5 Minutes

Deploy VaultSandbox with a single Docker Compose file. Auto-provisions TLS and DNS.

# docker-compose.yml
services:
  vaultsandbox:
    image: vaultsandbox/gateway:latest
    ports: ["25:25", "80:80", "443:443"]
    environment:
      VSB_VSX_DNS_ENABLED: 'true' # Auto-provisions TLS & Domain
    volumes:
      - vsb_data:/app/data        # Persists API Key & Certs

volumes:
  vsb_data:

The Problem

Mocks hide the exact email failures that break production

You mock the email client to get a green build. But in production, you use real SMTP, real TLS, and real DNS. This disconnect creates a dangerous blind spot.

The Dangerous Test Config

ignore_tls: true
rejectUnauthorized: false

Safe in CI Catastrophic in Production.

The "Works on My Machine" Shortcuts:

Fake SMTP

No TLS, DNS, or MX records — a fantasy environment.

Polling & Sleep Loops

Flaky CI tests relying on sleep(5) break pipelines.

Shared Public Inboxes

Risky data leaks on public cloud tools.

The Real-World Failures You Miss

Authentication Rot

SPF, DKIM, and DMARC only break on real domains. Mocks always pass.

TLS Negotiation

SSL/TLS issues surface only in production once you disable checks in dev.

Rendering Bugs

HTML emails render differently in real clients vs. plain text viewers.

The Solution

Real Domains. Real SMTP. Real TLS.
Zero Risk to Customer Data.

VaultSandbox provides isolated inboxes that behave exactly like production — without exposing a single byte of customer data.

How it works (inside your VPC)

Infrastructure requirements: Public IP, ports 25/80/443 open.

Two DNS Options

Zero-config: Use vsx.email — your IP is encoded into a subdomain automatically. No DNS setup required.

Your domain: Point an A record and MX record to the container. Subdomains supported.

Terminates Real SMTP + TLS

ACME certificates for SMTP and HTTPS auto-provisioned.

Full Message Validation

SPF, DKIM, DMARC, and rDNS checks on every message.

True Isolation

Email storage is encrypted in a sandbox; outbound mail is hard-blocked.

Production Fidelity

Test authentication, MX, DNS, MIME, and TLS exactly as they behave in the real world.

What You Gain

Keep secure: true

No more weakening TLS or SMTP configs just to make tests pass.

Catch Auth Issues Early

Validate domain crypto before deployment.

Data Sovereignty

All data stays in your infrastructure — never shared, never leaked.

Deterministic Pipeline

No guesswork, no polling, no sleeps.

The Landscape

Beyond Local Mocks and Public SaaS

Swap real provider for fake SMTP

rejectUnauthorized: false

Polling loops, sleep(5000)

DKIM issues found in production

Public cloud or local only

Keep real provider, change recipient

Real TLS, real certificates

SSE-based, deterministic waits

DKIM validated on every test

Private VPC, Zero-Knowledge

Is This For You?

You should use VaultSandbox if:

  • You use transactional email providers like Postmark, SendGrid, SES, or Resend.
  • You've been burned by DKIM/SPF failures in production.
  • You're tired of sleep() statements flaking out your CI.
  • Your compliance team forbids sending test data to third-party SaaS inboxes.

Architecture & Security

Zero-Trust Email Testing

Zero-Knowledge Storage Architecture

The server literally cannot decrypt your emails, even if compromised.

Private keys are generated locally and never touch the server.

Emails are encrypted in-memory on receipt; plaintext never hits the disk.

Decryption happens exclusively on your client. Your data remains sovereign.

Production-Like Message Analysis

VaultSandbox validates and inspects mail like a hardened email gateway:

SPF, DKIM, DMARC, and rDNS verdicts instantly returned.

Full MIME parsing — boundaries, attachments, HTML structure.

Strict SMTP protocol compliance, catching failures mocks silently ignore.

Ephemeral by Design (CI-Optimized)

VaultSandbox is built for high-velocity pipelines.

100% In-Memory: Lightning-fast execution with zero disk I/O bottlenecks.

Automatic Cleanup: No need to manually flush databases; restart the container to wipe the slate clean.

Disposable Inboxes: Generate random addresses that exist only for the duration of one test.

Use Cases

Real World Scenarios

The Signup Flow

QA tester creates [email protected], signs up, checks the inbox. Done. No shared credentials, no data leaks.

The Password Reset Integration

CI pipeline triggers a real password reset via Postmark. VaultSandbox catches the email, extracts the reset link, and "clicks" it. A true end-to-end integration test.

The DKIM/SPF Check

You rotated your DKIM keys. Send one test email to VaultSandbox and instantly verify if the signature is valid. Catch authentication rot before it blocks your newsletter.

Official SDKs

Open Source & Commercially Safe

The core engine is open-source and un-gated — the Docker image you pull is the same engine used in production setups.

  • Core Gateway: AGPLv3
  • SDKs + UI: MIT (safe for proprietary apps)

No Artificial Limits

Unlimited inboxes, connections, containers

Unlimited volume (hardware-bound only)

100% in-memory for high-speed CI
(Local persistence coming soon)

Full Encryption by Default

Quantum-safe cryptography is built in from day one.

Product Roadmap

Roadmap: Foundation First

PHASE 1: CORE FOUNDATION

Current

  • Official SDKs released for all major languages.
  • Closing critical feature gaps based on community feedback.
  • Achieving 100% test coverage & complete docs for a rock-solid core.

PHASE 2: ENTERPRISE CONTROL PLANE

Architecting

For compliance-heavy teams:

  • SSO (OIDC/SAML)
  • Audit Logs & Retention

Have governance needs? Help shape the specs.

Frequently Asked Questions

Still have questions? Drop a line to [email protected]

Is the Gateway truly free? What’s the catch?

Yes. The Core Gateway is AGPLv3 and free forever — no limits on domains, messages, or retention. We only charge for optional Enterprise features (SSO, Audit Logs).

Do I need a public IP and domain?

Yes, to unlock full production parity. To issue real Let's Encrypt certificates (ACME) and perform valid SPF/DKIM checks, the container must be publicly reachable on Ports 80, 443, and 25.

  • Port 80/443: Required for ACME certificate issuance and secure API/UI access
  • Port 25: Required to receive inbound SMTP traffic from the open internet.
  • Running locally implies using self-signed certificates and bypassing strict DNS validations.
Can I use this as a temporary email service for QA?

Absolutely. VaultSandbox acts as a catch-all for your testing domains. Create infinite inboxes like `[email protected]` instantly.

Is this heavy to run (vs Mailcow/Mailu)?

No. VaultSandbox omits heavy components like antivirus or spam filtering — optimized strictly for testing.

How is this “Zero-Knowledge” if the server receives email via SMTP?

Storage is zero-knowledge:

  • Client generates keys
  • Server encrypts with your public key
  • Plaintext is discarded
  • Decryption happens only client-side
Why quantum-safe cryptography?

We're building from scratch, so we used modern standards. ML-KEM-768 is NIST's finalized post-quantum algorithm—the performance cost is negligible, so there's no reason not to future-proof. Regulated industries will likely require it eventually; we're already there.

Won't my sandbox get hammered by spam if I open port 25?

No. The SMTP server has multiple layers of protection:

  1. Domain Restriction — Only accepts mail for your configured domains. Not an open relay; rejects mail for other domains immediately.
  2. Inbox Validation — Rejects mail at the RCPT TO stage if no matching inbox exists. Spammers can't even send data for non-existent addresses.
  3. Per-IP Rate Limiting — Configurable limits (e.g., 10 emails/60s per IP). Abusive IPs get temporarily blocked with SMTP 421 responses.
  4. Connection Limits — Configurable max concurrent connections, session timeouts, and message size limits prevent resource exhaustion.
  5. Early Talker Detection — Optional delay catches spam bots that send commands before the server banner.
  6. Hard Mode (optional) — Rejects all mail if no inboxes are configured. Nothing to receive means nothing to spam.

Bottom line: your sandbox only accepts mail for addresses you explicitly create, and rate limiting stops any single source from overwhelming it.

What happens if my container crashes or restarts?

Emails are ephemeral by default — restart wipes them. API keys and certificates are persisted, so your test environment stays configured; only inbox contents reset.

Can I use a REST client if there's no SDK for my language?

Yes. The Gateway exposes a standard REST API. SDKs are convenience wrappers with SSE support for real-time waiting. You can poll or integrate however you like, though you'll need to manage key creation and decryption yourself.

Full client spec: vaultsandbox.dev/sdk/client-spec

Do I have to manage encryption keys myself?

No — the SDKs handle key-pair generation and decryption automatically. Just call getEmail() and get plaintext back. If you're using the REST API directly, you'll need to handle decryption yourself (see the client spec).

How long are emails stored?

Until the container restarts (in-memory only), until the inbox TTL expires (configurable when you create the inbox), or until you delete the inbox — whichever comes first.

Ready to drop your mocks?

Stop guessing if your emails will land. Spin up the full VaultSandbox environment in your VPC in minutes.

Open Source (AGPLv3/MIT) • Deploys via Docker

Newsletter

Stay in touch with VaultSandbox

Subscribe for product updates, security releases, and deep dives on building production-grade email testing inside your VPC.

We protect your privacy. Privacy Policy

Fuente: VaultSandbox