Last updated: July 2026

In short: Vultr blocks outbound TCP port 25 by default across all cloud instances to protect network security. Unlike permanently blocked DDoS ports, the port 25 restriction can be removed upon manual request via a support ticket. Alternatively, authenticated smarthost relaying over port 587 remains fully open.

When deploying a self-hosted email server on a Vultr cloud compute instance or bare metal server, direct outbound SMTP traffic on port 25 will fail by default. This network filtering policy is enforced by Vultr to prevent spam and protect global IP reputation across its data centers.

Network security rationale and blocked ports list

Vultr implements upstream network filtering to safeguard its hosting infrastructure. In official technical documentation, the provider states: We block several outbound ports for network security.

Within the breakdown of default network restrictions, Vultr explicitly lists the standard email delivery port: TCP port 25 (SMTP)

Because this block operates at the data center network level, adjusting local operating system firewall settings (ufw or iptables) or modifying Vultr Cloud Firewall groups will not open outbound port 25.

Requesting restriction removal via support ticket

Unlike specific high-risk network ports that remain blocked permanently across all accounts, TCP port 25 falls into Vultr’s category of removable network blocks.

To highlight the distinction, Vultr notes regarding permanently restricted protocol ports (such as ports 17 or 19): These ports are commonly abused for DDOS attacks. These blocks are permanent and cannot be removed.

Conversely, for the standard blocklist that includes TCP port 25 (SMTP), Vultr outlines an explicit resolution path: You may request these blocks be removed by opening a support ticket

Before opening a support ticket to unblock port 25, ensure your instance is configured professionally for email delivery. Support agents typically check that your server has a valid reverse DNS (PTR) record assigned within the Vultr customer portal alongside published SPF and DKIM authentication records before approving your request.

IP reputation reality check

Even after Vultr support successfully removes the port 25 restriction, delivering mail directly from cloud hosting subnets poses significant deliverability hurdles. Because Vultr IP pools are dynamically recycled across thousands of global developers, many subnets carry pre-existing negative reputation history.

Frequently, Vultr IP ranges appear on strict blocklists (DNSBLs) such as UCEPROTECT (Level 2 or 3) and Spamhaus. Major receiving providers (including Gmail, Outlook, and Yahoo) strictly filter direct traffic originating from VPS subnets, often sending messages directly to spam folders despite valid authentication headers.

Smarthost relaying via port 587

To bypass support verification queues and avoid the deliverability risks of VPS subnets, you can route your outbound mail through an external smarthost relay over port 587 (Submission). Port 587 is designed for authenticated client submission and is not subject to Vultr’s outbound port restrictions.

A standard Postfix configuration (/etc/postfix/main.cf) for relaying through 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 opening support tickets, monitoring IP blocklists, and managing an external smarthost relay, you can route your outbound mail quickly and securely via Dispatch.

Verifying your configuration

Once your sending workflow or external relay is active, audit your email authentication headers (SPF, DKIM, DMARC) and domain health using the free MXAudit scanner.

Further reading