Lohnt sich E-Mail-Self-Hosting 2026 noch?

Die kurze Antwort

Self-Hosting von E-Mail ist auch 2026 noch sinnvoll, solange Sie die Aufgabe in zwei Teile aufteilen. Der Empfang Ihrer eigenen E-Mail auf Ihrem eigenen VPS ist risikoarm und funktioniert, weil Sie der Empfänger sind und niemand Ihnen vertrauen muss. E-Mail zu versenden, die große Mailbox-Anbieter akzeptieren, ist eine andere Aufgabe. Sie hängt von einem Ruf der IP-Adresse ab, den Sie übernehmen, statt ihn selbst aufzubauen.

Erfahrene Betreiber verwenden in der Praxis eine hybride Konfiguration. Der eigene Server enthält die Mailboxen und das Archiv. Ausgehende E-Mail wird über ein authentifiziertes Relay auf Port 587 versendet. Vollständiges Self-Hosting in beide Richtungen ist in einigen speziellen Fällen weiterhin sinnvoll. Diese Fälle werden gegen Ende dieses Beitrags beschrieben.

Die schwierige Seite des Self-Hostings von E-Mail ist die Zustellbarkeit

Die Installation eines Mailservers nimmt ein Wochenende Arbeit in Anspruch. Ein moderner Stack stellt SMTP (Simple Mail Transfer Protocol) für den Versand von E-Mail, IMAP (Internet Message Access Protocol) zum Lesen, Spamfilterung und eine Webmail-Oberfläche über eine einzige Compose-Datei bereit. Die Anleitung Installation des Mailservers Mailcow auf einem VPS behandelt diese Themen. Die Installation selbst ist nicht der schwierige Teil.

Die Schwierigkeit beginnt, wenn Ihr Server eine Verbindung zu einem Rechner eines Unternehmens herstellt, das Sie nicht kennt, und diesen Rechner auffordert, eine Nachricht im Posteingang eines Benutzers abzulegen. Der Empfänger hat keinen Grund, dieser Anfrage zuzustimmen. Er entscheidet anhand verschiedener Signale: der Reputation der verbindenden IP-Adresse, der Reputation Ihrer Domain, der Authentifizierung der Nachricht und der bisherigen Reaktionen der eigenen Benutzer auf Ihre E-Mails. Ein neuer Absender hat keinerlei Historie. Das Fehlen einer Historie wird nicht als neutral bewertet, sondern als Risiko. Deshalb landen die ersten Nachrichten im Spam-Ordner oder werden zurückgestellt, bis ein Muster erkennbar ist.

Sie sehen die Ablehnung. Gmail sendet eine permanente Ablehnung dieser Form:

550-5.7.1 [203.0.113.5      19] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked.

Microsoft sendet eine andere Meldung, die mit einem variierenden Blocklist-Code endet:

550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent. Please
contact your Internet service provider since part of their network is on
our block list (S3150).

Lesen Sie zuerst die erste Ziffer. Ein Code, der mit 4 beginnt, ist vorübergehend. Ihr Server behält die Nachricht und versucht die Zustellung erneut. Ein Code, der mit 5 beginnt, ist dauerhaft. Die Nachricht wird sofort an den Absender zurückgesendet. Eine 4xx-Zurückstellung, die nicht aufgehoben wird, weist auf eine Begrenzung der Versandrate oder der Reputation hin und kann sich selbstständig auflösen. Ein 5xx-Code ist eine Entscheidung. Sie wird nicht aufgehoben.

Warum landen die E-Mails eines neuen Servers im Spam?

Weil die IP-Adresse nicht neu ist. Sie erhalten keine ungenutzte Adresse. Sie erhalten eine wiederverwendete Adresse aus dem Pool Ihres Providers, einschließlich ihrer bisherigen Reputation. Wenn der vorherige Nutzer Spam versendet hat, kann bereits Ihre erste Nachricht abgewiesen werden, bevor Sie eine zweite versendet haben.

Prüfen Sie die Adresse, bevor Sie darauf etwas einrichten. Die öffentlichen Blocklisten antworten über DNS. Dabei werden die vier Oktette der Adresse in umgekehrter Reihenfolge verwendet:

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd swaks
dig +short 10.0.0.10.zen.spamhaus.org

