I have a Zivver account
User manuals and reference documentation
Proof of delivery report overview
Introduction
Zivver provides a proof of delivery report of Zivver messages. You can get such report with the Zivver WebApp or the Zivver Office Plugin.
The Proof of delivery report has these main purposes:
- Inform the sender of a message what the status is of the delivery of their (notification) message.
- Provide the sender of a message with detailed information on the delivery process of their message
In some cases, the report shows also whether the recipient opened the message or not.
To make the report available, the administrator must enable the proof of delivery for the organization.
Content of the proof of delivery report
The proof of delivery report consist of these main sections:
- Message details (for each message)
- Summary (for each recipient)
- Detailed event log (for each recipient)
Message details
The message details section gives an overview of the main attributes of the sent message.
- message ID
- from
- to
- subject
- attachments
| Message ID | The internal message ID that is used on the Zivver platform to identify the message. |
|---|---|
| From | Email address of the sender of the message. In case the message was send via a delegate account of functional mailbox the email address of the delegate account or functional mailbox will be shown here |
| To | Email addresses of the recipients provided in the ‘to’, ‘cc’ and ‘bcc’ fields of the send message. When a message is sent via Zivver, all the recipients are placed in the same conversation and therefore there is no distinction between recipients in the ‘to’, ‘cc’ and ‘bcc’ fields of the original message. |
| Subject | The subject line as provided in the send message |
| Attachments | The attachments that were attached to the message. Each attachment is displayed as the combination of the attachment name and the internal Zivver attachment UUID. |
Summary
The summary section displays the ‘message opened’ status for a recipient of the message. This section also shows an overview of the relevant events before this status. Each event has an event ID that you can use to find the event in the ‘Detailed event log’ section of the proof of delivery report. The timestamp in UTC represents the moment the event was logged.
The ‘message opened’ status reflects the situation that the Zivver platform has successfully decrypted the Zivver conversation of which the message is a part of, for a recipient. The ‘message opened’ status of a Direct Delivery email cannot be verified, as it is delivered directly to the recipient’s mail server. These are not opened via the Zivver WebApp. These therefore receive the status ‘Unknown’, unless the email has been bounced, in which case it receives the status “No”.
The table below lists the possible events that can be displayed in the summary section of the proof of delivery report:
| Message created by {0} | Reflects the situation that a new message has been created on the Zivver platform by the sender. |
|---|---|
| Failed to deliver email | Reflects the situation where the email (either a notification email or a ‘Direct Delivery’ email) could not be delivered to the mail server of the recipient. |
| Successfully sent email to {0} | Reflects the situation where the email (either a notification email or a ‘Direct Delivery’ email) was delivered to the mail server of the recipient. |
| Asynchronous bounce received from {0} | Reflects the situation where the mail server of the recipient initially reported back that the email (either a notification email or a ‘Direct Delivery’ email) was delivered, but then later on reports back that the email was not delivered. Since this event might happen somewhat after the initial sending of the email, this is called an ‘asynchronous’ bounce. |
| Message opened by {0} | Reflects the situation that the Zivver platform has decrypted the Zivver conversation of which the message is a part of, for a recipient. |
| Message decrypted for ‘Direct Delivery’ | Reflects the situation that the Zivver platform has decrypted the message before sending so that the message can be provided as payload for the ‘Direct Delivery’ email. Go here to read more information on ‘Direct Delivery’ emails. This does NOT necessarily mean that the recipient has opened the message. It only means the message was sent as a decrypted payload with the ‘Direct Delivery email to the recipient. The recipient does not need to perform any extra actions (for example, an extra verification step via SMS code) to decrypt the original message. |
| Email relayed by recipient mail server | Reflects the situation that the mail server of the recipient relayed the message to a third party system that does not generate Delivery Status Notifications (DSN) for successful delivery. The Zivver platform receives a DSN with status “relayed”. |
Detailed event log
The detailed event log section gives a more extensive overview of the events that occurred in the lifecycle of the message.
There is more detail in the type of events (for example, there are also events listed about the conversation in this section) as well as more detail in the level of information about events themselves (this is mostly the case for events that relate to sending an email to the mail server of the recipient). 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 situation that has occurred. The possible values for these events are listed below the table.
| Message | Description | Possible values |
|---|---|---|
| Verification method {0} set by {1} | Reflects the situation that a verification method has been set by the sender. This is the verification method that the recipient should use when they would like to access the message. | {0} verification method can be one of: SMS / Password / Email / Zivver account |
| Message created by {0} | Reflects the situation that a new message has been created on the Zivver platform by the sender. | |
| Notification email with ID {0} internally queued for delivery | Reflects the situation 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} | Reflects the situation 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} | Reflects the situation that the email (either a notification email or a ‘Direct Delivery’ email) could not be put in transit internally on the Zivver platform. Possible reasons are: suspended account silent notifications enabled This recipient has a Zivver account and for this account the setting is enabled that the recipient does not want to receive notification emails. recent bounce Zivver has detected that a previous email to this email address has bounced recently. In this situation Zivver will not try to send another email to prevent that Zivver will be classified as a sender of spam mail. generic EXIM exception There is something wrong with the mail server of Zivver. | |
| Failed to deliver email to {0} with security level {1}. Remote MTA: {2}. Status: {3}. Reason: {4}. | Reflects the situation where the email (either a notification email or a ‘Direct Delivery’ email) could not be delivered to the mail server of the recipient. | |
| Successfully sent email to {0} with security level {1}. Remote MTA {2}. | Reflects the situation where the email (either a notification email or a ‘Direct Delivery’ email) was delivered to the mail server of the recipient. | |
| Asynchronous bounce received. Failed to deliver email to {0}. Remote MTA: {1}. Status: {2}. Reason: {3}. | Reflects the situation where the mail server of the recipient initially reported back that the email (either a notification email or a ‘Direct Delivery’ email) was delivered, but then later on reports back that the email was not delivered. Since this event might happen somewhat after the initial sending of the email, this is called an ‘asynchronous’ bounce. | |
| {0} was successfully verified via verification method {1} | Reflects the situation where a recipient has successfully verified themselves via the verification method that was setup by the sender of the message. | |
| {0} has indicated to be unable to access this message with verification method {1} | Reflects the situation that the recipient seems to be unable to provide the requested verification method. This can happen for example when a guest recipient doesn’t know the password anymore that is required to fill in when trying to access the Zivver message. | |
| Recipient verification method changed to {0} by {1} | This reflects the situation where the sender of the message has changed the required verification method to access the message from A to B. For example, from ‘SMS’ to ‘Password’. | |
| Message opened by {0} | Reflects the situation that the Zivver platform has decrypted the Zivver conversation of which the message is a part of, for a recipient. | |
| Message decrypted for ‘Direct Delivery’ | Reflects the situation that the Zivver platform has decrypted the message before sending so that the message can be provided as payload for the ‘Direct Delivery’ email. Go here to read more information on ‘Direct Delivery’ emails. This does NOT necessarily mean that the recipient has opened the message. It only means the message was sent as a decrypted payload with the ‘Direct Delivery email to the recipient. The recipient does not need to perform any extra actions (for example, an extra verification step via SMS code) to decrypt the original message. | |
| 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} related 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 |