Skip to content
Mailack
esBook a demo

Product · Evidence chain

Six facts per message. Each with its own record.

This page walks the full chain: from the byte stream that goes over the wire to the proof bundle a third party checks without connecting to Mailack.

System under construction. We are working with pilot customers.

portal.mailack.com/mensajesPRODUCTION
MensajesLa bitácora de todo lo que ha enviado, con el estado de entrega y la evidencia.
  • MLK-9F2C-4187legal@acme.mx09:41
  • MLK-7A1D-9023ops@nova-logistica.com09:12
  • MLK-3E8B-5561finanzas@grupoorion.mx08:57
  • MLK-6C4F-2208rh@constructora-anda.mx08:30

raíz Merkle verificadab3:91:0c:4e:…:f7:2a

01What can be proven

The six facts, per message.

Each fact has its own record, captured at the moment it happens. No record, no claim.

  1. Exact content

    What the message said, byte by byte. The hash is computed over the canonical byte stream that went over the wire.

    hash · canonical byte stream

  2. Instant of issuance

    When it was issued. Date is fixed before hashing, and the batch root is sealed with PSC Codex with sealed_at.

    fixed Date · sealed_at

  3. Acceptance on delivery

    The message was accepted for delivery. The literal SMTP response from that conversation is kept, with the queue id assigned.

    250 2.0.0 · queue id

  4. Delivery or rejection

    The outcome. The RFC 3464 DSN arrives via the return-path and is archived raw, before parsing.

    RFC 3464 · VERP return-path

  5. Integrity over time

    The evidence has not changed since sealing. WORM preservation and an inclusion proof against the sealed root.

    WORM · inclusion proof

  6. Verifiability by third parties

    Any third party checks the canonical hash and the inclusion proof on their own, in their browser, without uploading the bundle to any server. The certificate itself is backed by PSC Codex, which issued it.

    mailack.com/verificar · nothing uploaded

02Dual capture

Two captures per delivery, at two different moments.

Acceptance and outcome are separate facts. They are recorded separately, and neither replaces the other.

At the moment: the literal SMTP response

mailack-dispatcher preserves the exact line with which the message was accepted on delivery, including the queue id assigned. Not a translated code: the line itself.

SMTP transcript · moment of delivery
>>> MAIL FROM:<bounce+9f2c1e7a-…@mailack.com>
<<< 250 2.1.0 Ok
>>> RCPT TO:<user@domain.com>
<<< 250 2.1.5 Ok
>>> DATA
<<< 354 End data with <CR><LF>.<CR><LF>
>>> .
<<< 250 2.0.0 Ok: queued as 4bK9Qz3Yx1z

Afterwards: the raw RFC 3464 message

The outcome arrives later, via the VERP return-path. mailack-collector archives the .eml whole before parsing it and correlates it with its originating message.

RFC 3464 · DSN
Reporting-MTA: dns; mail-out-01.mailack.comArrival-Date: Wed, 29 Jul 2026 11:04:14 -0600Final-Recipient: rfc822; user@domain.comAction: deliveredStatus: 2.0.0Remote-MTA: dns; mx.domain.comDiagnostic-Code: smtp; 250 OK  queue id 4bK9Qz3Yx1z

Raw evidence exactly as archived, before parsing. The original .eml is preserved in WORM storage; what you see is its literal content.

03Canonicalization

What went over the wire is what gets hashed. Nothing else.

Message-ID and Date are fixed before hashing. From that point the byte stream is final: the MIME is never re-serialized.

If a byte changes, the hash changes. That is why the message is fixed first and hashed second, over the exact byte stream that goes over the wire.

Hash inputexact byte stream on the wire
Fixed beforehandMessage-ID · Date
Neverre-serialize the MIME
04Merkle + NOM-151

One tree per window. One certificate per root.

Hashes enter an RFC 6962 Merkle tree in windows of one hour or ten thousand leaves. mailack-sealer seals the root with PSC Codex; each message keeps its inclusion proof.

rootn1234n5678n12n34n56n78h1h2h3h4h5h6h7h8
Inclusion path from one leaf up to the sealed root.Sealed rootInclusion pathRest of the batch
Window1 h or 10,000 leaves
ConstructionRFC 6962 · prefix 0x00 leaf / 0x01 internal node
What gets sealedthe tree root · NOM-151 certificate from PSC Codex
The certificate includescertificate_id · serial_number · policy_oid · algorithm_oid · sealed_at

Sealing the root covers every leaf in the window: the inclusion proof connects each message to the sealed root. For litigation, an individual certificate for the message is also issued on demand.

05Preservation and verification

Preserved in WORM. Verified without taking our word.

Evidence is kept in Object Storage with retention and bucket lock. The proof bundle is verified in the browser, without querying Mailack.

What the proof bundle carries

  • Canonical hash of the message
  • Inclusion path up to the root
  • Batch root
  • NOM-151 certificate from PSC Codex

WORM preservation

The .eml and the evidence are archived in Object Storage with retention and bucket lock: during the retention period they are not overwritten or deleted.
In-browser verification
GET /v1/messages/{id}/proof-bundle
→ mailack.com/verificar

The public verifier recomputes the hash of the .eml and rebuilds the inclusion path up to the sealed root, entirely in the browser: the file never leaves the device. The certificate is checked against PSC Codex, which issued it.

06The honest distinction

Data residency and evidentiary value are not the same thing.

Both matter. Each answers a different question, and they are not interchangeable.

Data residency

The Mexican IP evidences where from

Mail leaves from OCI mx-monterrey-1 with a fixed egress IP and its own HELO. That evidences where it is sent from and where the evidence resides. It is a contractual and regulatory argument. It is not proof of the message.

Evidentiary value

The NOM-151 certificate evidences what and when

Evidentiary value comes exclusively from the NOM-151 preservation certificate issued by PSC Codex over the tree root. It is what a third party checks during verification.

See the full chain with a message of yours.

In the demo: the send, both captures and the offline verification of the proof bundle.

Book a demo