Freorit

Open Source & Security Practitioner
Mail OCI Überblick Open Source Stand: 2025

Eigener Mailserver auf Oracle Cloud: Überblick und Einstieg

Dieser Artikel ist kein Schritt-für-Schritt-Guide. Er ist eine Orientierungshilfe für alle, die verstehen wollen, worauf man sich einlässt — bevor man anfängt. Themen: warum man das tun würde, welche Plattform genutzt wird, was DNS mit Mail zu tun hat, und welche Sicherheitsmechanismen unverzichtbar sind.

Warum ein eigener Mailserver?

Die meisten Leute nutzen Gmail, Outlook oder einen Anbieter ihres Hosting-Pakets — und das ist für viele Zwecke vollkommen in Ordnung. Trotzdem gibt es gute Gründe, es selbst zu betreiben:

Realistische Erwartungen

Ein Mailserver ist kein Set-and-forget-Projekt. Deliverability — also ob eigene Mails bei Gmail, Outlook und Co. ankommen und nicht im Spam landen — ist das eigentliche schwierige Problem. Nicht die Installation, nicht die Konfiguration: das Reputationsmanagement einer IP-Adresse. Dazu später mehr.

Die Plattform: OCI Always Free Tier

Oracle Cloud bietet unter oracle.com/cloud/free den Always Free Tier — ein festes Ressourcenkontingent, das dauerhaft kostenlos bleibt. Das Always Free Tier ist das, was uns hier interessiert — und ein Angebot, das in dieser Form kein anderer grosser Cloud-Anbieter macht. Für einen einzelnen Mailserver reicht das Kontingent problemlos:

Warum OCI und nicht AWS Free Tier oder Hetzner?

AWS' Free Tier läuft nach 12 Monaten aus. Hetzner und ähnliche Anbieter kosten 3–5 EUR/Monat. OCI Always Free Tier ist dauerhaft kostenlos — der Kompromiss sind eine aufwändige Registrierung und Besonderheiten, die man kennen muss (siehe Fallstricke).

Fallstricke und Einschränkungen

1

Registrierung kann scheitern

Die Registrierung für OCI ist mit einer Kreditkartenprüfung verbunden. In manchen Regionen ist der Free Tier derzeit nicht verfügbar oder die Verifizierung schlägt ohne klaren Fehlerhinweis fehl. Das ist kein Fehler auf deiner Seite — es ist ein bekanntes Problem. Die Liste verfügbarer Regionen findet sich unter oracle.com.

2

Idle-Reclaim: inaktive Ressourcen werden zurückgefordert

OCI behält sich das Recht vor, Compute-Instanzen des Free Tier zurückzufordern, wenn deren CPU-, Netzwerk- und Speicherauslastung über 7 Tage hinweg am 95. Perzentil unter 20 % liegt. Ein Mailserver mit wenig Aufkommen kann diesen Schwellwert unterschreiten.

Workaround: Künstliche Last erzeugen

Der übliche Ansatz ist ein Shell-Skript, das in einem Cron-Job läuft und minimale CPU-Last erzeugt — zum Beispiel durch wiederholte Rechenoperationen oder Netzwerkanfragen. Das ist kein eleganter, aber ein funktionierender Kompromiss.

3

Home Region ist unveränderlich

Bei der Kontoerstellung wird eine Home Region festgelegt. Diese Region enthält die Identitäts- und Zugangsdaten des Accounts und kann nach der Provisionierung nicht mehr geändert werden. Man sollte also von Anfang an die gewünschte Region wählen — am besten eine in geografischer Nähe.

4

Paid Accounts haben Vorrang

Wenn Ressourcen knapp sind, werden zahlende Kunden bevorzugt bedient. Free-Tier- Instanzen können in solchen Situationen nicht neu gestartet oder provisioniert werden. Im laufenden Betrieb ist das selten ein Problem — beim erstmaligen Einrichten kann es frustrierend sein.

