How TmpKit Works Behind the Scenes: Running a Temp Mail Service

Most temp mail sites describe themselves in marketing language and stop there. Since TmpKit is built and run by one developer, I can do something more interesting: walk you through what actually happens between someone hitting "send" and a message appearing in your disposable inbox. If you have ever wondered whether these services are magic or just plumbing — it is plumbing, and here is the diagram.

Sender
  │  1. DNS MX lookup
  ▼
TmpKit SMTP receiver (go-guerrilla)
  │  2. Accept + parse the RFC 5322 message
  ├──────────────► SQL: routing metadata and lookup row
  └──────────────► Redis: compressed raw body with TTL
                         │
Browser ── session cookie ──► API checks session + recipient
  ▲                         │
  └──── sanitized HTML + proxied remote images ────────────┘

Implementation snapshot: July 19, 2026

These are code-derived values, not estimated marketing numbers:

| Control | Current implementation | | --- | --- | | Session identifier | 16 random bytes (32 hexadecimal characters) | | Default generated prefix | 4 random bytes (8 hexadecimal characters) | | Session cookie | HttpOnly, SameSite=Strict, Secure in production | | Default active window | 3,600 seconds; production can override it | | Default extension limit | Once; production can override it | | Inbox access check | Active session cookie and matching recipient | | HTML isolation | DOM allowlist plus empty-permission sandboxed iframe | | Disposable-domain snapshot | 7,892 entries from the CC0 upstream list | | Live DNS timeout | 5 seconds |

The Product & Tool Methodology is the maintained, code-level reference for these controls and their limitations.

The journey of one message

Say you use a TmpKit address to sign up somewhere, and their system sends you a verification code. Five things happen in sequence.

1. DNS points the way. The sender's mail server looks up the MX records for the domain in your temporary address. Those records point at our mail servers. This is standard email infrastructure — the same lookup that happens when anyone emails your Gmail account, as defined in RFC 5321.

2. The TmpKit-operated SMTP layer accepts the message. The receiving layer is built on go-guerrilla, an open-source SMTP server written in Go. Like any production web service, it depends on network, DNS, hosting, database, and security providers rather than claiming that no third party exists. The domain is configured as a catch-all: mail to any name before the @ is accepted. That is the whole trick that lets a temp mail service hand out unlimited addresses without creating mailboxes in advance — we explained the DNS side of this in how catch-all domains work.

3. The message is parsed and stored — briefly. Routing metadata is written to SQL and the compressed raw message can be placed in Redis with a TTL so the web interface can parse headers, body, and attachments. The API exposes only messages whose recipient matches the address in an active session. This is a holding area, not an archive; the active window is shown in the interface.

4. Your session claims it. When you opened TmpKit, the server created a cryptographically random session tied to your address. Sessions live in Redis with a hard expiry: the code default is one hour, and the default configuration permits one extension. The session key and raw-body cache expire through Redis TTLs. An independently rate-limited cleanup removes SQL rows older than the active mail window, while the delete action can remove selected messages sooner. A deployment can change the default values, so the countdown in the app is authoritative.

5. Your browser picks it up. The inbox page polls for new messages every ten seconds while the session is active (and pauses when it is not — no point burning requests on a dead inbox). Fresh mail typically appears within seconds of delivery.

Deliberate design decisions

A few choices in this pipeline are worth explaining, because they are where privacy actually gets decided.

Receive-only, by design. TmpKit cannot send email. That is not a missing feature — an anonymous outbound mail service would be a spam cannon within a week, and running one responsibly is impossible. Receive-only keeps the abuse surface small and the use case honest.

Remote images go through a proxy. Marketing emails love tracking pixels: a one-pixel image whose URL identifies the message, so a direct request can reveal a reader's IP address and reading time to the sender. TmpKit rewrites remote image URLs through a same-site proxy before the sanitized message reaches its sandboxed iframe. This reduces direct browser-to-sender tracking, but it is not a promise of anonymity. Attachments are downloaded from TmpKit's stored copy through a session-checked endpoint and must still be treated as untrusted files.

No inbox account, but not “no data.” There is no inbox signup, so TmpKit does not ask for the usual name, password, or recovery phone. The service and its infrastructure still process the temporary address, message, session ID, IP and request/security data needed to deliver and protect the service. The Privacy Policy describes those categories and retention boundaries. This is also why you should never use a temp address for anything you need to recover later; our safety rules spell out where a disposable inbox is the wrong tool.

Short retention is the feature. It would be trivial to keep messages for a month. We do not, because every stored message is a liability for you and for us. The one-hour default (plus one extension) covers the actual use case — receiving a verification code or download link — without turning the service into an unintended archive of other people's mail.

The part nobody tells you about: running the domains

The genuinely hard part of operating a temp mail service is not the software. It is that the entire detection industry we described in why websites block disposable email is working to identify your domains and add them to blocklists. Within weeks of a domain becoming popular, signup forms start rejecting it.

This is the economics behind domain rotation, and it shapes the trade-offs every provider makes: fresh domains work on more sites but have no track record; older domains are stable but increasingly blocked. When an address from any provider gets rejected, this arms race is what you are seeing — you can even check where a given domain stands with our disposable domain checker.

Why write this up?

Because trust in a privacy tool should not require faith. You now know what happens to a message sent to a TmpKit address: accepted by the TmpKit-operated SMTP layer, split between short-lived storage and lookup metadata, available only to a matching active session, sanitized before display, and removed by TTL plus cleanup. The image proxy reduces one common tracking path without pretending the service is anonymous. No magic — just deliberately short-lived plumbing with documented limits.

Questions about any of this? The about page explains who runs the service, and the contact form reaches a human who wrote the code.