Eigenen Mailserver betreiben: Was hinter den Kulissen passiert

Du hast bereits mehrere Dienste selbst gehostet – vielleicht Nextcloud, einen Reverse Proxy, ein paar Webservices – und nun kommt der Gedanke: Warum nicht auch den Mailserver selbst betreiben? Es klingt nach der logischen Vollendung der Selbsthosting-Idee. Alles auf der eigenen Hardware, alles unter eigener Kontrolle, keine Abhängigkeit von einem Cloud-Anbieter.

Bei Webdiensten stimmt das meist. Bei Mail sehr oft nicht.

Denn beim Mailserver geht es nicht nur darum, Mails zu empfangen und zu senden. Es geht darum, Mails zu senden, die beim Empfänger ankommen – und nicht in dessen Spam-Ordner landen oder gar abgelehnt werden. Und das ist eines der aufwendigsten Probleme im Selfhosting, weil es von externen Faktoren abhängt, die du nicht kontrollierst: IP-Reputationsdatenbanken, Spam-Filter von Gmail und Outlook, Richtlinien von großen Empfängern, und eine Anాలే లేదు Lieferkette von DNS-Einträgen, die alle korrekt sein müssen.

Der Artikel erklärt, was du brauchst, bevor du überhaupt startest, wie du die einzelnen Komponenten einrichtest, welchen Weg du konkret gehst, und wo die häufigsten Fehler liegen. Keine Versprechungen – nur Dienste und Konfigurationen, die tatsächlich existieren.

Warum Mail das schwierigste Selfhosting-Projekt ist

Bei einem Webserver hast du eine Domain, ein Zertifikat, einen Port und bist erreichbar. Bei Mailservern gibt es eine zusätzliche Dimension: Reputation.

Jeder Mailserver auf der Welt hat eine Reputation – eine Art Bonität, die von Empfängern und Spam-Filteranbietern bewertet wird. Wenn du einen neuen Server aufsetzt, beginnt er mit keiner Reputation – und damit oft mit einem Problem. Große E-Mail-Provider wie Gmail, Outlook/Hotmail, Yahoo und viele Firmensysteme betrachten eingehende Mails von neuen oder unbekannten Servern mit Skepsis. Das zeigt sich typischerweise so:

Mails landen im Spam-Ordner
Mails werden abgelehnt mit Fehlermeldungen wie "550 5.7.1 Rejection" oder "421 Too many connections"
Mails werden nur dann angenommen, wenn der Absender eine etablierte Reputation hat

Reputation ist kein einzelner Schalter, den du setzt. Sie ist das Ergebnis von mehreren Faktoren: der IP-Adresse, der Domain, der Konfigurationskorrektness, dem Versandverhalten über Zeit, und wie andere Server deine Mails behandeln – also eine Kombination aus Technik und Zeit.

Das Problem ist, dass du Reputation nicht einfach "bekommst" – du musst sie aufbauen. Und der Aufbau dauert. Die ersten Wochen nach Inbetriebnahme sind typischerweise die schwierigste Phase, weil deine Mails ohne etablierte Reputation oft begrenzt zustellen oder abgelehnt werden.

Die Pflicht-Komponenten: IP-Reputation, PTR, SPF, DKIM, DMARC

Bevor du einen Mailserver installierst, musst du die DNS-basierten und reputationsrelevanten Komponenten verstehen. Ohne diese Komponenten landest du schnell in einer Situation, in der Mails technisch funktionieren, aber nicht beim Empfänger ankommen.

IP-Reputation und statische IP

Deine IP-Adresse ist einer der wichtigsten Reputation-Faktoren. Wenn du eine dynamische IP hast (wie bei vielen Hausanschlüssen), wird dein Mailversand wahrscheinlich nicht funktionieren, weil viele Provider dynamische IPs blockieren oder stark einschränken. Für einen eigenen Mailserver ist eine statische IPv4-Adresse praktisch unverzichtbar.

