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.

Note
Does the bounce show a specific error code? Then also see Bounce 5.0.0 Unable … diagnostic code or Bounce 5.3.0 Unable … delivered; 5.3.0.

Overview

SituationGo to
A new or automated sending domain bounces with authentication requiredNew sending domain
A shared, automated, or no-reply sender bouncesShared or automated sender
Only one recipient or domain is affectedOnly one recipient or domain affected
Bounces are consistent and you use a strict outbound firewallStrict outbound firewall
Several unrelated recipient domains bounce at onceSeveral unrelated domains affected
Out-of-office replies or calendar responses bounce or arrive malformedAuto-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 messageRecipient 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?