← Back to blog

How TmpKit Works Behind the Scenes: Architecture, Go-Guerrilla SMTP, and Ephemeral Storage

July 6, 2026

Updated September 17, 2026

#engineering#architecture#Go#Redis#SMTP#behind the scenes
How TmpKit Works Behind the Scenes: Architecture, Go-Guerrilla SMTP, and Ephemeral Storage

How TmpKit Works Behind the Scenes: Architecture, Go-Guerrilla SMTP, and Ephemeral Storage

Most disposable email services hide behind vague marketing slogans like "military-grade anonymous inbox" without disclosing a single line of their actual technical implementation. In reality, a temporary email service is an exercise in high-throughput network plumbing, distributed session management, strict data sanitization, and defensive domain operations.

TmpKit was built from the ground up to solve a very specific problem: receiving low-risk transactional verification codes without cluttering primary mailboxes or leaking long-term identifiers to data brokers.

In this behind-the-scenes technical breakdown, we pull back the curtain on the entire pipeline—from the moment an external Mail Transfer Agent (MTA) executes a DNS MX query to the sub-second browser polling loop that delivers sanitized email to your screen.

1. End-to-End System Architecture

The following architectural diagram illustrates the complete data flow from outbound sender to browser display:

Sender MTA (e.g. Gmail / SendGrid)
  │
  │  1. Inbound SMTP Connection (Port 25, Opportunistic STARTTLS)
  ▼
[ edge.tmpkit.com:25 ] -> Go-Guerrilla SMTP Daemon
  │
  ├── 2. Header & Body MIME Stream Demuxing
  │      - Enforces Max 10MB message ceiling
  │      - Strips executable attachments (.exe, .bat, .scr)
  │
  ├── 3. Dual-Tier Ephemeral Persistence
  │      ├── Tier A (PostgreSQL): Address, Subject, From, Timestamp, Metadata
  │      └── Tier B (Redis): Compressed Raw MIME / Body with Hard 3600s TTL
  │
  ▼
[ Next.js Edge Web Service ]
  │
  ├── 4. Session Validation (Strict HttpOnly Cookie Matching Recipient)
  ├── 5. Content Sanitization (DOMPurify Allowlist + Tracking Pixel Rewriter)
  │
  ▼  6. Polling & Realtime Event Stream (HTTP Long-Polling / SSE)
Client Browser (Sandboxed <iframe> Display)

2. The Ingestion Engine: Go-Guerrilla SMTP Daemon

Traditional mail servers such as Postfix or Exim were engineered for permanent Unix mailboxes (/var/mail/$USER) with disk-backed Maildir hierarchies. They incur severe file I/O overhead and complex user directory lookups that make them poorly suited for throwaway inboxes.

TmpKit employs a customized deployment of go-guerrilla, an event-driven, non-blocking SMTP daemon written in Go capable of ingesting tens of thousands of concurrent connections on minimal hardware footprint.

How Catch-All Mail Routing Functions

Unlike standard mail servers that require creating a system user or virtual mailbox table in advance, TmpKit configures its domains in catch-all mode. During the SMTP session:

C: EHLO mailer.example.com
S: 250-edge.tmpkit.com Hello mailer.example.com
S: 250-STARTTLS
S: 250-SIZE 10485760
S: 250 8BITMIME
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
[... TLS 1.3 Handshake Negotiated ...]
C: MAIL FROM: <[email protected]>
S: 250 2.1.0 OK
C: RCPT TO: <[email protected]>
S: 250 2.1.5 OK Recipient matched active domain
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
[... Message Payload ...]
C: .
S: 250 2.0.0 OK: message queued 4f1a8c9b

In the Go backend, the daemon processes the Envelope struct within a pipeline processor:

// Simplified Go-Guerrilla custom Redis+SQL pipeline processor
func SaveToTmpKitStorage(e *backends.Envelope) (backends.Rendered, error) {
    recipient := strings.ToLower(e.RcptTo[0].User + "@" + e.RcptTo[0].Host)
    
    // Check if the domain is currently hosted on TmpKit
    if !isSupportedDomain(e.RcptTo[0].Host) {
        return backends.NewRendered("554 Transaction failed: Unrecognized domain"), nil
    }

    messageId := generateSecureToken(16)
    
    // Store message metadata in Postgres for index querying
    go recordMetadataInSQL(messageId, recipient, e.MailFrom.String(), e.Subject)
    
    // Store compressed payload in Redis with TTL matching active session window
    go cacheMessagePayloadInRedis(messageId, e.Data.Bytes(), 3600*time.Second)
    
    return backends.NewRendered("250 2.0.0 OK: Message accepted"), nil
}

3. Dual-Tier Storage & Ephemeral Lifecycle Management

One of the most consequential engineering decisions in a privacy-oriented temp mail service is guaranteed deletion. If data lingers on disk or in database backups, the promise of ephemerality is broken.

TmpKit implements a dual-tier storage architecture designed specifically to balance indexing performance against automated garbage collection:

