Every comparison of VPS providers for Mailcow leads with RAM, storage, and price per month, as if those were the deciding factors. They are not. The single question that determines whether a VPS can run Mailcow at all is whether the provider allows outbound traffic on port 25, the port SMTP servers use to actually deliver mail to other mail servers. Get this wrong and it does not matter how much RAM you bought or how fast the NVMe storage is, because your Mailcow instance will install perfectly, run without errors, and simply never manage to deliver a single email to an external inbox.
This article covers the best VPS hosting for Mailcow specifically through that lens: which providers open port 25 by default versus which ones require a manual request or block it outright, how IP reputation on a given provider’s address ranges affects deliverability before you have sent a single email, the real RAM requirement once you account for Mailcow’s full Docker stack including antivirus scanning, and the specific plans and price points that make sense for a small business or law firm running its own email rather than paying for Google Workspace or Microsoft 365 seat licenses.
Port 25 is the first filter, not an afterthought
Port 25 is the protocol port SMTP servers use for server-to-server mail delivery, distinct from ports 587 or 465, which are used for a mail client submitting outgoing mail to your server. Many budget and mainstream cloud providers block outbound port 25 by default specifically to prevent their infrastructure from being used for spam, since a compromised account spinning up VPS instances to blast spam is a common abuse pattern providers actively defend against. The practical consequence is that a provider blocking port 25 makes Mailcow functionally useless for its core purpose, receiving is unaffected, but outbound delivery to external mail servers simply fails silently or bounces, regardless of how correctly Mailcow itself is configured.
This is worth dwelling on because it is genuinely counterintuitive for anyone coming from a managed email background. With Google Workspace or Microsoft 365, the entire question of which port carries outbound mail is invisible, handled entirely by infrastructure the provider manages and has already spent years building a trusted sending reputation for. Self-hosting removes that abstraction layer entirely, which means a decision that most people never think about, which network port their email travels through, suddenly becomes the single most consequential technical choice in the entire deployment, ahead of server brand, price, or even the choice of Mailcow itself over a similar alternative. Skipping this check and discovering the problem only after Mailcow is fully installed and configured is one of the most common and most avoidable mistakes in self-hosted email setups, because by that point the natural assumption is that something is wrong with the software rather than the network policy sitting underneath it.
Hetzner opens port 25 by default on most of its VPS lines, with no support ticket or waiting period required, which is precisely why it has become the most consistently recommended provider across self-hosted email communities and practitioner guides. DigitalOcean blocks port 25 by default across its entire Droplet lineup and requires a manual request through their support system to have it unblocked, a request that is reviewed on a case-by-case basis and is not guaranteed to be approved, particularly for new accounts without an established usage history. Vultr and OVHcloud generally allow port 25 on most of their standard VPS plans without the same friction DigitalOcean imposes, making them reasonable fallback options if a specific data center location Hetzner does not cover is a requirement.
Before committing to any provider for a Mailcow deployment, the single highest-value step is confirming port 25 policy directly with that provider’s current documentation or support team, since these policies do shift over time as providers adjust their abuse-prevention approach. A provider’s marketing page rarely states its port 25 policy prominently, since blocking it is framed internally as an anti-abuse measure rather than a customer-facing limitation, which means this detail is usually buried in a knowledge base article or only surfaces once you actually submit a support ticket asking about it directly. Some providers will also distinguish between residential-style consumer VPS plans and business-tier plans specifically when it comes to port 25 policy, so confirming the exact plan tier being purchased, not just the provider’s general reputation, matters as well.
IP reputation matters before you send your first email
Even with port 25 open, the IP address your VPS is assigned carries a reputation history that exists independently of anything you do. VPS providers reuse IP address ranges across customers over time, and if a previous tenant on the specific IP you are assigned used it for spam, that IP may already be listed on one or more public blacklists before you have configured a single DNS record. This is a genuinely under-discussed risk in most Mailcow setup guides, which tend to focus entirely on the software configuration and treat IP reputation as an afterthought to check once deliverability problems already show up.
Hetzner’s overall IP reputation is generally regarded as strong within the self-hosted email community, in part because Hetzner actively manages abuse on its network rather than treating IP hygiene as the customer’s problem alone. DigitalOcean’s IP ranges are flagged more frequently due to a documented history of higher abuse rates on portions of its address space, a pattern serious enough that one detailed guide on self-hosted email flatly states that major cloud provider ranges, including DigitalOcean, AWS, GCP, and Azure, are either outright blocked for SMTP by many receiving mail servers or heavily tarpitted, meaning your outbound mail gets deliberately slowed and scrutinized more heavily even when technically not blocked outright.
It is worth being precise about what “tarpitting” actually means in this context, since it is a softer and more insidious problem than an outright block. A tarpitted sender is not rejected outright, which would at least produce a clear bounce message pointing to the actual problem. Instead, the receiving server deliberately slows down the SMTP conversation, delays acceptance, or applies extra scrutiny and greylisting that causes legitimate mail to arrive late or occasionally not at all, without ever producing an error message that clearly identifies IP reputation as the cause. This makes tarpitting-related delivery problems considerably harder to diagnose than an outright block, since everything appears to be working from the sending side while a meaningful percentage of mail simply never shows up, or shows up hours later than expected, on the receiving end, leaving whoever manages the server chasing a phantom problem that never produces a clear error message pointing at its actual root cause.
The practical workaround, regardless of which provider you choose, is checking the specific IP address assigned to your new VPS against a blacklist checking tool before configuring anything else. If the assigned IP shows up on an active blacklist, the fastest fix on most providers is destroying that VPS instance and provisioning a new one, since a fresh instance is typically assigned a different IP from the provider’s available pool, repeating this until a clean IP comes up. This sounds like an unusual step to take before even installing Mailcow, but it is standard practice among people who have run into deliverability problems that traced back to a poisoned IP rather than anything wrong with their actual mail server configuration.
For an agency deploying Mailcow on behalf of a client, building this IP verification step into a standard deployment checklist, rather than treating it as an optional nice-to-have, is the kind of process discipline that prevents an embarrassing situation where a client’s first month of self-hosted email goes to spam folders industry-wide because nobody checked the starting IP before pointing DNS at it. This single check takes under five minutes and costs nothing, which makes skipping it one of the more avoidable mistakes in an otherwise sound deployment process.
RAM requirements: the real number, not the marketing minimum
Mailcow’s own documentation lists a minimum RAM requirement that undersells what the platform actually needs to run comfortably in production. The full Mailcow Docker Compose stack runs more than fifteen separate containers, including Postfix for SMTP, Dovecot for IMAP, Rspamd for spam filtering, SOGo for webmail and calendaring, and optionally ClamAV for antivirus scanning. With ClamAV enabled, which is the setting most guides recommend keeping on for anything beyond a purely personal, single-user deployment, realistic RAM needs land closer to 6GB rather than the 2GB figure sometimes cited as a bare technical minimum. Disabling ClamAV can bring usable RAM down to the 3 to 4GB range, but that means running a mail server without built-in virus scanning, a tradeoff worth making deliberately rather than by accident because a smaller VPS looked cheaper.
The gap between the documented minimum and the realistic production requirement is worth understanding rather than just accepting as a rule of thumb. Mailcow’s containers each reserve their own memory allocation, and the platform’s install script does not aggressively trim resource usage on smaller servers the way a more purpose-built, single-binary alternative might. Running the full stack on a genuinely minimal 2GB server tends to work during initial testing, when mailbox count and message volume are both near zero, and then degrades under real load as spam filtering, indexing, and concurrent IMAP connections all compete for the same limited memory pool. Several practitioner accounts describe exactly this pattern: a smooth setup experience followed by out-of-memory crashes once the mail server starts handling actual daily traffic from a real team rather than a handful of test messages.
For a small law firm or agency running email for a handful of staff, a VPS in the 4GB RAM range is the realistic entry point if ClamAV stays disabled, and 6 to 8GB is the safer choice if antivirus scanning is a requirement, as it typically should be for any business handling client communication and attachments. Providers commonly cited as delivering solid Mailcow performance at these RAM tiers include Hetzner’s CX22 or CAX11 plans, both landing in the $4 to $5 per month range for 2 vCPUs and 4GB RAM, and Contabo’s budget VPS lines, which offer 4GB configurations around $5 per month with NVMe storage, though Contabo‘s port 25 and IP reputation track record should be verified directly before committing, since it does not carry the same consistent recommendation Hetzner does across self-hosted email communities specifically.
CPU allocation matters less than RAM for a typical small business Mailcow deployment, but it is not irrelevant. Spam filtering through Rspamd and virus scanning through ClamAV are both CPU-intensive processes that spike briefly on every incoming message, and a server with only a single shared vCPU can develop a noticeable processing delay during a burst of incoming mail, such as a morning surge of client emails all arriving within the same few minutes. Two dedicated or lightly shared vCPUs is a reasonable practical floor for a business deployment, with the actual RAM allocation remaining the more important lever to adjust as mailbox count and message volume grow over time and usage patterns evolve.
Storage requirements scale primarily with mailbox retention policy and attachment volume rather than user count alone, so sizing storage on message count assumptions borrowed from a managed provider’s marketing page is a common early mistake. A typical office email user generates somewhere between 1 and 3GB of storage per year under normal use, with attachments consistently accounting for the largest share of that growth. A firm planning to retain email indefinitely for compliance or record-keeping reasons, which is common in legal practice specifically, should budget storage growth several years out rather than sizing a server only for current usage, since migrating a live mail server to larger storage later is a meaningfully more disruptive operation than provisioning generously from the start, particularly once client-facing accounts are already actively relying on that mailbox for day-to-day correspondence.
Related comparisons on this site:
1. DigitalOcean vs AWS Lightsail comparison
2. Cloudways vs RunCloud: managing a DigitalOcean VPS
3. RoseHosting vs Scala Hosting: managed VPS compared
4. NameHero vs Hostinger: performance compared
5. Hosting account exceeded inode limit
Cost comparison against Google Workspace and Microsoft 365
The financial case for self-hosted email becomes clear once you compare a Mailcow VPS against per-seat licensing costs at scale. Google Workspace Business Starter runs approximately $7 per user per month, and Microsoft 365 Business Basic runs a similar range, meaning a 10-person law firm pays somewhere between $70 and $85 per month indefinitely, scaling linearly with headcount. A single Mailcow VPS in the $10 to $20 per month range handles the same 10 mailboxes, or considerably more, for a flat cost that does not increase as staff are added, provided the underlying server resources keep up with growing storage and processing demand.
Running the numbers out over a longer horizon makes the gap more concrete. A 15-person firm on Google Workspace Business Starter pays roughly $1,260 per year in licensing alone, before factoring in any add-ons like additional storage or advanced security features that many firms end up needing as they grow. The same 15 mailboxes on a well-specified Mailcow VPS, sized generously at 8GB RAM to keep headroom for growth, runs closer to $180 to $240 per year at typical VPS pricing, a difference of roughly $1,000 per year that compounds every year the firm continues operating rather than being a one-time savings. Scaled to a 50-person firm, the gap widens into the range of several thousand dollars annually, assuming the underlying server is upgraded appropriately to handle the larger mailbox count and message volume.
This comparison is not an argument that self-hosted email is automatically the right choice for every business. Google Workspace and Microsoft 365 include managed infrastructure, automatic security patching, dedicated abuse and deliverability teams actively protecting sender reputation across their entire platform, and support you can call when something breaks. A self-hosted Mailcow instance trades that managed safety net for direct cost savings and full data control, at the cost of becoming personally responsible for server maintenance, security patching, DNS configuration, and troubleshooting deliverability issues without a vendor support line to call. For a technically capable operator, or an agency already comfortable managing VPS infrastructure for clients, the savings at scale are real and can justify the tradeoff. For a business without that in-house capability, hiring or contracting someone with the skill to maintain it properly should be factored into the true cost comparison rather than treating the VPS price alone as the full cost of ownership.
There is a middle path worth mentioning for a firm that wants the data control benefits of self-hosting without accepting the full maintenance burden alone: contracting a managed VPS provider or a freelance systems administrator specifically to handle Mailcow’s ongoing patching, backup verification, and deliverability monitoring, while the firm itself retains ownership of the domain, the data, and the underlying infrastructure contract. This adds a recurring cost on top of the base VPS price, but that cost is typically still well below per-seat licensing at any meaningful headcount, while removing the requirement that someone inside the firm personally develop and maintain the Linux and Docker administration skill self-hosting otherwise demands.
DNS configuration is where most Mailcow deployments actually fail
A properly provisioned VPS with port 25 open and a clean IP address is necessary but not sufficient for reliable email delivery. Mailcow deployments most commonly fail on the DNS side rather than the server side: missing or misconfigured SPF records, DKIM signing not properly enabled, no DMARC policy published, or a PTR record on the VPS provider’s side that does not match the mail server’s own hostname. Receiving mail servers check all of these as part of deciding whether to accept, flag, or reject incoming mail from an unfamiliar sender, and a mismatch on any one of them is often enough to land legitimate mail in a spam folder or have it rejected outright.
Each of these four checks serves a distinct purpose worth understanding rather than treating as an interchangeable checklist item. SPF publishes which servers are authorized to send mail on behalf of your domain, and a missing or incorrect SPF record lets a receiving server flag your mail as potentially spoofed since it cannot verify the sending server is legitimate. DKIM cryptographically signs outgoing messages so a receiving server can verify the message was not altered in transit and genuinely originated from your domain’s mail server. DMARC builds on both of those, publishing a policy telling receiving servers what to do with mail that fails SPF or DKIM checks, ranging from doing nothing to quarantining it to rejecting it outright, and also enables reporting back to the domain owner about authentication failures happening across the wider internet, which is itself a valuable early warning signal if someone else ever attempts to spoof your domain in a phishing campaign targeting your clients or contacts. Skipping any one of these three leaves a meaningful gap in how trustworthy your domain appears to receiving mail servers, even if the other two are configured correctly.
Most VPS providers allow configuring a PTR, or reverse DNS, record through their own control panel or API, and this step is required rather than optional for a mail server, since receiving servers specifically check that the sending IP’s PTR record resolves to a hostname matching what the server announces during the SMTP handshake. This is one of the more commonly overlooked steps precisely because it happens on the VPS provider’s side rather than within Mailcow’s own admin panel, meaning a Mailcow setup guide focused purely on the software installation can walk through every configuration screen correctly while never mentioning that a separate PTR record needs setting on the hosting provider’s own dashboard.
Running a fresh domain through a free tool like mail-tester.com after DNS configuration but before sending any real mail is standard practice, since a score below the tool’s passing threshold reliably indicates a specific, fixable DNS or configuration problem rather than a vague reputation issue that takes time to diagnose otherwise. Skipping this verification step and going straight to production use is the single most common reason new Mailcow operators conclude their mail server does not work, when the actual issue is a DNS record that takes ten minutes to fix once identified. Running this test again after any significant configuration change, not just at initial setup, is worth building into an ongoing maintenance routine, since a DNS record can occasionally be altered accidentally during unrelated domain management work and silently break deliverability until someone notices mail bouncing.
Which provider to actually choose
For most self-hosted email deployments in 2026, Hetzner is the most consistently recommended starting point across practitioner guides and the self-hosted community generally, specifically because it removes the two biggest early obstacles: port 25 is open without a support request, and its IP ranges carry a track record of reasonable reputation compared to larger, more heavily abused cloud provider ranges. The tradeoff is geographic: Hetzner’s data center footprint is concentrated in Europe, with limited US options in Ashburn and Hillsboro specifically, so a business needing a different North American region for latency reasons may need to weigh that against the port 25 convenience.
DigitalOcean and Vultr remain reasonable alternatives specifically for businesses that need a particular US or regional data center location Hetzner does not offer, provided the port 25 request process is initiated well before the mail server needs to go live, since approval is not instant and is not guaranteed on a first request from a new account. A practical approach for a firm on a tight timeline is submitting the port 25 request to DigitalOcean or Vultr as the very first step, before any other configuration work begins, precisely because that approval process is the one variable outside your direct control and therefore the one most likely to introduce an unplanned delay if left until later in the deployment.
Contabo offers competitive RAM-to-price ratios worth considering for a budget-conscious deployment, though its port 25 and IP reputation track record is less consistently documented across self-hosted email specific communities than Hetzner’s, making it a second-tier recommendation rather than a first choice. Anyone considering Contabo or a similarly less-documented provider specifically for Mailcow should treat the blacklist and port checks described earlier in this article as mandatory rather than optional precautions, since the absence of a strong community track record means there is less prior experience to draw on if something does not work as expected on the first attempt.
Whichever provider is chosen, verifying port 25 policy and checking the assigned IP against a blacklist tool before any DNS or Mailcow configuration work begins will save considerably more time than troubleshooting a deliverability problem after the fact. A useful habit for any agency deploying Mailcow repeatedly across multiple clients is maintaining a short internal checklist covering exactly these steps, in this order: confirm port 25 policy with the provider, provision the server, check the assigned IP against a blacklist tool and reprovision if needed, configure DNS including SPF, DKIM, DMARC, and PTR, install and configure Mailcow itself, and finally run a mail-tester.com check before pointing any real domain traffic at the new server, documenting each result along the way so a future troubleshooting session has a clear record of what was already verified. Treating this as a fixed sequence rather than an ad hoc process is what separates a smooth Mailcow deployment from one that generates a support headache during the first week of real use, and writing that checklist down once means every future client deployment starts from a proven process rather than reinventing the sequence from memory each time and risking a step getting skipped under time pressure.
Sources and references consulted: SMTP submission ports, mxtoolbox.com, mailcow.email, Portal Nacional de Contratações Públicas.