Die Bausteine

Ein funktionsfähiger Mailserver auf OCI besteht aus vier Schichten. Hier ist der konzeptionelle Aufbau — ohne die Details jedes einzelnen Schritts:

1. Domain registrieren

Eine eigene Domain ist die Grundvoraussetzung. Anbieter wie Cloudflare Registrar, Ionos oder GoDaddy ermöglichen die Registrierung einer .de-Domain für ca. 10 EUR/Jahr. Cloudflare Registrar ist eine gute Wahl, weil Cloudflare auch als DNS-Verwaltung genutzt werden kann und die DNS-Änderungen schnell propagieren.

2. VPS erstellen

Für diesen Mailserver nutzen wir Debian. Oracle Cloud bietet Debian nicht als Standard-Image an — die Lösung ist BYOI (Bring Your Own Image): ein eigenes Debian-Abbild wird als Custom Image in OCI importiert und dient als Grundlage der Instanz. Wie das geht, ist Thema eines eigenen Guides.

3. Control Panel installieren

HestiaCP ist ein Open-Source-Webpanel, das einen vollständigen LAMP-Stack (Linux, Apache, MySQL, PHP) inklusive Postfix, Dovecot und SpamAssassin in einem Installer-Skript bündelt. Es nimmt viel Konfigurationsarbeit ab, ohne die Kontrolle vollständig zu entziehen — eine vernünftige Wahl für den Einstieg. Wer keinen vollständigen Stack braucht, kann alternativ Cockpit als leichtgewichtiges Web-UI für den Systemüberblick einsetzen.

4. DNS konfigurieren

Nach der Installation müssen DNS-Records gesetzt werden, damit E-Mails den Server finden können und der Server als legitimer Absender erkannt wird. Das ist der technisch anspruchsvollste Teil — und der entscheidende für Deliverability.

Ausgehende Mail: SMTP-Relay

Port 25 ist auf OCI blockiert

OCI blockiert ausgehenden Verkehr auf Port 25 für alle Instanzen — unabhängig von Firewall-Regeln oder NSG-Konfiguration. Ohne SMTP-Relay ist kein Mailversand möglich.

OCI Email Delivery

Oracle Cloud bietet mit OCI Email Delivery einen eigenen SMTP-Relay-Dienst an, der für den Always Free Tier geeignet ist:

AUTH PLAIN statt AUTH LOGIN

OCI Email Delivery unterstützt ausschliesslich AUTH PLAIN. Postfix und HestiaCP setzen standardmässig AUTH LOGIN ein — das erfordert eine manuelle Anpassung der Mailserver-Konfiguration, bevor der Relay funktioniert.

Alternative: Brevo

Brevo (ehemals Sendinblue) ist eine einfach einzurichtende Alternative. Der kostenlose Plan erlaubt bis zu 300 E-Mails pro Tag und unterstützt AUTH LOGIN — damit ist Brevo mit HestiaCP ohne zusätzliche Konfigurationsänderungen nutzbar.

SMTP-Relay, SPF und DKIM

Wer einen externen Relay nutzt, muss dessen Server in den SPF-Record der Domain aufnehmen — sonst schlagen SPF-Prüfungen beim Empfänger fehl. Ausserdem signiert der Relay-Dienst ausgehende Mails mit eigenem DKIM, zusätzlich zur DKIM-Signierung des eigenen Servers. Beide Signaturen erscheinen im Mail-Header und sind kein Problem — solange beide Schlüssel korrekt im DNS veröffentlicht sind.

DNS für Mail

E-Mail funktioniert anders als Web-Traffic. Es gibt keine zentrale Routing-Instanz — stattdessen findet ein sendender Server den empfangenden Server ausschliesslich über DNS-Records. Diese Records müssen korrekt gesetzt sein, damit Mails ankommen:

Grundlegende Records

Warum PTR so wichtig ist

