I am a Zivver admin
Configure and manage Zivver
Why is my Zivver email or notification bouncing?
A message sent with Zivver, or a Zivver notification email, returns a bounce message. A bounce is also called a non-delivery report (NDR). This page helps you find the cause. Work through the situations below in order and stop at the first one that matches.
Overview
| Situation | Go to |
|---|---|
| A new or automated sending domain bounces with authentication required | New sending domain |
| A shared, automated, or no-reply sender bounces | Shared or automated sender |
| Only one recipient or domain is affected | Only one recipient or domain affected |
| Bounces are consistent and you use a strict outbound firewall | Strict outbound firewall |
| Several unrelated recipient domains bounce at once | Several unrelated domains affected |
| Out-of-office replies or calendar responses bounce or arrive malformed | Auto-generated email |
| The bounce concerns delivery to a Dutch healthcare partner (NTA 7516) | Cross-vendor delivery |
| You received a bounce, but the recipient opened the message | Recipient opened the message |
New sending domain
Does the bounce concern email from a new or automated sending domain? And does the bounce say authentication required? Then the domain may not be on the Zivver SMTP and SPF allowlist yet.
Solution
Contact Zivver Support and ask them to add the domain to the allowlist.
For more information, see Encryption Gateway.
Shared or automated sender
Does the bounce concern email from a shared, automated, or no-reply sender? Every From address needs an active Zivver account.
Solution
Choose one of these options:
- Create an active Zivver account for the sender.
- Exclude the sender from the mail flow rule that sends email to Zivver.
For more information, see Encryption Gateway.
Only one recipient or domain affected
Is only one recipient or domain affected, while all other email is delivered? Then the cause is very likely on the recipient’s side. For example, the recipient’s spam filter, secure email gateway, geo-IP rule, or reputation service may temporarily block Zivver.
Solution
Ask the IT department of the recipient to allowlist:
- the domain
zivver.com - the email address
noreply@zivver.com - the Zivver sending servers, by using the SPF record
include:_spf.zivver.com
For more information about the Zivver SPF record, see Send Zivver mails from your own domain.
Strict outbound firewall
Are the bounces consistent, and does your organization use a strict outbound firewall? Your firewall may block the server that your mail server contacts to check certificate revocation (CRL or OCSP) during the TLS handshake. When this check times out, your own mail server can refuse the connection.
Diagnose
Have your administrator check the firewall logs for blocked or timed-out connections to the CRL or OCSP server of the certificate authority.
Solution
Allow outbound traffic to the CRL and OCSP servers of the certificate authority.
Several unrelated domains affected
Do bounces hit several unrelated recipient domains at the same time? A third-party reputation service may have temporarily listed the sending IP addresses of Zivver. The incident is on the Zivver side. You cannot solve it with an allowlist per domain.
Solution
Contact Zivver Support to confirm the incident and to request delisting.
Auto-generated email
Do auto-generated messages, such as out-of-office replies or calendar responses, bounce or arrive malformed? And are these messages sent through the Encryption Gateway?
The Encryption Gateway is not a transparent relay. It always rebuilds the original message as a Zivver notification. This removes or misaligns the original DKIM signature. A mode that preserves the original DKIM signature does not exist.
Solution
Exclude auto-generated message types from the Encryption Gateway mail flow rule. Do not try to preserve the original signature.
For more information, see Encryption Gateway.
Cross-vendor delivery
Does the bounce concern delivery to a recipient through an NTA 7516 interoperability partner, such as Zorgmail? Your own Zivver mail flow rule (Zivver Relay) may have a higher priority than the rule of the partner. Email then leaves through the wrong outbound IP address and fails the SPF check of the recipient.
Diagnose
Check the order of your transport rules. Does your own Zivver rule come before the rule of the interoperability partner?
Solution
Change the order of your transport rules, so that the rule of the interoperability partner has a higher priority than your own Zivver rule.
Recipient opened the message
Did you receive a bounce, but does the recipient confirm that the message opened fine? The bounce is expected. It applies to the separate notification email, not to the encrypted message itself.
Solution
No action is needed.
Still need help?
Does none of the situations above solve the problem? Contact Zivver Support and include this information in your request:
- The full bounce message (NDR), including the error code.
- Does the problem occur for one recipient, one domain, or several domains?
- Do you send with a Zivver client, the DLP Gateway, or the Encryption Gateway?
- Which steps from this page did you try, and what was the result?