Eine statische IP bedeutet: Die IP-Adresse ändert sich nicht. Das ist wichtig, weil Reputation an die IP gebunden ist – wenn sich die IP ändert, ist die Reputation weg.

Reverse DNS (PTR)

PTR (Pointer Record) ist der DNS-Eintrag, der einer IP-Adresse einen Hostnamen zuordnet – die Umkehrung des normalen A-Records. Für Mailserver ist PTR essentiell, weil viele empfangende Server prüfen, ob die IP-Adresse des Absenders einen korrekten PTR-Eintrag hat. Ohne PTR oder mit einem PTR, der nicht zum Hostnamen des Mailservers passt, werden Mails oft abgelehnt.

PTR wird nicht in deinem eigenen DNS verwaltet – es wird von dem Provider verwaltet, der die IP-Adresse zugewiesen hat. Wenn du eine IP bei einem Hosting-Provider hast, musst du beim Provider eine PTR-Änderung beantragen oder konfigurieren. Die IP muss auf einen Hostnamen zeigen, der wiederum auf die IP zeigt – eine zirkuläre Verifikation, die viele Spam-Filter prüfen.

SPF (Sender Policy Framework)

SPF ist ein DNS-Eintrag (TXT-Record) auf deiner Domain, der angibt, welche Server Mails in deinem Auftrag senden dürfen. Ein Beispiel:


v=spf1 ip4:198.51.100.28 -all

Das sagt: Nur die IP 198.51.100.28 darf Mails für diese Domain senden. -all bedeutet "alle anderen verbieten". Es gibt auch ~all (soft fail) und ?all (neutral), aber für einen klar konfigurierten Server ist -all die saubere Variante, wenn du wirklich nur einen Server hast.

SPF ist einer der grundlegendsten Schutzmechanismen. Wenn du SPF nicht hast, kann jeder beliebige Server Mails in deiner Domain verschicken – und viele Empfänger behandeln das als verdächtig.

DKIM (DomainKeys Identified Mail)

DKIM fügt einer jeden abgesendeten Mail einen kryptographischen Signaturalgorithmus hinzu. Der Empfänger prüft die Signatur anhand eines Public-Keys, den du im DNS bereitstellst. Wenn die Signatur stimmt, weiß der Empfänger, dass die Mail nicht manipuliert wurde und wirklich von dir kam.

DKIM erzeugt ein Schlüsselpaar – einen privaten Schlüssel auf dem Server und einen öffentlichen Schlüssel im DNS. Der Server signiert Mails mit dem privaten Schlüssel, der Empfänger verifiziert mit dem öffentlichen Schlüssel.

Die DNS-Ausgabe für DKIM sieht typischerweise so aus (der exakte Name hängt von der Software und dem Selector ab):


mailing._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ..."

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC ist ein DNS-Eintrag (TXT-Record auf _dmarc.deinedomain.de), der angibt, wie ein Empfänger reagieren soll, wenn SPF oder DKIM fehlschlagen. DMARC setzt also auf SPF und DKIM auf – es ist kein Ersatz, sondern ein Policy-Empfehlungssystem.

Ein typischer DMARC-Eintrag für den Start:


v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=none bedeutet: Noch nichts tun, nur Berichte sammeln. Das ist die empfohlene Startposition, weil du erst sehen willst, was passiert, bevor du harte Regeln aktivierst.
p=quarantine bedeutet: Mails, die die Prüfung nicht bestehen, in Quarantäne verschieben.
p=reject bedeutet: Mails, die die Prüfung nicht bestehen, ablehnen.

Wichtig: Beginne mit p=none. Wenn du direkt mit p=reject startest und etwas ist falsch, werden deine eigenen Mails abgelehnt. Also erst berichten, dann nachsehen, dann Schritt für Schritt verschärfen.

Vergleich: Mailcow vs. Postfix mit Dovecot vs. reines Relay

Es gibt mehrere Wege, einen Mailserver zu betreiben. Die drei wichtigsten Optionen sind:

|---|---|---|---|

