Got an email? Verify it. Click nothing.

The problem

The advice is to never click a link in an email. A verification link contradicts that advice. And a genuine email, once copied and re-sent by a fraudster, can look like the original.

What Seal Email does

Your sending system asks Seal for one code per email and places it at the end of the message as text, never as a link, with this sentence:

Seal code: … — Verify it at seal.lifaio.com/email. Click nothing.

Your customer types Seal's address themselves, pastes the email's code, and enters their email address and personal Seal code.

Green — this email was issued by your organisation, for this address, at this time, and this is its first verification. The customer also sees a phrase, a colour and a word they chose themselves and that only they know: markers to recognise the real Seal page.

Red — do nothing with this email. The reason is shown in plain words: created for another address; already verified; too old; not authentic; organisation no longer verified.

Optionally, the customer pastes the email's original source. A program in their own browser compares the sender address and the authentication results written by their mail provider (DKIM, DMARC) with your verified domains. The source is not transmitted to Seal.

How it works — for your customer

1. Create a personal Seal code once, using your address, a phrase, a colour and a word.
2. When an email carries a Seal code, open seal.lifaio.com/email yourself. Click nothing in the email.
3. Paste the email's code, enter your personal code and your address.
4. Green: it was for you, and your markers appear. Red: do nothing; call the organisation at the number on your card.
5. To go further, paste the email's original source. Your browser checks the signature. The source is not sent.

Sending at scale — three ways to issue codes

Your Seal file is active and your sending domain is verified by DNS TXT, publishes DMARC and signs with DKIM.

Codes are valid for 72 hours by default.

• Portal — one code at a time, for a single email.
• CSV or batch API — campaigns of up to 10,000 recipients per call. Upload a CSV with one column of addresses in the portal and receive the same file with a phrase_seal column, ready to merge into your mailing tool. Or call POST /api/message-jetons. Addresses are processed in memory and then forgotten, never stored. The API never returns an address in clear text.
• Issuing key — for high-volume senders with their own sending system. Seal provides a key that signs only for your organisation. Your system computes codes locally, without an API call, using a ten-line library (Node 18+, no dependency). The key is shown once and is never stored by Seal. Reserved to paid and verified files.

Issuing key: available only to paid and verified files in workforce bands of 501 employees or more.

Two buttons in the portal, for two different situations

• Revoke the issuing key — invalidates only codes issued with that key. Codes issued by the portal or the API remain valid. For when a sending provider is compromised, not the organisation.
• Rotation — invalidates every issued code, including those issued with the key, and invalidates the key itself. For when you no longer know what is compromised.

Treat the issuing key like your DKIM key. The portal shows “key handed over on …” for as long as a key is in circulation.

Verification receipts (optional)

For any email, your organisation may request a verification receipt. The customer is informed on the verification page and decides: they tick the box or choose “always / ask me / never” when creating their personal code. If they agree, your signed webhook receives the code’s SHA-256 fingerprint, the event and the time. You alone link it to your customer; Seal receives neither name nor address in this receipt. Refusals (“presented for another address”, “already verified”) are always reported: they are fraud signals on your email, not the customer’s act. A receipt proves that an authenticated verification took place at a given time; it does not prove that the customer read, understood or accepted anything.

What it proves — and what it does not

The code proves who sent the email, to whom and when, and that it had not been verified before. With the optional signature check, it also proves the email was transmitted from your domain and not copied.

It does not prove the content of the email or that what the email asks for is legitimate. The first line of the verification page says so.

What Seal keeps

No email address. Seal keeps a keyed fingerprint of the address, the customer's markers encrypted with their personal code and unreadable by Seal, and fingerprints of already-verified codes until they expire. The personal code is stored nowhere and never sent by email. If a customer loses it, they create another by confirming their mailbox — free, with no identity check.

Languages, documentation and patents

Verification pages, help and technical documentation are available in 18 languages.

UK patents pending — including applications GB2622122.6 and GB2622135.8 of 22 September 2026 for this module.

Verification help · Technical documentation

Public presentation — “Your emails” card

Pricing

Codes are included according to your organisation’s workforce band. Seat charges remain separate from the annual licence.

Beyond the quota: blocks of 10,000 codes at 29 USD each, purchased in the portal through Stripe, with no expiration. An occasional campaign does not require moving to a higher band.

Issuing key: available only to paid and verified files in workforce bands of 501 employees or more.

The website counts the codes verified by your organisation’s customers.

The portal, CSV and batch API count every code issued against the quota. The portal shows codes used this month, codes remaining and block codes in reserve. Blocks are paid for once.