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.

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 the PSC 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, offline, with the CLI. The certificate itself is backed by the PSC that issued it.

    mailack-verify · no network

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 the PSC; 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 the PSC
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 a network.

Evidence is kept in Object Storage with retention and bucket lock. The proof bundle is verified with the CLI, 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 the PSC

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.
Offline verification
GET /v1/messages/{id}/proof-bundle
./bin/mailack-verify bundle.json -eml mensaje.eml

The CLI recomputes the hash of the .eml and rebuilds the inclusion path up to the sealed root, with no network and no dependence on mailack. The certificate is checked against the PSC that 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 the PSC 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