| Einrichtungsaufwand | Mittel: Docker-Compose, Konfiguration über Web-UI, aber viele Komponenten laufen automatisch | Hoch: Jede Komponente manuell konfigurieren, Postfix, Dovecot, TLS, DKIM, Dspam/Rspamd, Datenbank, Firewall-Regeln | Niedrig: Nur DNS und Relay-Einstellungen; kein eigener Empfangsserver |

| Weboberfläche | Ja: Vollständige Admin-UI für Domains, Benutzer, Filter, Logs, Wartung | Nein: Konfiguration über Dateien und CLI; optional Webmail (Roundcube, SnappyMail) als separates Paket | Nein: Nur Einstellungen beim Relay-Provider |

| Filterregeln | Integriert: Rspamd, ClamAV, Sieve-Filter, benutzerdefinierbare Regeln über UI | Manuell: Rspamd oder SpamAssassin selbst konfigurieren, Sieve für Benutzerregeln | Wenig kontrollierbar: Der Relay setzt eigene Filter; du hast wenig Einfluss auf Empfangsfilter |

| Backup | Datenbank (MySQL/MariaDB) und Mail-Speicher (im Docker-Volume oder auf Platte) – klar getrennt | Datenbank (falls verwendet, z.B. für virtual users) und Mail-Speicher – muss selbst konfiguriert werden | Kein eigener Mailspeicher – E-Mails beim Relay; Backup ist Aufgabe des Relays |

| Ressourcenbedarf | Mittel bis hoch: Mehrere Container, Rspamd, ClamAV (optional), Admin-UI; auf einem kleinen System heftig | Variabel: Postfix ist leicht, Dovecot ebenfalls; Rspamd/SpamAssassin können zusätzlichen Bedarf erzeugen; insgesamt kleiner als Mailcow | Sehr gering: Kein eigener Server, nur DNS und Konfiguration |

| Fehleranfälligkeit | Geringer: Vorkonfiguration, automatisierte Komponenten; Fehler entstehen eher bei manuellen Änderungen an der UI-Konfiguration | Hoch: Viele manuelle Komponenten, jede muss korrekt sein; eine fehlerhafte Postfix-Konfiguration, fehlerhafter TLS oder fehlendes DKIM-Key kann zu Mailverlust führen | Gering: Kein eigener Server, aber Abhängigkeit von externem Relay; Probleme beim Relay wirken sich direkt auf den eigenen Versand aus |

Mailcow ist die vollständigste Lösung, wenn du alles selbst haben willst – mit der höchsten Ressourcenanforderung. Postfix + Dovecot gibt dir volle Kontrolle, aber auch volle Verantwortung und den größten Konfigurationsaufwand. Ein reines Relay ist die einfachste Lösung, hat aber den größten Kontrollverlust – du hast keinen eigenen Empfangsserver, keine eigene Filterung, und du bist abhängig von einem externen Dienst.

Mailcow wird über Docker-Compose installiert und bietet eine Web-Oberfläche für die Administration. Die Dokumentation ist öffentlich verfügbar unter der Mailcow-Webseite und im GitHub-Repository. Postfix und Dovecot sind Einzelkomponenten, die separat installiert und konfiguriert werden müssen.

Der realistische Weg: Schritt für Schritt

Die Reihenfolge ist wichtig. Viele Fehler entstehen, weil man in die falsche Reihenfolge geht – zum Beispiel SPF einrichtet, bevor die IP und PTR korrekt sind, oder DMARC mit zu strengen Regeln startet.

Schritt 1: Domain vorbereiten

Du brauchst eine Domain, die du kontrollierst. Es geht nicht darum, eine Subdomain oder ein kostenloses Hosting zu nehmen – du brauchst eine Domain, bei der du die DNS-Einträge selbst setzen kannst. Das ist die Grundlage für SPF, DKIM, DMARC – alles basiert auf der Domain.

Wenn du eine Domain hast, stelle sicher, dass du Zugriff auf den DNS-Hoster hast, um TXT-, A-, MX- und andere Records zu setzen.

Schritt 2: Statische IP und Port 25 beim Provider klären

