Communications guide
Self-Hosted Email Server: The Deliverability Gate Before You Install
Use a strict DNS, network, reputation, staffing, backup, and recovery gate before making self-hosted email business-critical.
Published and reviewed by OpenAlt · October 1, 2026
Verdict: a small team should not put primary business mail on a self-hosted email server until it has a stable sending identity, DNS control, open network paths, monitoring, recovery procedures, and a named owner. You gain control and operational learning, but inherit delivery reputation, outages, backups, and security responsibilities.
Table of Contents
- Hard gate: the owner and network must exist first
- Why receiving mail is easier than earning outbound delivery
- mailcow as a concrete stack
- DNS checklist before mailbox creation
- Network and reputation checks before accepting a mailbox
- Backups must include messages, configuration, and keys
- Monitoring is part of the mail service
- Safer choices and the final go/no-go scorecard
- FAQ
Hard gate: the owner and network must exist first
Do not run primary business mail without a stable public identity, usable ports, DNS control, monitoring, and one accountable owner. Full virtualization, network access, and DNS are explicit mailcow prerequisites; operational ownership keeps the service usable over time. See the mailcow system prerequisites.
Before creating a mailbox, confirm:
- A stable public IP and matching PTR plan exist.
- Required mail ports are open, documented, and externally tested.
- The team controls the sending and receiving domains.
- Someone owns alerts, updates, incidents, and user support.
- A recovery location and restore procedure are documented.
- The team can tolerate an outbound-delivery incident.
If any item is uncertain, decide “not yet.” Reachability alone does not make the service safe for invoices, account recovery, customer replies, or internal approvals.
Why receiving mail is easier than earning outbound delivery
Receiving mail is mostly a reachability problem; outbound delivery is a continuing trust problem. Sender authentication and sending practices affect whether other providers accept or prioritize messages from your domain. Review Google’s sender requirements.
Treat outbound delivery as an ongoing service:
- Keep the sending identity consistent.
- Publish and maintain authentication records.
- Watch deferred and failed messages.
- Investigate unusual sending or authentication failures.
- Provide a fallback for urgent communication.
A working login page proves little. The team may receive normally while replies are delayed, filtered, or rejected elsewhere. Acceptance testing must include whether the team can detect and respond when delivery quality changes.
mailcow as a concrete stack
mailcow dockerized is a service stack, not a single binary, so its components and Docker volumes create several stateful surfaces to operate and protect. The documented minimum is 6 GiB of RAM plus 1 GiB of swap, with 20 GiB of disk excluding mail storage; full virtualization, ports, and DNS are also required. Consult the mailcow overview and official prerequisites.
Plan for more than the first mailbox:
- Reserve memory for the stack and supporting services.
- Treat 20 GiB as system space, not a complete mail archive.
- Separate mail growth from operating-system capacity.
- Confirm the virtualization layer supports the workload.
- Record where Docker volumes, configuration, and keys live.
A small virtual machine may meet the minimum yet remain unsuitable if nobody watches disk usage or knows which volumes contain business data.
DNS checklist before mailbox creation
Treat DNS as one identity chain. Before accepting a mailbox, verify that A/AAAA, MX, PTR, SPF, DKIM, DMARC, and the server hostname consistently describe the intended service. Use the mailcow documentation and Google’s sender guidance.
Preflight each record:
- A/AAAA: resolve the mail hostname to the intended public address.
- MX: point the receiving domain to the intended mail service.
- PTR: map the sending address to a stable hostname.
- SPF: identify the authorized sending path.
- DKIM: publish the public verification record for signed mail.
- DMARC: define how authentication results should be handled.
- Hostname consistency: align server name, forward DNS, reverse DNS, and certificate naming.
Document expected values and who can change them. DNS access that depends on an unavailable contractor, former employee, or forgotten registrar account is not operational control.
Network and reputation checks before accepting a mailbox
A mailbox is ready only after external reachability, stable addressing, reverse-DNS ownership, required ports, and reputation monitoring are confirmed. These checks build on mailcow’s documented need for virtualization, ports, and DNS. See the prerequisite list.
Run a controlled acceptance review:
- Confirm the public address and hostname are documented.
- Verify inbound and outbound paths from outside the hosting network.
- Check that DNS changes propagated as expected.
- Define an unacceptable delivery failure or delay.
- Record escalation contacts for the host, DNS provider, and registrar.
Do not make users dependent on the service until the team knows who investigates a queue, unreachable host, certificate warning, or reputation problem.
Backups must include messages, configuration, and keys
A useful backup covers messages, database state, configuration, Docker volumes, and cryptographic keys, then proves recovery works. Mailcow documents an official backup_and_restore helper and retention example. Start with the backup and restore guidance.
Use a recovery sequence someone else can follow:
- Identify every data source required to rebuild the service.
- Store backups away from the primary host and restrict access.
- Apply a documented retention policy.
- Restore into an isolated environment or controlled recovery target.
- Verify representative messages, accounts, configuration, and key access.
- Record the restore date, owner, gaps, and next corrective action.
A successful backup job is not proof of a recoverable mail service. If the team cannot restore messages and decrypt required data, recovery is incomplete.
Monitoring is part of the mail service
Monitoring must cover queues, certificates, blocklists, disk capacity, authentication failures, and host availability. These signals turn silent degradation into an actionable incident. The mailcow documentation describes the stack and volumes; the alerting policy remains an operational responsibility.
Assign an owner and response rule for each signal:
- Queues: investigate growing or aging deferred mail.
- Certificates: renew before users and remote servers see failures.
- Blocklists: assess listing changes before delivery is broadly affected.
- Disk: alert before mail or system storage is exhausted.
- Authentication failures: distinguish mistakes from abuse.
- Availability: escalate when the host, network, or DNS path is unavailable.
Every alert should identify the first diagnostic action and its owner.
Safer choices and the final go/no-go scorecard
Host your own email only when the team can own delivery, recovery, and daily operations; otherwise, use a hosted mailbox, relay, or noncritical lab. OpenAlt’s self-hosted resources, email newsletter coverage, and SLA downtime calculator can help frame the tradeoff.
| Area | Go when… | No-go when… |
|---|---|---|
| Network | IP, PTR, ports, and DNS are controlled | Reachability depends on guesswork |
| Delivery | Authentication and response rules are owned | Nobody watches outbound failures |
| Capacity | Memory, swap, and storage are planned | Minimums are treated as a full plan |
| Recovery | Backups and restore steps are tested | Only the backup job is configured |
| Staffing | One owner and escalation path exist | Mail is “everyone’s responsibility” |
| Risk | A failure has an acceptable fallback | Business-critical mail has no fallback |
If one critical row is “no-go,” delay primary adoption. A lab or secondary domain can still provide learning without making every business conversation depend on an immature service.
FAQ
Is self-hosted email suitable for a small team?
It can be, but only when the team has DNS control, a stable network identity, monitoring, backups, restore capability, and an owner. Begin with noncritical mail or a lab unless those responsibilities are explicit.
Is mailcow enough to solve deliverability?
No. Mailcow provides a concrete stack to operate, but delivery also depends on sender authentication, sending practices, DNS consistency, network reachability, and reputation management.
What should be backed up first?
Back up messages, database state, configuration, Docker volumes, and mail and encryption keys. Then perform a documented restore test; a backup that cannot recreate usable mail data and key access is incomplete.
When should a team choose a hosted mailbox or relay?
Choose one when the team cannot continuously own DNS, delivery monitoring, incident response, or restoration. Self-hosting becomes reasonable when the scorecard is complete and a fallback exists.