Eine leere Antwort bedeutet, dass die Adresse nicht gelistet ist. Eine Antwort innerhalb von 127.0.0.0/8 bedeutet, dass sie gelistet ist. Das letzte Oktett gibt an, welche Liste den Treffer geliefert hat. Bei diesem Test gibt es eine wichtige Einschränkung: Spamhaus lehnt Anfragen ab, die über die großen öffentlichen Resolver eingehen. Deshalb liefert dieselbe Abfrage über 8.8.8.8 unabhängig vom tatsächlichen Status 127.255.255.254 zurück. Dieser Code bedeutet, dass die Abfrage abgelehnt wurde, nicht dass die Adresse gelistet ist. Führen Sie die Abfrage über den Resolver Ihres eigenen Servers aus oder verwenden Sie stattdessen die Webabfrage.

Ein sauberes Ergebnis ist notwendig, reicht aber nicht aus. Nicht gelistet zu sein bedeutet nur, dass sich in letzter Zeit niemand über diese Adresse beschwert hat. Die Adresse besitzt dadurch keine positive Reputation. Eine positive Reputation sorgt tatsächlich dafür, dass E-Mails im Posteingang landen. Sie entsteht, wenn Sie über mehrere Wochen kleine Mengen erwünschter E-Mails versenden.

Auch Ihre Nachbarn spielen eine Rolle, weil manche Empfänger die Reputation eines gesamten Netzwerkblocks statt nur einer einzelnen Adresse bewerten. Wenn ein anderer Kunde im selben /24-Bereich mit dem Versand von Spam beginnt, können Ihre E-Mails deswegen langsamer zugestellt werden. Diese Bewertung auf Blockebene erklärt auch, warum Missbrauchsbeschwerden in einem VPS-Posteingang eingehen können, obwohl der Kontoinhaber den betreffenden Datenverkehr nie gesendet hat: Die Beschwerde folgt dem Adressbereich.

Was Sie vor dem Start prüfen müssen: Port 25 und der PTR-Eintrag

Der ausgehende TCP-Port 25 wird im Internet am häufigsten missbraucht. Deshalb sperren viele Hosting-Anbieter ihn bei neuen Konten standardmäßig. Einige Anbieter öffnen ihn auf Anfrage. Andere öffnen ihn erst, wenn ein Konto eine bestimmte Bestandsdauer und Zahlungshistorie aufweist. Manche öffnen ihn nie. Die Richtlinien unterscheiden sich zwischen den Anbietern und ändern sich im Laufe der Zeit. Betrachten Sie diesen Beitrag, einen alten Forenbeitrag oder die Marketingseite eines Anbieters daher nicht als aktuelle Tatsache. Fragen Sie nach und lassen Sie sich die Antwort schriftlich geben, bevor Sie bezahlen.

Testen Sie den Pfad direkt vom Server aus:

nc -vz gmail-smtp-in.l.google.com 25

Ein offener Pfad gibt innerhalb einer Sekunde succeeded! aus. Bei einem gesperrten Pfad wartet der Befehl und läuft anschließend ohne Meldung zum Grund der Sperre in einen Timeout. Ein stillschweigend verworfenes Paket sieht für den Absender genauso aus wie ein gewöhnliches Netzwerkproblem.

Die zweite Voraussetzung ist ein PTR-Eintrag, auch Reverse DNS genannt. Empfänger nehmen die IP-Adresse, von der die Verbindung hergestellt wurde, ermitteln deren PTR-Eintrag und erhalten dadurch einen Namen. Anschließend lösen sie diesen Namen wieder in eine Adresse auf. Stimmen beide Adressen überein, wird dies als Forward-confirmed Reverse DNS bezeichnet. Das ist eine einfache Prüfung, ob der verbindende Host dem Betreiber gehört, als der er sich ausgibt.

dig -x 203.0.113.5 +short
dig +short mail.example.com

Der erste Befehl muss Ihren Mail-Hostnamen zurückgeben. Der zweite Befehl muss dieselbe Adresse zurückgeben, mit der Sie begonnen haben. Nur der Besitzer einer IP-Adresse kann deren PTR-Eintrag veröffentlichen. Ihr Host muss ihn daher für Sie setzen oder eine Einstellung dafür im Control Panel bereitstellen. Ein fehlender PTR-Eintrag oder ein generischer Eintrag wie 203-0-113-5.static.example-isp.net ist ein stark negatives Signal. Echte Mailserver haben fast immer einen passenden Namen. Quellen für Massen-Spam haben häufig keinen.

