How to Restrict Outbound Email Relay by IP Address in Zimbra

To limit which systems can send unauthenticated outbound mail through a Zimbra MTA, set that server's zimbraMtaMyNetworks attribute to a short allowlist of trusted IP addresses or CIDR networks. Keep loopback in the list, preserve any existing trusted hosts that still need relay, and remove broad ranges you no longer intend to trust. Then reload Postfix and test both an approved source and an unapproved one.

This setting controls trusted SMTP clients that can relay without SMTP authentication. It does not block every outbound message from an authenticated Zimbra user, and it does not set the next-hop mail server. If your goal is to require authentication for roaming mail clients or to restrict particular user accounts, use the appropriate authentication or mail-policy controls instead.

What does the IP allowlist control?

Zimbra's MTA uses Postfix. In Postfix, a client whose source address matches mynetworks is treated as trusted for relay. Zimbra exposes this list through zimbraMtaMyNetworks. A listed host can submit mail for external destinations without authenticating, so each entry is a meaningful trust decision.

Do not confuse the allowlist with zimbraMtaRelayHost. The allowlist decides which SMTP clients may relay through this MTA. A relay host is the upstream server to which the MTA forwards nonlocal messages, for example when a network provider requires a smarthost. Changing one does not perform the job of the other.

Zimbra's Tech Center pages describe this attribute and the relevant commands, but some material is marked as work in progress or archive documentation. Confirm the behavior against your installed Zimbra release and deployment design before applying changes. The examples below use the Zimbra command-line tools as the zimbra service account, consistent with Zimbra's MTA guidance.

Before changing the setting

• Identify the MTA host that receives SMTP submissions from the systems you intend to allow. In a multi-MTA environment, determine which MTAs handle those connections and plan the change on each relevant server.
• Find the fixed source IP address that the MTA actually sees. If the application is behind NAT, use its public egress address, not its private LAN address. If the IP changes frequently, an IP-only allowlist will need ongoing maintenance.
• Record the current Zimbra attribute and effective Postfix value. Do not replace an existing list with only the new address until you have checked which services depend on the current entries.
• Arrange a maintenance window or change window appropriate for your mail service, and keep a rollback copy of the exact original value.

Use a single-host CIDR such as /32 for an IPv4 address. For example, 198.51.100.25/32 represents one IPv4 host; this documentation-only address is an example and must not be copied as a real server address. A broader range such as /24 trusts every address in that subnet. Do not add public networks or large provider ranges just to make a test succeed.

How to set the Zimbra relay allowlist

1. Inspect the configured and effective values

Log in to the MTA host and switch to the Zimbra service account. Replace mta.example.com with the exact server name returned by your installation's zmhostname command.

su - zimbra
zmhostname
zmprov gs mta.example.com zimbraMtaMyNetworks
postconf mynetworks

The first query reads the value stored for the Zimbra server object; postconf shows the effective Postfix setting. Save both outputs. If the LDAP attribute is unset, Postfix may be using a default, so do not assume an empty query means no trusted networks. Check the effective value and your version's configuration behavior before proceeding.

2. Build the smallest complete list

Make a list containing loopback plus each source that genuinely needs unauthenticated relay. For a server that should accept relay only from localhost and one fixed application host, the shape would be:

127.0.0.0/8 198.51.100.25/32

Replace the sample with the real address visible to the MTA. Include the server's necessary local interfaces or additional trusted services only after confirming that they are needed. Avoid leaving a broad office subnet in place if only one server should be trusted; reduce it to a host entry where practical.

3. Set the value on the correct MTA

Use zmprov ms to set the server-level attribute. This command replaces the value, so include every entry you intend to retain, including loopback:

zmprov ms mta.example.com zimbraMtaMyNetworks '127.0.0.0/8 198.51.100.25/32'

For multiple IPs, put the complete approved list inside the quoted value, separated by spaces. Do not run a sample command unchanged. If your setup relies on a global value, server-level overrides, IPv6, multiple MTAs, or version-specific behavior, verify how inheritance and generated Postfix configuration work in that deployment before setting the attribute.

4. Reload Postfix and confirm the active setting

After changing the Zimbra configuration, reload Postfix as the Zimbra service account, then query the effective value again:

postfix reload
postconf mynetworks
zmprov gs mta.example.com zimbraMtaMyNetworks

The output should match the allowlist you intended, including loopback. If Postfix reports a malformed network or the values differ, stop and resolve that configuration issue before testing mail flow. CIDR entries must use the correct network boundary; for a single host use the host address with /32, rather than a network mask that includes neighboring hosts.

How to verify that the restriction works

Test from a controlled, authorized system using the same network path and SMTP listener as the real application. Send a message to a mailbox you control outside the Zimbra domains. Confirm that the approved host can submit it and that the MTA logs show successful acceptance or delivery. Zimbra MTA activity is commonly logged in /var/log/zimbra.log; inspect the relevant timestamp and source IP rather than relying only on a mail client's success message.

Then test from a host that is not on the allowlist and is not authenticated. The expected result is a relay denial when it tries to send to a nonlocal recipient. Check the MTA log for the rejected connection and the source address observed by Postfix. An unauthenticated client may still be allowed to send to local Zimbra recipients; that is normal mail reception and does not prove that it can relay outbound mail.

Also test any legitimate application that was on the old list. A failed application submission usually means the wrong source address was allowlisted, an old trusted dependency was removed, or the application needs SMTP authentication. If clients roam between networks or their egress IP is not stable, SMTP authentication over TLS is generally easier to manage than repeatedly changing an IP allowlist.

How to roll back or troubleshoot

If approved applications stop sending, restore the exact saved value rather than adding a guessed subnet. Apply it with zmprov ms, reload Postfix, and confirm the effective value with postconf mynetworks. Check whether a load balancer, NAT gateway, container host, or outbound proxy changes the source address before it reaches the MTA.

A Relay access denied response can also mean that the client is not authenticated and its source IP is absent from the trusted list. For normal email users, configure SMTP submission with authentication rather than adding all user networks to zimbraMtaMyNetworks. Broad allowlists create a larger unauthenticated relay surface and can expose the server to abuse if a trusted network contains unmanaged devices.

If the MTA value appears correct but behavior does not change, confirm that you edited the server that accepted the connection, that the reload succeeded, and that no other Postfix instance or network appliance is handling SMTP. Do not edit Zimbra-generated Postfix files directly as a lasting fix; configuration management may regenerate them. Check your release's Zimbra administration documentation or support channel for release-specific procedures when the LDAP value and runtime configuration disagree.

What a successful result looks like

• postconf mynetworks lists only loopback and the intended trusted source addresses or networks.
• The approved, unauthenticated application can send to an external test mailbox.
• An unauthenticated, unapproved host receives a relay denial for an external recipient.
• Authenticated users and local inbound mail continue to work as expected.
• The recorded rollback value and list of dependent services are retained for future changes.

This method narrows unauthenticated relay by source IP. It does not replace SMTP authentication, TLS, rate controls, account security, or monitoring, and it cannot distinguish individual applications that share one public NAT address. Use it as one focused control, and review the allowlist whenever network egress or MTA roles change.

Sources

• Zimbra Tech Center: ZimbraMtaMyNetworks
• Zimbra Tech Center: Zimbra MTA
• Zimbra Tech Center: Identify and Resolve Mail Flow Issues
• Postfix manual: mynetworks