Configuring Postfix to relay directly to Gmail requires careful attention to SMTP protocol limits rather than arbitrary numerical caps. This setup involves defining Gmail as the final destination in your
main.cf configuration, ensuring that outbound mail is authenticated and delivered through Google’s secure infrastructure. Understanding these constraints prevents delivery failures and ensures compliance with Google’s acceptance policies for direct relays.
Understanding Direct Relay Architecture
When you configure Postfix to send email directly to Gmail, you are establishing a client-server relationship where Postfix acts as the SMTP client and Gmail’s servers act as the recipient SMTP server. This is distinct from using Gmail as an intermediate relay hub; here, Postfix connects to
smtp.gmail.com (or similar endpoints) to deliver messages to end-users or other domains. The primary challenge lies not in Postfix’s internal limits, but in adhering to Gmail’s acceptance criteria and rate limits imposed on unauthenticated or incorrectly authenticated connections.
Many administrators mistakenly believe they need to tune Postfix’s
smtpd_client_connection_count_limit for this scenario. This parameter controls how many simultaneous connections a single client IP can make to the *local* Postfix instance (the server receiving mail), not how many connections Postfix can open when sending mail out. For outgoing relays, the relevant settings reside in the
smtp transport configuration, not the
smtpd daemon settings. Confusing these two areas leads to misconfigured systems that fail under load or reject legitimate traffic due to incorrect resource allocation.
Configuring Gmail as the Destination
To set up a direct relay, you must define the transport map in your Postfix configuration. This involves specifying the hostname of Gmail’s SMTP service and enabling authentication. The most common approach uses the
smtp transport defined in
master.cf or via generic maps in
main.cf. You will need to ensure that TLS is enforced, as Gmail rejects non-encrypted connections on standard ports.
The configuration typically requires setting
relayhost to
[smtp.gmail.com]:587 or configuring specific transport maps for different domains. Authentication credentials are stored securely in
sasl_passwd, which must be hashed using
postmap to create the
sasl_passwd.db file. Without proper SASL authentication, Gmail will treat your connection as anonymous and likely reject it or impose strict, undocumented throttling. Ensure that
smtp_sasl_auth_enable is set to
yes and that
smtp_tls_security_level is set to
encrypt.
For detailed guidance on managing sender addresses during this process, refer to our article on
Change Postfix Sender Envelope MAIL FROM Address To Match Return Path Header Email For Multiple Domains. Properly aligning envelope senders with authentication headers is crucial for avoiding spam filters at the receiving end.
Authentication and Security Settings
Gmail requires robust security measures. Use App Passwords if you have Two-Factor Authentication enabled on the Google account used for relaying. Standard passwords are no longer sufficient for third-party SMTP clients. Additionally, verify that your server’s reverse DNS (PTR record) matches the hostname of the machine sending the mail. While Postfix handles the handshake, a mismatched PTR record can cause Gmail to defer or reject messages as potential spam.
Managing Connection Limits and Concurrency
Unlike inbound connections, outbound connections to Gmail are governed by
smtp specific parameters. The key setting is
smtp_helo_name, which should match your domain’s HELO/EHLO string. More importantly,
smtp_connect_timeout and
smtp_max_retries determine how Postfix behaves when Gmail is temporarily unavailable. Gmail may throttle connections if they appear too aggressive.
There is no single "magic number" for outgoing connections that applies universally because Gmail adjusts limits based on reputation, volume, and authentication status. However, keeping
smtp_destination_concurrency_limit reasonable (e.g., 5-10) helps prevent overwhelming the remote server. If you experience timeouts, check your network firewall and ensure that port 587 or 465 is accessible. Avoid setting extremely high concurrency limits, as this can trigger anti-abuse mechanisms on the Gmail side.
For insights into troubleshooting local delivery issues that might interfere with relay configurations, see our guide on
Troubleshooting Postfix: Local Delivery despite External Agent Configuration. Sometimes, misrouted local domains can consume resources intended for external relays.
Monitoring and Troubleshooting
Monitor your mail logs (
/var/log/mail.log) for rejection codes such as
550 5.7.1 or
421 4.7.0. These often indicate authentication failures or temporary throttling. If emails are being deleted unexpectedly, review your system’s cleanup policies. Our article on
Automatically Deleted Postfix Emails explains how queue management settings might inadvertently remove messages before successful delivery.
Ensure that your Postfix version supports modern TLS versions. Older versions may struggle with Gmail’s current security requirements. Regularly update your Postfix installation to maintain compatibility with evolving SMTP standards.
Frequently Asked Questions
Why does Gmail reject my Postfix connection even with correct credentials?
Gmail may reject connections if the server’s reverse DNS (PTR record) does not match the hostname sent in the HELO command. Verify that your PTR record points to your domain and that
smtp_helo_name in Postfix is configured correctly to match.
Can I use port 25 to relay to Gmail instead of 587?
No, Gmail does not accept incoming mail on port 25 for submission from third-party clients. You must use port 587 with STARTTLS or port 465 with SSL/TLS for authenticated submissions. Port 25 is reserved for server-to-server communication between MTAs.
How do I fix "Relay access denied" errors when sending to Gmail?
This error usually indicates that Postfix is not properly authenticating via SASL or that the
relayhost is not configured correctly. Check your
sasl_passwd file for syntax errors and ensure
smtp_sasl_auth_enable is set to yes. Also, verify that the user has granted access to less secure apps or generated an App Password.
What happens if I exceed Gmail’s implicit rate limits?
Gmail may temporarily block your IP address or return 421 errors indicating rate limiting. To avoid this, reduce the
smtp_destination_concurrency_limit in Postfix and implement backoff strategies. Spreading out sends over time is more effective than increasing concurrency.
Is it safe to store Gmail credentials in plain text in Postfix config?
Never store credentials in plain text within
main.cf. Always use the
sasl_passwd file and run
postmap to create a hashed database file. Restrict permissions on these files to root only to prevent unauthorized access to your authentication details.