The Email Problem in Hosting

Becoming a host is not as simple as it looks. I’m starting to learn that the hard way.

Even with robust systems like cPanel and WHM, you’re still operating inside someone else’s network—and those networks are locked down heavily in the name of security. Nowhere is that more apparent than with email.

Email is one of the biggest risks in server environments. It’s trivial for a compromised account or misconfigured script to start blasting spam, and when that happens, it doesn’t just affect one server—it can damage the reputation of an entire IP range across a data center.

Because of that, providers like DigitalOcean block outbound port 25 by default. That prevents direct SMTP delivery, which is how traditional mail servers send messages. Their documentation often recommends using a relay service like Mailgun, so I gave that a try.

I was able to get Mailgun working quickly using their HTTP API with PHP, which was straightforward. But my goal wasn’t just application email—I wanted full mailbox support for clients, meaning IMAP/POP/SMTP through cPanel. That meant configuring Exim to relay all outbound mail through Mailgun.

That’s when things got more complicated.

In addition to blocking port 25, my server couldn’t connect on ports 465 or 587 either. After some digging, I found that port 2525 was open and supported by Mailgun, and I was able to establish a connection using STARTTLS. That part worked.

But then I ran into a bigger issue: domains.

For every domain or subdomain I wanted to send email from, Mailgun required that it be added and verified with DNS records. Even though I was on a paid plan that allowed 10,000 emails per month—far more than I need right now—I was limited to a single sending domain. The next tier jumped to support for 1,000 domains, along with a much higher monthly cost.

That’s when it clicked: Mailgun isn’t really designed for hosting providers. It’s built for applications—systems that send large volumes of email from a single domain.

As a host, that model doesn’t fit well. Each additional client domain introduces friction, both technically and financially. If port 25 were open, cPanel would handle all of this natively with no additional cost.

At this point, I’m planning to recommend that clients who need robust email—multiple accounts, strong spam filtering, reliability—use services like Google Workspace or similar platforms. That shifts the responsibility to providers who specialize in email.

Meanwhile, I still need a workable outbound solution for the server itself.

That led me to evaluate SMTP relay services like SMTP2GO and MailChannels. MailChannels is clearly designed for hosting providers and includes built-in abuse protection, but it starts around $100 per month. SMTP2GO, on the other hand, offers a more accessible entry point—around $15 to $75 depending on usage.

The tradeoff seems to be responsibility. MailChannels takes on more of the burden of filtering and protecting your reputation. SMTP2GO is simpler and more affordable, but puts more responsibility back on the server administrator.

For now, SMTP2GO looks like the most practical option. Their free plan supports multiple domains and a modest number of emails, and importantly, it works over ports that are actually open in my environment. I don’t need to register every subdomain individually the way I did with Mailgun, which removes a major point of friction.

My next step is to look into how well SMTP2GO integrates with cPanel and whether I can streamline domain onboarding.

This whole process has been a reminder that hosting isn’t just about spinning up servers—it’s about understanding the constraints of the ecosystem you’re operating in. Email, in particular, turns out to be one of the hardest parts to get right.

Discover more from Lewis Moten

Subscribe now to keep reading and get access to the full archive.

Continue reading