Read receipt vs policy acknowledgement
Updated October 17, 2026
In short
- A read receipt or an open-tracking pixel records that an email client opened a message. It does not record who read it, what document version was attached or linked, or that the person agreed to anything.
- Read receipts can be declined, are often turned off by the organization, and open tracking can fire without anyone reading, so both miss people and count people who never read.
- A policy acknowledgement is an explicit confirmation by an identified person, against a named version, with a time, kept in a record that cannot be edited.
- Auditors ask for acknowledgement events, not delivery events. A folder of read receipts is usually treated as a sign of distribution at best.
A read receipt confirms that an email was opened. A policy acknowledgement confirms that a named person read a specific version of a policy and said so. The two are often treated as the same thing. In an audit they are not.
What a read receipt actually proves
A read receipt is a message an email client sends back when a message is marked as read, if the recipient's client supports it and the recipient agrees to send it. Open tracking, used by newsletter tools, is a small image that is counted when it is loaded. Either way, what is recorded is an event in an email client:
- that a message reached a mailbox
- that the message was marked as read, or that its images were loaded
- roughly when that happened
What neither records:
- who was at the keyboard, in a shared or delegated mailbox
- whether the attachment or the linked policy was opened at all
- which version of the policy the link pointed to at that moment
- that the person understood the policy or agreed to follow it
- anything about the people who never opened it, until someone goes looking
Five ways read receipts go wrong as evidence
- They can be declined. Most email clients ask before sending a receipt, and many people always say no. Some organizations turn receipts off entirely.
- They fire without reading. Preview panes mark messages as read. Some mail apps and security scanners load images automatically, which counts as an open in tracking tools.
- They do not reach the document. The receipt is about the email. The policy is an attachment or a link, and nothing records whether it was opened.
- They lose the version. A link to the intranet shows whatever is there today. A year later, nobody can say which text the person saw.
- They are scattered. Receipts land in the sender's inbox, one by one. Turning them into a list of who has and has not read version 2.1 is manual work, and it is out of date the moment it is finished.
How the common methods compare
The question an auditor asks is always the same: can you show that this person confirmed this version of this policy, and when? The table shows how far each method gets.
| Method | Named person | Policy version | Explicit action | Record you can hand over |
|---|---|---|---|---|
| Email read receipt | Mailbox only | No | No | Scattered in an inbox |
| Open tracking in an email tool | Mailbox only | No | No | A campaign report |
| Views in SharePoint or the intranet | Signed-in account | Only if versioning is kept and read back | No, a view is not a confirmation | An audit log export |
| Reply email: "I have read it" | Usually | Rarely | Yes | Scattered in an inbox |
| Spreadsheet ticked by HR | Yes | If someone types it | No, the action is by HR | Editable by anyone |
| E-signature on each policy | Yes | Yes, per document | Yes | Per envelope, not per policy over time |
| Policy acknowledgement system | Yes, identity checked | Yes | Yes | Per person, per policy, per round |
The pattern: methods built for email or file storage know about mailboxes and files, not about people confirming versions. Methods where the person acts, a reply or a signature, get the confirmation but not the overview. Comparisons with specific tools are on SharePoint vs Policy Confirm, Excel vs Policy Confirm and e-signature tools vs Policy Confirm.
What an acknowledgement records instead
An acknowledgement is recorded when the person acts, not when their mail client does. In Policy Confirm, each confirmation stores:
- the person's name and email address, after a one-time code or Microsoft sign-in
- the policy and its version number
- the date and time, and the IP address it was made from
- a confirmation ID shared by the policies confirmed together
- whether the person confirmed or signed, and their signature if they signed
- the cycle it belonged to
- for an uploaded PDF, a SHA-256 hash of the exact file, so it can be shown which document they saw
The people who did not read
The most useful thing a read receipt cannot do is tell you who has not read. Silence looks the same as a declined receipt. An acknowledgement system starts from the list of people who should confirm, so the gap is visible from day one and can be followed up.
When email is enough
Not every message about a policy needs to be evidence. A note that the canteen hours have changed does not. Email is fine for information. Acknowledgement is for policies people are expected to follow, where someone may later ask whether they knew: security, data protection, conduct, health and safety, anything in scope for an audit or a customer questionnaire.
Legal disclaimer
This page is general information, not legal advice. Requirements differ between frameworks, sectors and countries. Ask your auditor or lawyer what applies to your organization.
Frequently asked questions
Is an email read receipt valid proof that an employee read a policy?
Rarely. A read receipt shows that an email client marked a message as read. It does not show who read it, whether the attached or linked policy was opened, which version it was, or that the person agreed to follow it, and receipts can be declined or turned off.
Can open tracking in an email tool replace policy acknowledgement?
No. Open tracking counts when an image in the email loads, which some mail apps and security scanners do automatically. It can count people who never read the email and miss people who did, and it says nothing about the policy document.
Is a view log in SharePoint enough?
A view log shows that an account opened a file. It is not a confirmation by the person and usually not tied to a version you can show later. It is useful as a supplement, not as acknowledgement on its own.
What should a policy acknowledgement record contain?
The person's identity, the policy and its version, the date and time of the confirmation, how the person confirmed, and where it is stored so it cannot be changed. Many systems also record the IP address and a hash of the document.
Policy acknowledgement that fits how you work
Send policies to the right people, follow up on its own, and keep a record you can hand over.