Wenn Ihr Host zusätzlich IPv6 zuweist und Ihr Server diese Adresse bevorzugt, gelten die obigen Anforderungen auch für die IPv6-Adresse. Gmail ist in diesem Fall strenger. Der Versand über IPv6 von einer Adresse ohne PTR-Eintrag führt zu einer Ablehnung mit dem Hinweis, dass die Nachricht die IPv6-Richtlinien für den Versand in Bezug auf PTR-Einträge und Authentifizierung nicht erfüllt. Wenn Sie keinen IPv6-PTR-Eintrag setzen können, versenden Sie ausschließlich über IPv4. In Postfix verwenden Sie dafür smtp_address_preference = ipv4, um IPv4 zu bevorzugen, oder inet_protocols = ipv4, um IPv6 vollständig zu deaktivieren.

Die drei Fragen an jeden Host

1. Ist der ausgehende TCP-Port 25 bei einem neuen Konto geöffnet? Falls nicht: Wie sehen der genaue Ablauf und der Zeitplan für die Freischaltung aus?
2. Kann ich den PTR-Eintrag für meine IPv4-Adresse und meine IPv6-Adresse selbst setzen? Wo nehme ich diese Einstellung vor?
3. Falls sich herausstellt, dass meine Adresse wegen eines früheren Kunden auf einer Blocklist steht: Wechseln Sie mich dann auf eine andere Adresse?

Stellen Sie alle drei Fragen, bevor Sie kaufen, nicht erst danach. Ein Host, der die ersten beiden Fragen klar beantwortet und die dritte verneint, ist trotzdem nutzbar. Sie können die Adresse am ersten Tag prüfen und den Vertrag kündigen. Ein Host, der keine dieser Fragen schriftlich beantworten will, hat Ihnen bereits gezeigt, wie der Betrieb von Mail dort aussehen wird.

Was SPF, DKIM und DMARC tatsächlich nachweisen

Drei DNS-Einträge weisen nach, dass eine E-Mail, die angeblich von Ihrer Domain stammt, tatsächlich von dort gesendet wurde. Jeder Eintrag beantwortet eine andere Frage. Der dritte funktioniert erst, wenn Sie die ersten beiden verstanden haben.

SPF (Sender Policy Framework) ist ein TXT-Eintrag, der die Server aufführt, die E-Mails für Ihre Domain senden dürfen. Der Empfänger prüft ihn gegen den Envelope-Sender. Das ist die Adresse im SMTP-MAIL FROM-Befehl. Sie ist nicht der From:-Header, den der Empfänger sieht.

DKIM (DomainKeys Identified Mail) fügt den Headern der Nachricht eine kryptografische Signatur hinzu. Sie umfasst den Nachrichtentext und eine ausgewählte Liste von Headern. Der passende öffentliche Schlüssel liegt unter einem von Ihnen gewählten Selector in DNS. Jeder kann dadurch prüfen, dass die Nachricht vom Inhaber Ihres privaten Schlüssels stammt und unterwegs nicht verändert wurde.

DMARC (Domain-based Message Authentication, Reporting and Conformance) verknüpft die beiden anderen Verfahren mit der Domain im sichtbaren From:-Header. Außerdem teilt es Empfängern mit, was sie tun sollen, wenn diese Verknüpfung fehlschlägt.

example.com.                  TXT  "v=spf1 mx -all"
mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.           TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Entscheidend ist die Übereinstimmung. DMARC ist nicht erfolgreich, nur weil SPF erfolgreich war. DMARC ist erfolgreich, wenn SPF oder DKIM erfolgreich ist und die authentifizierte Domain mit der Domain im From:-Header übereinstimmt. Hier scheitern weitergeleitete E-Mails unauffällig: Ein Relay, das den Envelope-Sender in seine eigene Domain umschreibt, erreicht zwar einen SPF-Pass. Die authentifizierte Domain ist jedoch die Domain des Relays. Deshalb besteht keine Übereinstimmung, und DMARC schlägt fehl, sofern Ihre eigene DKIM-Signatur nicht vorhanden und gültig ist. Signieren Sie mit einem Schlüssel, der unter Ihrer Domain veröffentlicht ist, verschwindet dieses Problem.

