Proof of Sending · Verification
Verify a Proof of Sending
Confirm that a wemail Proof of Sending certificate is genuine and has not been altered since it was issued. Verification happens locally in your browser — only the document's fingerprint is sent to us, never the file itself.
How this document is protected
A Proof of Sending is protected by three independent layers. Each one would have to be defeated separately to pass off a fake or altered certificate.
1
Content fingerprint
What it protects: The exact message that was sent.
How: At sending time the message body is reduced to a SHA-256 fingerprint — 64 characters that change completely if a single character of the message changes. Kept attachments get their own fingerprints, which you can check on this page by choosing the file.
sha-256
2
Signed record of the facts
What it protects: Who sent it, to whom, the subject, the times and the delivery result.
How: These facts, together with the content fingerprint, are signed with a secret key held only inside wemail’s infrastructure. Every check on this page re-computes the signature; a changed fact cannot produce the same signature.
hmac-sha256
3
Registry of issued certificates
What it protects: That this exact PDF was issued by wemail.
How: When the PDF is issued, its own SHA-256 fingerprint is written to wemail’s registry. Uploading a PDF here compares its fingerprint with the registry — a byte-for-byte match proves it is the file we issued, unchanged.
append-only
How certification works
Every certified send passes through five stages, each producing evidence the next stage locks in place. Watch the pulse travel the pipeline:
✉
Message sent
Your email enters wemail over an authenticated API or SMTP session.
authenticated
#
Fingerprinted
A SHA-256 hash of the message body is computed — 64 characters unique to this exact content. Each kept attachment gets its own.
sha-256
⚿
Signed
Message ID, parties, subject, timestamps and hash are signed with a key held only by wemail.
hmac-sha256
◷
Registered
The signed record is written to a tamper-evident registry with the delivery response from the recipient server.
append-only
❏
Certificate issued
A Proof-of-Sending PDF is generated; its own fingerprint is stored so the PDF itself can be verified here.
verifiable
Why the proof cannot be spoofed
A certificate is only as strong as the attacks it survives. Here is every way someone could try to fake a Proof of Sending — and the specific mechanism that defeats each one.
Attack
Alter the certificate PDF
A party edits the Proof-of-Sending PDF — changes a date, a recipient, or the subject line — and presents the modified copy as evidence.
Why it fails
Changing even one byte of the PDF produces a completely different SHA-256 fingerprint, so it no longer matches the one recorded at issue time and verification here fails instantly.
Attack
Forge a certificate from scratch
Someone fabricates a convincing-looking certificate for an email that was never sent, copying wemail’s layout exactly.
Why it fails
The certified facts are signed with HMAC-SHA256 using a secret key that never leaves wemail’s infrastructure. Without that key it is computationally infeasible to produce a valid signature — a forged certificate has no matching registry record and an invalid signature.
Attack
Backdate or re-time a message
A sender tries to claim an email was sent earlier (or later) than it really was, e.g. to meet a contractual deadline.
Why it fails
Timestamps are recorded by wemail’s servers at the moment of acceptance and at the recipient server’s SMTP acknowledgement — not taken from the sender’s machine. They are inside the signed record, so they cannot be changed afterwards without breaking the signature.
Attack
Tamper with the registry itself
The most demanding scenario: an insider or intruder attempts to rewrite the stored evidence after the fact.
Why it fails
Registry records are written once at issue time and never updated. Each certificate can be re-verified independently by anyone holding the PDF, so a silently altered registry entry would immediately disagree with certificates already in circulation.
Using the certificate in court
The certificate is designed to answer the two questions every court asks about electronic evidence: is this record authentic, and has it been altered.
What the certificate attests
✓Content — the SHA-256 fingerprint of the exact message body that was sent, and of each attachment kept with the message.
✓Parties — the authenticated sending account and the recipient address(es).
✓Time — UTC timestamps of acceptance and of the recipient server's SMTP acknowledgement.
✓Delivery outcome — the receiving mail server's response code, recorded verbatim.
✓Integrity — a cryptographic signature over all of the above; any alteration invalidates it.
✕Not attested — that a human opened or read the message. It proves sending and hand-off, like registered mail proves posting.
EU
eIDAS framework
Under eIDAS Article 43, data sent through an electronic registered delivery service cannot be denied legal effect or admissibility solely because it is electronic. The certificate documents integrity, sending time and the recipient server's answer. wemail is not a qualified registered delivery service, so the presumptions of Article 43(2) do not apply automatically — the certificate is weighed as ordinary electronic evidence, and its strength comes from the independent checks on this page. The evidence record itself is held in the EU.
US
Federal Rules of Evidence
The certificate supports authentication under FRE 901(b)(9) (result of an accurate process) and self-authentication under FRE 902(13)–(14): records generated by an electronic process, verified by hash value, certified by a qualified person. wemail can supply the certification of its automated logging process on request.
This page explains how the evidence is constructed; it is not legal advice. Admissibility is always decided by the court — consult counsel for your specific matter.
Frequently asked questions
Need certified sending for your own mail?
Add Proof of Sending to any transactional email with one API parameter.
Trusted by leading brands
