November 2026 • Guide

This page rests on NIST SP 800-123, the M3AAWG sender best common practices, Spamhaus-related articles, the Google and Microsoft sender requirements, the Postfix and Mailcow documentation, and the OWASP Core Rule Set. All were read on 7 November 2026. Statements about PFHW come from our own product facts. Where a point is our reasoning and not a source's finding, the text says so.

Running a mail server and web server on the same server works technically, and many small sites do it. The problem is that the two services have different risks. A website is open to anyone, runs code that changes often, and is attacked all day. A mail server depends on the reputation of one IP address, and a bad day on the web side can damage it.

This page explains the main reasons to use a separate mail server, with sources for each point. It then lists what a web server and a mail server each need, describes how we split them at CloudAcropolis, and gives a fair section on when one server is acceptable. No setup removes risk completely, and separation is no exception.

Why a separate mail server is safer: seven risks of one VM

1. Shared IP reputation and blocklists

Receiving servers judge mail partly by the reputation of the sending IP address. The M3AAWG sender best common practices say that in a shared environment the reputation of the IP is also shared. If web and mail use one IP address, a problem on one side becomes a problem for both.

Blocklists make this concrete. Spamhaus publishes lists such as the SBL, XBL and CSS, and mail servers query them to decide whether to accept a message. Word to the Wise described a case where one customer on a shared hosting platform caused the platform's IP addresses to be listed on the Spamhaus SBL. Receivers that check the IP behind a domain in a message could then reject mail from other customers who did nothing wrong.

2. Hacked website scripts that send spam

A website is a program that anyone can probe. A hosting provider's guide on compromised email scripts explains that attackers plant PHP scripts with names like mailer.php that call the PHP mail() function, sometimes hidden with obfuscated code. The same guide says the result can be a blacklisted domain or server IP and an automatic account suspension.

Sucuri, a website security company, writes that a compromised website or server is a common reason for a Spamhaus listing, and that infected hosts can appear on the XBL list. If the mail server shares the IP address of a compromised site, the mail users pay for the website's incident. On a separate server, a hacked script can still send spam through whatever relay it can reach, but it does not send from the mailbox server's own address.

3. Resource contention

Mail software with spam and virus filtering needs memory. The Mailcow documentation lists a minimum of 6 GiB RAM plus 1 GiB swap for a default installation, says ClamAV and full-text search can use a lot of RAM, and says one SOGo worker can use about 350 MiB, with 20 workers in the default setup. A busy website adds PHP or application workers and a database on top. Our reasoning: when both run on one VM, a traffic spike or a runaway script on the web side can starve the mail processes of memory and the other way around.

4. Different patch and exposure profiles

NIST SP 800-123 says that dedicating a host to one service is the most secure option, and that each extra service is another possible attack path. It also recommends removing services that are not needed. A web server opens ports 80 and 443 and runs application code, plugins and themes. A mail server opens the SMTP and IMAP ports and runs mail, filter and webmail components. These two sets are patched on different schedules and by different rules, so a combined server needs the union of both.

5. Backup and restore differences

The two services store different data. The Mailcow backup script handles the mail directory, the SQL database, Redis, Rspamd and Postfix data as separate components, and the Mailcow documentation says to restore onto a fresh, empty Mailcow installation. A website restore usually means files plus a database. Our reasoning: if both live on one VM, restoring the whole machine to undo a website incident also rolls back mail that arrived after the backup. Separate servers let you restore each service on its own.

6. Outage blast radius

When one server hosts everything, any failure takes down everything. A failed website update, a full disk, or a kernel update that needs a reboot stops mail too. Keeping mail on its own server means a web incident does not stop mail, and a mail incident does not stop sites.

7. The cost of separation

Separation costs money and attention. You pay for a second server or service, you maintain a second system, and you need DNS records and authentication to match. Mail also needs a stable IP address with a good history. For a business with several client sites, weigh that cost against the cost of a deliverability incident. For a single small site it can be more than the risk is worth, which is why we add a section on that case below.

What a web server must be managed and protected like

  • Patching: apply operating system and web server updates promptly. NIST SP 800-123 lists testing and applying patches in a timely manner as an ongoing task.
  • WAF: a web application firewall filters malicious requests. The OWASP Core Rule Set is a rule collection for ModSecurity-compatible firewalls and covers many attack categories in the OWASP Top Ten.
  • Least privilege: NIST SP 800-123 says service processes should run as a user with strictly limited rights, not as root.
  • Isolation between sites: a compromise of one site should not give access to the others. Use separate system users, file permissions and, where possible, separate PHP pools.
  • Backups: frequent, stored on separate storage, and restore-tested. NIST SP 800-123 calls for backing up critical information frequently.

What a mail server must be managed and protected like

