SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
FixMyError.net
Email New Added 26 October 2026

Postfix: connect to mx1.example.net[203.0.113.25]:25: Connection timed out

Your server never got a TCP connection to the recipient's mail server on port 25, so the message sits deferred in the queue. If it happens for every destination, the remote side is almost never at fault: most cloud providers block outbound port 25 by default (Google Cloud, Azure, AWS and many VPS hosts), and residential ISPs do too. Port 587 is usually left open, which is why sending through a relay works while direct delivery to MX servers does not.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Is it every destination, or just one?
mailq | tail -n 20
sudo grep 'Connection timed out' /var/log/mail.log | awk -F'connect to ' '{print $2}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

# A timeout on 25 while 587 connects means the port is blocked
nc -vz -w 5 gmail-smtp-in.l.google.com 25
nc -vz -w 5 smtp.gmail.com 587

# Fix 1: ask the provider to lift the block (AWS has a request form)
# Fix 2: relay through a smarthost on 587, such as your email provider
sudo postconf -e 'relayhost = [smtp.example-esp.com]:587' 'smtp_tls_security_level = encrypt'
sudo postconf -e 'smtp_sasl_auth_enable = yes' 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
sudo postconf -e 'smtp_sasl_tls_security_options = noanonymous'
sudo systemctl reload postfix

# Retry everything that was deferred
sudo postqueue -f

How to diagnose Email errors

SMTP errors follow a strict convention: a 4xx code is temporary and will be retried, a 5xx is permanent and will not. Beyond delivery mechanics, most modern email problems are authentication problems (SPF, DKIM and DMARC alignment) which cause silent filtering into spam rather than an explicit bounce, and therefore need to be checked proactively.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Read the full bounce message. The enhanced status code (for example 5.7.1) is far more specific than the three-digit code and usually names the exact policy that rejected the message.
  2. Test the SMTP conversation manually with swaks --to [email protected] --server smtp.example.com --tls. It shows each command and response.
  3. Verify SPF, DKIM and DMARC records with dig TXT example.com, dig TXT selector._domainkey.example.com and dig TXT _dmarc.example.com.
  4. Check DMARC alignment, not just presence: the domain in the From: header must align with the SPF or DKIM domain, or DMARC fails even when both pass individually.
  5. Confirm the sending IP is not on a blocklist and has valid reverse DNS. Missing PTR records cause rejection by many large providers.

Tools worth reaching for

  • swaks
  • dig TXT
  • openssl s_client -starttls smtp
  • postfix mail logs
  • DMARC aggregate reports

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

cloud.google.com postfix.org

Related Email errors

See all 20 Email errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.