Eigener Mailserver auf dem VPS: Port 25, PTR & warum Mails im Spam landen

Was ein Mailserver beim Empfang wirklich prüft – und in welcher Reihenfolge

Ein empfangender Mailserver trifft eine ganze Reihe von Entscheidungen, und die meisten davon fällt er, bevor er auch nur ein einziges Byte Ihrer Nachricht gelesen hat. Genau diese Reihenfolge ist der entscheidende Punkt: Ein Problem auf der Verbindungsebene lässt sich nicht durch besseren Inhalt reparieren, und eine perfekt authentifizierte Mail von einer Adresse ohne Historie landet trotzdem im Spam-Ordner. Wer die Kette der Reihe nach liest, sieht sofort, wo die eigene Arbeit tatsächlich hingehört – und das ist fast nie dort, wo die meisten sie investieren.

Die erste Entscheidung fällt bei der TCP-Verbindung: Wer ist das, und soll ich mit dieser Gegenstelle überhaupt reden? In diesem Moment kennt der Empfänger Ihre IP-Adresse, deren Reverse DNS und jede Reputation, die er selbst oder seine Blocklist-Anbieter dieser Adresse zuschreiben. Die zweite Entscheidung fällt beim SMTP-Envelope – HELO und MAIL FROM –, wo SPF gegen die verbindende IP geprüft wird. Die dritte kommt mit den Nachrichtendaten: DKIM-Signaturen werden verifiziert, und DMARC entscheidet, ob eines der Authentifizierungsergebnisse mit der sichtbaren From:-Domain übereinstimmt (Alignment). Erst danach beginnt überhaupt etwas, das wie Content-Filterung aussieht – und zu diesem Zeitpunkt steht das Ergebnis meist schon fest.

Daraus folgen zwei Dinge. Die billigsten Erfolge liegen ganz oben in der Kette: Ein korrekter PTR-Eintrag kostet ein einziges Feld im Kontrollpanel und beseitigt eine ganze Klasse von Ablehnungen. Und das untere Ende der Kette – der Teil, um den sich alle sorgen, der Wortlaut der Nachricht – ist der Teil, auf den Sie am wenigsten Einfluss haben, und der erst relevant wird, sobald alles darüber sauber ist.

Port 25: der günstigste Teil des Problems

Fast jede große Cloud blockiert ausgehenden Port 25 standardmäßig, und die Freischaltung bedeutet: nachfragen. AWS, Google Cloud, Azure, Oracle Cloud und die meisten großen VPS-Marken liefern mit gefiltertem Egress auf Port 25 aus, und der Freischaltungsantrag ist ein Formular, verknüpft mit einem Konto, das bereits Ihre Identität, Ihre Karte und Ihre Telefonnummer trägt. Genau daran scheitert ein Selbsthosting-Plan am häufigsten – still und leise. Und genau deshalb landen die meisten Leute über eine Suche wie welcher VPS hat Port 25 offen auf einer Seite wie dieser.

Es lohnt sich, genau zu unterscheiden, welcher Port wofür da ist, denn die drei werden ständig verwechselt. Port 25 ist Server-zu-Server: So übergibt ein MX eine Nachricht an den nächsten, er wird nie authentifiziert, und er ist der einzige Port, der für die Zustellung an Leute zählt, die nicht Ihre eigenen Nutzer sind. Port 587 ist Submission – Ihre eigenen Clients authentifizieren sich gegenüber Ihrem Server, bevor er für sie weiterleitet. Port 465 macht dasselbe, nur mit TLS ab dem ersten Byte; er wurde in den Neunzigern als veraltet eingestuft und dann durch RFC 8314 offiziell zurückgeholt – heute ist er der vernünftige Standard. Verlieren Sie ausgehenden Port 25, können Sie nicht mehr an die Welt senden; verlieren Sie eingehenden Port 25, kann die Welt Ihnen nicht mehr senden, und es ist durchaus möglich, das eine ohne das andere zu haben und einen ganzen Nachmittag lang DNS die Schuld zu geben.

