Warum der Mailfilter von T-Online ein Problem der Telekom-Kunden ist

"Ich hab nix bekommen!"

Ihr wartet auf eine wichtige E-Mail. Im Posteingang liegt nichts, im Spamordner ebenfalls. Also hat Euch vermutlich niemand geschrieben? Leider ist das nicht immer so einfach.

Eine Nachricht kann bereits am Eingang des Mailproviders abgewiesen werden. Dann erreicht sie Euer Postfach überhaupt nicht. Der Absender erhält normalerweise eine Fehlermeldung – Ihr als Empfänger bekommt von dem Zustellversuch möglicherweise nichts mit.

Genau das ist bei einer Nachricht meines Mailservers an eine T-Online-Adresse passiert. Es folgten rund zehn Tage und zehn E-Mails, bis die Telekom schließlich einen Reputationsreset zusagte.

Der Vorgang wirft für mich eine grundsätzliche Frage auf: Wie gut funktionieren die Annahmeregeln großer Provider für kleine, unabhängig betriebene Mailserver – und welche Folgen haben sie für Eure Erreichbarkeit?

Für kritische/Geschäftskommunikation untragbar?

Ihr nutzt eine T-Online-Adresse und verlasst Euch darauf, dass Kunden, Geschäftspartner oder Bewerber Euch darüber erreichen? Genau dieses Vertrauen stellt mein Fall infrage: T-Online hat eine reguläre Nachricht meines Mailservers abgewiesen, bevor sie überhaupt übertragen wurde. Beim Empfänger kam nichts an – auch nicht im Spamordner. Wer Euch erstmals schreibt, kann so an einer Hürde scheitern, von der Ihr selbst nichts mitbekommt. Als alleinige Adresse für wichtige Kommunikation halte ich T-Online deshalb für nicht verlässlich genug – erst recht im Geschäftsalltag.

Was konkret passiert ist

Am 22. Juli 2026 versuchte mein Mailserver, eine reguläre E-Mail an eine Adresse bei t-online.de zuzustellen. Der angesprochene Telekom-Mailserver antwortete:

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

Mein Versandprotokoll beschrieb den Vorgang mit „refused to talk to me“.

Die Gegenstelle verweigerte den weiteren SMTP-Dialog bereits zu Beginn. SMTP ist das Protokoll, über das Mailserver Nachrichten untereinander übertragen. In diesem Fall kam die Verbindung gar nicht erst bis zur Übermittlung von Nachrichtenkopf und Inhalt.

Eine Prüfung der DKIM-Signatur oder ein vollständiges DMARC-Ergebnis waren damit für diese Nachricht nicht möglich. Was diese Verfahren leisten, erkläre ich weiter unten.

Die Nachricht wurde auch nicht in einen Spamordner einsortiert. Sie wurde gar nicht erst angenommen.

Technisch ist eine solche Ablehnung vorgesehen: SMTP erlaubt ausdrücklich, eine Verbindung schon zu Beginn mit dem Fehlercode 554 zurückzuweisen. Auch andere Provider blockieren Verbindungen zur Abwehr von Spam und Missbrauch. Die Ablehnung allein belegt deshalb keinen Verstoß gegen den E-Mail-Standard. Quelle: RFC 5321, Abschnitt 3.1

Entscheidend sind für mich die Begründung und der Weg zurück zu einer funktionierenden Zustellung.

Die Begründung: längere Zeit keine Aktivität

Auf meine Nachfrage antwortete das Telekom-Team:

Von der genannten IP-Nummer war lange Zeit keine Aktivität bei uns feststellbar. Aus Sicherheitsgründen nehmen unsere Systeme von solchen IP-Nummern erst nach Prüfung und Reset der Reputation E-Mails entgegen.

In dieser Antwort wurde kein konkreter aktueller Spamversand oder anderer Missbrauch meiner IP-Adresse genannt. Als Grund führte die Telekom die längere Inaktivität gegenüber ihren Systemen an.

Die Fehlermeldung „None/bad reputation“ allein unterscheidet nicht eindeutig zwischen fehlender und schlechter Reputation. Erst die ergänzende Antwort machte nachvollziehbar, welche Rolle die fehlende Aktivität in meinem Fall spielte.

Für kleine Betreiber ist das relevant: Ein eigener Mailserver verschickt möglicherweise nur gelegentlich Nachrichten an T-Online. Eine kontinuierliche Versandhistorie bei jedem Empfängerprovider entsteht dabei nicht automatisch.

Wenig Versand beweist zwar keine Vertrauenswürdigkeit. Es ist aber ebenso wenig ein Beleg für Missbrauch. Wenn eine längere Versandpause eine manuelle Prüfung erforderlich macht, wird selbst gelegentliche, berechtigte Kommunikation zum zusätzlichen Betriebsaufwand.