Bevor du den Server einrichtest, kläre folgendes beim Hosting-Provider:

Statische IPv4-Adresse: Du brauchst eine feste IP, die sich nicht ändert.
Port 25 (SMTP) geöffnet: Viele Provider blockieren Port 25 von Haus aus, um Spam zu verhindern. Das ist einer der häufigsten Haken für Einsteiger – du richtest alles korrekt ein, aber Mails können nicht versenden, weil Port 25 blockiert ist. Frage beim Provider explizit nach, ob Port 25 ausgehend (für Relay) und/oder eingehend (für eigenen Empfang) erlaubt ist.

Schritt 3: PTR (Reverse DNS) beim Provider einrichten

Sobald die statische IP da ist, richte beim Provider den PTR-Eintrag ein. Der PTR muss auf einen Hostnamen zeigen, der als Mailserver identifiziert wird – typischerweise etwas wie mail.example.com.

Der Hostname in der PTR muss wiederum auf die IP zeigen (ein A-Record für mail.example.com muss auf die IP zeigen). Das ist die zirkuläre Verifikation, die viele Server prüfen.

Schritt 4: SPF einrichten

Setze den SPF-Eintrag in deinem DNS. Für den Anfang ein konkretes Beispiel – wenn dein Server die IP 198.51.100.28 ist und nur dieser Server Mails senden soll:


example.com.  IN  TXT  "v=spf1 ip4:198.51.100.28 -all"

Teste SPF nach der Einrichtung mit Tools wie dig oder nslookup, bevor du weitere Einträge hinzufügst:


dig example.com txt

Schritt 5: DKIM einrichten

DKIM erfordert die Konfiguration auf dem Server (Schlüsselerzeugung und Signierung) sowie den DNS-Eintrag (öffentlicher Schlüssel).

Bei Mailcow wird DKIM typischerweise über die Admin-Oberfläche verwaltet – du erstellst einen Selector, Mailcow generiert den Schlüssel, und du kopierst den öffentlichen Schlüssel in den DNS.

Bei Postfix + Dovecot musst du DKIM selbst konfigurieren – typischerweise mit OpenDKIM oder Rspamd, die einen Schlüssel generieren und die Signierung übernehmen. Der öffentliche Schlüssel wird dann als TXT-Record im DNS eingetragen.

Teste DKIM mit Tools wie opendkim-testkey oder einem Online-DKIM-Test, nachdem du den DNS-Eintrag gesetzt hast.

Schritt 6: DMARC einrichten – mit p=none starten

Setze den DMARC-Eintrag mit p=none, um Berichte zu sammeln, bevor du harte Regeln aktivierst:


_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Der rua-Teil ist die Adresse, an die Berichte gesendet werden. Diese Berichte sind XML-Dateien mit Informationen darüber, was Empfänger über deine Mails denken – eine nützliche Quelle, um Probleme zu erkennen.

Warte eine bis zwei Wochen mit p=none, bevor du schrittweise zu p=quarantine und später zu p=reject gehst. Das gibt dir Zeit, Probleme zu erkennen, ohne dass Mails abgelehnt werden.

Umzug bestehender Postfächer von einem Cloud-Anbieter

Wenn du von einem Cloud-Mail-Anbieter (z.B. Google Workspace, Microsoft 365, IONOS, Host Europe) zu einem eigenen Server umziehst, ist das ein umfassenderes Projekt als nur den Server aufzusetzen.

Was du brauchst

Zugriff auf die alten Postfächer (Admin-Zugriff oder User-Zugriff mit IMAP)
Zugriff auf die Domain-DNS (für SPF, DKIM, DMARC, MX-Record-Umschaltung)
Einen Zeitplan für den Umzug, weil nicht alle Mails gleichzeitig umgezogen werden können

Der Umzugsprozess

1. neuen Mailserver einrichten und testen – bevor du etwas umziehst, muss der neue Server funktionsfähig sein: Mails empfangen, Mails versenden, SPF/DKIM/DMARC korrekt, PTR gesetzt.

