Self-Hosted Mail on Oracle Cloud: Overview and Starting Point
This is not a step-by-step walkthrough. It is an orientation for anyone who wants to understand what they are getting into before they start. Topics covered: why you would do this at all, which platform to use, what DNS has to do with mail, and which security mechanisms are non-negotiable.
Why Run Your Own Mail Server?
Most people use Gmail, Outlook, or whatever comes bundled with their hosting plan — and for most purposes that is completely fine. Still, there are solid reasons to run your own:
- Learning by doing: Running a mail server is technically demanding. DNS, TLS, authentication standards, deliverability — you learn topics that no tutorial covers completely, because the only way to understand them is to debug them yourself.
- Privacy and control: Your email lives on your own server, not on a corporate platform. Whoever controls the hardware controls the data.
- Catch-all addresses: With your own domain you can configure
*@example.com— all mail sent to the domain lands in the same inbox regardless of the prefix used. Useful for registrations and for tracing which services sell your address. - Effective spam filtering: A self-operated mail server gives you granular control over filtering rules and blocklist configuration.
- Portfolio value: Being able to explain how SPF, DKIM, and DMARC work together demonstrates infrastructure knowledge that comes up frequently in IT job interviews.
- Because you can: Some motivation needs no justification.
A mail server is not a set-and-forget project. Deliverability — whether your outgoing mail actually reaches Gmail, Outlook, and others without landing in spam — is the genuinely hard problem. Not the installation, not the configuration: the reputation management of an IP address. More on that below.
The Platform: OCI Always Free Tier
Oracle Cloud offers the Always Free Tier at oracle.com/cloud/free — a fixed resource allowance that never expires. No other major cloud provider offers anything comparable. For a single mail server the allowance is more than enough:
- ARM-based compute instances (OCI Ampere A1): up to 4 VMs with 24 GB RAM total — a single instance with one ARM core and 6 GB RAM is realistic and sufficient
- Outbound data transfer: 10 TB per month
- Block storage: up to 200 GB total
- Archive storage: 20 GB for backups
- 1 network load balancer
- 50 IPSec connections
AWS Free Tier expires after 12 months. Hetzner and similar providers cost 3–5 EUR/month. OCI Always Free Tier is permanently free — the trade-off is a more involved registration process and some operational quirks you need to know about (see Pitfalls).
Pitfalls and Limitations
Registration Can Fail
Signing up for OCI involves a credit card verification step. In some regions the Free Tier is currently unavailable, or the verification fails without a clear error message. This is a known issue, not a mistake on your end. The list of available regions is at oracle.com.
Idle Reclaim: Inactive Resources Get Taken Back
OCI reserves the right to reclaim Free Tier compute instances if their CPU, network, and memory utilisation stays below 20% at the 95th percentile for 7 consecutive days. A mail server with low traffic volume can fall below this threshold.
The common approach is a shell script running in a cron job that produces minimal CPU load — for example by running repeated calculations or making network requests at regular intervals. Not elegant, but it works.
Home Region Cannot Be Changed
When creating an account you select a home region. This region holds the account's identity and access management data and cannot be changed after the tenancy is provisioned. Choose carefully from the start — picking a region geographically close to you is the right default.
Paid Accounts Take Priority
When resources are scarce, paying customers are served first. Free Tier instances may not be restartable or provisionable in those situations. In practice this rarely affects running instances — but it can be frustrating during initial setup.
The Building Blocks
A working mail server on OCI consists of four layers. Here is the conceptual overview — without the detail of every individual step:
1. Register a Domain
A domain of your own is the prerequisite for everything else. Registrars like
Cloudflare Registrar, Ionos, or GoDaddy let you register a .de domain
for around 10 EUR/year. Cloudflare Registrar is a reasonable choice because
Cloudflare also handles DNS and propagates changes quickly.
2. Create a VPS
For this mail server we use Debian. Oracle Cloud does not offer Debian as a standard image — the solution is BYOI (Bring Your Own Image): a custom Debian image is imported into OCI as a custom image and used as the instance base. How to create and import that image is covered in a dedicated guide.
3. Install a Control Panel
HestiaCP is an open source web panel that bundles a complete LAMP stack (Linux, Apache, MySQL, PHP) together with Postfix, Dovecot, and SpamAssassin in a single installer script. It handles a significant amount of configuration work without removing your control entirely — a sensible starting point. For those who do not need a full stack, Cockpit is a lightweight web UI alternative for system monitoring and management.
4. Configure DNS
After installation you need to set DNS records so that mail can find your server and so that your server is recognised as a legitimate sender. This is the most technically demanding part — and the one that determines deliverability.
Outbound Mail: SMTP Relay
OCI blocks all outbound traffic on port 25 regardless of firewall rules or NSG configuration. Without an SMTP relay, no outbound mail is possible.
OCI Email Delivery
Oracle Cloud provides OCI Email Delivery, its own SMTP relay service that works within the Always Free Tier:
- Free up to 100 emails per day
- Connection on port 587 with STARTTLS
- Authentication via AUTH PLAIN only — not AUTH LOGIN
- Sender addresses must be added as "Approved Senders" in the OCI dashboard before mail can be sent
- OCI signs outgoing mail with its own DKIM key — in addition to the mail server's own DKIM (both signatures are valid)
- SPF must explicitly include the OCI relay servers
OCI Email Delivery only supports AUTH PLAIN. Postfix and HestiaCP default to AUTH LOGIN — this requires a manual configuration change before the relay works.
Alternative: Brevo
Brevo (formerly Sendinblue) is a simpler alternative. The free plan allows up to 300 emails per day and supports AUTH LOGIN — making it compatible with HestiaCP without additional configuration changes.
When using an external relay, its servers must be included in the domain's SPF record — otherwise SPF checks at the receiving end will fail. The relay service also signs outgoing mail with its own DKIM key, alongside your mail server's own DKIM signature. Both signatures appear in the mail headers and are not a problem — as long as both public keys are correctly published in DNS.
DNS for Mail
Email does not work like web traffic. There is no central routing authority — instead, a sending server locates the receiving server exclusively through DNS records. These records must be set correctly for mail to be delivered:
Core Records
- A record: Maps the domain name to the server's IP address.
Example:
example.com → 91.15.97.33 - NS record: Specifies which nameservers are authoritative for the domain.
- MX record: The Mail Exchanger — indicates which server should receive incoming email for the domain. Without a valid MX record, no one can send email to your domain.
- PTR record (reverse DNS): Maps an IP address back to a hostname — the inverse of the A record. Receiving mail servers check whether the hostname of the sending IP matches the A record. A missing or mismatched PTR record is one of the most common reasons new servers end up in spam or get rejected outright. On OCI the PTR record is set in the networking console.
- SOA record: Start of Authority — contains administrative information about the zone and is usually set automatically by your DNS provider.
Large mail providers like Gmail and Outlook run automated reputation checks on incoming connections. A missing or non-matching PTR record is one of the most common reasons mail from new servers gets flagged as spam. It signals that the operator of the IP address actually controls the domain — a basic trust indicator that receiving servers look for before anything else.
Mail Security: SPF, DKIM, DMARC and More
These records are the core of modern mail authentication. Without them correctly configured, outgoing mail will land in spam reliably — and some providers will reject it outright.
A DNS TXT record that specifies which IP addresses and servers are authorised to send mail on behalf of your domain. Receiving servers check on arrival whether the sending IP is listed in the sender domain's SPF record. A missing or incorrect SPF record is a strong spam signal.
DKIM signs every outgoing email cryptographically — headers and body are signed with a private key held on your mail server. The corresponding public key is published as a DNS TXT record. Receiving servers use this to verify that the message genuinely originated from the stated server and was not modified in transit.
DMARC builds on SPF and DKIM and defines what should happen to messages that
fail both checks: none (monitor only), quarantine
(send to spam), or reject (drop). DMARC also enables receiving
reports about failed authentication attempts — useful for detecting if your
domain is being spoofed.
Additional Recommended Records
- CAA record: Specifies which Certificate Authorities are allowed to issue SSL certificates for your domain. Prevents unauthorised certificate issuance.
- MTA-STS (RFC 8461): Enforces TLS encryption for inbound SMTP connections. Similar to HSTS for HTTP — prevents downgrade attacks on the mail transport layer.
- DNSSEC (RFC 4033): Cryptographic signing of the domain's DNS records. Prevents DNS answers from being tampered with in transit (DNS spoofing).
- BIMI (Brand Indicators for Message Identification):
Displays a sender logo in supporting mail clients. Requires a valid DMARC
policy of
rejectorquarantine. Nice to have rather than necessary.
Tools and Resources
These projects and tools are directly relevant to running a mail server on OCI:
- dnschecker.org — Checks DNS records globally across many resolvers.
- mxtoolbox.com — Mail server diagnostics: MX, SPF, DKIM, blacklist status, SMTP test.
- easydmarc.com — Generator and tester for DMARC, SPF, and DKIM records. A good starting point before editing records by hand.
Summary
- OCI Always Free Tier is permanently free — but registration can be difficult, and idle reclaim is a real risk for lightly used instances.
- DNS is the critical path. Without correct A, MX, and PTR records the mail server simply does not work. Without SPF, DKIM, and DMARC your outgoing mail will reliably land in spam.
- HestiaCP takes care of a lot of the work — it configures Postfix, Dovecot, and SpamAssassin automatically. The DNS records you still need to understand and set yourself.
- Deliverability is the actual hard problem. A new IP address has no reputation. It takes time and correct configuration before outgoing mail arrives reliably.
- The home region in OCI cannot be changed. This decision needs to be made carefully when creating the account.
- The project is worth it. Anyone who sees it through will understand how mail infrastructure actually works — a topic that most courses and certifications cover only superficially.
- OCI blocks port 25. Outbound mail only works through an SMTP relay service. OCI Email Delivery is the natural choice — Brevo is a simpler alternative.
This article is an overview — a production setup has more moving parts. For specific questions about configuration, migration, or operations, reach me via the contact page.
Open Source Projects Used
- HestiaCP — Open source web panel for Linux servers; source code on GitHub
- Exim4 — MTA (Mail Transfer Agent) handling inbound and outbound SMTP; source code on GitHub
- Dovecot — IMAP and POP3 server for mailbox access; source code on GitHub
- SpamAssassin — Spam filter; source code on GitHub
- Roundcube — Browser-based webmail client; source code on GitHub
- Cockpit — Web-based server management; source code on GitHub