Warum Euch der Spamordner hier nicht hilft

Für Empfänger liegt das Problem in der fehlenden Sichtbarkeit.

Eine im Spamordner abgelegte E-Mail könnt Ihr öffnen, prüfen, als erwünscht markieren und so vielleicht zukünftige E-Mails direkt sehen. Eine vor der Übertragung abgewiesene Nachricht steht Euch dafür nicht zur Verfügung.

Bei einer Ablehnung ganz am Anfang kennt die Gegenstelle zudem noch nicht einmal die konkrete Empfängeradresse. Diese wird erst später im SMTP-Dialog übermittelt. Eine persönliche Benachrichtigung lässt sich diesem Versuch deshalb nicht ohne Weiteres zuordnen.

Das ist nicht die nervige Postwurfsendung, die ihr in den Papiermüll werfen müsst, dass ist der Postbote, der schon vor eurem Briefkasten entscheidet, Briefe an euch weg zu werfen.

Das erklärt die technische Grenze. Die praktische Folge bleibt:

Ihr könnt aus einem leeren Spamordner nicht schließen, dass Euch keine Nachricht entgangen ist.

Bei einer erwarteten Terminbestätigung fällt das vielleicht auf. Bei einer ersten Kundenanfrage, einer Bewerbung oder einem Angebot möglicherweise nicht.

Der Absender kann die Fehlermeldung auswerten und einen anderen Kontaktweg suchen. Der Empfänger weiß unter Umständen gar nicht, dass Handlungsbedarf besteht.

Von der IP-Adresse zur Betreiberwebsite

Für die erneute Annahme verwies die Telekom auf Abschnitt 4.1 ihrer Postmaster-FAQ. Dort fordert sie, dass sich aus dem Hostnamen des einliefernden Systems eine Betreiberwebsite mit unmittelbarer Kontaktmöglichkeit recherchieren lässt. Quelle: Telekom-Postmaster-FAQ, Abschnitt 4.1

Daraufhin richtete ich für die betroffene Domain eine Weiterleitung auf meine geschäftliche Website mit Impressum und Kontaktdaten ein.

Im weiteren Austausch verlangte das Team dann eine entsprechende Erreichbarkeit auch über den konkreten Hostnamen. Außerdem sollte der Kontaktweg "unabhängig vom betroffenen Mailsystem" funktionieren. Eine E-Mail-Adresse innerhalb dieses Systems genügte nach dieser Auskunft nicht.

Ein unabhängiger Kontaktweg kann für Störungen durchaus sinnvoll sein. Er beantwortet jedoch eine andere Frage als die technische Authentifizierung einer E-Mail: Er hilft dabei, einen Betreiber zu erreichen, bestätigt aber nicht die Berechtigung oder Unbedenklichkeit einer konkreten Nachricht.

Die Auflösung: zehn E-Mails und rund zehn Tage später

Ich fragte erneut nach. In meiner Antwort verwies ich auf die eingerichtete Weiterleitung zur Website mit Impressum und Kontaktadresse, die üblichen administrativen Adressen wie postmaster@ und abuse@ sowie die vorhandenen Authentifizierungseinträge.

Auch die pauschale Annahme, eine Kontaktadresse innerhalb der Domain sei im Störungsfall nicht erreichbar, stellte ich infrage. Hinter den Adressen steht eine Cluster-Infrastruktur, bei der Dienste zwischen Systemen wechseln können. Aus der Zugehörigkeit zur gleichen Domain lässt sich daher kein zwangsläufiger gemeinsamer Ausfall ableiten. Eine vollständig unabhängige Erreichbarkeit beweist das umgekehrt allerdings ebenfalls nicht.

Meine abschließende Bitte war konkret: Was spricht jetzt noch gegen die Annahme der E-Mails – und wie lässt sich das Problem abschließend lösen?

Daraufhin kam die entscheidende Antwort des Telekom-E-Mail-Teams:

Wir werden veranlassen, dass die Reputation der IP-Adresse in unserem System resettet wird.

Die Änderung könne bis zu 24 Stunden benötigen, erfahrungsgemäß werde sie innerhalb von ein bis zwei Stunden wirksam.

Damit lenkte die Telekom schließlich ein – nach insgesamt rund zehn Tagen und zehn E-Mails.

Das gehört ausdrücklich zur Geschichte: Es gab eine individuelle Prüfung und am Ende die Zusage, die Reputation zurückzusetzen. Diese Zusage allein ist noch kein Nachweis einer anschließend erfolgreichen Zustellung.