2. MX-Records umstellen – sobald der neue Server bereit ist, stellst du die MX-Records auf den neuen Server um. Achtung: Das hat eine Verbreitungszeit in DNS – einige Systeme nutzen die alten MX-Records noch etwas länger.

3. Mails während des Übergangs – Mails, die während des Übergangs beim alten Server eintreffen, müssen irgendwie behandelt werden. Typischerweise lässt du den alten Server noch kurz laufen und leitet Mails weiter, oder du holst Mails per IMAP nach.

4. Benutzerkonten und Daten migrieren – bestehende Mails, Ordner, Adressbücher – alles muss auf den neuen Server oder in die neue Umgebung. Bei Mailcow gibt es Migrationstools und -Anleitungen; bei eigenem Postfix/Dovecot musst du selbst konfigurieren.

Die ehrliche Warnung: Reputation muss neu aufgebaut werden

Das ist der wichtigste Punkt beim Umzug: Die IP-Reputation, die dein alter Cloud-Anbieter aufgebaut hat, geht verloren. Deine neue IP beginnt bei null.

Das bedeutet konkret:

Die ersten Wochen nach dem Umzug landen Mails möglicherweise im Spam-Ordner von Empfängern
Mails können abgelehnt werden, weil die neue IP keine Reputation hat
Du musst aufpassen, dass du nicht auf einmal große Mengen Mails versendest – das wird als Spam-Verhalten interpretiert

Das ist kein Fehler – das ist normal. Reputation wird aufgebaut durch konsequenten, moderaten Versand über Zeit. Wenn du viele Mails auf einmal versendest, ohne Reputation, wird das von Spam-Filtern als verdächtig angesehen.

Ein Umzug ist also kein einmaliger Moment, sondern ein Prozess über Wochen bis Monate, in dem du die neue Reputation aufbaust.

Mailcow in Betrieb nehmen: Ein vorkonfigurierter Stapel

Mailcow ist eine der vollständigsten Lösungen für einen eigenen Mailserver, weil es viele Komponenten zusammenbringt und über eine Web-Oberfläche verwaltet wird.

Voraussetzungen

Ein Linux-System (Debian, Ubuntu oder ähnlich) mit Docker und Docker-Compose
Eine statische IP-Adresse mit offenem Port 25 (eingehend und ausgehend, je nach Vertrag)
Eine Domain, für die du DNS-Einträge setzen kannst
PTR-Eintrag beim Provider

설치 und erste Schritte

Mailcow wird über Docker-Compose installiert. Die Dokumentation auf der offiziellen Webseite beschreibt den genauen Ablauf. Die wesentlichen Schritte sind:

1. Docker und Docker-Compose installieren – falls nicht bereits vorhanden.

2. Mailcow-Dateien herunterladen – typischerweise aus dem GitHub-Repository, das die Docker-Compose-Konfiguration und Skripte enthält.

3. Konfiguration anpassen – in der .env-Datei und ggf. in der docker-compose.yml werden Konfigurationen wie Datenbank-Passwörter, Hostname, und andere Einstellungen vorgenommen.

4. Container starten – mit docker compose up -d werden die Container gestartet.

Portfreigaben

Mailcow benötigt mehrere Ports, die im Firewall geöffnet sein müssen:

Port 25 (SMTP) – für eingehende Mails von anderen Servern
Port 587 (Submission) – für Mails von Clients (Clients senden über 587 mit STARTTLS)
Port 465 (SMTPS) – alternativer Port für verschlüsselten Versand von Clients
Port 993 (IMAPS) – für IMAP-Verbindungen von Clients
Port 995 (POP3S) – für POP3-Verbindungen von Clients, falls genutzt
Port 80 und 443 – für die Web-Oberfläche und die Webmail-Oberfläche

Die genaue Portkonfiguration ist in der Mailcow-Dokumentation beschrieben.

Zertifikat

