Protocol v1.0 · 28 July 2026

Mail-delivery test protocol

This is a protocol, not a performance claim. TmpKit will publish measured delivery rates only after a run has enough documented samples, fixed senders, timestamps, and retained evidence. Until then, an empty result is more honest than a fabricated benchmark.

Download the CSV observation template

Question and measurement unit

For a message sent to a newly created TmpKit address, can the system accept it, expose it to the matching browser session, and render or download its parts without altering the evidence needed to diagnose a failure?

Measurement unit: The unit is one message attempt. A resend is a new attempt with its own ID; it must not replace a failed row.

Controlled setup

  1. Use a fresh TmpKit session and record the generated recipient exactly as shown. Do not use a personal or sensitive message.
  2. Synchronize the sender device and observation device to a reliable UTC clock. Record timestamps with milliseconds where the sender provides them.
  3. Use only sender accounts you control. Record provider, sending domain, message ID, subject token, attachment name, and network condition.
  4. Keep the browser tab open, do not manually refresh unless the case requires it, and record consent state and viewport because they can affect scripts and rendering.
  5. Run at least three attempts per sender and message type at separated times before summarizing. A small run remains a diagnostic sample, not a population estimate.

Required test matrix

IDCasePass evidenceFailure class
DEL-01Plain-text messageSubject token and plain body appear for the correct session.acceptance, routing, visibility, or timeout
DEL-02Simple HTML messageText and allowed formatting render; scripts and active forms do not execute.sanitization or rendering
DEL-03Remote imageImage is hidden until requested and loads through the same-site image proxy.privacy proxy or rendering
DEL-04Small benign attachmentAttachment metadata appears and downloaded bytes match the sender-side SHA-256.parse, storage, or download
DEL-05Unicode sender, subject, and bodyCharacters remain readable without replacement or mojibake.encoding
DEL-06SPF/DKIM/DMARC-bearing senderRaw headers remain available for analysis; recorded results match the received header evidence.authentication evidence
DEL-07Two messages in rapid sequenceBoth unique message IDs appear once and in descending received-time order.deduplication or ordering
DEL-08Session expiry boundaryBefore expiry, matching recent mail is visible; after expiry, the API no longer returns inbox content.expiry control

Timing definitions

  • send_at: the sender's accepted/submitted timestamp, not when the draft was opened.
  • first_seen_at: the first observation of the message in the TmpKit UI or API.
  • delivery_observation_ms = first_seen_at − send_at. This combines sender queueing, DNS, SMTP, storage, polling, and clock error; it is not pure SMTP latency.
  • timeout: 120 seconds for a diagnostic run. A later arrival remains recorded, but the attempt is a timeout for the predefined threshold.

Failure classification

  • Sender rejection: the sending provider refuses or bounces before TmpKit accepts the message.
  • SMTP acceptance failure: TmpKit's receiver rejects or drops the transaction; retain the SMTP status when available.
  • Routing/storage failure: SMTP appears accepted but the matching database or body record is absent.
  • Visibility failure: stored mail exists but the correct active session cannot list it.
  • Rendering/download failure: the item is listed but sanitized HTML, text, image proxy, or attachment behavior is wrong.
  • Inconclusive: clocks, sender logs, message ID, or recipient evidence are insufficient. Do not relabel it as pass.

Minimum evidence per attempt

  • attempt_id, test_case_id, UTC send_at, UTC first_seen_at, and calculated observation milliseconds
  • sender provider/domain, recipient domain, anonymized recipient token, RFC Message-ID, and subject token
  • sender outcome or SMTP status, inbox outcome, rendering outcome, and attachment hash where applicable
  • browser/version, viewport, network notes, session expiry state, and operator notes

Privacy and safe publication

Use synthetic content only. Public results must hash or redact the mailbox local part, remove IP addresses and routing identifiers that are not needed for reproduction, and never publish authentication tokens, private headers, or real correspondence. Raw observations should be retained only as long as needed to verify the aggregate.

When a result may be published

A report must name the run dates, sender mix, sample count, protocol version, timeout, exclusions, missing rows, and calculation method. Report counts alongside percentages and keep sender-specific failures visible. Do not compare TmpKit with another service unless the same controlled messages, time window, network, and definitions are used for both.