Fix Zimbra Outbound Mail Deferred: “Connection Timed Out Port 25”

If Zimbra reports connect to mx.example.net[203.0.113.25]:25: Connection timed out, the message has usually reached the Zimbra mail queue, but the server has not completed a TCP connection to the recipient domain’s mail exchanger. Start by checking the queue, DNS, and outbound network path. Do not change Postfix timeouts or repeatedly flush the queue until you know which hop is blocking the connection.

A timeout is different from an SMTP rejection. A rejection such as “550” means a remote server answered and refused the message; “Connection timed out” means the connection attempt did not receive a timely response. The cause may be a local firewall, a cloud or hosting provider’s outbound mail policy, routing, an unreachable destination, or less commonly a DNS/address-family issue.

What does “Connection timed out port 25” mean in Zimbra?

Zimbra uses its MTA to route outgoing messages. When a recipient is outside your organization, the MTA looks up that domain’s mail exchanger and connects to it using SMTP. Zimbra’s current Daffodil administrator guide describes messages that cannot be delivered as entering the deferred queue, where delivery is retried. The queue entry and mail log identify the destination and the error, so they are the best starting evidence.

In a typical mail flow, public mail servers exchange email with one another over TCP port 25. Port 587 is commonly used by authenticated mail clients to submit messages to an outbound relay. Switching Zimbra’s relay path to port 587 is an option only when you have an authorized relay service configured for that purpose; it is not a general replacement for receiving Internet mail on port 25.

1. Is the problem affecting every recipient or just one domain?

Check the deferred queue before making changes. On the Zimbra MTA host, run administrative commands as the zimbra account:

su - zimbra
postqueue -p

Look for repeated timeout messages and note the recipient domain, target MX hostname, and resolved IP address. In the Zimbra Administration Console, open Monitor → Mail Queues and inspect the Deferred queue by error type and recipient domain. The exact menu label can vary by Zimbra release and edition.

If failures cluster around one recipient domain or one MX address, the destination may be temporarily unreachable or filtering connections from your server. If many unrelated domains fail with the same port 25 timeout, suspect the Zimbra host’s egress path, provider policy, or firewall first. Record timestamps and a few representative destinations; do not post message bodies or credentials when seeking help.

2. Does DNS resolve the recipient domain to reachable mail servers?

Query the recipient domain’s MX records from the Zimbra server. Replace example.net with a domain that is failing:

dig MX example.net +short

Use the returned MX hostname to look up its addresses:

dig A mx.example.net +short
dig AAAA mx.example.net +short

A domain may have multiple MX hosts. Test the actual hostnames shown by DNS rather than assuming the recipient’s website server accepts mail. If DNS returns no usable MX target, inspect the authoritative DNS configuration for that recipient domain; do not add a made-up MX record on your Zimbra server.

Next test a TCP connection. If nc is installed, use:

nc -vz -w 10 mx.example.net 25

Or use telnet mx.example.net 25 if that is available. A successful TCP connection should produce a connection success message; an SMTP server may then show a greeting. A timeout indicates the TCP handshake did not complete. A “connection refused” result is different: the remote host responded but did not accept the connection on that address and port.

Repeat the test against each MX target and, where practical, test both IPv4 and IPv6 paths. If the hostname resolves to an IPv6 address but the server has no working IPv6 route, an IPv6 attempt can fail while IPv4 works. Verify the route and logs before changing Postfix address-family settings; any such change should be version- and deployment-specific.

3. Is a firewall or hosting provider blocking outbound SMTP?

Check the server’s firewall policy without changing it first. On systems using UFW:

sudo ufw status verbose

UFW can manage outbound as well as inbound traffic. If the outbound policy is restrictive, inspect the numbered rules and confirm whether TCP connections to remote port 25 are denied. Only add a narrowly scoped outbound allow rule if that matches your security policy and the server is authorized to send mail directly.

A host firewall may allow the connection while an upstream firewall, cloud security control, network ACL, or hosting-provider policy blocks it. Ask the provider whether outbound TCP/25 is permitted for this instance, whether an account-level restriction applies, and whether a release or review process is available. Policies differ by provider, account, region, and product, so a successful local firewall check does not prove that the Internet path is open.

If you control a network firewall, check its egress rules and logs for the Zimbra server’s source IP, the destination MX IP, protocol TCP, and destination port 25. A packet capture can help an experienced administrator distinguish unanswered SYN packets from replies that are blocked on the return path, but capture only the relevant headers and protect any operational data. Do not open inbound port 25 as a fix for outbound timeouts; these are separate traffic directions.

4. What should you do if direct delivery on port 25 is unavailable?

If the provider does not allow direct outbound SMTP, use an authorized smarthost or outbound relay. Obtain the relay hostname, port, TLS requirements, authentication method, allowed sender domains, and any IP allowlisting requirements from the relay operator. Configure the relay through the supported Zimbra administration method for your version, or follow your organization’s Zimbra change process. Zimbra’s administrator guide notes that a relay host must be configured when DNS-based delivery is not enabled.

Many providers offer authenticated submission on port 587 with STARTTLS, but the relay’s documentation is authoritative. A relay may instead require port 465, IP allowlisting, or a provider-specific connector. Do not assume that port 587 is open or that any public SMTP server can be used as a relay. Keep credentials in the supported protected configuration, restrict who can read them, and never place a relay password in a support ticket or shell history.

After configuring the relay, send a controlled test message to a mailbox you manage. Confirm in the Zimbra mail log that the connection goes to the relay host and expected port, TLS/authentication succeeds if required, and the relay accepts the message. If it returns an SMTP error, troubleshoot that response as an authentication, sender-policy, TLS, or relay-permission issue rather than as a port 25 timeout.

When should you retry the deferred queue?

Once the root cause is corrected and a direct test to the destination or relay succeeds, request a queue retry. From the Zimbra account, postqueue -f asks Postfix to attempt delivery for queued messages:

su - zimbra
postqueue -f

This can trigger delivery attempts for many messages, so avoid running it repeatedly during an outage. You can also use the Administration Console’s queue controls where available. Zimbra documents that flushing attempts delivery for messages in the Deferred, Incoming, and Active queues. Check a few messages afterward and verify that the deferred count is falling and that the logs show successful delivery or a new, actionable SMTP response.

Quick decision guide

How can you confirm the fix?

Use a short verification sequence: confirm DNS returns the intended MX or relay; confirm a TCP connection succeeds to the configured host and port; send a controlled test message; verify the remote or relay accepted it; then inspect the Deferred queue and logs for the original messages. A successful connection test alone does not prove that the recipient accepted the message, and a successful relay handoff does not guarantee inbox placement.

Do not “fix” a timeout by increasing Postfix’s connection timeout. The Postfix smtp_connect_timeout setting controls how long the SMTP client waits to complete a TCP connection; extending it cannot make a blocked route work and may leave delivery attempts waiting longer. Also avoid deleting queued messages or changing queue lifetimes to hide the symptom. If messages approach the configured bounce lifetime, tell affected users that delivery is delayed and preserve queue evidence while restoring the route.

Official references

• Zimbra Daffodil (v10) Administrator Guide: mail flow and queues
• Zimbra Daffodil (v10) Single-Server Installation Guide: port mapping
• Postfix postconf(5): smtp_connect_timeout
• Ubuntu Server documentation: firewalls and UFW status