In der abschließenden Antwort wurde weder ein weiterer technischer Mangel benannt noch erläutert, welcher Punkt nun den Ausschlag gegeben hatte. Auch blieb offen, wie sich eine erneute Sperre nach längerer Versandpause vermeiden lässt.

Besonders ernüchternd ist für mich der Vergleich mit meinem früheren Anlauf: Bereits etwa ein Jahr zuvor hatte ich versucht, das Zustellproblem mit T-Online zu klären – damals ohne Erfolg.

Ich begrüße die jetzige Entscheidung. Der Weg dorthin bleibt aus meiner Sicht unverhältnismäßig aufwendig.

Was daraus für InitInsights folgt

Die Telekom hat den Reputationsreset zugesagt. Damit ist eine konkrete Lösung in Aussicht – und das erkenne ich ausdrücklich an.

Meine grundsätzliche Kritik bleibt: Ein Zustellproblem sollte sich anhand klarer Kriterien nachvollziehen und beheben lassen. Nach diesem Austausch weiß ich, dass eine individuelle Klärung möglich war. Ich weiß weiterhin nicht, wie dauerhaft die Freigabe ist und unter welchen Bedingungen erneut Handlungsbedarf entstehen könnte.

Ich werde meine Maildienste weiter pflegen, Zustellfehler auswerten und technische Probleme beheben. Einen vergleichbaren Abstimmungsaufwand kann und möchte ich jedoch nicht bei jeder erneuten Sperre leisten.

Sollten Nachrichten an T-Online erneut abgewiesen werden, werde ich Euch nach Möglichkeit auf anderem Weg kontaktieren und um eine alternative Adresse bitten. Auch Newsletter können von solchen Ablehnungen betroffen sein.

Aus diesem Vorgang lässt sich keine allgemeine Ausfallquote für T-Online ableiten. Für mich ist er dennoch Anlass, eine T-Online-Adresse als alleinigen Kanal für wichtige geschäftliche Kommunikation kritisch zu bewerten. Ein zusätzlicher Kontaktweg ist hier sinnvoll.

Eine Lösung im Einzelfall – offene Fragen beim Verfahren

Diese Geschichte endet mit einer positiven Zusage. Sie zeigt zugleich, wie viel Aufwand nötig sein kann, bis einem kleinen Mailserver die erneute Annahme seiner Nachrichten zugesagt wird.

Auf meiner Seite standen rund zehn Tage und zehn E-Mails. Auf Empfängerseite gab es keine Nachricht, die sich im Spamordner finden oder freigeben ließ.

Genau hier wünsche ich mir Verbesserungen: verständliche Ablehnungsgründe, eindeutige Anforderungen und einen Klärungsprozess, der auch für kleine und selten sendende Systeme praktikabel ist.

Eine Freigabe hilft im konkreten Fall. Ein nachvollziehbares Verfahren hilft auch beim nächsten Mal.

Welche Erfahrungen habt Ihr mit solchen Zustellproblemen gemacht – als Nutzer, Unternehmen oder Betreiber eigener Mailserver? Und wie gut ließ sich für Euch klären, warum eine Nachricht abgewiesen wurde und was für eine dauerhafte Lösung erforderlich war?

Ignorierte technische Möglichkeiten

Was Reverse-DNS damit zu tun hat – und wo es endet

Reverse-DNS lässt sich als Rückwärtssuche beschreiben: Zu einer IP-Adresse wird ein Hostname ermittelt. Löst dieser Hostname wiederum auf dieselbe IP-Adresse auf, ist die Zuordnung konsistent.

Für meinen Server sieht diese technische Kette so aus:

IP-Adresse → mail.jukut.de → dieselbe IP-Adresse

Das wird als Forward-confirmed Reverse DNS bezeichnet.

RFC 1912 beschreibt passende Vorwärts- und Rückwärtszuordnungen im DNS. Eine Website am Mailserver-Hostnamen oder einen externen Kontaktkanal verlangt das Dokument nicht. Es ist außerdem als „Informational“ veröffentlicht. Quelle: RFC 1912, insbesondere Abschnitt 2.1

Die zusätzliche Website- und Kontaktanforderung ist deshalb als eigene organisatorische Annahmeregel zu bewerten. Aus einer korrekten DNS-Zuordnung ergibt sie sich nicht.

Diese Trennung ist wichtig: Technische Standards, betriebliche Kontaktwege und individuelle Providerregeln erfüllen unterschiedliche Zwecke.

Was SPF, DKIM und DMARC leisten

Zum Verständnis meiner Kritik gehört auch die Frage, welche technischen Vertrauenssignale zur Verfügung stehen.

