Eine wichtige E-Mail verlässt den eigenen Server – und kommt beim Empfänger nicht an. Nicht weil die Adresse falsch wäre. Nicht weil SPF, DKIM oder DMARC scheitern. Nicht weil der Inhalt als Spam erkannt wurde. Der empfangende Telekom-Server verweigert bereits das Gespräch:

554 IP=203.0.113.42 - None/bad reputation. Ask your postmaster for help or to contact tobr@rx.t-online.de for reset. (NOWL)

Die IP-Adresse in der öffentlich wiedergegebenen Fehlermeldung wurde durch eine reservierte Dokumentationsadresse ersetzt.

Damit ist die Nachricht aussortiert, bevor T-Online Absender, Signatur und Inhalt überhaupt regulär prüfen kann. Betroffen war in unserem Fall eine sachliche Kontaktaufnahme an einen T-Online-Empfänger. Eine zweite legitime Nachricht blieb aus demselben Grund in der Warteschlange. Beide Nachrichten gingen nicht verloren; unser Postfix hält sie zurück und versucht die Zustellung später erneut. Aber sie kamen nicht rechtzeitig an.

Das ist kein kleines Komfortproblem. E-Mail ist weiterhin Infrastruktur für Behördenkontakte, politische Kommunikation, Fristsachen, medizinische Hinweise und persönliche Notfälle. Wer ganze Server-IP-Adressen pauschal an der Tür abweist, übernimmt deshalb Verantwortung für reale Kommunikationsabbrüche.

Was technisch passiert ist

Unser selbstbetriebener YunoHost-Mailserver sendet unter srv.darknight-coffee.org. T-Online blockierte die öffentliche IPv4-Adresse 203.0.113.42 unmittelbar beim SMTP-Verbindungsaufbau. Die hier genannte Adresse ist eine reservierte Dokumentationsadresse; die echte Server-IP veröffentlichen wir nicht. Ein direkter Test gegen den Telekom-Mailserver reproduzierte exakt dieselbe Ablehnung. Der Mailinhalt spielte dabei keine Rolle, weil die Gegenstelle die SMTP-Sitzung gar nicht erst annahm.

Die Postfix-Warteschlange zeigte zwei zurückgehaltene Nachrichten mit derselben Ursache. Das ist wichtig: Eine Warteschlange ist der Rückweg eines ordentlich betriebenen Mailservers. Sie verhindert den sofortigen Verlust und erlaubt spätere Zustellversuche. Sie löst aber nicht das Grundproblem. Solange T-Online die IP ablehnt, läuft jeder automatische Versuch gegen dieselbe Wand.

Unsere eigene Konfiguration war zunächst nicht fehlerfrei

Wer Kritik übt, muss die eigene Seite offenlegen. Nach einem Serverwechsel waren mehrere öffentliche DNS-Einträge noch nicht vollständig auf die neue Hetzner-IP umgestellt. In den DNS-Zonen lagen alte IPv4- und IPv6-Adressen; außerdem fehlten für einzelne Domains Mail-Einträge. Das haben wir nicht kleingeredet, sondern systematisch repariert.

Geprüft und korrigiert wurden unter anderem:

• die A- und AAAA-Einträge der Hauptdomain und aktiver Subdomains;
• MX und SPF;
• der von YunoHost tatsächlich verwendete DKIM-Selektor mail._domainkey;
• DMARC;
• CAA für Let’s Encrypt;
• Reverse-DNS für IPv4 und IPv6.

Beim DKIM-Test lag zunächst auch unsere eigene Annahme daneben: YunoHost nutzte nicht den vermuteten Selektor dkim, sondern mail. Erst die von YunoHost erzeugte DNS-Empfehlung lieferte den korrekten Schlüssel. Genau so muss technische Fehlersuche aussehen: Annahme prüfen, Fehler eingestehen, autoritative Quelle heranziehen und anschließend erneut messen.

Nach den Korrekturen bestätigte YunoHost für den Bereich E-Mail ausdrücklich: Success! Everything looks OK for Email! Der Server war von außen erreichbar, Port 25 offen, Versand und Empfang grundsätzlich möglich. Die öffentliche IPv6-Rückwärtsauflösung zeigte autoritativ korrekt auf srv.darknight-coffee.org. Die Diagnose meldete außerdem keine einschlägige Blacklist-Notierung.

T-Online blockierte die IPv4 trotzdem weiterhin mit None/bad reputation.

Reputation ist eine private Schranke

Der Begriff „Reputation“ klingt objektiver, als er ist. Dahinter stehen Datenbestände, Gewichtungen, Schwellenwerte und Entscheidungen des jeweiligen Anbieters. Von außen ist häufig nicht nachvollziehbar, wodurch eine IP schlecht bewertet wurde, welche Beobachtung zugrunde liegt, wie aktuell sie ist oder wann eine Neubewertung stattfindet.

Gerade kleine selbstbetriebene Mailserver geraten dadurch in eine strukturell schwache Position. Große Plattformen verfügen über etablierte Zustellbeziehungen, eigene Abuse-Abteilungen und erhebliche Mengen historischer Versanddaten. Ein kleiner Server kann technisch sauber arbeiten und trotzdem an einer pauschalen Reputationsentscheidung scheitern. Er muss anschließend beweisen, dass er kein Störer ist.

Die Telekom nennt in ihrer Fehlermeldung immerhin einen Kontaktweg für den Reset. Wir haben ihn genutzt und eine sachliche Prüfung beantragt. Übermittelt wurden die betroffene IP, der Hostname, die vollständige Fehlermeldung und der Hinweis auf die korrigierten Authentifizierungs- und DNS-Daten. Zum Veröffentlichungszeitpunkt steht die inhaltliche Antwort der Telekom noch aus.