Die Übereinstimmung erklärt auch das Verhalten bei Weiterleitungen. Wenn eine Mailingliste oder eine alte Universitätsadresse Ihre Nachricht weiterleitet, wird der Weiterleitungsserver zur verbundenen IP-Adresse. Diese steht nicht in Ihrem SPF-Eintrag. Deshalb schlägt SPF beim endgültigen Empfänger fehl. DKIM bleibt bei der Weiterleitung gültig, solange die signierten Header nicht verändert wurden. DKIM muss in diesem Fall funktionieren.

Veröffentlichen Sie zuerst p=none mit einer rua=-Adresse für Berichte. Lesen Sie anschließend zwei Wochen lang die aggregierten Berichte, bevor Sie die Richtlinien verschärfen. Nur in diesen Berichten sehen Sie E-Mails, die in Ihrem Namen gesendet wurden, aber nicht von Ihnen stammen. Außerdem finden Sie dort Weiterleitungsserver, die Sie vergessen haben. Wenn Sie direkt zu p=reject wechseln, überspringen Sie diesen Schritt und unterbrechen legitime E-Mails, ohne nachvollziehen zu können, was genau fehlgeschlagen ist.

Testen Sie anschließend die gesamte Kette von Anfang bis Ende. Senden Sie eine Nachricht an ein Konto bei einem großen Anbieter, auf das Sie selbst zugreifen können, und öffnen Sie den vollständigen Quelltext:

swaks --to you@gmail.com --from postmaster@example.com --server 127.0.0.1
sudo journalctl -t postfix/smtp -f

swaks gibt die SMTP-Kommunikation in Echtzeit aus. Die eigene Postfix-Logzeile für die Zustellung endet mit status=sent (250 2.0.0 OK ...), wenn der empfangende Server die Nachricht akzeptiert hat. Bei jeder anderen Antwort wird der Ablehnungstext unverändert protokolliert. Nach dieser Zeichenfolge suchen Sie. Im zugestellten Quelltext enthält der Authentication-Results:-Header für jede Prüfung den Status pass oder fail sowie die authentifizierte Domain. Alle drei Prüfungen müssen pass anzeigen, und die Domain muss Ihre eigene sein.

Wie erkennen Sie ein Reputationsproblem?

Eine Feedbackschleife ist eine Vereinbarung, bei der ein Mailbox-Anbieter Ihnen eine Kopie einer Nachricht sendet, sobald einer seiner Benutzer auf die Schaltfläche zum Melden von Spam klickt. Ohne eine solche Schleife ist das erste Anzeichen eines Problems eine bereits fehlgeschlagene Zustellung, die Sie erst Wochen später bemerken.

Die Programme unterscheiden sich, und nicht alle eignen sich für einen einzelnen VPS mit einer Adresse. Im August 2026 betreibt Microsoft einen adressbezogenen Daten- und Beschwerdedienst, für den sich der Inhaber der Adresse registrieren kann. Yahoo bietet eine Complaint-Feedback-Schleife an, die an die DKIM-Signaturdomain gebunden ist. Google veröffentlicht aggregierte Reputationsdaten statt einzelner Beschwerden in einem Dashboard, das leer bleibt, bis Sie täglich eine relevante Nachrichtenmenge an seine Benutzer senden. Lesen Sie die aktuellen Bedingungen der einzelnen Anbieter, bevor Sie sich auf eines dieser Programme verlassen. Die Programme ändern sich, und keiner der Anbieter muss Ihnen Zugriff darauf gewähren.

Die von Google veröffentlichten Anforderungen für Massenversender gelten seit Februar 2024 und sind die eindeutigste öffentliche Aussage darüber, was ein großer Empfänger inzwischen erwartet. Ein Absender, der mehr als 5,000 Nachrichten pro Tag an persönliche Gmail-Konten sendet, muss sich mit SPF und DKIM authentifizieren, eine DMARC-Richtlinie veröffentlichen, für Massenmail einen Abmeldemechanismus mit einem Klick anbieten und die Spam-Beschwerderate unter 0.3 Prozent halten. Persönliche E-Mails von einem kleinen Server liegen deutlich unter diesem Schwellenwert. Dieselben Signale werden jedoch bei jedem Versandvolumen ausgewertet. Die Beschwerderate können Sie ohne Feedbackschleife nicht sehen.

