Proof of delivery report

Introduction

Zivver provides proof of delivery for Zivver messages in the form of a proof of delivery report which you can obtain using the Zivver WebApp or the Zivver Office Plugin.

The Proof of delivery report has two 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 will also show if the message was opened or not.

For the report to be available, proof of delivery must be turned on for the organisation.

Content of the proof of delivery report

The proof of delivery report is build up out of three main sections:

  1. Message details (per message)
  2. Summary (per recipient)
  3. Detailed event log (per recipient)

Message details

The message details section gives an overview of the of the main attributes of the sent message, namely: message ID, from, to, subject and 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 and also provides an overview of the relevant events resulting in this status. Each event has an event ID that can be used to find the event in the ‘Detailed event log’ section of the proof of delivery report. The timestamp represents the moment the event was logged and is displayed in UTC.

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 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.

Detailed event log

The detailed event log section gives a more extensive overview of the events that have 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.

Was this article helpful?

thumb_up thumb_down