Approvals
An email “yes” is easy to give and hard to prove.
Most businesses approve payments, deployments and changes by email: “please confirm”, “yes, go ahead”. When something goes wrong, that reply is the evidence. This page is for a business deciding how people approve things, and for whoever writes the contract that says how.
Side by side
What each one proves.
Who answered?
An email “yes”
Whoever sent it from, or as, that address. A DMARC pass confirms only the domain: not the part before the @, not the person, and not the name shown beside the address.
A Proof Holdings approval
Whoever opened the one-time link sent to the Telegram or WhatsApp account the business set up. Like an email, the link can be forwarded: the record shows a decision made through that link, not who held it, and not legal identity.
Could it come from a look-alike?
An email “yes”
Yes. A reply from a domain one letter away from the real one can pass DMARC, which does not address look-alike domains.
A Proof Holdings approval
A look-alike can still send a link. What it cannot produce is a record for your account: each record is signed with our key and carries the id of the account that asked, so check both.
What exactly was approved?
An email “yes”
Whatever the thread seemed to say. A reply can point to an earlier message by its id, but nothing in DKIM ties the reply to that message’s exact content.
A Proof Holdings approval
The record carries a SHA-256 hash of the exact encrypted request. Anyone holding that request can hash it and compare: the record was made for it and for nothing else.
Yes or no?
An email “yes”
"Ok", "sounds good", "go ahead" — a person has to read the meaning into it.
A Proof Holdings approval
When a person approves or denies, the record carries that signed decision and the time it was made. A request nobody answers is denied automatically and gets no record.
Who can read the request?
An email “yes”
Everyone the thread reaches and, unless the email is end-to-end encrypted, the mail servers it passes through.
A Proof Holdings approval
Only someone holding a key that opens it: the business and the approvers it enrolled. Requests are encrypted before they reach us, and we refuse any that are not.
Who can check it later?
An email “yes”
Someone with access to a copy of the message, in a mailbox, an archive or a backup.
A Proof Holdings approval
Anyone, without an account: against our published keys, or by asking POST /api/v1/proofs/validate whether it still stands.
What if an account is closed?
An email “yes”
The evidence is whatever copies survive: in the mailbox, with other recipients, or in archives.
A Proof Holdings approval
If the business deletes its Proof Holdings account, a decision already made stays valid until its token expires.
How long can a record be checked?
A record can be checked for as long as its token is valid: by default for the length of the approval window, counted from the decision, and up to 365 days when the request sets proof_expiry_days. Keep the token and the request; for evidence needed longer than that, keep them in your own records.
Is it an electronic signature?
An approval proves that someone controlled a messenger account and decided, not who they legally are. Where that places it under eIDAS is set out, with its limits, on the electronic signatures page.
For your contract
A model clause.
Paste it into an agreement that needs approvals, and replace the sentence in brackets if you agree another method.
Model clause
Approvals. Where this Agreement requires a Party's approval of a specific action, the approval is given through Proof Holdings: a one-time link to the request is delivered to the approver's Telegram or WhatsApp account, and the approver approves or denies it on the Proof Holdings approval page. [If the Parties agree another method of approval, describe it here.] Each approval or denial the approver makes produces a signed record of the decision and the time it was made, which either Party may verify against Proof Holdings' published keys or through POST /api/v1/proofs/validate for the validity period the requesting Party sets, up to 365 days. Each Party keeps the records of its decisions, together with the requests they answer, for as long as this Agreement requires records to be kept.
This clause is a starting point, not legal advice; have it reviewed for your jurisdiction.
Sources
Checked on 25 October 2026.
- RFC 9989 §2.2: DMARC acts only on exact-domain spoofing; it does not address look-alike domain names or abuse of the display name.
- RFC 9989 §2.4: Display-name attacks, and the authentication of anything other than a domain, are out of DMARC’s scope.
- RFC 9989 §4.1: The checks DMARC relies on validate only the use of a domain, not the part of the address before the @.
- RFC 6376 §1.5: A valid DKIM signature ties a message to the signing domain and says the signed content has not changed since it was signed; it asserts nothing else about the message’s end-to-end integrity.