Die funktionierende Aufteilung: E-Mails selbst empfangen, ausgehende E-Mails über ein Relay senden

Der Empfang ist der Teil mit nahezu keinen Nachteilen. Niemand muss Ihnen vertrauen, um E-Mails anzunehmen, die an Sie gesendet wurden. Ihr MX-Record, also der DNS-Record mit dem Mailserver für Ihre Domain, zeigt auf Ihren Server. Absender verbinden sich mit Ihnen. Danach liegt jede Entscheidung bei Ihnen: Was Sie behalten, wie lange Sie es aufbewahren, wie es indiziert wird und wer danach suchen darf. Speicherplatz ist günstig. Ein Archiv, das Ihnen gehört, kann nicht durch eine automatisierte Richtlinienentscheidung an einer anderen Stelle geschlossen werden. Der Aufwand ist real, aber begrenzt: Halten Sie den Spamfilter aktuell, erneuern Sie die TLS-Zertifikate (Transport Layer Security), erstellen Sie Backups und verhindern Sie, dass der Datenträger vollläuft.

Beim Versand umgehen Sie das schwierige Problem, indem Sie dafür bezahlen. Konfigurieren Sie Ihren Server so, dass er jede ausgehende Nachricht an ein authentifiziertes Relay auf Port 587 übergibt, statt über Port 25 direkt mit dem Internet zu kommunizieren. In Postfix steht in main.cf:

relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Schreiben Sie die Zugangsdaten mit einem Editor in /etc/postfix/sasl_passwd, damit das Passwort niemals in Ihrer Shell-History landet. Die Datei enthält eine Zeile. Der Host auf der linken Seite muss exakt so geschrieben werden, wie er in relayhost erscheint:

[smtp.relay.example]:587 username:password

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd.db
sudo systemctl reload postfix

Eine danach gesendete Nachricht protokolliert relay=smtp.relay.example[...]:587 und status=sent. Eine Logzeile mit SASL authentication failed bedeutet, dass die Zugangsdaten nicht akzeptiert wurden. Die häufigste Ursache ist ein Hostname in sasl_passwd, der anders geschrieben ist als in relayhost, weil der Lookup einen exakten Stringvergleich verwendet.

Diese Aufteilung funktioniert, weil das Relay Adressen mit einer über Jahre aufgebauten Zustellreputation verwaltet und deren Pflege sein gesamtes Geschäftsmodell ist. Sie behalten die Domain, die Mailboxen, das Archiv und die Möglichkeit zum Wechsel. Ein anderes Relay zu verwenden, erfordert nur eine Konfigurationszeile und einen DNS-Record. Was Sie aufgeben, ist die Vertraulichkeit ausgehender E-Mails gegenüber dem Relay-Betreiber. Das ist der ehrliche Preis dieser Lösung. Es ist besser, diese Entscheidung bewusst zu treffen, als die Konsequenzen später festzustellen.

Eine weitere Trennung sollten Sie bereits am ersten Tag umsetzen. Alles, was in großen Mengen versendet wird, sollte über eine eigene Subdomain mit einem eigenen DKIM-Schlüssel gesendet werden: news.example.com für einen Newsletter und mail.example.com für persönliche E-Mails. Die Reputation ist an die sendende Domain gebunden. Eine Beschwerderate bei einem selbst gehosteten Listmonk-Newsletter kann dadurch nicht Ihre persönlichen E-Mails beeinträchtigen.

Wann ist vollständiges Self-Hosting weiterhin die richtige Entscheidung?

Volumen. Die Abrechnung pro weitergeleiteter Nachricht ist bei einigen hundert Nachrichten pro Monat gut tragbar und bei mehreren Millionen nicht mehr. In dieser Größenordnung können Sie dedizierte IP-Adressen und den Aufwärmplan finanzieren, der für deren zuverlässigen Einsatz erforderlich ist.

Rechtsordnung. Wenn eine Vorschrift oder ein Vertrag verlangt, dass die E-Mails nicht auf dem Datenträger eines Drittanbieters gespeichert werden dürfen, ist die Zustellqualität nicht entscheidend. Ein Relay steht Ihnen dann schlicht nicht zur Verfügung.