Die drei wichtigsten Begriffe lassen sich so zusammenfassen:

• SPF prüft, ob die einliefernde IP-Adresse für die Domain des technischen Absenders senden darf. Dieser technische Absender kann von der im Mailprogramm sichtbaren Adresse abweichen.
• DKIM verwendet eine digitale Signatur. Sie ermöglicht die Prüfung, ob die signierten Teile einer Nachricht unverändert sind und die Signatur zur angegebenen Domain gehört.
• DMARC stellt die Verbindung zur sichtbaren Absenderdomain her. Dafür muss mindestens eine passende SPF- oder DKIM-Prüfung erfolgreich sein.

Diese Verfahren helfen gegen bestimmte Formen gefälschter Absender. Sie garantieren jedoch weder harmlose Inhalte noch die Zustellung. Auch Angreifer können eigene Domains korrekt authentifizieren. Reputation, Versandverhalten und weitere Filter bleiben deshalb notwendig.

Google verlangt für Sendungen an persönliche Gmail-Adressen unter anderem SPF oder DKIM, gültiges Forward- und Reverse-DNS sowie TLS. Für Versender von mehr als 5.000 Nachrichten täglich gelten zusätzliche Anforderungen, darunter SPF, DKIM und DMARC. Quelle: Google-Richtlinien für E-Mail-Absender

Was die Telekom dazu dokumentiert

In Abschnitt 3.5 ihrer öffentlich abrufbaren FAQ erklärt die Telekom weiterhin, SPF weder beim Empfang noch beim Versand einzusetzen. DKIM werde ebenfalls nicht gesetzt oder ausgewertet; genannt wird eine Ausnahme für „Trusted Dialog“. Quelle: Telekom-Postmaster-FAQ, Abschnitt 3.5

Das ist zunächst eine Aussage über die veröffentlichte Dokumentation. Sie ersetzt keine unabhängige Untersuchung sämtlicher heute eingesetzter Systeme.

Aus dieser Beschreibung lässt sich allerdings nicht nachvollziehen, wie eine reguläre DMARC-Prüfung umgesetzt würde: Dafür benötigt es ein ausgerichtetes, erfolgreiches SPF- oder DKIM-Ergebnis.

Hier wünsche ich mir eine aktuelle und eindeutige technische Erklärung der Telekom.

Mein konkreter Zustellfehler beweist dabei nicht, dass die fehlende Nutzung dieser Verfahren die Sperre verursacht hat. Er zeigt, dass die Verbindung aufgrund der IP-Bewertung bereits endete, bevor die nachrichtenbezogenen Authentifizierungsmerkmale geprüft werden konnten.

Warum das kleine Betreiber besonders trifft

Nach meiner eigenen technischen Prüfung sind auf meinen Systemen alle empfohlenen und verbreiteten aktuellen Methoden, unter anderem konsistentes DNS, SPF, DKIM, DMARC und TLS, eingerichtet. Hinzu kommen Missbrauchsschutz, administrative Kontaktadressen und die Verarbeitung von Unzustellbarkeitsmeldungen.

Das bildet eine nachvollziehbare technische Grundlage für den Mailbetrieb.

Wenn darüber hinaus nach längerer Versandpause eine individuelle Betreiberprüfung erforderlich wird, entsteht zusätzlicher Aufwand. Für kleine Unternehmen, Vereine und private Betreiber kann dieser Aufwand im Verhältnis zu ihrem Versandvolumen erheblich sein.

Große Versandplattformen verfügen häufig über kontinuierlichen Mailverkehr und spezialisierte Teams. Wer einen kleinen Mailserver betreibt, muss solche Klärungen neben dem eigentlichen Betrieb erledigen.

Ein vorgeschalteter Versanddienst kann Zustellprobleme praktisch entschärfen. Für mich bleibt dennoch die Frage, wie eigenständig betriebene Infrastruktur zuverlässig am E-Mail-Verkehr teilnehmen kann.

Ich wünsche mir dafür:

• nachvollziehbare Kriterien für Sperren und deren Aufhebung,
• eine aktuelle Dokumentation der eingesetzten Authentifizierungsverfahren,
• möglichst automatisierte Wege für korrekt betriebene, selten sendende Systeme,
• eine klare Trennung zwischen technischen Anforderungen und organisatorischen Zusatzbedingungen.

Schutz vor Missbrauch und ein praktikabler Zugang müssen zusammen gedacht werden. Ein kleiner Mailserver sollte eine realistische Möglichkeit haben, Vertrauen aufzubauen, ohne dafür einen langen individuellen Abstimmungsprozess durchlaufen zu müssen.