Mail can remain in Postfix’s deferred queue when outbound SMTP tries an IPv6 address that the host cannot route. The typical diagnostic is connect to ...mail.protection.outlook.com[2a01:...]:25: Network is unreachable. That local routing error is distinct from an SMTP reply returned by Microsoft’s servers.
Separate transport errors from remote rejection
Network is unreachable usually means the local host has no usable IPv6 route. By contrast, 451 4.7.0 Temporary server error is a response received after establishing an SMTP session and can reflect a remote temporary condition. Both defer delivery, but they have different causes.
postqueue -p | head -80
postconf -h inet_protocols
postconf -h smtp_address_preference
postconf -h maximal_queue_lifetime
ip -6 route show default
getent ahosts example-com.mail.protection.outlook.com
Use the actual destination MX for live DNS testing. Don’t infer a Microsoft-wide incident from a single deferred queue: corroborate remote errors with official service health and the timestamps of affected deliveries.
IPv4 preference vs IPv4-only
If IPv6 is simply not routed, smtp_address_preference = ipv4 prioritizes IPv4 when both address families are available, while inet_protocols = ipv4 disables IPv6 for Postfix listeners and outbound SMTP as a whole. Choose deliberately, especially if the server accepts incoming IPv6 email.
# Prefer IPv4 without removing IPv6 support:
postconf -e 'smtp_address_preference = ipv4'
postfix reload
Avoid repeated postqueue -f loops during a remote outage; Postfix’s retry scheduler handles temporary failures. Record the queue size and oldest deferred message, verify DNS and routing, and follow up with a small delivery test after the remote service recovers.
Operational checks
Review recipient-specific deferrals and the configured queue lifetime. If the queue is near expiry, notify affected users rather than assuming all messages will eventually be accepted. Never discard the queue to “fix” a transient routing or Microsoft 365 problem.