Kontrolle, die Sie nicht kaufen können. Aufbewahrungsregeln, die Ihrer Richtlinie statt einer Tarifstufe entsprechen, eine Adresse pro Dienst, anhand derer Sie erkennen können, wer sie weitergegeben hat, Filterung mit Ihrem eigenen Code und keine Kontosperrung durch ein System ohne Einspruchsmöglichkeit.

E-Mails, die Ihr Netzwerk nie verlassen. Warnungen und andere E-Mails zwischen Maschinen haben überhaupt kein Zustellproblem, weil beide Seiten Ihnen gehören. Ein lokaler SMTP-Server, der E-Mails in Ihre eigenen Postfächer zustellt, ist die vollständige Lösung. Dasselbe Muster steht hinter einem eigenen Self-Hosted-Postfach für einen Assistenten über MCP (model context protocol).

Wenn Sie ausgehend direkt zustellen, wärmen Sie die Adresse auf. Beginnen Sie mit einem geringen täglichen Volumen an Empfänger, die Ihre E-Mails erwarten, erhöhen Sie es über mehrere Wochen schrittweise und senden Sie niemals einen großen Schub von einer kalten Adresse. Reputation entsteht durch akzeptierte E-Mails mit wenigen Beschwerden über einen längeren Zeitraum. Ein plötzlicher Anstieg von einer Adresse ohne Historie sieht daher genau wie ein kompromittierter Server aus und wird auch so behandelt.

Was kostet der Betrieb eines Mailservers im ersten Jahr?

In der ersten Woche erfolgt der Aufbau: Pakete, DNS-Einträge, TLS-Zertifikate, die ersten Testnachrichten und DMARC auf p=none.

Die Wochen zwei bis sechs sind der Teil, den niemand einplant. Sie lesen die DMARC-Aggregate-Reports, finden das bisher unbekannte Alignment-Problem, entdecken den Forwarder, der SPF beschädigt, und setzen die Richtlinie anschließend auf p=quarantine und später auf p=reject. In dieser Phase entscheidet sich, ob Self-Hosting für Sie zur Routine wird oder zu einer Aufgabe, die Sie nur noch widerwillig erledigen.

Danach stabilisiert sich der Aufwand bei ungefähr einer Stunde pro Monat: Paketaktualisierungen, eine Zertifikatserneuerung, die Sie überprüfen statt einfach vorauszusetzen, ein Restore-Test aus dem Backup, ein Blick auf das Disk-Wachstum und eine Abfrage bei einer Blocklist.

Dann gibt es die Woche, die Sie nicht einplanen können. Eine Adresse wird wegen etwas gelistet, das Sie nicht getan haben. Ein großer Empfänger ändert eine Regel, und Ihre Nachrichten landen wieder im Spam. Warteschlangennachrichten sind keine verlorenen Nachrichten: Postfix versucht standardmäßig fünf Tage lang, eine zurückgestellte Nachricht erneut zuzustellen. Dies wird durch maximal_queue_lifetime = 5d festgelegt. Ein Ausfall von einigen Stunden verursacht daher Verzögerungen, aber sonst nichts. Ein Ausfall von einer Woche kostet Sie Nachrichten.

Ein Backup-MX-Record ist eine weniger geeignete Lösung, als es zunächst scheint. Sendende Server führen ihre Zustellversuche ohnehin mehrere Tage lang selbstständig fort. Ein sekundärer Server, der Nachrichten nur in die Warteschlange stellt, bringt daher wenig. Noch problematischer ist ein sekundärer Server, der Nachrichten für Ihre Domain annimmt, ohne zu wissen, welche Adressen existieren. Er nimmt dann auch Nachrichten für nicht vorhandene Adressen an und sendet sie anschließend an gefälschte Absender zurück. Dadurch wird Ihr Backup zu einer Quelle für Backscatter. Investieren Sie den Aufwand stattdessen in Monitoring und in einen Restore, den Sie tatsächlich getestet haben.

Beurteilen Sie das gesamte Vorhaben mit der Frage, die Sie auch auf alles andere auf dem Server anwenden würden: Erhalten Sie durch den eigenen Betrieb etwas, das Sie nicht kaufen können? Für Mailboxen und das Archiv lautet die Antwort meistens ja. Für die Zustellung an fremde Empfänger lautet sie meistens nein. Mit demselben Test lässt sich auch der Rest der Liste der Dinge sortieren, die sich 2026 für Self-Hosting lohnen.