Mailcow verwaltet Zertifikate typischerweise selbst – entweder über Let's Encrypt (wenn die Domain von außen erreichbar ist und die ACME-Challenge funktioniert) oder durch eigene Zertifikate. Die Web-Oberfläche und die Verschlüsselung von Client-Verbindungen (SMTPS, IMAPS) benötigen gültige Zertifikate.

Stelle sicher, dass die Domain, unter der die Web-Oberfläche erreichbar ist, korrekt in Mailcow konfiguriert ist und dass Let's Encrypt-Zertifikate korrekt erneuert werden.

Backup der Datenbank und des Mail-Speichers

Mailcow speichert Daten in Docker-Volumes. Ein Backup muss beide Teile umfassen:

Datenbank: Die MySQL/MariaDB-Datenbank, die Benutzer, Domains, Einstellungen und andere Konfigurationsdaten enthält.
Mail-Speicher: Die tatsächlichen E-Mails, die im Dateisystem oder in Volumes gespeichert sind.

Mailcow bietet Backup-Mechanismen – entweder über Skripte, die im Repository mitgeliefert werden, oder über eigene Backup-Strategien. Ein Backup sollte regelmäßig erfolgen und auf einem separaten Speichermedium oder -ort gespeichert werden.

Ein Backup, das nur die Datenbank umfasst, reicht nicht – du verlierst alle Mails. Ein Backup, das nur den Mail-Speicher umfasst, reicht auch nicht – du verlierst alle Konten und Einstellungen. Beides gehört zusammen.

Häufige Fehler und wie sie vermieden werden

Port 25 beim Provider blockiert

Das ist der häufigste Fehler überhaupt. Viele Provider blockieren Port 25, um Spam zu verhindern. Du richtest alles korrekt ein, installierst Postfix oder Mailcow, aber Mails können nicht versendet werden, weil Port 25 blockiert ist.

Lösung: Frage beim Provider explizit nach, ob Port 25 erlaubt ist. Wenn nicht, ist ein eigener Mailserver mit eigenem Empfang nicht möglich – dann bleibt nur ein reines Relay über einen externen Anbieter.

Kein PTR oder falscher PTR

Ohne PTR oder mit einem PTR, der nicht zum Mailserver-Hostnamen passt, werden Mails von vielen Servern abgelehnt. PTR wird beim Provider konfiguriert – nicht in deinem eigenen DNS.

Lösung: Stelle sicher, dass der PTR-Eintrag beim Provider korrekt ist und auf einen Hostnamen zeigt, der wiederum auf die IP zeigt.

DMARC mit zu rasanten Regeln aktiviert

Wenn du sofort mit p=reject startest und etwas in der Konfiguration falsch ist (z.B. SPF nicht korrekt, DKIM nicht funktionierend), werden deine eigenen Mails abgelehnt.

Lösung: Starte mit p=none, sammle Berichte, prüfe, ob alles funktioniert, und verschärfe dann schrittweise.

Offenes Relay – Spam-Massenversand durch falsch konfigurierte Server

Ein offenes Relay ist ein Server, der Mails von jedem annimmt und weiterleitet – ohne Authentifizierung. Das ist eines der gefährlichsten Konfigurationsprobleme, weil ein offener Relay missbraucht werden kann, um Spam zu versenden, und die IP-Adresse wird schnell auf Spam-Listen gesetzt.

Lösung: Stelle sicher, dass der Server nur authentifizierten Nutzern Mails zum Versand akzeptiert. Bei Postfix bedeutet das korrekte mynetworks und Authentifizierungskonfiguration; bei Mailcow ist das standardmäßig korrekt, aber manuelle Änderungen können es gefährden.

Passwort im Klartext in der Konfiguration

Passwörter für Datenbanken, Relay-Zugänge, Admin-Konten oder andere Komponenten gehören nicht im Klartext in Konfigurationsdateien, die von vielen Personen gelesen werden können.

Lösung: Nutze geeignete Passwort-Management-Praktiken, setze Berechtigungen auf Konfigurationsdateien (Linux-Dateiberechtigungen, chmod 600 für sensible Dateien), und übertrage keine Passwörter in öffentliche Templates oder Version-Controllsysteme.

