Skip to content
SendPoint / Education
Sending infrastructure

NGINX mail proxy: scope and configuration

Understand where a mail proxy fits and why it does not replace an MTA.

SendPoint referenceUpdated 1 min read

Place the proxy in the right role

NGINX’s mail modules proxy mail protocol connections to upstream servers. They do not provide a complete outbound mail queue, retry engine or deliverability platform. Keep the MTA responsible for message transport and queue policy.

Review documented SMTP proxy options

These directives belong in the supported mail or server configuration context described by the module documentation. They are individual options for an existing, reviewed mail proxy setup; upstream authentication, routing and TLS configuration are still required.

NGINX mail proxy directive
proxy_pass_error_message on;

This option permits an upstream authentication error message to be passed to the client. Review whether those messages expose internal information before enabling it.

Documented proxy timeout default
proxy_timeout 24h;

The timeout applies between successive read or write operations. It is not an SMTP retry schedule and does not tell an MTA how long to queue a message.

Validate the complete route

  1. Confirm the installed NGINX build includes the required mail modules.
  2. Identify the real upstream MTA, authentication service and TLS termination points.
  3. Review which component observes the original client identity and records the final delivery result.
  4. Validate the configuration before a controlled reload and inspect connection behavior through the complete route.

SendPoint recommendation: document proxy and MTA ownership separately so a proxy connection failure is not mistaken for a mailbox-provider rejection. For queue and relay controls, see Postfix configuration review.

Sources