Mailcow guide series: Part 1 of 7. Start with Part 1.
Next: Create an Oracle Cloud Server for Mailcow and Open the Right Ports
Want email at you@example.com without renting a complete mailbox service? Mailcow packages the main parts of an email system into a manageable Docker installation: the mail transfer agent, mailboxes, webmail, spam filtering, antivirus, and an administration page. This series builds a new installation using an Oracle Cloud Ubuntu server, Route 53 DNS, and Oracle Cloud Infrastructure (OCI) Email Delivery for outbound relay.
This is a real internet-facing service. A mail server stores private messages, receives attacks every day, and can damage your domain’s reputation if it sends spam. Work through the steps in order, use a domain you control, and do not point your existing email domain at the new server until you have tested it.
First, understand the mail journey
Incoming email and outgoing email use different routes:
Incoming: sender -> your domain's MX record -> your mail server on TCP 25 -> mailbox
Outgoing: mail app -> Mailcow on TCP 587 (encrypted login) -> OCI relay on TCP 587 -> recipient
An MX record tells other mail servers where to deliver incoming mail. TCP port 25 is the server-to-server delivery door. TCP port 587 is the authenticated submission door your phone, website, or desktop app uses to hand outgoing mail to Mailcow. An outbound relay is a separate service that accepts mail from your server and delivers it to the recipient’s mail server.
This split matters on Oracle Cloud: many OCI tenancies cannot make direct outbound connections to internet mail servers on TCP 25. An authenticated relay on port 587 avoids that restriction. It does not replace inbound port 25; other mail servers still need to reach yours to deliver incoming mail. Oracle describes the restriction in its outbound SMTP notice.
What you need before starting
- A domain name you own, such as
example.com. - Access to its authoritative DNS provider. This guide uses Route 53; if the domain’s nameservers point elsewhere, edit DNS there instead.
- A cloud account whose acceptable-use rules permit email hosting and a fixed public IPv4 address.
- An Ubuntu virtual machine. Mailcow officially supports Ubuntu 22.04 or newer and ARM64 or x86-64. Plan at least 6 GiB RAM plus 1 GiB swap and 20 GiB disk; 8 GiB RAM or more is a more comfortable starting point. Antivirus, full-text search, active mailboxes, and users all need memory. See Mailcow’s system requirements.
- A second place to store backups. A backup on the same VM will not help if that VM or disk is lost.
- A sender service for outbound mail. This guide uses OCI Email Delivery, which needs an OCI SMTP credential, verified email domain, and approved sender.
Do not use a home internet connection with a changing residential IP for a first production mail server. Providers may block port 25, change the address, or decline to set reverse DNS. A stable cloud IP with a provider-supported PTR record is much easier to operate.
Choose the host name and mail domain
In the examples, mail.example.com is the server’s permanent host name and example.com is the email domain. The host name should remain stable: certificates, mail client settings, and reverse DNS all depend on it. Do not use a CNAME as the target of an MX record; the MX target should resolve directly to an A or AAAA address.
Write down these placeholders before opening cloud consoles:
EMAIL_DOMAIN=example.com
MAIL_HOSTNAME=mail.example.com
PUBLIC_IPV4=203.0.113.10 # replace; this is documentation-only space
ADMIN_EMAIL=you@example.com
Keep real passwords, private keys, and OCI SMTP credentials in a password manager or protected secret store. Never put them in a blog post, Git repository, screenshot, support ticket, or shell command that will be saved in history.
Do not move existing email yet
If another provider currently receives mail for your domain, keep its MX record in place while you build Mailcow. Set up a test subdomain such as lab.example.com if you want to experiment without affecting real mail. When ready to migrate, reduce the existing MX record’s TTL ahead of time, copy any old messages you need, test the new server, then change the MX record during a planned window. Keep the old account active while DNS caches expire and you confirm that new mail reaches Mailcow.
The rest of the series:
- Part 2: Create the Oracle VM and network rules
- Part 3: Install Mailcow
- Part 4: Publish Route 53 DNS records
- Part 5: Configure an OCI outbound relay
- Part 6: Create accounts and test
- Part 7: Back up and recover
Official references: Mailcow prerequisites, Mailcow DNS guide, OCI Email Delivery overview.