Introduction

This guide explains when to use Zivver Encryption Gateway and how to set it up.

Zivver Encryption Gateway uses Microsoft Exchange (Server and Online) or Google Workspace mail flow rules to enable secure delivery of selected messages. It is also possible to connect an external application directly to the Zivver SMTP Gateway to securely deliver all messages sent from that application.

Use Zivver Encryption Gateway within your organization to securely deliver messages when:

1. A specific (word in the) subject is used:

   • For example, when your organization wants employees to send secure messages regardless of the device and/or application they use. This includes scenarios such as using a mail app on a mobile device for which no Zivver client is currently available.

2. A message and/or an attachment has a certain Sensitivity Label applied (Microsoft Exchange only):

   • For organizations using Microsoft Sensitivity Labels to help employees comply with information protection policies.

3. A specific email address is used as the sender (Microsoft Exchange only):

   • When a specific application automatically sends messages that must be delivered securely and uses a fixed email address as the sender (From:).

4. A specific application is used to send messages:

   • When all messages from a specific application must be delivered securely and are sent directly from that application.

Requirements

To implement Zivver Encryption Gateway, your organization must meet the following requirements:

• Microsoft Exchange (Server or Online) is used when messages need to be securely delivered in the following cases:
  • A specific (word in the) subject is used.
  • A specific email address is used as the sender.
• Microsoft Exchange Online (Office 365) is used when messages need to be securely delivered based on a Sensitivity Label.
  • Microsoft Sensitivity Labels are only available in Office 365 with specific Microsoft licenses.
• You do not use a Secure Email Gateway (SEG).
  • Exceptions apply if the SEG supports a connection with:
    • Host name: smtp.zivver.com
    • Port: 25 or 587
    • Security: TLS 1.2 with STARTTLS
  • The connection must be authenticated via:
    • SMTP credentials, or
    • SPF configured for outbound messages.
• Google Workspace is used when messages need to be securely delivered based on a specific (word in the) subject.
• A different email server is used.
  • A connection must be configured with:
    • Host name: smtp.zivver.com
    • Port: 25 or 587
    • Security: TLS 1.2 with STARTTLS
  • The connection must be authenticated via:
    • SMTP credentials, or
    • SPF configured for outbound messages.
• There must be an active Zivver account for the sender’s email address (From:).
• The Zivver DNS settings must be implemented. This ensures that Zivver can send messages on behalf of the domain(s) your organization uses.

Limitations

Be aware of the following limitations when using Zivver Encryption Gateway:

• Zivver’s Data Loss Protection (DLP) does not apply to messages sent via Zivver Encryption Gateway. You can only use Zivver’s DLP when sending a message with a Zivver client (integration) or Zivver DLP Gateway.
• If a mail flow rule in Microsoft Exchange (or a similar functionality in another email server or Secure Email Gateway) is misconfigured or disabled, the message may not be delivered or may be sent as a regular email.
• Only when a recipient receives a notification message and replies through the Zivver Guest Portal, the original sender will receive the reply securely via Zivver. If the recipient replies to a message delivered by Zivver using an alternative delivery method, it depends on the recipient’s email server how that reply is secured.
• When the original sender replies to a reply from the recipient, a new Zivver conversation will be created.

Implement Zivver Encryption Gateway

Zivver Encryption Gateway is implemented in your organization’s email server, Secure Email Gateway (SEG), or any other application that sends email. To use Zivver Encryption Gateway, outbound email must be 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 using the following specifications:

• Host name: smtp.zivver.com
• Port: 587
• Security: TLS 1.2 with STARTTLS
• Authentication is done by either:
  • Providing SMTP credentials generated by a Zivver admin in the Zivver Admin Panel
  • 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 which outbound messages are relayed to Zivver’s SMTP Gateway and which ones are not. For example, you can exclude messages to certain domains. For more information about how to filter those sent messages, refer to third-party documentation. This can be:

• Your email server
• Your Secure Email Gateway (SEG)
• Your sending application

Or refer to the chapters below for more information about how to filter out messages in Exchange.

Implement Encryption Gateway in Microsoft Exchange

This chapter describes how to implement Encryption Gateway in Microsoft Exchange.

With the implementation of Encryption Gateway in Microsoft Exchange, you can securely deliver messages when:

• A specific (word in the) subject is used.
• A message and/or an attachment has a certain Sensitivity Label applied (Exchange Online only).
• A specific email address is used as the Sender.

To implement Encryption Gateway in Microsoft Exchange, these changes are necessary:

• Create an Accepted Domain (Exchange On-premise only).
• Create a Contact (Exchange On-premise only).
• Create a Connector.
• Create a Rule.

Create an Accepted Domain (Exchange On-premise only)

Please follow the instructions in Create an accepted domain in Exchange on premise to create an Accepted Domain in Exchange On-premise.

Create a Contact (Exchange On-premise only)

Please follow the instructions in Create a contact in accepted domain to create a contact in Exchange On-premise.

Create a Connector

