Email verification

Purpose and scope

Allow the recipient of an email to establish, without following any link, that the message was issued by a verified organisation, was meant for them, has not already been verified, and was transmitted from a domain of the sender rather than copied. Seal establishes the sender, the recipient, the time of issue and, if the recipient asks, the transmitting domain; it establishes neither the content of the message nor the legitimacy of what it requests.

Operating principle

1. The organisation asks Seal for one code per email; the code is a signed token carrying a keyed fingerprint of the recipient’s address and the time of issue. It is placed in the email as text, never as a link.
2. The recipient creates a personal code once: address, a phrase, a colour, a word. Seal sends a confirmation code to the address; the personal code is shown once. Seal keeps neither the address nor the markers in readable form.
3. The recipient types Seal’s address themselves, pastes the code from the email, enters their personal code and their address.
4. Seal checks the signature, validity and the organisation’s standing; compares the address fingerprint; decrypts the markers with the personal code; then, and only then, marks the code as consumed and returns the organisation, subject, time of issue and markers.
5. Optional: the recipient pastes the email’s original source. A program in their browser compares the sending address and the authentication results (DKIM, DMARC) with the organisation’s verified domains. Nothing is transmitted.

Targeted threats

• Forging a code: refused by the signature (derived key, never stored).
• Redirecting a genuine code to another person: refused by the keyed fingerprint of the address.
• Replaying a genuine code to the same person: exposed by the time of issue, refused after validity, refused as already verified after the first verification.
• Copying the whole email from a stolen mailbox: the copier can neither verify nor consume the code without the personal code, and cannot produce the organisation’s domain signature.
• Counterfeit verification page: it cannot display the recipient’s phrase, colour and word.

Components and responsibilities

Data and privacy

Seal keeps a keyed fingerprint of the address (never the address), the markers encrypted with a key derived from the personal code (unreadable by Seal), and, for each verified code, a one-way fingerprint and its expiry, purged on expiry. The personal code is stored nowhere and is never sent by email. The email source pasted by the recipient does not leave their browser.

Verification receipt (optional): the organisation may seal into a code its wish to be notified of its verification. The person verifying is told before the button and decides alone (preference encrypted with their markers: always, ask me, never). Seal then sends the organisation’s signed webhook the code’s SHA-256 fingerprint, the event and the time — the organisation alone links it to its customer. Refusals “other address” and “already verified” are sent without a checkbox, since they are not the person’s act but a fraud signal on their email. Seal keeps these events 30 days, with no address or name. Verifications without a receipt are not individually identifiable, except by inference on a very small batch. A receipt attests neither reading, understanding nor consent.

Expected security properties

• No valid code can be produced without Seal’s master key.
• A code is consumed only by a verification authenticated by the personal code; any other read is pure and consumes nothing.
• A copy of Seal’s database reveals no address, no marker, no personal code.
• A key-version rotation by the organisation instantly invalidates every issued code.
• The email signature comparison is made against the domains verified by Seal, not against what the email asserts.

Limitations and assumptions

• The code proves who, to whom and when — not the text of the email nor the legitimacy of its request.
• The signature comparison relies on the Authentication-Results header written by the recipient’s provider; without it, the comparison is not possible and the page says so.
• A compromised mail account of the organisation itself produces emails signed by the organisation: that is not a copier, it is a breach at the organisation.
• A lost personal code cannot be restored; the recipient creates another, which replaces their markers.
• The attempt limit bounds the trial of personal codes without eliminating it; the code’s length and alphabet are chosen accordingly.
• The text of the email is covered by the domain’s DKIM signature, checked in the recipient’s browser when the original is pasted — Seal seals no content fingerprint, since DKIM already carries one. Seal is not a legal-evidence service: the code is consumed on first verification and nothing is retained.

Items to confirm before integration

• The organisation’s sending domain is verified at Seal and publishes DMARC; DKIM is in place.
• The sending system calls the API for each email and places the prescribed sentence at the end of the message, with no link to Seal.
• The default 72-hour validity suits the recipients’ reading cycle; otherwise, the chosen value and its justification.
• Customer-relations training: “click nothing, verify the code” is the only instruction to give.
• The message-key rotation procedure in case the sending system is compromised.
• The fallback channel told to the recipient on a red result: the number on their card or the official website.
• The list of sending domains and subdomains declared to Seal is complete.
• The chosen issuing mode: portal (one code at a time), batch or CSV (up to 10,000 codes per call), or a delegated issuing key — reserved to paid and verified files, shown once, revocable in one click without affecting portal codes.
• The band’s monthly quota (1,000 codes for 1-100, up to unlimited for 50,001+) and, if needed, blocks of 10,000 codes for US$29 with no expiry.
• The verification counter, per organisation and per month: codes turned green and genuine codes refused red (presented for another address or already verified). Two integers, no address, no code. It measures emails verified, never emails received — no pixel, no link.

Public references

• https://seal.lifaio.com/email/aide
• https://seal.lifaio.com/methode
• https://seal.lifaio.com/documentation