Mailboxes and forwarders for the domains you already host, on the server you already pay for, managed from the same panel as your sites. This page covers what running your own mail stack on Linux actually takes, the sender rules Gmail enforces, and the point where buying hosted email is the smarter call.
# free plan · no credit card required
hetzner digitalocean aws ovhcloud vultr linode
A self hosted mail server is a mail stack you run on your own Linux box, usually Postfix for SMTP and Dovecot for IMAP, so mailboxes for your domains sit on infrastructure you control instead of a per user subscription. The software is free; the real cost is deliverability, because Gmail requires matching forward and reverse DNS, a TLS connection, and SPF or DKIM on every sending domain, plus DMARC and one click unsubscribe once you pass 5,000 messages a day. Self hosting pays off when you need many low volume domain mailboxes and forwarders. It stops paying off when a large team lives in email all day, where Microsoft 365 Business Basic at $7.00 per user per month is simply the better buy.
Last updated August 2026
Postfix moves mail between servers, Dovecot serves it over IMAP and POP3, and both are packaged in every mainstream Linux distribution at no cost. A working install is an afternoon. Everything that follows on this page is the reason people still get this wrong six months later.
An MX record points mail at your server, an SPF TXT record says which hosts may send for the domain, DKIM publishes the public key that signs your outbound mail, and DMARC tells receivers what to do when the first two disagree. Gmail's published sender guidelines require SPF or DKIM on every sending domain, and both plus DMARC once you send in bulk.
Gmail requires valid forward and reverse DNS, and the sending IP has to match the address of the hostname in the PTR record. On most clouds the PTR is set in the provider console, not in your DNS zone, which is why it is the single most commonly missed record on a new mail server.
Most cloud providers block outbound port 25 by default and unblock it only on request, so plan for that before launch day. You also inherit whatever reputation the previous tenant of that IP address left behind, which is worth checking against the public blocklists before you send a single message.
Gmail asks senders to keep the spam rate reported in Postmaster Tools below 0.3 percent, and recommends staying under 0.10 percent. A new IP has no history, so volume has to ramp gradually. There is no way to buy your way past this step and no support ticket that fixes it faster.
Mailboxes only grow, and a lost mailbox is worse than a lost website because there is no rebuild from Git. Sending servers retry for a few days, so a short outage is survivable, but the backup and restore path has to be real and tested rather than assumed.
Give mail its own server or at least its own IP address, so a compromised web app cannot burn the reputation your mail depends on. Open a ticket with the provider to unblock outbound port 25 and confirm you can set a custom PTR record for that IP before you commit to it.
MX, SPF, DKIM, DMARC and PTR all need to be correct and consistent on day one. A single bad send from a misconfigured domain teaches receivers something about you that takes weeks to unlearn, so verify the records first and send test mail to a throwaway address second.
Create the real addresses per domain, plus the role accounts people forget: postmaster and abuse are expected to exist and to be read. Forwarders cover every client contact address that needs to land somewhere without becoming a whole mailbox you have to maintain.
Start with low volume to real recipients who want the mail, and increase gradually. Register the domain in Google Postmaster Tools and Microsoft SNDS so you can see the spam rate rather than guess at it, and treat any climb toward 0.3 percent as the emergency it is.
Panel license prices below were read off each vendor's own pricing page on 13 August 2026 and the Microsoft figure on 14 August 2026. The open source column is genuinely free software, and this table does not pretend otherwise.
swipe to see all columns →
| DeployManage on your server | cPanel, Plesk or DirectAdmin | mailcow, iRedMail or Mail-in-a-Box | Microsoft 365 Business Basic | |
|---|---|---|---|---|
| Billing model | Flat panel fee, unlimited mailboxes and forwarders per domain, cloud server billed to you directly | License tier metered by account (cPanel) or by domain (Plesk) | No license fee, the software is open source | Per user, per month, on an annual subscription |
| Price, verified August 2026 | Free to start | cPanel Solo $29.99/mo for one account; DirectAdmin Standard $29/mo unlimited; Plesk Web Admin 6.60 EUR/mo for 10 domains | $0 for the open source editions | $7.00 per user per month, up to 300 users |
| Who operates the mail stack | You do, on your server, provisioned from the panel | You do, on your server | You do, all of it | Microsoft does |
| Mailboxes included | Unlimited per domain | Bounded by the account or domain tier you bought | Unlimited | One mailbox per paid user |
| Mailbox storage | Whatever the disk on your server holds | Whatever the disk holds | Whatever the disk holds | 100 GB primary plus 50 GB archive per user |
| Deliverability is your responsibility | Yes | Yes | Yes | No |
| Webmail and groupware bundled | Not the focus, connect any IMAP or desktop client | Yes, webmail included | Yes, webmail included | Yes, Outlook on the web and Teams |
| Deploys your application code too | Yes, zero downtime releases with rollback | Partly, Git deploys but not a release pipeline | No, mail only | No |
| Best fit | Domain mailboxes and forwarders next to the sites they belong to | Reselling hosting, or running a full mail stack with DNS and FTP | Teams who want to own and operate every layer themselves | A company whose staff live in email all day |
| Where it loses | Not a groupware suite, and you still own deliverability | You pay per account or per domain even when you never resell | Every upgrade, backup and blocklist appeal is yours to handle | Cost scales linearly with headcount, forever |
Each client needs one contact address and maybe a forwarder to the account manager. Paying a per user price for 40 addresses that receive a handful of messages a week is the worst possible fit for per seat pricing, and it is the clearest case for mailboxes on a server you already run.
You need billing@, support@ and a sending domain for password resets. Nobody on the team lives in those inboxes. A mail stack next to the app servers covers this without adding a per seat line to the bill for every engineer who never opens it.
If you are already provisioning boxes, holding root and handling TLS and firewalls, mail is one more managed service rather than a new discipline. The marginal cost is real but small, and the data stays on infrastructure you already trust and already back up.
Thirty people who spend their day in a mail client, with shared calendars, mobile sync and a compliance team asking about retention, are not a self hosting problem. Microsoft 365 Business Basic at $7.00 per user per month buys guaranteed delivery and someone else's on call rota, and that is money well spent.
A self hosted mail server is a mail stack running on hardware or a virtual machine you control, so incoming and outgoing mail for your domains is handled by your server rather than by a provider who charges per mailbox. In practice it is several programs that each do one job.
| Component | Job | Common choice |
|---|---|---|
| MTA | Accepts and relays mail over SMTP between servers | Postfix, Exim |
| MDA and IMAP server | Stores mail and serves it to your mail client | Dovecot |
| DKIM signer | Cryptographically signs outbound mail so receivers can verify it | OpenDKIM, Rspamd |
| Spam and policy filter | Scores inbound mail and enforces rules | Rspamd, SpamAssassin |
| TLS certificates | Encrypts SMTP and IMAP connections | Let's Encrypt |
Bundles like mailcow, iRedMail and Mail-in-a-Box assemble those pieces for you, and hosting panels such as cPanel, Plesk and DirectAdmin wrap them in an account model. DeployManage takes the narrower path: it provisions the server, manages the sites and databases on it, and adds mailboxes and forwarders per domain in the same panel, without metering you per account.
Sometimes. The honest test is how many addresses you need and how much each one is used, because hosted email prices per person while a server prices per box.
| Scenario | Hosted at $7.00 per user per month | Your own server | Better buy |
|---|---|---|---|
| 5 staff who live in email | $35 per month | Server, plus your time on DNS and reputation | Hosted |
| 40 client contact addresses, low volume | $280 per month | One server you already run | Your own server |
| 3 role accounts and app mail | $21 per month | Mailboxes beside the app | Either, on preference |
| 30 staff plus compliance retention | $210 per month | Server, plus retention and legal hold you build | Hosted |
The pattern is consistent: self hosting wins on many cheap addresses and loses on many busy humans. The cost that never appears in a spreadsheet is the hour you spend on a blocklist appeal, so if nobody on the team wants to own that, buy the hosted seat and spend the time elsewhere.
Six things have to be true before your first send. Miss any one and mail will be accepted by your server and quietly discarded by the receiver.
| Requirement | Why it matters | Where it is set |
|---|---|---|
| MX record | Tells the world which host accepts mail for the domain | Your DNS zone |
| SPF record | Lists the hosts allowed to send for the domain | TXT record in your DNS zone |
| DKIM key | Signs outbound mail so receivers can verify it was not altered | TXT record plus the signer on the server |
| DMARC policy | Tells receivers what to do when SPF and DKIM fail | TXT record at _dmarc |
| PTR record | Reverse DNS that must match the sending host, required by Gmail | Your cloud provider console |
| Outbound port 25 | Without it your server cannot deliver anywhere | Provider support request |
A static IP is effectively mandatory too, because the PTR record has to keep matching. This is the same discipline that a production server setup checklist applies to the rest of the stack, just with less forgiving referees.
There is no single answer, because the options differ in how much they assemble for you and how much they charge. All of the following run on mainstream Linux distributions.
| Option | Shape | Cost | Suits |
|---|---|---|---|
| Postfix and Dovecot | The components themselves, configured by hand | Free | Engineers who want exact control |
| mailcow | Full stack in containers with an admin UI, GPLv3 | Free | Teams comfortable with Docker |
| iRedMail | Installer that assembles a complete stack | Free edition, paid admin panel separately | A conventional server install |
| Mail-in-a-Box | Opinionated single box setup, few decisions | Free | One domain, minimal fuss |
| cPanel, Plesk, DirectAdmin | Hosting panels with mail as one module | Paid license per account or domain | Reselling hosting |
| DeployManage | Deployment panel with mailboxes per domain | Free to start | App servers that also need domain mail |
If mail is the only thing the server does, one of the free bundles is a perfectly good answer and we will not argue otherwise. The case for a panel is different: it matters when the same box also runs your applications and you would rather not operate two separate control planes. That is the same reasoning behind choosing a server management panel over a pile of shell scripts.
Almost always because of authentication or reputation, not because of the message. Google publishes its sender requirements, and they are specific enough to check off one at a time.
| Gmail requirement | Applies to |
|---|---|
| SPF or DKIM configured for the sending domain | Every sender |
| Valid forward and reverse DNS, with the sending IP matching the PTR hostname | Every sender |
| A TLS connection for transmitting mail | Every sender |
| Spam rate in Postmaster Tools kept below 0.3 percent | Every sender |
| SPF and DKIM together, plus a DMARC policy that may be set to none | Senders above 5,000 messages a day |
| One click unsubscribe headers on marketing and subscribed mail | Senders above 5,000 messages a day |
Google also recommends keeping the spam rate under 0.10 percent rather than merely under the 0.3 percent threshold, because the reported figure moves slowly and you want headroom. If everything above is correct and mail still lands in spam, the usual culprit is the IP address history you inherited, which improves with a slow, steady warm up and nothing else.
Most teams do not want a mail project. They want the contact address on a client domain to work, and they want it in the same place they already manage the site. That is the practical argument for keeping mail on the servers you already provision: one panel, one audit trail, one set of credentials, one backup policy.
The trade is real and worth stating plainly. You keep root and you keep the bill flat as addresses multiply, and in exchange deliverability stays your problem forever. A hosted provider absorbs that problem and charges per head for it. Neither is a trick; they are two different products, and the number of humans on your team decides which one is cheaper.
If you are already weighing panels for the rest of the stack, the mail question usually rides along with the wider one about which server management panel to standardise on, and about whether you want to keep paying a hosting panel per account for multi tenancy you never resell.
A self hosted mail server is a mail stack running on a machine you control, typically Postfix for SMTP and Dovecot for IMAP, so mail for your domains is stored and delivered by your own server. You own the configuration, the storage and the sending reputation, and you pay for the server rather than for each mailbox.
It is worth it when you need many low volume addresses, such as contact mailboxes and forwarders across a lot of client domains, because per user pricing punishes that shape badly. It is not worth it when a large team lives in email all day and expects shared calendars, mobile sync and guaranteed delivery.
The software can cost nothing, since Postfix, Dovecot, mailcow and Mail-in-a-Box are all free and open source. Your real costs are the server itself, the storage that mailboxes consume as they grow, and the engineering time spent on DNS, reputation and the occasional blocklist appeal.
For hand configured control, Postfix paired with Dovecot remains the standard. mailcow suits teams comfortable with Docker, iRedMail suits a conventional install, and Mail-in-a-Box suits a single domain with minimal decisions. If the same server also runs your applications, a panel that manages mail alongside sites saves you a second control plane.
Yes, in practice. Gmail requires that the sending IP matches the hostname in its PTR record, and a changing address breaks that match every time it moves. Dynamic residential addresses are also widely blocked outright by receivers, regardless of how correct the rest of your configuration is.
Cloud providers block outbound port 25 by default to limit spam from compromised instances. Most will unblock it on request once you explain the use case, but you should confirm the provider's policy before you build anything, because without port 25 your server cannot deliver mail to anyone.
Usually authentication or reputation. Check that SPF or DKIM is configured, that forward and reverse DNS match, and that mail is sent over TLS, since Gmail requires all three. If those are correct, the cause is normally a cold or previously abused IP address, which only improves through a gradual warm up.
Gmail requires SPF or DKIM from every sender, and requires SPF and DKIM together plus a DMARC record once you send more than 5,000 messages a day. Even below that threshold, configuring all three is the cheapest insurance available, because receivers other than Gmail apply their own stricter rules.
Google asks senders to keep the spam rate reported in Postmaster Tools below 0.3 percent, and recommends staying below 0.10 percent. The figure updates slowly, so treat any sustained climb as urgent rather than waiting for it to cross the published threshold before acting.
Technically yes, but delivery will be poor. Residential IP ranges are widely blocked by receivers, home connections rarely allow outbound port 25, and you usually cannot set the PTR record that Gmail requires. A cheap cloud server avoids all three problems for a few dollars a month.
Far more than most teams need. Mail is light on CPU and heavy on disk, so the practical limit is storage and backup time rather than processing power. A modest virtual machine comfortably serves dozens of domains and hundreds of low volume mailboxes before sizing becomes a real conversation.
It is more private, not automatically more secure. Nobody else reads or scans your mail, which is the genuine benefit. Against that, a hosted provider patches faster than most small teams and runs threat detection you would have to build, so security depends entirely on how well you actually operate the server.
Provision on the cloud you already pay for, keep root, and manage mailboxes and forwarders per domain in the same panel that handles your sites, databases, certificates and zero downtime releases. Free to start.
# free plan · no credit card required