Postfix fails to deliver mail to Gmail while succeeding with ProtonMail because of strict TLS certificate validation and authentication requirements. The root cause is usually an untrusted CA in the system's certificate store or mismatched hostname verification during the STARTTLS handshake. By updating the CA bundle and ensuring the Postfix hostname matches its SSL certificate, you can resolve the connection refusal and restore reliable delivery to Google's servers.
Understanding the TLS Handshake Failure
Gmail enforces stringent security standards that differ from many other providers like ProtonMail. While ProtonMail may accept connections with self-signed certificates or less rigorous hostname checks, Gmail requires a valid, trusted TLS certificate issued by a recognized Certificate Authority. When Postfix attempts to establish a secure connection, it performs a series of checks including verifying the server's identity against the certificate subject. If these checks fail, Gmail rejects the connection immediately, resulting in deferred or bounced emails.
This behavior is not arbitrary but part of Google's effort to prevent spoofing and man-in-the-middle attacks. The error often manifests as a "connection refused" or "certificate verify failed" message in the Postfix logs. Unlike ProtonMail, which might prioritize privacy over strict infrastructure validation in some configurations, Gmail’s infrastructure demands cryptographic proof of identity. This discrepancy explains why your mail server works seamlessly with one provider but fails with another.
To diagnose this issue, you must examine the mail log for specific TLS-related errors. Look for messages indicating that the client could not verify the server's certificate chain. This step is crucial before attempting any configuration changes, as it confirms whether the issue is indeed related to trust anchors or hostname mismatches.
Updating the System Certificate Store
The most common solution involves ensuring your operating system trusts the Certificate Authorities that sign Gmail’s servers. Gmail uses certificates from well-known CAs such as Google Trust Services or DigiCert. If your system’s CA bundle is outdated or incomplete, it will reject these valid certificates. You need to update the package that manages these certificates on your Linux distribution.
For Debian-based systems, use the following command to update the CA certificates:
sudo apt-get update
sudo apt-get install --reinstall ca-certificates
sudo update-ca-certificates
On Red Hat-based systems, the process involves reinstalling the ca-certificates package:
sudo yum reinstall ca-certificates
# or for newer versions using dnf
sudo dnf reinstall ca-certificates
After updating the certificates, restart the Postfix service to ensure it picks up the new trust anchors. This simple step resolves the majority of TLS verification failures caused by missing root certificates. It is important to note that this fix applies to the local machine’s trust store, not just the Postfix configuration. Without a complete CA bundle, no application on the server can verify Gmail’s identity securely.
Verifying Hostname and Certificate Matching
Beyond basic trust, Gmail validates that the hostname used in the SMTP greeting matches the Common Name (CN) or Subject Alternative Name (SAN) in the SSL certificate. If your server presents a certificate for "server.example.com" but greets clients as "localhost" or an IP address, Gmail will reject the connection. This is a critical security feature to prevent identity confusion.
You must configure Postfix to use the correct hostname in its EHLO/HELO commands. Check the
myhostname parameter in
/etc/postfix/main.cf. Ensure it points to a fully qualified domain name (FQDN) that has a valid DNS A record pointing to your server’s IP.
myhostname = mail.yourdomain.com
Additionally, if you are using a self-signed certificate or a custom PKI, you must ensure the certificate covers the exact hostname used in the SMTP transaction. For production environments, it is highly recommended to use Let's Encrypt or another commercial CA to obtain a free or paid certificate that is universally trusted. Self-signed certificates will almost always fail Gmail’s strict validation unless you manually import them into every recipient’s trust store, which is impractical.
If you are dealing with mutual authentication scenarios, similar principles apply. As discussed in our guide on
TLS Mutual Authentication, both parties must present valid credentials. While Gmail does not typically require client certificates for submission, ensuring your server’s identity is impeccable is the first step.
Configuring Postfix for Strict TLS
Once the certificate store and hostname are corrected, you should enforce TLS usage in Postfix. Configure the
smtp_tls_security_level to
may or
encrypt depending on your needs. Using
may allows fallback to non-TLS if necessary, but
encrypt forces TLS, which is safer. However, forcing encryption without a valid cert will break delivery entirely.
smtp_tls_security_level = may
smtp_tls_loglevel = 1
Setting the log level to 1 helps you monitor the TLS negotiation process. Watch the logs when sending a test email to Gmail. You should see successful certificate exchange and handshake completion. If you still encounter issues, check for network-level blocking or ISP restrictions on port 465 or 587. Some cloud providers block outgoing SMTP traffic to prevent spam.
Also, consider SPF, DKIM, and DMARC records. While these are not TLS issues per se, they are often confused with delivery failures. Gmail will reject or spam-filter emails that lack proper authentication records, even if the TLS connection succeeds. Ensure your domain’s DNS zone includes a valid SPF record and that you have signed your emails with DKIM.
For more insights on handling spam filters and authentication, refer to our article on
Fighting Nasty Sexual Spam Emails in Gmail for the Past 3 Months. Proper configuration of these records complements your TLS setup by building sender reputation.
Frequently Asked Questions
Why does my mail work with Outlook but not Gmail?
Outlook.com often has more lenient TLS policies compared to Gmail, especially regarding certificate validity periods and hostname matching. Gmail strictly enforces RFC-compliant TLS behaviors and may reject connections that Outlook accepts. Always prioritize meeting Gmail’s stricter standards to ensure universal deliverability.
Can I disable TLS verification for testing purposes?
While you can set
smtp_tls_security_level = none in Postfix, this is highly discouraged for production use. Disabling TLS exposes your emails to interception and will likely result in immediate rejection or spam classification by Gmail. Use this only in isolated lab environments for debugging.
What if my server has a dynamic IP address?
Gmail generally prefers static IPs due to reverse DNS (PTR) record requirements. Dynamic IPs are often flagged as suspicious. If you must use a dynamic IP, consider using a smart host relay that handles TLS and authentication on your behalf. This offloads the complexity and ensures consistent deliverability.
How do I check if my CA bundle is up to date?
You can list installed certificates using
openssl x509 -in /etc/ssl/certs/ca-certificates.crt -text -noout or check the package version via your system’s package manager. Regularly updating your OS packages ensures you have the latest root certificates required by modern services like Gmail.
Is EAP-TLS relevant to Postfix SMTP connections?
No, EAP-TLS is used for network access authentication (like Wi-Fi), not for SMTP email transmission. Confusing these protocols can lead to unnecessary troubleshooting. Focus on standard TLS/SSL settings within Postfix rather than enterprise network authentication methods.