Tier 1: Relational Metadata (PostgreSQL)

  • Stores non-confidential routing metadata: message_id, recipient_address, sender_address, subject_preview, received_at, and expires_at.
  • Enables rapid pagination and index scans when the frontend polls GET /api/inbox.
  • An independent background cron executes partitioned truncation: 
    DELETE FROM email_messages WHERE expires_at < NOW() - INTERVAL '600 seconds';

Tier 2: Compressed Ephemeral Payloads (Redis)

  • The raw MIME stream, parsed HTML/plain-text bodies, and inline attachment buffers are stored in memory via Redis.
  • Every message payload key is assigned a strict Redis TTL: 
    SETEX email:payload:4f1a8c9b 3600 "<gzip-compressed-mime-bytes>"
  • Once the 3,600-second window elapses, the Redis key-eviction mechanism automatically purges the memory block. Even if the SQL background worker experiences transient database locks, the message body evaporates automatically at the memory layer.

4. Client-Side Security: Content Sanitization & Sandboxed Iframes

Allowing untrusted third-party HTML and JavaScript to render directly in a user's web browser is an invitation to Cross-Site Scripting (XSS), session hijacking, and CSRF attacks. Attackers routinely weaponize HTML emails using malicious SVG payloads, javascript: pseudoprotocols, and hidden redirect triggers.

TmpKit implements a strict defense-in-depth isolation boundary:

[Raw Untrusted HTML Payload]
  │
  ▼
[1. DOMPurify Server-Side Sanitizer]
  │ Aggressively strips scripts, form elements, base tags, and event handlers
  ▼
[2. Remote Image & Web Beacon Proxy]
  │ Rewrites tracking pixel URLs to anonymous server-side proxy
  ▼
[3. Browser Native Sandboxed Iframe]
  │ Rendered in <iframe sandbox="allow-popups"> without allow-scripts

Defense 1: Server-Side Allowlist Sanitization

Before HTML is returned to the client, it passes through a rigorous DOMPurify ruleset. All script tags, object/embed wrappers, form elements, base tags, and interactive handlers (onload, onerror, onclick) are aggressively stripped.

Defense 2: Sandboxed Iframe Isolation

The rendered email is placed inside an isolated <iframe> configured with minimal sandbox permissions:

<iframe
  sandbox="allow-popups allow-popups-to-escape-sandbox"
  srcdoc="<!DOCTYPE html><html>...sanitized html...</html>"
  className="w-full border-0 min-h-[400px]"
/>

Notice what is omitted: allow-scripts, allow-same-origin, and allow-top-navigation are deliberately absent. Even if a zero-day sanitization bypass exists, the browser's native iframe boundary prevents the payload from executing JavaScript or reading the parent window's cookies.

Defense 3: Remote Image & Web Beacon Proxy

Email marketers frequently embed 1x1 transparent tracking pixels to log when an email is opened, alongside the reader's IP address, user-agent, and approximate physical location.

To mitigate this vector, TmpKit intercepts and rewrites all <img src="..."> tags:

  • Direct tracking URL: https://tracking.adnetwork.com/beacon.gif?uid=9872
  • Rewritten TmpKit URL: /api/image-proxy?url=https%3A%2F%2Ftracking.adnetwork.com%2Fbeacon.gif%3Fuid%3D9872

When the browser requests the image:

  1. The request hits TmpKit's proxy worker rather than the sender's ad network.
  2. The proxy strips the client's Cookie, Referer, and IP address headers.
  3. The image is fetched server-to-server and streamed back with aggressive cache headers.

5. The Operational Reality: Domain Reputation and The Blocklist Arms Race

Building the software for a disposable mail service is only half the battle. The far more exhausting operational challenge is navigating the global domain reputation ecosystem.

Anti-fraud and identity verification providers maintain continuous automated crawlers that monitor public temp mail services. When a domain is identified as disposable:

  1. It is appended to public and commercial DNSBL lists (such as Spamhaus DBL or proprietary vendor blocklists).
  2. Major web applications (e.g., streaming providers, social media platforms, cloud services) reject signups containing that domain at the registration form.
[Step 1: Form Submission]
  User enters disposable address (e.g. [email protected]) on target web service.

[Step 2: Anti-Fraud Verification]
  Registration backend queries third-party fraud detection API or DNSBL cluster.

[Step 3: Blocklist Match]
  Detection engine resolves domain MX record or matches static blacklist: DISPOSABLE_MATCH.

[Step 4: Form Rejection]
  Web app halts signup: "Please provide a valid permanent or business email address."

To provide full transparency on this arms race:

  • We publish our Disposable Domain Observatory, documenting the exact dataset (7,892+ curated disposable domains) used by our detection engine.
  • We maintain the Disposable Domain Checker to help developers and system administrators audit whether a given domain is flagged in industry databases.

6. Verifiable Engineering Principles

TmpKit's implementation adheres to transparent, verifiable rules:

  • Zero Outbound Capability: We maintain no SMTP submission servers (ports 465/587). We cannot send or relay email.
  • Strict Cryptographic Entropy: Session keys are generated via 16 cryptographically secure random bytes (crypto/rand), preventing address enumeration.
  • Hard Expiry Windows: Messages strictly expire after 60 minutes unless explicitly extended once by the user.

For more technical and compliance details, explore our Code-Level Methodology or review our Email Header Analyzer and SPF Checker developer tools.