Große Mailprovider wie Gmail und Outlook führen automatisierte Reputationsprüfungen durch. Ein fehlender oder nicht übereinstimmender PTR-Record ist einer der häufigsten Gründe, warum Mails von neuen Servern als Spam eingestuft werden. Er zeigt, dass der Betreiber der IP-Adresse die Domain kontrolliert — ein grundlegendes Vertrauenssignal.

Mail-Sicherheit: SPF, DKIM, DMARC und mehr

Diese Records sind der Kern moderner Mail-Authentifizierung. Wer sie nicht korrekt konfiguriert, wird feststellen, dass eigene Mails zuverlässig im Spam landen — bei manchen Providern auch vollständig abgelehnt werden.

SPF — Sender Policy Framework

Ein TXT-Record in DNS, der festlegt, welche IP-Adressen und Server berechtigt sind, E-Mails im Namen dieser Domain zu versenden. Empfangende Server prüfen beim Eingang, ob die sendende IP im SPF-Record der Absenderdomain aufgeführt ist. Ein fehlender oder falscher SPF-Record ist ein starkes Spam-Signal.

DKIM — DomainKeys Identified Mail

DKIM signiert jede ausgehende E-Mail kryptografisch — Header und Body werden mit einem privaten Schlüssel signiert, der auf dem Mailserver liegt. Der zugehörige öffentliche Schlüssel wird als TXT-Record in DNS veröffentlicht. Empfangende Server können damit prüfen, ob die Mail tatsächlich vom angegebenen Server stammt und auf dem Weg nicht verändert wurde.

DMARC — Domain-based Message Authentication

DMARC baut auf SPF und DKIM auf und legt fest, was mit E-Mails passieren soll, die beide Prüfungen nicht bestehen: none (nur beobachten), quarantine (Spam) oder reject (ablehnen). DMARC ermöglicht auch das Empfangen von Berichten über fehlgeschlagene Authentifizierungsversuche — hilfreich, um Missbrauch der Domain zu erkennen.

Weitere empfohlene Records

Werkzeuge und Ressourcen

Diese Projekte und Tools sind direkt für den Betrieb eines Mailservers auf OCI relevant:

Zusammenfassung

  • OCI Always Free Tier ist dauerhaft kostenlos — aber die Registrierung kann schwierig sein, und Idle-Reclaim ist ein reales Risiko bei wenig genutzten Instanzen.
  • DNS ist der kritische Pfad. Ohne korrekte A-, MX- und PTR-Records funktioniert der Mailserver schlicht nicht. Ohne SPF, DKIM und DMARC landen eigene Mails zuverlässig im Spam.
  • HestiaCP nimmt viel Arbeit ab — Postfix, Dovecot und SpamAssassin konfiguriert es automatisch. Die DNS-Records muss man trotzdem selbst verstehen und setzen.
  • Deliverability ist das eigentliche Problem. Eine neue IP-Adresse hat keine Reputation. Es braucht Zeit und korrekte Konfiguration, bis eigene Mails zuverlässig ankommen.
  • Die Home Region in OCI kann nicht geändert werden. Diese Entscheidung muss beim Anlegen des Accounts sorgfältig getroffen werden.
  • Das Projekt lohnt sich. Wer durchhält, versteht am Ende, wie Mail-Infrastruktur wirklich funktioniert — ein Thema, das in den meisten Ausbildungen und Kursen zu kurz kommt.
  • OCI blockiert Port 25. Ausgehende Mail funktioniert nur über einen SMTP-Relay-Dienst. OCI Email Delivery ist die naheliegende Wahl — Brevo eine einfachere Alternative.
Fragen zum konkreten Setup?

Dieser Artikel gibt einen Überblick — ein produktives Setup hat mehr Details. Bei spezifischen Fragen zu Konfiguration, Migration oder Betrieb erreichst du mich über die Kontaktseite.

Verwendete Open-Source-Projekte