Bei BitVPS ist ausgehender Port 25 auf jedem Plan und an jedem Standort standardmäßig freigeschaltet. Es gibt kein Formular und kein Ausnahmeverfahren, weil es nichts freizuschalten gibt. Eingehender Port 25, 465 und 587 laufen hinter einer mail-bewussten Scrubbing-Lösung statt hinter einem generischen Layer-3-Filter – genau das macht während eines Angriffs den Unterschied: Ein Filter, der SMTP versteht, kann eine Flut abwehren, ohne dabei auch die legitime MX-Konversation dahinter zu kappen. Die Mailserver-Seite hat die Details, und der DDoS-Erklärartikel beschreibt allgemein, was Scrubbing bedeutet und was nicht.

Ein offener Port 25 ist eine notwendige Bedingung, aber bei weitem keine hinreichende – und genau deshalb geht dieser Guide noch dreitausend Wörter weiter.

Die IP-Adresse entscheidet mehr als Ihre Konfiguration

Ihre Konfiguration ist eine Handvoll DNS-Records und ein Arbeitstag. Die IP-Adresse dagegen ist eine Geschichte, die Sie nicht selbst geschrieben haben. Ein /24, das 2019 Pharma-Spam verschickt hat, wird nicht vergessen; eine Adresse, die von einem letzten Monat gesperrten Kunden recycelt wurde, kommt bereits vorverurteilt an; ein Bereich mit lauten Nachbarn wird bei Empfängern, die auf /24-Ebene bewerten, in Sippenhaft genommen. Nichts davon ist von innerhalb der Maschine sichtbar, und nichts davon lässt sich mit einer besseren main.cf beheben.

Prüfen Sie also vorher, nicht erst hinterher. Die öffentlichen Blocklisten erzählen einen Teil der Geschichte: Spamhaus ist diejenige, die tatsächlich etwas an der Zustellung bewegt – SBL und CSS listen beobachtete Absender, PBL listet Bereiche, deren Betreiber erklärt hat, dass von dort keine Mail direkt versendet werden soll, und DBL listet Domains statt Adressen. Barracuda und SpamCop sind einen Blick wert und lassen sich schnell bereinigen, sobald die Ursache behoben ist. Die zwei Reputationen, die den größten Teil Ihres Ergebnisses entscheiden, sind allerdings privat: Google und Microsoft pflegen jeweils eigene Scores pro IP und pro Domain, die Sie überhaupt nur über Postmaster Tools und SNDS einsehen können – und auch das erst, sobald Sie genug versenden, damit sich überhaupt eine Meinung bilden kann.

Zwei Warnungen zu den Checklisten, die Sie sonst überall finden. Die Hälfte davon rät Ihnen immer noch, SORBS zu prüfen: SORBS wurde von seinem Betreiber am 5. Juni 2024 abgeschaltet, und die Zonen antworten inzwischen mit gar nichts – eine Abfrage dort ist also kein sauberes Zeugnis, sondern eine tote Anfrage. Und begegnen Sie UCEPROTECT Level 2 und Level 3 mit Skepsis – dort werden Nachbarn und ganze autonome Systeme in Sippenhaft gelistet, verbunden mit der Einladung, für eine beschleunigte Entfernung zu zahlen, weshalb die meisten ernstzunehmenden Empfänger sie ignorieren. Einem Level-3-Eintrag hinterherzujagen, ist eine gute Methode, ein ganzes Wochenende mit nichts zu verbringen. Spamhaus' eigenes Reputationsportal ist dasjenige, das Sie ernst nehmen sollten.

Das ist auch der Punkt, an dem ein Host entweder hilft oder eben nicht. BitVPS prüft jede Adresse bei der Bereitstellung gegen die wichtigsten Listen und tauscht sie aus, bevor Sie sich überhaupt zum ersten Mal einloggen, falls sie dort auftaucht. Mail-Kunden bekommen Adressen aus /29-Bereichen, die in den letzten zwölf Monaten von keinem vorherigen Mail-Kunden recycelt wurden, und ein /29 lässt sich zwischen Maschinen im selben Rechenzentrum verschieben, ohne dass sich Ihre IP ändert – was enorm viel wert ist, sobald eine Adresse eine Reputation trägt, an der Sie sechs Monate gearbeitet haben. Nichts davon macht eine Adresse gut; es macht sie neutral, und mehr kann ein Host ehrlicherweise nicht versprechen.

