Vultr Blocks SMTP Port 25 — They Even Told Us No. Here's How to Send Email Anyway

Technical Vultr, SMTP, Port 25, Deliverability July 9, 2026 by Mailer To Go Team

Vultr blocks outbound port 25 and won't remove the block — even for an email infrastructure company sending authenticated, transactional-only mail from its own IP space. Here are their denial emails verbatim, why the policy makes sense, and how Mailer To Go lets any Vultr customer send email in minutes.

Server racks in a data center with orange and green fiber cabling

If your application on Vultr can’t send email, it isn’t a bug in your code. Vultr blocks outbound SMTP port 25 by default on new accounts — and in our experience, they will not remove that block even for a well-documented, transactional-only sender.

We know because we asked. We run an email infrastructure company. We submitted an SMTP port block removal request with just about the strongest case a sender can make, and Vultr said no. Twice — the second time after an escalation to management.

This post shares Vultr’s actual responses verbatim, explains why the block exists (and why, honestly, it’s the right call for them to make), and shows how to send email from a Vultr instance anyway.

What we asked for

In July 2026 we opened a ticket titled “SMTP Port Block Removal” on a fresh Vultr instance intended as an outbound mail delivery node. The request was as transparent as we could make it:

Transactional email only — account verifications, password resets, 2FA codes, order confirmations, receipts. No marketing, no newsletters, prohibited by our own terms of service.
Full authentication — every message DKIM-signed (Ed25519 + RSA dual-signature), SPF-aligned, and DMARC-compliant, with automated suppression of hard bounces and spam complaints.
Our own IP space — a dedicated /24 block we own, announced via BGP from our Vultr account, so our sending reputation would be entirely our own. Vultr’s IPs would carry none of our traffic.
A documented warming plan — starting at 50–100 messages per day and ramping over weeks while monitoring blocklist status.

Vultr’s answer, verbatim

Here is the first response from Vultr’s Accounts Team, word for word:

Hello,

Thank you for providing the requested information. We have thoroughly reviewed your request, but unfortunately, we are unable to remove the SMTP block on your account. Based on the information you provided, it appears that the activities you described are not compatible with our platform. It is crucial for us to strictly adhere to our Policy in order to ensure optimal performance and maintain the integrity of our services.

We understand that this may come as disappointing news, and we apologize for any inconvenience caused. However, we remain committed to assisting you in finding a suitable solution. We recommend exploring third-party software solutions that specialize in email services. These platforms are designed to meet the specific requirements and offer the necessary features and flexibility for your email operations.

We understand that this may not have been the outcome you anticipated, and we genuinely appreciate your understanding and cooperation in this matter. Our dedicated support team is here to help you in any way we can. If you have any further questions or if there’s anything else we can assist you with, please do not hesitate to reach out to us.

Best Regards,

Vultr Accounts Team

We replied and asked one clarifying question: would the determination change if we were restricted to sending only from our own BGP-announced IP addresses — so that our IP block, not Vultr’s, would carry every consequence of our sending behavior?

Vultr took the question seriously and escalated it:

Hello Jonathan,

Please allow us some additional time to review your request.

In the meantime, you can always respond here to add additional information.

A couple of hours later, the final answer came back:

Hello Jonathan,

Thank you for your patience while this was escalated to management.

Unfortunately, due to your intended usage, we are unable to unblock SMTP for you.

We recommend exploring third-party software solutions that specialize in email services, which are designed to meet the specific requirements for your email operations. Thank you for your understanding in this matter.

That’s a firm, final no — for a sender with full authentication, owned IP space, a warming plan, and a transactional-only policy. If your request is “I’d like to send email from my VPS,” expect the same answer or a quieter version of it.

Why Vultr blocks port 25 in the first place

It would be easy to read those emails as unhelpful. They’re not. They’re rational, and understanding why tells you a lot about how email actually works in 2026.

Network switch patch panel with blue and grey ethernet cables

Port 25 is the port mail servers use to talk to each other. It’s also the port spammers need. A cloud provider that leaves it open becomes a spam cannon within days: anyone with a stolen credit card can spin up a hundred instances, blast spam until the IPs burn, and walk away. The provider is left holding the damage — and the damage is collective. Blocklists like Spamhaus don’t just list a single bad IP; they list ranges. One abusive customer can get an entire /24 of a provider’s address space blocked, which means every other customer’s legitimate mail starts bouncing.

So every major cloud does some version of what Vultr does. AWS blocks port 25 by default. So do Google Cloud, Azure, DigitalOcean, and Hetzner. The blunt truth in Vultr’s response — “the activities you described are not compatible with our platform” — is a general-purpose cloud correctly recognizing that email delivery is not its business, and that even a good sender on its network is a liability it isn’t equipped to supervise. Vultr can’t cheaply distinguish a disciplined transactional sender from a spammer with a well-written ticket, so the safe policy is to decline everyone and, in their own words, recommend “third-party software solutions that specialize in email services.”

They’re right. We’re one of those.

Why deliverability became a specialist’s craft

Here’s the elegant paradox at the heart of this story: the thing that makes email delivery hard is the same thing that makes it necessary to specialize in it.

Delivering email reliably stopped being a networking problem years ago — it’s a reputation problem. Inbox providers judge every message against the history of the IP that sent it and the domain that signed it: complaint rates, bounce rates, engagement, authentication, volume consistency. That reputation is earned slowly (new IPs must be warmed over weeks), spent quickly (a single bad batch can undo months), and maintained continuously (feedback loops, suppression lists, blocklist monitoring, and per-provider quirks at Gmail, Microsoft, and Yahoo all demand daily attention).

No general-purpose cloud wants to underwrite that on your behalf — as Vultr’s Accounts Team just demonstrated. A specialized provider, on the other hand, stakes its entire business on it. Our infrastructure, our IP space, our monitoring, and our anti-abuse enforcement all exist to protect one asset: the sending reputation our customers’ email rides on. That alignment is the whole product. It’s challenging to deliver — which is precisely why it’s worth paying a specialist to deliver it.

A red POST mailbox on a post in front of a green hedge

How to send email from Vultr (the way that works)

Here’s the good news: Vultr only blocks port 25 — the server-to-server port. Port 587, the standard submission port your app uses to hand mail to an email service, is wide open. Which means Mailer To Go works perfectly from any Vultr instance, with zero tickets, zero waiting, and zero warming.

# Rails — config/environments/production.rb
config.action_mailer.smtp_settings = {
  address:        ENV["MAILERTOGO_SMTP_HOST"],
  port:           587,
  user_name:      ENV["MAILERTOGO_SMTP_USER"],
  password:       ENV["MAILERTOGO_SMTP_PASSWORD"],
  authentication: :plain,
  enable_starttls_auto: true
}

// Node.js — with Nodemailer
const transporter = nodemailer.createTransport({
  host: process.env.MAILERTOGO_SMTP_HOST,
  port: 587,
  auth: {
    user: process.env.MAILERTOGO_SMTP_USER,
    pass: process.env.MAILERTOGO_SMTP_PASSWORD,
  },
});

DKIM signing, SPF alignment, DMARC, bounce and complaint handling, suppression lists, and IP reputation are all handled on our side — the parts Vultr correctly decided not to be in the business of supervising.

Your Vultr instance keeps doing what Vultr is genuinely great at: running your application. Your email rides on infrastructure that exists for exactly one purpose — getting it delivered.