I have a Zivver account
User manuals and reference documentation
Proof of Delivery/Receipt report overview
Note
InfoIntroduction
Zivver provides a Proof of Delivery report for Zivver messages. You can generate this report using the Zivver WebApp or the Zivver Office Plugin.
The Proof of Delivery report serves the following main purposes:
- Inform the sender about the delivery status of their (notification) message.
- Provide detailed information to the sender about the delivery process of their message.
For messages that are not sent as a Direct Delivery email, the report also shows the status of the message opened by the recipient. This status is determined by the Zivver platform when the recipient successfully decrypts the Zivver conversation that the message belongs to.
NoteContent of the proof of delivery report
The proof of delivery report consists of the following main sections:
- Message details (per message)
- Summary (per recipient)
- Detailed event log (per recipient)
Message details
The message details section provides an overview of the main attributes of the sent message.
- Message ID
- From
- To
- Subject
- Attachments
- Timestamp
| Attribute | Description |
|---|---|
| Message ID | The internal message ID used on the Zivver platform to identify the message. |
| From | Email address of the sender. If the message was sent via a delegate account or functional mailbox, the email address of the delegate account or functional mailbox is shown here. |
| To | Email addresses of the recipients listed in the ‘To’ and ‘Cc’ fields of the sent message. When a message is sent via Zivver, all recipients are included in the same conversation, so there is no distinction between recipients in the ‘To’ and ‘Cc’ fields. |
| Subject | The subject line as provided in the sent message. |
| Attachments | The files attached to the message. |
| Timestamp | Date and time when the message was sent in the UTC time zone. |
Summary
The summary section shows the ‘message opened’ status for each recipient of the message. It also provides an overview of the relevant events that occurred prior to this status. Each event has an event ID that can be used to locate the event in the ‘Detailed event log’ section of the Proof of Delivery report. The UTC timestamp indicates when the event was logged.
NoteThe ‘message opened’ status cannot be verified for Direct Delivery emails, as they are delivered directly to the recipient’s mail server and not opened via the Zivver WebApp. These emails are therefore assigned the status ‘Unknown’, unless the message has bounced — in that case, the status is ‘No’.
The table below lists the possible events that can appear in the summary section of the proof of delivery report:
| Event | Description |
|---|---|
| Message created by {0} | Indicates that a new message was created on the Zivver platform by the sender. |
| Failed to deliver email | Indicates that the email (either a notification or Direct Delivery email) could not be delivered to the recipient's mail server. |
| Successfully sent email to {0} | Indicates that the email (either a notification or Direct Delivery email) was successfully delivered to the recipient's mail server. |
| Asynchronous bounce received from {0} | Indicates that the recipient's mail server initially confirmed delivery of the email, but later reported it as undelivered. Since this may happen after the email was sent, it is referred to as an 'asynchronous' bounce. |
| Message opened by {0} | Indicates that the Zivver platform has decrypted the Zivver conversation that the message is part of, for a recipient. |
| Message decrypted for ‘Direct Delivery’ | Indicates that the Zivver platform decrypted the message before sending it, so it could be included as the payload in a Direct Delivery email. This does NOT necessarily mean the recipient opened the message — it only confirms that the message was sent as a decrypted payload. The recipient does not need to take additional steps (e.g. verify via SMS) to decrypt the message. |
| Email relayed by recipient mail server | Indicates that the recipient’s mail server relayed the message to a third-party system that does not generate Delivery Status Notifications (DSNs) for successful delivery. The Zivver platform received a DSN with the status "relayed". |
Detailed event log
The detailed event log section provides a more comprehensive overview of the events that occurred during the lifecycle of the message.
There is more detail in the types of events (for example, events about the conversation are also listed in this section) as well as in the level of information provided about the events themselves (this is mostly the case for events related to sending an email to the recipient’s mail server). For each event, the ID, event description, and timestamp in UTC are listed.
The table below lists the possible events that can be displayed in the detailed event log section of the Proof of Delivery report. Some events include dynamic values that depend on the specific situation. The possible values for these events are listed below the table.
| Event | Description | Possible values |
|---|---|---|
| Verification method {0} set by {1} | Indicates that a verification method has been set by the sender. This is the method the recipient should use when accessing the message. | {0} verification method can be one of: SMS / Password / Email / Zivver account |
| Message created by {0} | Indicates that a new message has been created by the sender on the Zivver platform. | |
| Notification email with ID {0} internally queued for delivery | Indicates that the notification email is in transit internally on the Zivver platform. | |
| ‘Direct Delivery’ email with ID {0} internally queued for delivery with minimum required security level {1} | Indicates that the ‘Direct Delivery’ email is in transit internally on the Zivver platform. | {1} Possible security levels can be one of: None / PKIX / DANE |
| Failed to queue email for delivery because of {0} | Indicates that the email (either a notification or ‘Direct Delivery’ email) could not be put in transit on the Zivver platform. | {0} Possible reasons include: suspended account, silent notifications enabled, recipient does not want to receive notification emails, recent bounce, or generic EXIM exception. |
| Failed to deliver email to {0} with security level {1}. Remote MTA: {2}. Status: {3}. Reason: {4}. | Indicates that the email (either a notification or ‘Direct Delivery’ email) could not be delivered to the recipient's mail server. | |
| Successfully sent email to {0} with security level {1}. Remote MTA {2}. | Indicates that the email (either a notification or ‘Direct Delivery’ email) was successfully delivered to the recipient's mail server. | |
| Asynchronous bounce received. Failed to deliver email to {0}. Remote MTA: {1}. Status: {2}. Reason: {3}. | Indicates that the recipient's mail server initially reported that the email (either a notification or ‘Direct Delivery’ email) was delivered, but later reported a failure. This is known as an ‘asynchronous’ bounce. | |
| {0} was successfully verified via verification method {1} | Indicates that the recipient has successfully verified themselves using the verification method set up by the sender. | |
| {0} has indicated to be unable to access this message with verification method {1} | Indicates that the recipient is unable to provide the requested verification method. This can occur when a guest recipient forgets the password required to access the message. | |
| Recipient verification method changed to {0} by {1} | Indicates that the sender has changed the required verification method to access the message from one method to another (e.g., from ‘SMS’ to ‘Password’). | |
| Message opened by {0} | Indicates that the Zivver platform has decrypted the Zivver conversation containing the message for the recipient. | |
| Message decrypted for ‘Direct Delivery’ | Indicates that the Zivver platform decrypted the message before sending it, so it could be used as payload for the ‘Direct Delivery’ email. This does NOT necessarily mean that the recipient opened the message. It only means the message was sent as a decrypted payload with the ‘Direct Delivery’ email. | |
| Email relayed or gatewayed | Shows the official RFC explanation that the email was “relayed or gatewayed into an environment that does not accept responsibility for generating delivery status notifications upon successful delivery”: Email to {0} with security level {1} relayed or gatewayed into an environment that does not accept responsibility for generating delivery status notifications upon successful delivery. | {1} Possible security levels can be one of: None / PKIX / DANE |