PTR, HELO und A-Record müssen dieselbe Geschichte erzählen

Das ist der mit Abstand häufigste Grund, warum ein sauber installierter Mailserver abgelehnt wird – und zugleich das Günstigste auf dieser Seite, das man richtig hinbekommen kann. Drei Namen müssen übereinstimmen. Ihr Server kündigt sich mit einem Hostnamen in HELO an; dieser Hostname hat einen A-Record, der auf die Adresse zeigt, von der aus verbunden wird; und diese Adresse hat einen PTR-Eintrag, der zurück auf den Hostnamen zeigt. Lösen Sie vorwärts auf, landen Sie bei der Adresse; lösen Sie rückwärts auf, landen Sie beim Namen. Dieser Rundlauf heißt Forward-Confirmed Reverse DNS, und seit Februar 2024 ist ein gültiger PTR-Eintrag bei Gmail keine Nettigkeit mehr, sondern eine erklärte Pflicht für jeden Absender, egal ob Massenversand oder nicht.

Vier Arten, wie es schiefgeht, absteigend nach Häufigkeit sortiert. Es gibt gar keinen PTR, weil der Host das Feld nicht anbietet. Es gibt einen PTR, aber es ist der generische des Providers – etwas, das auf die Domain des Hosting-Unternehmens endet und jedem Empfänger signalisiert, dass hier eine gemietete Adresse aus einem Bereich spricht, der überwiegend keine Mail versendet. Der HELO-Name ist falsch: der Standardwert des Installers, ein kurzer unqualifizierter Hostname oder localhost – nichts davon löst auf. Und der Fall, der selbst vorsichtige Leute erwischt: Die Maschine hat IPv6, die MTA bevorzugt IPv6, sobald der Empfänger einen AAAA-Record veröffentlicht, und auf der v6-Adresse fehlt der PTR – Mail an Gmail über IPv4 funktioniert also einwandfrei, während dieselbe Mail über IPv6 abgelehnt wird. Setzen Sie entweder den v6-PTR korrekt, oder pinnen Sie den Transport mit smtp_address_preference = ipv4, bis Sie das erledigt haben.

Bei BitVPS ist das PTR-Feld für jede IPv4- und IPv6-Adresse im Panel selbst bedienbar, es akzeptiert jeden FQDN, den Sie wollen, ohne erzwungenes Provider-Suffix, Änderungen verbreiten sich global in unter fünf Minuten, und Massenbearbeitungen decken bis zu zehn Adressen gleichzeitig ab. Die Netzwerk-Seite hat die Details, und der Grund, warum genau das zählt, steht in diesem Abschnitt: Ein Host, bei dem Sie für den Reverse-DNS-Eintrag ein Ticket öffnen müssen, ist ein Host, bei dem Sie bei jedem Neuaufbau wieder ein Ticket öffnen müssen.

SPF, DKIM und DMARC: was jedes davon beweist – und was Alignment bedeutet

Alle drei werden als DNS-Records veröffentlicht, ihre Einrichtung dauert eine Stunde, und fast überall werden sie schlecht erklärt – meist als drei austauschbare Spam-Amulette statt als drei unterschiedliche Aussagen. SPF (RFC 7208) legt fest, welche Adressen Mail mit einem bestimmten Envelope-Absender verschicken dürfen. DKIM (RFC 6376) hängt eine kryptografische Signatur über Header und Body an, sodass die Nachricht beweisen kann, welche Domain die Verantwortung dafür übernommen hat. Keines von beiden sagt irgendetwas über die Adresse aus, die Ihr Empfänger tatsächlich sieht.

