Mail Submission

Introduction

This guide explains when to use Zivver Mail Submission and how to set it up. Zivver Mail Submission allows you to securely send messages from your mail server or any other application that supports sending emails via SMTP. There’s no Zivver client or integration needed to do so.

Requirements

To implement Zivver Mail Submission, your organization must meet the following requirements.

  • Outbound messages need to be relayed from your organization’s email server or submitted directly from other applications to Zivver’s SMTP Gateway.
  • Connect your email server or application to Zivver’s SMTP Gateway: Host name: smtp.zivver.com. Port: 587. Security: TLS 1.2 with STARTTLS. Authentication done by either:
  • Providing SMTP credentials.
  • Having SPF implemented for outbound messages.
  • There must be a Zivver account for the Sender’s email address (From:).
  • The Zivver DNS Settings need to be implemented to allow Zivver to send messages on behalf of the domain(s) that your organization uses to send messages from.
  • There’s no other third-party Secure Email Gateway (SEG) used, unless it allows outbound messages to be relayed to Zivver’s SMTP Gateway. As such Zivver Mail Submission will be the last “hop” before the message is delivered to the Recipient.

Limitations

Please be aware of the following known limitations when using Zivver Mail Submission.

  • Only when a Recipient receives a notification message and replies within the Zivver Guest Portal, the original Sender will receive this reply securely via Zivver. If the Recipient replies to a message delivered by Zivver via an alternative delivery method, it depends on the recipient’s email server how that reply is secured.
  • A reply by the original Sender to a reply received from the Recipient will cause a new Zivver conversation to be created.

Implement Zivver Mail Submission

Zivver Mail Submission is implemented in your organization’s email server, Secure Email Gateway (SEG), or any other application sending email. To make use of Zivver Mail Submission the outbound email is submitted to Zivver’s SMTP Gateway.

Connect to Zivver’s SMTP Gateway.

Connect your email server, Secure Email Gateway (SEG) or sending application to Zivver’s SMTP Gateway by using the following specifications: * Host name: smtp.zivver.com. * Port: 587. * Security: TLS 1.2 with STARTTLS. * Authentication done by either: 1. Providing SMTP credentials that are generated by a Zivver Admin in the Zivver Admin Panel. 2. Having SPF implemented for outbound messages. The Zivver SMTP Gateway will check if SPF passes and also verifies that the domain in the From header is allowed to submit messages.

Customize which outbound messages are submitted

Your organization can decide on which outbound messages are relayed to Zivver’s SMTP Gateway and which ones are not. For example, messages sent to certain domains can be excluded from submitting them to the Zivver SMTP Gateway. Please check the documentation of your email server, Secure Email Gateway (SEG) or sending application on what is possible and how to filter out those sent messages. Or see the manual about Zivver’s Custom Relay for more information on how to filter out messages.

Default behavior

Every email submitted to Zivver Mail Submission will start a new secure Zivver conversation. Emails with multiple recipients are handled in the following manner: * ‘To’ recipients and ‘CC’ recipients will become part of the same secure Zivver conversation. There is no distinction between ‘To’ and ‘CC’ recipients. * For each ‘BCC’ recipient, a separate secure Zivver conversation will be started.

Each recipient will be verified according to the most secure method available to Zivver in the following order of priority:

Order of priority Verification method Used when: Delivery method
#1 Zivver Account This method is automatically applied if the Recipient has their own Zivver account, which is protected with 2FA. Zivver message notification*
#2 NTA7516 This method is automatically applied when both the Sender and the Recipient meet the requirements of the NTA7516. Direct delivery email
#3 Custom access rights Access rights are specified in the Zivver access rights header. See below for more detail on how this can be used. Zivver message notification
#4 Transport security layer This method is applied if your organization allows transport security compliance as a recipient verification method. Direct delivery e-mail
#5 Time-based one-time passcode via sms Either the Sender or someone else within your Zivver organization could have used a shared SMS verification before for this specific Recipient. If the Recipient successfully opened that message, the same SMS verification can automatically be applied to this new message to the same Recipient. Zivver message notification
#6 Access code verification Either the Sender or someone else within your Zivver organization could have used a shared Access Code before for this specific Recipient. If the Recipient successfully opened that message, the same Access Code can automatically be applied to this new message to the same Recipient. Zivver message notification
#7 Email verification Email verification is used if no other (more secure) verification method is available. Zivver message notification

*Recipients with a Zivver account will receive a Zivver message notification. If they open this notification in an email client with a Zivver client integration installed, they will see the content of the message directly within their email client. If the recipient’s domain belongs to an organization that uses Zivver and that has inbound direct delivery (IDD) enabled, the message will be directly delivered to the recipient’s inbox.