FAQ

Kann ich E-Mail selbst hosten, wenn mein VPS-Anbieter ausgehenden Datenverkehr über Port 25 blockiert?

Ja, für den Empfang und für den Versand über ein Relay. Eingehende E-Mails erreichen Ihren Server über Port 25. Eine Sperre für ausgehenden Datenverkehr wirkt sich darauf nicht aus. Ausgehende E-Mails werden anschließend über ein authentifiziertes Relay auf Port 587 versendet, den Anbieter nicht blockieren. Bei geschlossenem Port 25 können Sie E-Mails jedoch nicht direkt an andere Mailserver zustellen, da die Zustellung zwischen Mailservern definitionsgemäß über Port 25 erfolgt. Testen Sie dies mit nc -vz gmail-smtp-in.l.google.com 25. Eine hängende Verbindung mit anschließendem Timeout bedeutet, dass der Port blockiert ist.

Warum landen meine E-Mails im Spam, obwohl SPF, DKIM und DMARC alle erfolgreich geprüft werden?

Die Authentifizierung belegt, wer eine Nachricht gesendet hat. Sie belegt nicht, dass die Nachricht erwünscht ist. Wenn alle drei Prüfungen erfolgreich sind, wechseln Sie vom Status „nicht identifiziert“ zu „identifiziert“. Danach bewertet der Empfänger die Reputation Ihrer IP-Adresse und Ihrer Domain. Ein neuer Absender verfügt darüber noch nicht. Bauen Sie diese Reputation auf, indem Sie über mehrere Wochen kleine Mengen erwarteter E-Mails versenden. Prüfen Sie anschließend, ob der PTR-Eintrag in beide Richtungen mit dem Hostnamen Ihres Mailservers übereinstimmt. Kontrollieren Sie außerdem, dass der Inhalt keine zusätzlichen Nachteile verursacht, etwa durch URL-Shortener oder eine unbekannte Tracking-Domain.

Benötige ich eine dedizierte IP-Adresse für einen selbst gehosteten Mailserver?

Für die direkte Zustellung ausgehender E-Mails: ja. Ein Mailserver benötigt eine Adresse, deren PTR-Eintrag Sie kontrollieren und deren Reputation ausschließlich Ihnen zugeordnet ist. Eine VPS-Adresse ist in diesem Sinne bereits dediziert. Was Sie nicht kontrollieren, sind ihre Vorgeschichte und die anderen Adressen im selben Netzwerkblock. Wenn Sie ausgehende E-Mails stattdessen über ein Relay versenden, tragen die Adressen des Relays die Reputation. Ihre Adresse muss dann nur eingehende Verbindungen akzeptieren.

Ist es sicher, meine Hauptadresse auf einen selbst gehosteten Server umzustellen?

Stellen Sie schrittweise um, statt die Änderung in einem einzigen Cutover vorzunehmen. Lassen Sie das vorhandene Postfach aktiv, fügen Sie Ihren eigenen Server als zweites Ziel hinzu und leiten Sie einige Wochen lang eine Kopie dorthin weiter. Lesen Sie in dieser Zeit die DMARC-Berichte und bestätigen Sie, dass E-Mails in beide Richtungen zugestellt werden. Ändern Sie den MX-Eintrag erst, nachdem eine Woche lang Test-E-Mails korrekt eingegangen sind. Der Fehler, den viele später bereuen, ist ein Cutover, bei dem eingehende E-Mails verloren gehen. Eingehende E-Mails sind der Teil, der nicht rekonstruiert werden kann.

Was ist die kleinste Konfiguration, mit der ich die Kontrolle über meine E-Mails behalte?

Ihr eigener Server für die Postfächer und das Archiv, während ausgehende E-Mails über ein authentifiziertes Relay auf Port 587 versendet werden. Sie besitzen die Daten und die Domain und vermeiden das Reputationsproblem vollständig. Die Kosten einer späteren Änderung bleiben gering, weil das Relay nur eine Konfigurationszeile und einen SPF-Eintrag erfordert. Es später zu ersetzen, ist an einem Nachmittag erledigt.