Das ist die Aufgabe von DMARC (RFC 7489), und deshalb ist Alignment das Wort, auf das es ankommt. DMARC besteht, wenn SPF oder DKIM besteht und die dabei authentifizierte Domain mit der Domain im sichtbaren From:-Header übereinstimmt. Genau hier liegt der klassische Fehler: Ihre Mail besteht SPF, weil die Bounce-Adresse auf einer Domain liegt, die der Versand-Host kontrolliert, aber diese Domain steht nicht im From:-Header – kein Alignment also, und ohne DKIM-Signatur als Rückfallebene scheitert DMARC an einer Nachricht, die in den Logs perfekt authentifiziert aussah. Der andere Klassiker: p=reject am ersten Tag veröffentlichen, bevor auch nur ein einziger Report gelesen wurde, und einen Monat später feststellen, dass das Rechnungssystem die ganze Zeit still abgelehnt wurde. Starten Sie mit p=none und einer rua-Adresse, lesen Sie, was ankommt, und ziehen Sie erst danach die Zügel an.

Zwei praktische Hinweise, die mehr wert sind, als sie aussehen. Halten Sie den SPF-Record innerhalb von zehn DNS-Lookups – jedes include: kostet einen, und drei verschachtelte SaaS-Anbieter sprengen das Limit und werden zu einem permanenten Fehler statt zu einem weichen Ausfall. Und rotieren Sie DKIM-Selectors gelegentlich statt nie: Ein Selector ist billig hinzuzufügen, und einen zweiten bereits veröffentlicht zu haben, ist der Unterschied zwischen einer Fünf-Minuten-Schlüsselrotation und einem Ausfall.

Die Untergrenze verschob sich 2024 – und 2025 erneut

Zwanzig Jahre lang lautete die Grundvoraussetzung für den Mailversand ungefähr: „Haben Sie einen PTR und stehen Sie nicht bei Spamhaus.“ Das änderte sich im Februar 2024, als Google und Yahoo nahezu identische Absenderanforderungen veröffentlichten und begannen, sie durchzusetzen. Jeder Absender – auch Sie, mit vier Nachrichten am Tag – braucht jetzt einen gültigen Forward-Confirmed-PTR-Eintrag, TLS auf der Verbindung und mindestens SPF oder DKIM. Absender mit mehr als etwa fünftausend Nachrichten am Tag an einen einzelnen Empfänger brauchen SPF und DKIM und einen DMARC-Record, einen funktionierenden One-Click-Unsubscribe-Header gemäß RFC 8058 und eine Spam-Beschwerdequote unter 0.3%.

Microsoft zog am 5. Mai 2025 mit einer Regel derselben Form für Outlook.com, Hotmail und Live nach: Domains, die mehr als fünftausend Nachrichten am Tag an diese Consumer-Postfächer senden, müssen SPF, DKIM und DMARC vorweisen, wobei nicht konforme Mail zunächst in den Junk-Ordner geroutet und danach ganz abgelehnt wird. Microsofts Sender-Support und Yahoos Best Practices sind beide zehn Minuten Lesezeit wert, bevor Sie irgendetwas verschicken.

Die praktische Konsequenz für einen persönlichen Server oder den eines kleinen Teams ist nicht, dass Sie die Schwellenwerte erwischen – das tun sie nicht –, sondern dass die unauthentifizierte Grundeinstellung inzwischen wirklich auffällig ist. Mail ohne DMARC-Record von einer Adresse ohne Historie galt früher als normal. 2026 sieht das genau nach dem Profil aus, gegen das die Filter eigentlich gebaut wurden. Konfigurieren Sie so, als wären Sie ein Massenversender, auch wenn Sie keiner sind – es kostet einen Nachmittag, und die Alternative ist, gegen eine Gruppe bewertet zu werden, zu der Sie gar nicht gehören.

Eine unbekannte Adresse aufwärmen (IP-Warmup)

