Product & Tool Methodology

This is a verifiable account of the current code, defaults, and known limits—not a marketing-level overview.

How a receiving session is created

  1. The server uses cryptographic randomness for a 16-byte session ID and an eight-hex-character default mailbox prefix.
  2. The session ID is stored in an essential HttpOnly, production Secure, SameSite=Strict cookie that front-end scripts cannot read directly.
  3. The session and address mapping live in Redis with a TTL. The code default is 3,600 seconds, with a 60-second floor and one extension by default. Production configuration can change these values, so the in-app countdown is authoritative for a current session.
  4. Selecting a custom address does not register or reserve it. Someone else may choose the same prefix, which is why no address is suitable for confidential material.

From SMTP to the browser

MX records deliver mail to an SMTP receiver based on go-guerrilla. Message metadata is written to SQL and raw content can be compressed in TTL-controlled Redis. API reads require both the current session cookie and a matching recipient; an expired session no longer returns mail. A rate-limited cleanup removes expired SQL rows, and users can delete selected messages sooner.

Before rendering, HTML is reduced to allowed tags and attributes. External image URLs are rewritten through a same-site proxy to reduce direct sender tracking of the browser IP. The body then runs in an empty-permission sandbox iframe, without script, forms, popups, or top-navigation privileges. Attachments remain untrusted external content.

DNS and authentication tools

MX, SPF, DMARC, and DKIM tools use the server-side Node.js DNS API for live MX/TXT queries. Inputs pass length, label, and character validation; lookups have a five-second timeout and responses are marked no-store. Results are a snapshot of public DNS. Caches, propagation, split TXT strings, multiple SPF records, and transient resolver failures can change output, so the tools explain records rather than issue a security certificate.

Disposable-domain checker

The checker uses a bundled 7,892-entry snapshot from the CC0 disposable-email-domains community project. It normalizes an address or domain and walks parent suffixes—for example, checking both sub.example.com and example.com—then runs a live MX lookup. A match means “present in this snapshot.” A miss does not prove that a new or rotating domain is permanent. Corrections should be submitted upstream and appear after TmpKit updates its snapshot.

Email-header analyzer

Header analysis extracts routing, authentication, and timing clues. Forwarders, mailing lists, gateway rewrites, clock skew, and forged fields can all alter conclusions; one Received, SPF, or DKIM result does not prove sender identity. Remove unnecessary addresses, Message-IDs, internal hostnames, and tokens before pasting.

Privacy, content, and ad separation

Inboxes and tools are functional screens, not AdSense publisher articles. During review, the site keeps only an account-verification meta tag and loads no ad script. Future serving requires approval, the enable flag, a configured Google-certified CMP, and a valid page-specific manual slot. The real inbox is now on the homepage; the homepage, message viewer, tools, and research pages permanently omit ad components. Article units may mount only after edited article content. See the Privacy Policyfor data handling and the Editorial Policyfor content standards.

Reproduction and reports

To reproduce a tool result, record the URL, input, UTC time, expected value, and observed value, but never send private message bodies. Report methodology or implementation errors to [email protected].