Mailverlust weil IMAP-Ordner nicht gesichert werden

Ein Backup, das nur die Datenbank sichert, verliert die tatsächlichen Mails. IMAP-Ordner und Mails liegen im Dateisystem oder in Volumes, nicht in der Datenbank. Wenn nur die Datenbank gesichert wird, sind die Mails weg.

Lösung: Sichere Datenbank und Mail-Speicher zusammen. Prüfe regelmäßig, ob ein Restore funktioniert – ein Backup, das nicht getestet wurde, ist kein Backup.

FAQ

Warum landen meine Mails im Spam?

Die häufigsten Gründe: Fehlende oder falsche SPF/DKIM/DMARC-Konfiguration, kein PTR oder falscher PTR, neue IP ohne Reputation, zu große Versandmengen auf einmal, Inhalte, die von Spam-Filtern als verdächtig eingestuft werden. Beginne mit dem Check der DNS-Einträge (SPF, DKIM, DMARC mit Tools wie dig oder Online-Testdiensten) und dem PTR beim Provider.

Brauche ich zwingend eine statische IP?

Für einen eigenen Mailserver, der Mails empfängt und sendet, ja – praktisch. Dynamische IPs werden von vielen Servern blockiert oder streng eingeschränkt. Wenn du nur Mails empfangen willst (und Versand über einen Relay machst), kannst du auf eine statische IP verzichten – aber das ist eine eingeschränkte Variante. Für volle Funktionalität ist eine statische IPv4-Adresse die empfohlene Voraussetzung.

Kann ich einen eigenen Mailserver ohne Port 25 betreiben?

Nein – nicht für eingehenden Mailverkehr. Port 25 ist der Standard-Port für SMTP zwischen Servern. Wenn Port 25 beim Provider blockiert ist, kannst du Mails nicht empfangen (andere Server können dich nicht erreichen). Für ausgehenden Versand kannst du einen Relay nutzen, aber für eigenen Empfang ist Port 25 notwendig.

Wie lange dauert es, bis Mails beim Empfänger ankommen?

Das hängt von der Reputation ab. Mit einer neuen IP und korrekter Konfiguration landen Mails oft in den ersten Wochen im Spam-Ordner oder werden begrenzt angenommen. Reputation baut sich über Zeit auf – typischerweise Wochen bis Monate, abhängig vom Versandverhalten. Es gibt keine feste Zeit, weil es von vielen Faktoren abhängt.

Was ist der Unterschied zwischen Mailcow und Postfix mit Dovecot?

Mailcow ist ein vorkonfigurierter Stapel mit Web-Oberfläche, der Docker-Container für alle Komponenten bereitstellt – einfacher zu betreiben, aber mehr Ressourcenbedarf. Postfix mit Dovecet ist ein Eigenbau, bei dem du jede Komponente selbst konfigurierst – mehr Arbeit, mehr Kontrolle, weniger Ressourcen, aber auch mehr Fehleranfälligkeit bei manuellen Konfigurationen.

Interne Verlinkungsvorschläge zu vorhandenen BsN-Artikeln

Reverse Proxy Vergleich – Mailserver und Reverse Proxy sind oft verwandt, besonders wenn die Web-Oberfläche hinter einem Proxy erreichbar sein soll
Monitoring ohne Cloud – Mailserver gehört überwacht: Uptime von SMTP/IMAP-Ports, Ressourcen auf dem Host, Logauswertung der Mail-Komponenten
Docker vs. VM – für die Entscheidung, in welcher Umgebung Mailcow oder Postfix/Dovecot laufen soll
DNS-Grundlagen und Records – SPF, DKIM, DMARC, MX, PTR sind DNS-Einträge; ein grundlegendes DNS-Verständnis erleichtert die Konfiguration
Backup-Strategie für Selfhoster – Backups für Mailserver sind besonders wichtig, weil Mails nicht einfach neuherstellbar sind

Bildvorschläge

Bild 1