Eine neue Adresse startet nicht wirklich neutral, sondern unbekannt, und unbekannt wird mit Misstrauen behandelt – im Verhältnis dazu, wie viel Sie versenden. Der Weg, der funktioniert, ist unspektakulär: Fangen Sie mit echter Korrespondenz an Leute an, die tatsächlich öffnen und antworten, halten Sie das tägliche Volumen einigermaßen stabil und lassen Sie es allmählich statt in Sprüngen wachsen, und richten Sie niemals eine gekaufte oder irgendwoher exportierte Liste auf eine frische Adresse. Engagement ist das Signal, das aus unbekannt vertraut macht, und dafür gibt es keine Abkürzung.

Messen Sie mit den Werkzeugen, die Ihnen die Empfänger selbst geben, statt in Ihr eigenes Postfach zu schauen. Googles Postmaster Tools zeigen Domain- und IP-Reputation, Spam-Beschwerdequoten und Authentifizierungs-Erfolgsquoten, sobald Sie die Domain verifiziert haben – bleiben aber leer, bis Sie genug versenden, damit überhaupt etwas aggregiert werden kann, was bei einem persönlichen Server durchaus nie der Fall sein kann, und das ist in Ordnung. Microsofts SNDS macht dasselbe für Outlook.com und ist mit dem Junk Mail Reporting Program gekoppelt, das Beschwerden direkt an Sie weiterleitet. Ein Einmal-Scoring-Dienst ist nützlich, um einen kaputten Record in zehn Sekunden zu erwischen, und für alles andere nutzlos – er sagt Ihnen nichts über Reputation, weil er ebenfalls keine Historie mit Ihnen hat.

Seien Sie ehrlich mit Ihren Erwartungen an den schwierigsten Empfänger. Outlook.com ist die Stelle, an der sich eine neue Adresse am längsten schwertut: Es ist üblich, dass ein korrekt konfigurierter Server mit perfekter Authentifizierung dort wochenlang im Junk-Ordner landet, während Gmail ihn schon ab der ersten Nachricht akzeptiert. Die Lösung ist Zeit, Konstanz und Empfänger, die die Nachricht selbst aus dem Junk-Ordner holen – kein weiterer DNS-Record. Wenn Outlook.com-Zustellbarkeit am ersten Tag eine geschäftliche Notwendigkeit ist und keine bloße Präferenz, ist das eines der Signale, dass Sie eher ein Relay wollen als einen selbst gehosteten Absender – das Thema des letzten Abschnitts.

Welche Software Sie brauchen – und wie viel Maschine dafür nötig ist

Vier Varianten decken fast jeden Fall ab. Postfix zusammen mit Dovecot für IMAP und rspamd für die Filterung ist das Referenz-Setup: drei Daemons, Klartext-Konfiguration, und jede Fehlermeldung, die Ihnen je begegnen wird, ist irgendwo bereits beantwortet. OpenSMTPD erledigt denselben Job mit einer Konfigurationsdatei, die Sie in einer Sitzung durchlesen können – das ist um drei Uhr nachts mehr wert, als es klingt. Stalwart ist eine einzige Binary, die SMTP, IMAP und JMAP spricht, mit eingebauter Filterung, und heute die angenehmste Option für einen Neuaufbau. Und Mailcow oder Mail-in-a-Box bauen Ihnen das Ganze fertig zusammen, Webmail inklusive – zum Preis eines Stacks, den Sie sich nicht ausgesucht haben und den Sie nicht ohne Weiteres wieder auseinandernehmen können.

Bei der Dimensionierung geht es weniger um Postfächer als um das, was Sie vorne dranhängen. SMTP und IMAP selbst sind günstig; ein paar Dutzend Postfächer sind auf jeder modernen Maschine ein Rundungsfehler. Der Speicher fließt in die Filterung. rspamd ist genügsam, ein paar hundert Megabyte mit geladenen Maps. ClamAV nicht: Allein die Signaturdatenbank drückt es weit über ein Gigabyte residenten Speicher, und es ist die eine Komponente, die eine kleine Instanz am ehesten ins Swapping treibt – was bei einem Mailserver bedeutet, dass sich die Queue staut und die Zustellung so weit verlangsamt, dass Empfänger anfangen, Sie zu deferren. Betreiben Sie es, wenn Sie das RAM haben, lassen Sie es weg, wenn nicht, und überlassen Sie rspamd die Hauptlast.