Encryption Gateway uses a Connector to submit sent messages to the Zivver SMTP Server.

Before you start creating a connector, please send an email to enterprise@zivver.com to request your domain to be added to the Zivver domain allowlist. This is needed to be able to make a connection from Microsoft Exchange Online to the Zivver SMTP Server.

With Microsoft Exchange, an outbound message can be processed only by one Connector. Therefore, know in advance which Connectors are configured in Microsoft Exchange Online. It might not be possible to implement Encryption Gateway if it is required that a different specific Connector also processes the sent messages. If this is the case or if you need help, send your use case to enterprise@zivver.com.

Please read Create a connector in Exchange Online for the steps to create a Connector in Microsoft Exchange Online.

Please read Create a connector in Exchange On-premise for the steps to create a Connector in Microsoft Exchange On-premise.

Create a Rule

With a Mail Flow Rule, you can filter sent messages on:

• A specific (word in the) subject is used.
• A message and/or an attachment has a certain Sensitivity Label applied (Exchange Online only).
• A specific email address is used as the Sender.

Once a message has been filtered out, it needs to be submitted to the Zivver SMTP Server to be able to deliver it securely to the recipient. Unfiltered messages will be delivered unsecured, as a regular email.

The pages below describe how to:

• Create an Encryption Gateway Rule in Exchange Online for a trigger word.
• Create an Encryption Gateway Rule in Exchange Online for a Sensitivity Label.
• Create an Encryption Gateway Rule in Exchange Online for a specific sender.
• Create an Encryption Gateway Rule in Exchange On-premise for a trigger word.
• Create an Encryption Gateway Rule in Exchange On-premise for a specific sender.

Implement Encryption Gateway in Google Workspace

This chapter describes how to implement Encryption Gateway in Google Workspace.

With the implementation of Encryption Gateway in Google Workspace, you can securely deliver messages when:

• A specific (word in the) subject is used.

To implement Encryption Gateway in Google Workspace, these changes are necessary:

• Create a connector.
• Create a rule.

Create a connector

Encryption Gateway uses a connector to submit sent messages to the Zivver SMTP Server.

Before you start creating a connector, please send an email to enterprise@zivver.com to request your domain to be added to the Zivver domain allowlist. This is needed to be able to make a connection from Google Workspace to the Zivver SMTP Server.

Please read Create a connector in Google Workspace for the steps to create a connector in Google Workspace.

Create a Rule

With a Mail Flow Rule, you can filter sent messages on:

• A specific (word in the) subject is used.

Once a message has been filtered out, it needs to be submitted to the Zivver SMTP Server to be able to deliver it securely to the recipient. Unfiltered messages will be delivered unsecurely, as a regular email.

The page below describes how to:

• Create an Encryption Gateway Rule in Google Workspace for a trigger word.

Test the configuration

After the connector and the rule are configured in Google Workspace, you can follow the steps below to test if the configuration is working.

1. Draft a new email.
2. Add a recipient.
3. Enter the word that you chose so the mail is sent via Zivver (e.g. Encrypt or Secure email) in the subject.
4. Add some text in the body of the email.
5. Send the email.
6. Validate if the email arrives as a Zivver email.

Default behavior

Every email submitted to Zivver Encryption Gateway 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 this order of priority:

¹ 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 the Zivver SMTP Gateway, you can (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 ‘sharedAccessCode’, 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 sharedAccessCode 135789
zivver-access-right: recipient4@domain.com sharedAccessCode 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’ is the minimum version of Transport Layer Security (TLS)
• ‘auth’ is the minimum level of recipient mail server authentication

Zivver currently supports the following values:

The header option and selected values should be separated by spaces. For example, a complete header would look as follows:
zivver-direct-delivery: tls tls1.2 auth certificate-validation

Note

The specified values are minimum values. 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:

See the full table with explanations of each verification method in the ‘default behavior’ section above.

Note

NTA 7516 (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 notification message.

Explicitly fall back to email verification

When direct delivery with the specified minimum level of transport security is not possible, Zivver falls back to the default behavior. See above. There is one exception: By default, Zivver prevents falling back to email verification if the email verification access code goes through a connection that does not have the minimum level of transport security.

You can override this default by including this custom email header and value:
zivver-minimum-recipient-verification: verification-email

Only when this header is included with the above value, Zivver enables falling back to email verification. If the header is included but the value is missing or invalid, Zivver prevents falling back to email verification. If falling back to email verification is not permitted and there is no other verification method available, Zivver returns to the sender a failed delivery status in a notification.

Attachment handling for direct delivery messages

When an email is directly delivered to the recipient(s), attachments smaller than 10MB will be added to the message as regular attachments. Attachments larger than 10MB will be added as secure download links to avoid failed deliveries.

Downloading the attachment via the secure download link requires 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 possible: the message has been directly delivered, which means the required level of transport security was met.

Note

A secure download link remains valid. When a recipient requests an access code via email, Zivver does not re-check if the recipient mail server meets the minimum level of transport security that was required for delivery of the original message.