Configuring Zimbra in dual stack ip4/ip6 mode

In this article you will learn how to set-up Zimbra in dual-stack IP mode.


First install Zimbra using ipv4 only mode. You can check the current Zimbra IP mode by running the following command as the user`zimbra`:

zmprov gs `zmhostname` zimbraIPMode

Then verify if all entries required all present in /etc/hosts file. Here is an example:                                       localhost.localdomain   localhost
:: 1                                            localhost.localdomain   localhost                             mail3
2603:c020:400d:567e:aa22:ab12:1234:2a34 mail3

Please make sure the localhost entries are as above for both ip4 and ip6 on your system before continuing!

In this example the server name is, replace above example with your own domain name. For ip4 the server address for (mail3) your server can be the external IP or the LAN IP if you are in a NAT environment. For ip6 the server address for (mail3) your server should be the external IP in 99% of the cases.

Enable Zimbra in dual stack mode

Run the following command as the user zimbra:

sudo su - zimbra
zmprov ms `zmhostname` zimbraIPMode both

zmiptool can take a bit of time. If zmiptool does not return any error, restart the Zimbra using:

zmcontrol restart

In case zmiptool does return errors, fix them before restarting Zimbra.

Update zimbraMailTrustedIP

After adding ip6 make sure to update the zimbraMailTrustedIP setting see:

Enclose zimbraMailTrustedIP in square brackets (eg. [1a01:2300:1f1:3:0:0:ffa:123]) the ipv6 address getting enclosed in zimbraMailTrustedIP should be in long format divided into 8 parts separated by colon. (eg. 1a01:2300:1f1:3::ffa:123 should be written like [1a01:2300:1f1:3:0:0:ffa:123]). The IPv6 addresses can be copy/pasted directly from mailbox.log.


If you use DNSMASQ or any other DNS cache on the Zimbra system, you need to restart DNSMASQ after changing /etc/hosts file using:

systemctl restart dnsmasq

2 Responses to Configuring Zimbra in dual stack ip4/ip6 mode

  1. Rainer December 6, 2023 at 9:10 AM #

    It should be noted that AFAIK there are no RBLs for IPv6-land (and likely never will be, due to the size of the pool, which is kind of obvious if you think about it…).

    As such, the only way to combat spam from IPv6 land apart from content analysis is to use post screen and hard-enforce SPF and DKIM rules (and thus make sure every domain you host has those configured correctly).

    Maybe somebody who actually has an IPV6-enabled mailserver can comment on the amount of spam they get these days?

  2. Robert December 19, 2023 at 2:15 AM #

    Unfortunately it is not possible to configure Zimbra completely dualstack, because only the setting ‘zimbraMailTrustedIP’ supports IPv6 addresses, while the setting ‘zimbraHttpThrottleSafeIPs’ does not.

    Speaking wearing my hat as an administrator running a dualstacked mail server for 20+ years:

    There are (common) RBLs with proper IPv6 support (for years already).

    Thinking about the huge amount of IPv6 addresses in literal IP addresses is unfortunately IPv4-only mindset, but does not pay attention to the IPv6 address and subnet design.

    For IPv6 a common blocking size at RBLs is a /64 subnet – or, if the provider documents it publicly in e.g. an RDAP/WHOIS database, another smaller or larger prefix. Note that a /64 is the minimum size recommented for subnets by the Regional Internet Registries, such as e.g. RIPE, ARIN. Blocking a /64 subnet should usually not affect more than one customer, which sounds acceptable for spam senders.

    Regarding spam on IPv6-enabled mail servers: While there is indeed spam nowadays as well, it usually comes mostly from huge cloud providers such as Google or Outlook freemail accounts, way less from abused self-managed mail servers. But this is actually not different than for IPv4-only mail servers, because also there Google and Outlook freemail accounts are a large source of spam which needs to be catched using content-filters, not on an IP source address base.

Leave a Reply

Copyright © 2022 Zimbra, Inc. All rights reserved.

All information contained in this blog is intended for informational purposes only. Synacor, Inc. is not responsible or liable in any manner for the use or misuse of any technical content provided herein. No specific or implied warranty is provided in association with the information or application of the information provided herein, including, but not limited to, use, misuse or distribution of such information by any user. The user assumes any and all risk pertaining to the use or distribution in any form of any subject matter contained in this blog.

Legal Information | Privacy Policy | Do Not Sell My Personal Information | CCPA Disclosures