Übertragen auf reale Pläne: Ein Starter für $8.50 mit 2 vCPU, 4 GB RAM und 60 GB NVMe betreibt Postfix, Dovecot und rspamd für eine persönliche Domain problemlos, solange Sie ClamAV weglassen. Ein Growth für $13.50 mit 4 vCPU, 8 GB und 120 GB ist die Größe, ab der Sie gar nicht mehr darüber nachdenken – zwanzig bis dreißig Postfächer mit voller Filterung, reichlich Luft für einen Mail-Speicher, der jahrelang wächst. Speicherplatz ist die Achse, die tatsächlich zuerst knapp wird, denn Mail wird für immer aufbewahrt, von jedem, der jemals eine bekommen hat.

In der richtigen Reihenfolge live gehen

1. Domain zeigen lassen und Instanz ausrollen. Entscheiden Sie sich für den Hostnamen, mit dem sich der Server identifiziert – mail.example.com ist die Konvention –, veröffentlichen Sie dessen A-Record, fügen Sie AAAA nur hinzu, wenn Sie über IPv6 senden wollen, und veröffentlichen Sie den MX-Record der Domain, der auf diesen Namen zeigt. Wählen Sie den Standort, der den Leuten am nächsten liegt, mit denen Sie korrespondieren; bei BitVPS ist die Instanz etwa sechzig Sekunden nach Zahlungsbestätigung live, mit bereits offenem ausgehendem Port 25.

2. Reverse DNS passend setzen. Setzen Sie den PTR der IPv4-Adresse – und der IPv6-Adresse, falls Sie eine AAAA veröffentlicht haben – exakt auf den Hostnamen aus Schritt eins. Vorwärts und rückwärts müssen in beide Richtungen übereinstimmen. Das ist ein einziges Feld im Panel, und es ist die wertvollste Minute im ganzen Verfahren.

3. Die richtigen Ports in beide Richtungen öffnen. Ausgehend 25 zum Zustellen, eingehend 25 zum Empfangen, 587 und 465 für die Submission Ihrer eigenen Nutzer, 993 für IMAP, alles andere geschlossen. Eine Firewall, die ausgehenden Port 25 erlaubt, aber nicht eingehenden, sieht in der ersten Stunde der Fehlersuche exakt wie ein DNS-Problem aus – ist es aber nicht.

4. MTA installieren und ihm eine echte Identität geben. Postfix, OpenSMTPD oder Stalwart; setzen Sie den HELO-Namen auf den Hostnamen aus Schritt eins; aktivieren Sie TLS mit einem Zertifikat für diesen Namen. Let's Encrypt ist kostenlos und das, was der Großteil des Internets vorzeigt. Schicken Sie sich selbst eine Nachricht und lesen Sie die Header, bevor Sie weitermachen – jeder spätere Schritt setzt voraus, dass dieser hier funktioniert hat.

5. SPF, DKIM und DMARC veröffentlichen. Ein SPF-Record, der die sendende Adresse listet und während des Testens auf ~all endet. Ein 2048-Bit-DKIM-Schlüssel mit veröffentlichtem Selector und aktivierter Signierung. Ein DMARC-Record auf p=none mit einer rua-Adresse, damit Reports zu kommen beginnen. Drei DNS-Records, keine Kosten, höchstens eine Stunde.

6. Die Authentication-Results lesen, nicht das Postfach. Senden Sie an Gmail, an Outlook.com und an einen Empfänger im Firmenumfeld, öffnen Sie dann bei jedem Authentication-Results. Sie wollen spf=pass, dkim=pass, dmarc=pass, und das Alignment gegen die Domain im sichtbaren From:. Junk mit drei Pässen ist ein Reputationsproblem; Junk mit einem Fehlschlag ist ein Konfigurationsproblem. Beides wird auf völlig unterschiedliche Weise behoben, und wer die beiden verwechselt, verschwendet Wochen.