Specifying custom access rights

For every email submitted to Zivver’s SMTP Gateway, Zivver allows you to (optionally) specify the verification method and details for the recipient(s). If present, the specified verification method will be used to determine the recipient verification method in line with the order of priority described in the previous section. The verification method for a recipient can be specified using the following custom email header:

zivver-access-right

Zivver supports specification of two different recipient verification methods using this header: * SMS verification through a time-based one-time passcode * Access code verification

To specify SMS verification, the header should contain the recipient email address, followed by ‘sms’, followed by the phone number of the recipient. To specify access code verification, the header should contain the recipient email address, followed by ‘access-code’, followed by the desired access code. Zivver requires a separate header per recipient. It is possible to specify different access rights per recipient. Below is an example with multiple recipients and different access rights:

zivver-access-right: recipient1@domain.com sms +31612345678

zivver-access-right: recipient2@domain.com sms +31687654321

zivver-access-right: recipient3@domain.com access-code 135789

zivver-access-right: recipient4@domain.com access-code 246789

Specifying a preference for direct delivery

For every email submitted to Zivver’s SMTP Gateway it is possible to indicate a preference for direct delivery of the message to the recipient(s) if the receiving mail server meets a specified minimum level of transport security. This provides you with the ability to give preference to direct delivery of specific messages, even if ‘transport security compliance’ is not an enabled verification method for your organization.

If the specified minimum level of transport security is not available, Zivver will fall back to the default behavior described above.

Preference for direct delivery of the message can be indicated using the following custom email header: zivver-direct-delivery The minimum level of transport security is split into two email header options: * ‘tls’ = the minimum version of Transport Layer Security (TLS) * ‘auth’ = the minimum level of recipient mail server authentication Zivver supports the following values:

Header option Supported values Description
tls tls1.2 This enforces Transport Layer Security version 1.2.
auth certificate-validation This is a check that the recipient mail server has a valid certificate from a certificate authority (CA), and not a self-signed certificate

For example, a complete header would look as follows: zivver-direct-delivery: tls=tls1.2 auth=certificate-validation Note: the specified values are minimums. If a higher version of TLS and/or a higher level of recipient mail server authentication are possible, Zivver will apply those. If the header is present but one or both values are missing or invalid, Zivver will default to: * tls=tls1.2 * auth=certificate-validation

If this header is used, each recipient will now be verified according to the following order of priority:

Order of priority Verification method Delivery method
#1 Zivver account Zivver message notification*
#2 NTA7516 Direct delivery email
#3 Direct Delivery Direct delivery email
#4 Custom access rights Zivver message notification
#5 Transport security compliance Direct delivery email
#6 Time-based one-time passcode via SMS Time-based one-time passcode via SMS
#7 Access code verification Zivver message notification
#8 Email verification Zivver message notification

See the full table with explanations of each verification method in the ‘default behavior’ section above. Note: NTA7516 (order of priority #2) still gets precedence over the specified minimum level of transport security because Zivver always applies the highest possible level of transport security. Zivver account verification (order of priority #1) still gets precedence over the specified minimum level of transport security because Zivver currently gives precedence to the delivery preference of the recipient(‘s organization). Note: it is still possible to specify recipient access rights as described in the previous section. Those access rights would be used if Zivver falls back to a Zivver message notification.

Explicitly allow fall back to email verification

When direct delivery using the specified minimum level of transport security is not possible Zivver will fall back to the default behavior described above, with one exception: by default, Zivver will not allow falling back to email verification as the email verification access code would be sent over a connection which does not meet the minimum required level of transport security.

It is possible to override this default by including the following custom email header and value: zivver-minimum-recipient-verification: email-verification Only when this header is included with the above value will Zivver allow falling back to email verification. If the header is included but the value is missing or invalid, Zivver will not allow falling back to email verification. If falling back to email verification is not permitted and there is no other verification method available, Zivver will return a failed delivery status notification to the sender.

Attachment handling for direct delivery messages

When an email is directly delivered to the recipient(s), attachments under 10MB in size will be added to the message as a regular attachment. Attachments over 10MB in size will be added to the message as secure download links to avoid failed deliveries.

Downloading the attachment via the secure download link will require verification of the recipient. They either need to be logged in to their Zivver account or will be verified using email verification.

Email-verification in this case is always allowed: the message has been directly delivered, meaning the required level of transport security was met. Note: A secure download link stays valid. When a recipient requests an access code via email, Zivver does not check again if the recipient mail server meets the minimum level of transport security that was required for delivery of the original message.

Was this article helpful?

thumb_up thumb_down