Typ: Konzeptionelles Diagramm der Mailserver-Reputation und DNS-Abhängigkeiten
Inhalt: Eine zentrale IP-Adresse mit Pfeilen zu vier Komponenten: PTR (Provider-Seite), SPF (TXT-Record in DNS), DKIM (TXT-Record mit Public Key), DMARC (TXT-Record auf _dmarc). Abhängigkeitspfeile zeigen, dass DMARC auf SPF und DKIM aufbaut. Rechts daneben: ein "Spam-Filter" mit Fragezeichen, der alle vier Einträge prüft, bevor eine Mail angenommen wird.
Alt-Text: Diagramm der Mailserver-Abhängigkeiten – PTR, SPF, DKIM und DMARC als Voraussetzungen, bevor Mails von Empfängern akzeptiert werden

Bild 2

Typ: Screenshot der Mailcow-Admin-Oberfläche im Browser
Inhalt: Die Mailcow-Dashboard-Übersicht mit Schlüsselinfo: Server-Status, eingegangene/ausgegangene Mails, Benutzerübersicht, und ein Bereich für DNS-Einträge (SPF/DKIM/DMARC-Hinweise). Der Screenshot zeigt die Weboberfläche, nicht die Server-Konsole.
Alt-Text: Mailcow-Admin-Oberfläche mit Serverstatus, Mails-Übersicht und DNS-Informationen für SPF, DKIM und DMARC

Bild 3

Typ: Vergleichstabelle als grafische Übersicht (eher Infografik als reine Tabelle)
Inhalt: Drei Spalten (Mailcow, Postfix + Dovecot, Reines Relay) mit Icons oder Kurzsymbolen für die Kriterien: Einrichtungsaufwand (Schwierigkeitsgrad), Weboberfläche (Ja/Nein), Filterregeln (integriert/manuell/mittel), Backup (Volles/Simple), Ressourcenbedarf (Bar oder Diagramm), Fehleranfälligkeit (niedrig/mittel/hoch). Die Werte sind als Symbolgrade dargestellt, nicht als Texttabelle.
Alt-Text: Infografik zum Vergleich Mailcow vs. Postfix mit Dovecot vs. reines Relay – Aufwand, Weboberfläche, Filter, Backup, Ressourcen und Fehleranfälligkeit im Überblick

Bild 4

Typ: Architekturdiagramm eines eigenen Mailservers mit Client-Zugriff
Inhalt: Eine einfache Architektur: Links ein E-Mail-Client (laptop oder smartphone), der via IMAPS (Port 993) oder SMTPS (Port 587/465) mit dem Mailserver verbindet. Der Mailserver (im Zentrum) hat Verbindungen nach außen: SMTP-Port 25 zu anderen Servern (für Empfang und Versand), DNS-Abfragen für SPF/DKIM/DMARC/PTR. Rechts: externe E-Mail-Provider (Gmail, Outlook etc.) als Empfänger, die die Reputation und DNS-Einträge prüfen.
Alt-Text: Architekturdiagramm eines eigenen Mailservers – Clients verbinden über IMAPS/SMTPS, Server kommuniziert über Port 25 mit externen Mailservern, DNS-Einträge (SPF, DKIM, DMARC, PTR) werden von empfangenden Servern geprüft

Bild 5

Typ: Illustration des Reputation-Aufbaus über Zeit
Inhalt: Eine simple Zeitachse (Wochen 1 bis 8) mit einer Kurve, die von "Keine Reputation / Mails im Spam" startet und sich langsam zu "Etablerte Reputation / Mails im Posteingang" bewegt. Markierungen an kritischen Punkten: " PTR gesetzt", "SPF hinzugefügt", "DKIM hinzugefügt", "DMARC p=none aktiv", "DMARC p=quarantine", "Erste Woche ohne Absender-Probleme". Keine realistischen Daten – rein konzeptionell.
Alt-Text: Konzept der Reputation-Aufbaus über Zeit – ein eigener Mailserver beginnt mit keiner Reputation und baut sie durch korrekte Konfiguration und moderaten Versand über mehrere Wochen auf

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.