Das ist ein dokumentierter Zwischenstand. Wir behaupten nicht, die Telekom habe den Reset endgültig verweigert. Wir halten aber fest: Bis zur manuellen Prüfung bleiben legitime Nachrichten blockiert.

Spamabwehr ist nötig – Pauschalblockaden bleiben problematisch

Natürlich muss T-Online seine Kunden vor Spam, Phishing und Schadsoftware schützen. Ein ungeschützter Mailbetrieb wäre verantwortungslos. Auch eine IP-Reputation kann ein sinnvoller Teil mehrerer Schutzschichten sein.

Problematisch wird sie, wenn sie zur undurchsichtigen Vorentscheidung wird. In unserem Fall wurden weder DKIM noch Inhalt zum entscheidenden Kriterium, weil die Verbindung vorher endete. Damit entwertet die pauschale IP-Sperre einen Teil der Mechanismen, die legitime Absender gerade zur Authentifizierung betreiben.

Die Gegenposition lautet: Ein Provider kann nicht jede eingehende Verbindung individuell untersuchen, wenn eine IP zuvor durch Missbrauch auffiel. Das stimmt. Daraus folgt aber nicht, dass legitime Betreiber tage- oder wochenlang in einer undurchsichtigen Sperre festhängen dürfen. Nötig sind nachvollziehbare Gründe, ein erreichbarer Entstörungsweg, kurze Reaktionszeiten und eine überprüfbare Neubewertung.

Was bei wichtigeren Nachrichten passieren kann

Unsere beiden wartenden Nachrichten sind konkret und relevant. Der strukturelle Punkt reicht weiter. Derselbe Mechanismus kann auch eine Fristsetzung, eine Nachricht an Angehörige oder einen Hinweis auf einen Krankheitsfall verzögern. Der Absender sieht zwar bei sauberem Serverbetrieb die Warteschlange oder später einen Rückläufer. Der Empfänger weiß jedoch nicht, dass überhaupt jemand versucht hat, ihn zu erreichen.

Deshalb darf E-Mail für echte Notfälle nie der einzige Kontaktweg sein. Für vorher vereinbarte Notfallkommunikation braucht es mindestens einen zweiten, unabhängig betriebenen Kanal und klare Regeln, wann er benutzt wird. Technische Redundanz ist keine Paranoia, sondern die Lehre aus einem System, in dem ein einzelner Provider Kommunikation bereits am Eingang beenden kann.

Selfhosting heißt auch Verantwortung übernehmen

Dieser Fall ist kein Werbetext nach dem Muster „Selfhosting gut, Konzerne schlecht“. Ein eigener Mailserver verlangt Arbeit. DNS, Reverse-DNS, Schlüssel, Warteschlangen, Updates, Missbrauchsschutz und Protokolle müssen verstanden werden. Ein Serverwechsel kann alte Einträge zurücklassen. Wer selbst hostet, muss Fehler suchen und öffentlich geäußerte Kritik mit eigenen Messwerten absichern.

Der Vorteil liegt nicht in Fehlerfreiheit. Er liegt in der Prüfbarkeit. Wir konnten die Warteschlange sehen, die Ablehnung reproduzieren, die autoritativen DNS-Daten korrigieren und den Zustand erneut diagnostizieren. Bei einem geschlossenen Maildienst bliebe häufig nur die Meldung: „Die Nachricht konnte nicht zugestellt werden.“

Digitale Souveränität bedeutet deshalb nicht, alles allein zu machen. Sie bedeutet, die eigenen Abhängigkeiten zu kennen, einen Rückweg zu besitzen und gegenüber marktmächtigen Zugangswächtern nicht auf bloßes Vertrauen angewiesen zu sein.

Fazit

T-Online hat unseren Mailserver trotz inzwischen sauber bestätigter Mailkonfiguration weiterhin aufgrund einer internen IP-Reputation abgewiesen. Die betroffenen Nachrichten liegen sicher in der Postfix-Warteschlange, sind aber bis zur Aufhebung der Sperre nicht zugestellt.

Spamabwehr legitimiert keine Blackbox ohne Folgenabschätzung. Wer E-Mail-Infrastruktur für Millionen Menschen betreibt, entscheidet mit solchen Sperren darüber, welche Kommunikation rechtzeitig ankommt. Gerade kleine, unabhängige Server brauchen faire und schnelle Entstörungswege – sonst wird aus Spamabwehr eine Zentralisierung durch technische Tatsachen.

Wir ergänzen diesen Artikel, sobald die Telekom auf den beantragten Reputation-Reset inhaltlich reagiert und die Zustellung erneut geprüft wurde.

Quellen und technische Belege

• T-Online-SMTP-Ablehnung vom 25. August 2026: Fehlercode 554, Begründung None/bad reputation, Reset-Kontakt in der Serverantwort.
• Postfix-Warteschlangenprüfung auf srv.darknight-coffee.org, 25./26. August 2026: zwei zurückgehaltene Nachrichten mit derselben T-Online-Ablehnung.
• YunoHost-DNS-Empfehlung und anschließend autoritativ geprüfte A-, AAAA-, MX-, SPF-, DKIM-, DMARC- und CAA-Einträge.
• Autoritative IPv6-PTR-Prüfung über die Hetzner-Nameserver: Die Rückwärtsauflösung der echten Serveradresse verweist auf srv.darknight-coffee.org; die konkrete IPv6-Adresse wird öffentlich nicht wiedergegeben.
• YunoHost-Maildiagnose vom 26. August 2026: Success! Everything looks OK for Email!

Diskussion: https://treff.darknight-coffee.eu

Blog: https://carrabelloy.darknight-coffee.org/blog/

Wenn dir das Projekt hilft: Spendenlinks sind im Blog.