Last updated: July 2026

In short: Google Cloud (GCP) blocks outbound connections on TCP port 25 to destination addresses external to your VPC network by default to prevent spam. This block applies even when attempting to use port 25 for Google Workspace SMTP relay. As an alternative, destination TCP ports 587 and 465 remain completely open for external relay submission.

When deploying a self-hosted email infrastructure on a virtual machine instance in Google Compute Engine, direct SMTP delivery to remote mail systems fails out of the box. This network restriction is enforced by Google Cloud at the edge of your Virtual Private Cloud (VPC) to protect global IP reputation and mitigate outbound spam.

Rationale and scope of the port 25 restriction

The network filtering policy distinguishes sharply between internal VPC routing and public internet destinations. In the official Compute Engine documentation, Google notes: Due to the risk of abuse, connections to destination TCP Port 25 are blocked when the destination is external to your VPC network. This includes using SMTP relay with Google Workspace. However, some projects do not have this restriction and do allow external SMTP egress on port 25.

While a small subset of legacy or specifically exempted projects permit external SMTP egress, the vast majority of Compute Engine workloads are permanently restricted from delivering direct traffic over port 25 to external MX gateways. Because this control is enforced by the VPC network fabric, adjusting local operating system firewalls or VPC egress firewall rules will not unblock port 25.

Google Workspace SMTP relay rules

Organizations operating within Google Cloud frequently attempt to route outbound VM mail through their existing Google Workspace SMTP relay service over port 25. Google explicitly forbids this configuration, clarifying: SMTP relaying through Google Workspace is only allowed through ports 465 or 587. Port 25 is not supported through Google Workspace.

IP reputation reality check

Even if your project is among the few that allow external port 25 egress, delivering email directly from Compute Engine external IPs poses extreme deliverability challenges. Compute Engine external IP addresses are dynamically assigned from data center pools shared across millions of cloud instances worldwide.

Consequently, these IP ranges frequently land on aggressive blocklists (DNSBLs) such as UCEPROTECT and Spamhaus. Major inbox providers (including Gmail, Outlook, and Yahoo) strictly filter or reject direct messages from cloud provider subnets, even when your sending domain publishes valid SPF and DKIM authentication records.

Smarthost relaying via ports 587 and 465

To bypass both the network-level port 25 block and the deliverability risks of hosting IP pools, Google Cloud provides an open path for authenticated relay submission: Google Cloud does not place any restrictions on traffic sent to external destination IP addresses using destination TCP ports 587 or 465.

You can reliably route your outbound mail through an external smarthost relay over port 587 (STARTTLS) or port 465 (SSL/TLS).

A standard Postfix configuration (/etc/postfix/main.cf) for relaying via an external smarthost over port 587 looks like this:

relayhost = [smtp.provider.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Or send reliably via Dispatch. If you want to avoid project exemption requests, Workspace relay restrictions, blocklist troubleshooting, and smarthost maintenance, you can route your outbound mail quickly and securely via Dispatch.

Verifying your configuration

Once your external smarthost or relay path is operational, verify your email authentication headers (SPF, DKIM, DMARC) and overall domain health using the free MXAudit scanner.

Further reading