Mail has stricter rules because other servers decide whether to accept your messages. Google requires all senders to authenticate with SPF or DKIM, and to have PTR (reverse DNS) records, TLS encryption and a low spam rate; bulk senders (more than 5,000 messages a day to Gmail) must also publish DMARC. Microsoft requires SPF, DKIM and DMARC for domains that send more than 5,000 messages a day to Outlook.com addresses, and since 5 May 2025 it rejects non-compliant mail from those senders.

  • Reverse DNS: M3AAWG requires one PTR name per IP that matches the forward DNS name.
  • SPF, DKIM and DMARC: publish all three and keep them aligned with the real sending systems. Our page on SPF, DKIM and DMARC for business email covers the setup.
  • Rate limiting: limit how many connections and messages a client can send per time unit. Postfix has options for this, such as smtpd_client_message_rate_limit.
  • TLS: encrypt connections between servers and to clients.
  • Spam and virus filtering: filter inbound mail and watch outbound mail for abuse.
  • Queue monitoring: a growing queue is an early sign of a compromised account or a delivery problem. M3AAWG lists blocklisting and abnormal volume changes among the things to monitor.
  • IP warm-up: M3AAWG advises a well-defined process for warming a new IP address, which means increasing volume gradually.
Area Web server Mail server
Open to Anyone on the internet, on HTTP and HTTPS Other mail servers and users, on SMTP and IMAP
What changes often Application code, plugins, themes Filter rules, authentication records, IP reputation
Typical attack Exploits in applications and plugins; uploaded scripts Stolen mailbox passwords; spam relaying; blocklisting
Key external dependency Search engines and visitors reaching the site Reputation of the IP and domain at receiving servers
Restore unit Files and database per site Mail directory, database and filter data

The table summarises the points above and is our own comparison, not a quotation from one source.

How we separate web and mail at CloudAcropolis

PFHW web servers do not carry mail server duties. Email is a separate add-on that runs on a Mailcow server in Vilnius. The reason is the one above: web traffic spikes and code errors should not interrupt mail. Outbound mail is rate-limited and sent through relays; in our reasoning this limits the damage a hacked script can do. Mail domains are managed from the PFHW panel.

Mail is priced by storage: 25 GB for €4 per month, 50 GB for €7, 100 GB for €10, and each extra 100 GB adds €10. Prices are in euros per month excluding VAT. Domains and mailboxes are unlimited. This is separate from the server plans, so you pay for mail only if you use it.

Separation does not remove all risk. A stolen mailbox password can still be used to send spam, and a hacked website can still harm other sites on the same web server if the accounts are not isolated. We reduce the effect of these events, we do not claim to prevent them.

When one server is acceptable

One server for web and mail can be a reasonable choice in some cases:

  • A very small site, such as a brochure site with a few mailboxes and little sending.
  • A personal or hobby project where a mail outage or a delisting would not harm a business.
  • A lab or test setup.
  • A team with the skills to monitor the mail queue, blocklists and authentication, and a tested recovery plan.

If you choose this, reduce the risk. Send website mail through an authenticated relay and not through local scripts. Keep sites updated and filtered by a WAF. Watch blocklist status and the mail queue. Set up SPF, DKIM, DMARC and reverse DNS before you send the first message. And write down how you would move mail to its own server, so that the decision can change when your needs grow.

Where PFHW fits, and where it does not

Where it fits

  • You host several client websites and want the web server kept free of mail duties.
  • You want mail domains managed from the same panel as your sites, with the mailboxes on a separate Mailcow server in Vilnius.
  • You want the data kept in the EU, in a Tier III data centre in Vilnius, Lithuania.

Where it does not, or where you should check first

  • Email is an add-on and is not included in server packages.
  • There is no webmail inside PFHW. Webmail belongs to the Mailcow server.
  • Autoresponders, email filters and spam-filter settings are not in the PFHW portal and are not imported from cPanel. Whatever Mailcow offers is on the mail server's own pages.
  • There are no mailing lists (Mailman), and the importer reports cPanel mailing lists as not imported.
  • There is no per-account dedicated IP management. Accounts use the shared server IPv4 and IPv6 addresses.

Frequently asked questions

Can I run a mail server and a web server on the same server?

Yes, it is technically possible. The risks are a shared IP reputation, resource competition and a larger blast radius when something fails. Small, low-volume setups can accept those risks if they monitor them.

Why does a hacked website affect my email?

A hacked site can send spam from the server's IP address. If that address is also your mail server's address, receiving servers or blocklists may then reject your normal mail. A separate mail server keeps its own address and history.

Do I need a dedicated IP address for mail?

M3AAWG notes that dedicated IP environments suit senders who need isolation, while shared ones combine the reputation of all senders. If mail matters to your business, a clean and stable address of its own removes one source of risk.

What DNS records does a mail server need?

At minimum, a PTR (reverse DNS) record that matches the server name, and SPF, DKIM and DMARC records for each sending domain. Google requires SPF or DKIM, a PTR record and TLS from all senders, and DMARC from bulk senders.

Does moving mail to a separate server remove all risk?

No. Accounts can still be compromised, and any server can be misconfigured. Separation limits how far a problem spreads. You still need authentication, filtering, rate limits and monitoring.

Does PFHW include email?

No. Email is a separate add-on on a Mailcow server in Vilnius, priced by storage from €4 per month for 25 GB, excluding VAT.

Related resources

Sources

Request a demo