7. Anziehen, sobald die Reports sauber sind. Nach ein bis zwei Wochen DMARC-Reports, in denen keine legitime Quelle scheitert, wechseln Sie zu p=quarantine, später zu p=reject, und ändern Sie SPF von ~all auf -all. Wer anzieht, bevor er Reports gelesen hat, blockiert auf diese Weise einen Monat lang die eigenen Rechnungen, ohne es zu merken.

8. Die Teile ergänzen, die alle vergessen. Veröffentlichen Sie MTA-STS und TLS-RPT, damit andere Absender wissen, dass sie bei Ihnen auf TLS bestehen sollen, fügen Sie DANE hinzu, falls Ihre Zone signiert ist, stellen Sie rspamd vor das Postfach, sichern Sie den Mail-Speicher irgendwo, das nicht diese Maschine ist, und verschlüsseln Sie ihn im Ruhezustand – der Guide zur Festplattenverschlüsselung erklärt, was das schützt und was nicht. Behalten Sie danach die ausgehende Queue im Auge: eine Queue, die still wächst, ist das erste Symptom eines Reputationsproblems, und das zeigt sich Tage, bevor Ihnen ausbleibende Antworten auffallen.

Wann Self-Hosting das falsche Werkzeug ist

Es gibt Fälle, in denen der Betrieb eines eigenen Absenders ein schlechter Tausch ist, und diese klar zu benennen, hilft mehr als noch ein weiterer Absatz Ermutigung. Kaltstart-Massenmarketing ist der offensichtlichste Fall: eine frische Adresse ohne Historie, die Tausende Nachrichten verschickt, ist genau die Signatur, für deren Erkennung die Filter gebaut wurden, und keine Konfiguration rettet das. Transaktionale Mail, bei der eine verlorene Nachricht bares Geld kostet – Passwort-Resets, Bestellbestätigungen, Zwei-Faktor-Codes – gehört auf Infrastruktur mit etablierter Reputation, denn die zwei Wochen, in denen sich eine neue Adresse beweisen muss, sind zwei Wochen Support-Tickets. Und jedes Team ohne jemanden, der sonntags mal in die Mail-Queue schaut, ist ein Team, das am Montag entdeckt, dass sein Versand seit Freitag hängt.

Es gibt außerdem einen Anonymitäts-Tausch, den die meisten Anleitungen auslassen. Ein Mailserver ist so ziemlich das Unanonymste, was Sie betreiben können. Er veröffentlicht eine Domain, eine feste Adresse, einen PTR-Eintrag, der diese Domain nennt, einen MX-Record, der beides verknüpft, und liefert jedem Empfänger einen vollständigen Satz Header, der den Weg beschreibt. Anonymität und ein öffentlicher MX ziehen in entgegengesetzte Richtungen, und wenn Ihr eigentlicher Grund hier Privatsphäre statt Kontrolle ist, lesen Sie wie nachverfolgbar Krypto-Hosting wirklich ist, bevor Sie loslegen. Self-Hosting entfernt tatsächlich einen Dritten aus Ihrer gespeicherten Mail und ihren Metadaten, was ein echter und lohnender Gewinn ist – es macht die Mail selbst aber nicht anonym, und das kann es auch gar nicht, denn die Hälfte jedes Gesprächs liegt im Postfach von jemand anderem.

Das Arrangement, das für die meisten funktioniert, ist eine Aufteilung: Mail, die unbedingt ankommen muss, bleibt bei einem Anbieter mit Reputation, eine zweite Domain wird selbst gehostet für die Korrespondenz, die Sie von Drittanbieter-Infrastruktur weghaben wollen – und jedes System trägt die Last, für die es gut ist. Das kostet eine zusätzliche DNS-Zone, bedeutet, dass kein System einen Job macht, für den es schlecht geeignet ist, und ist genau das, was ein großer Teil der Leute tut, die einen Mailserver auf BitVPS betreiben. Was auch immer Sie verschicken: nur Opt-in – gekaufte Listen liegen außerhalb unserer Nutzungsrichtlinie und sind der schnellste Weg, eine Adresse zu verbrennen, die sauber war, als wir sie Ihnen übergeben haben.