Hat Strato ein Konfigurationsproblem bei seinen E-Mail-Servern? Ein Leser hat mich darüber informiert, dass von Strato-E-Mail-Servern verschickte E-Mails beim Empfänger als SPAM klassifiziert werden. Ich packe es mal separat in einen kurzen Beitrag. Ergänzung: Inzwischen gibt der Leser an, dass das Problem nicht mehr reproduzierbar sei, obwohl nichts geändert wurde.
Blog-Leser Christian Krause hat sich per E-Mail gemeldet und den Sachverhalt in diesem Kommentar dargestellt. Dazu schrieb er:
Mehrere Kunden beschweren sich darüber, dass E-Mails von Strato bei anderen Anbietern im Spamordner landen.
Kunden nutzen alle den Strato eigenen Server zum Versand und es betrifft nicht alle E-Mails, sondern nur sporadisch einige.
Für mich sieht das so aus, als ob einige DNS Server bei Strato nicht/nicht rechtzeitig/falsch antworten und daher DKIM oder SPF nicht geprüft werden kann.
Strato schweigt und weiß von nichts. Noch jemand betroffen?
Betrifft mindestens 3 Kunden und ist mir seit dem 14.01. bekannt.
Ergänzung: Derzeit ist die technische Seite ziemlich offen – der Leser gibt an, dass er bei seinen Postfächern den Fehler nicht nachstellen könne – die "Problem-Mails der Kunden" geben wohl nicht viel her. Der Leser schrieb:
Ich kann den Fehler bei Strato zur Zeit nicht reproduzieren. Ich bin selbst kein Kunde von Strato/Ionos und habe nur Kenntnis von zwei betroffenen E-Mails. Zwei sind für mich mehr als ein bedauerlicher Einzelfall und die Rückmeldungen im Forum bestätigen ja, dass es dort ein Problem gab oder noch gibt.
Sämtliche Testmails, die ich im Anschluss geschrieben habe waren allerdings DKIM technisch korrekt.
Ich habe den Ablehnungslog meines Proxmox, sowie ein Screenshot des Ablehnungslogs der zweiten E-Mail als Screenshot. Die sagen nur, was schon bekannt ist: DKIM fehlerhaft. Da die E-Mail nicht angenommen wurde, liegt mir keine Header Information vor.
Der Leser hat dann noch folgenden Log übermittelt.
2026-01-14T14:10:14.645717+00:00 mx postfix/smtpd[41372]: connect from mout.kundenserver.de[212.227.126.187] 2026-01-14T14:10:15.229388+00:00 mx postfix/smtpd[41372]: NOQUEUE: client=mout.kundenserver.de[212.227.126.187] 2026-01-14T14:10:15.653495+00:00 mx pmg-smtp-filter[40522]: 110666967A3C78806B: new mail message-id=<B45D635A-6F4D-4563-94E9-20E0D416523F@****.de> 2026-01-14T14:10:20.160101+00:00 mx pmg-smtp-filter[40522]: 110666967A3C78806B: SA score=6/5 time=1.509 bayes=undefined autolearn=disabled hits=DKIM_BAD(3),DKIM_INVALID(0.1),DKIM_SIGNED(0.1),FROM_TLD_ANY(1),FROM_TLD_WHITELIST(1),KAM_DMARC_STATUS(0.01),RCVD_IN_DNSWL_NONE(-0.0001),RCVD_IN_HOSTKARMA_BL(1.5),RCVD_IN_MSPIKE_H2(0.001),RCVD_IN_PBL(0.001),RCVD_IN_VALIDITY_CERTIFIED_BLOCKED(0.001),RCVD_IN_VALIDITY_RPBL_BLOCKED(0.001),RCVD_IN_VALIDITY_SAFE_BLOCKED(0.001),SPF_HELO_NONE(0.001),SPF_PASS(-0.001) 2026-01-14T14:10:20.166034+00:00 mx pmg-smtp-filter[40522]: 110666967A3C78806B: block mail to <mail@***r.de> (rule: Block Spam (Level 6)) 2026-01-14T14:10:20.178220+00:00 mx pmg-smtp-filter[40522]: 110666967A3C78806B: processing time: 4.578 seconds (1.509, 2.988, 0) 2026-01-14T14:10:20.178983+00:00 mx postfix/smtpd[41372]: proxy-reject: END-OF-MESSAGE: 554 5.7.1 Rejected for policy reasons (110666967A3C78806B); from=<info@***.de> to=<mail@****.de> proto=ESMTP helo=<mout.kundenserver.de> 2026-01-14T14:10:20.184699+00:00 mx postfix/smtpd[41372]: disconnect from mout.kundenserver.de[212.227.126.187] ehlo=2 starttls=1 mail=1 rcpt=1 data=0/1 quit=1 commands=6/7
Laut Leseraussage gingen anschließende Testmails einwandfrei durch, obwohl nichts geändert wurde. Die Ionos/Strato DNS-Einstellungen befinden sich (nach wie vor) in der Default-Einstellung. Nachfolgend noch ein zweiter Log:
2026-01-21T09:14:31.490059+00:00 mx postfix/smtpd[99362]: connect from mout.kundenserver.de[212.227.126.134] 2026-01-21T09:14:32.389300+00:00 mx postfix/smtpd[99362]: NOQUEUE: client=mout.kundenserver.de[212.227.126.134] 2026-01-21T09:14:32.514533+00:00 mx pmg-smtp-filter[90857]: 11C15697098F877CFE: new mail message-id=<1347399070.431676.1768986865362@email.ionos.de> 2026-01-21T09:14:33.529192+00:00 mx pmg-smtp-filter[90857]: 11C15697098F877CFE: SA score=2/5 time=0.942 bayes=undefined autolearn=disabled hits=BODY_SINGLE_WORD(0.293),DKIM_SIGNED(0.1),DKIM_VALID(-0.1),DKIM_VALID_AU(-0.1),DKIM_VALID_EF(-0.1),FROM_TLD_ANY(1),FROM_TLD_WHITELIST(1),RCVD_IN_DNSWL_NONE(-0.0001),RCVD_IN_MSPIKE_H5(0.001),RCVD_IN_MSPIKE_WL(0.001),SPF_HELO_NONE(0.001),SPF_PASS(-0.001) 2026-01-21T09:14:33.546449+00:00 mx postfix/smtpd[99371]: connect from localhost[127.0.0.1] 2026-01-21T09:14:33.560570+00:00 mx postfix/smtpd[99371]: 88BA711A43: client=localhost[127.0.0.1], orig_client=mout.kundenserver.de[212.227.126.134] 2026-01-21T09:14:33.562668+00:00 mx postfix/cleanup[99372]: 88BA711A43: message-id=<1347399070.431676.1768986865362@email.ionos.de> 2026-01-21T09:14:33.604595+00:00 mx postfix/smtpd[99371]: disconnect from localhost[127.0.0.1] ehlo=1 xforward=1 mail=1 rcpt=1 data=1 commands=5 2026-01-21T09:14:33.605149+00:00 mx postfix/qmgr[823]: 88BA711A43: from=<info@***.de>, size=5320, nrcpt=1 (queue active) 2026-01-21T09:14:33.605323+00:00 mx pmg-smtp-filter[90857]: 11C15697098F877CFE: accept mail to <mail@****r.de> (88BA711A43) (rule: default-accept) 2026-01-21T09:14:33.612434+00:00 mx pmg-smtp-filter[90857]: 11C15697098F877CFE: processing time: 1.112 seconds (0.942, 0.066, 0) 2026-01-21T09:14:33.613033+00:00 mx postfix/smtpd[99362]: proxy-accept: END-OF-MESSAGE: 250 2.5.0 OK (11C15697098F877CFE); from=<info@***.de> to=<mail@***r.de> proto=ESMTP helo=<mout.kundenserver.de> 2026-01-21T09:14:33.621435+00:00 mx postfix/smtpd[99362]: disconnect from mout.kundenserver.de[212.227.126.134] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 2026-01-21T09:14:35.534708+00:00 mx postfix/smtp[99373]: 88BA711A43: to=<mail@***.de>, relay=172.30.0.3[172.30.0.3]:25, delay=2, delays=0.06/0.03/0.47/1.4, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 6D75A39547) 2026-01-21T09:14:35.535135+00:00 mx postfix/qmgr[823]: 88BA711A43: removed
Der Leser schließt daraus: "Es ist möglich, dass der Fehler längst behoben ist. Am Ende liegt Troubleshooting und Behebung bei Ionos/Strato. Der Anwender kann da weder groß etwas prüfen."
Inzwischen hat sich Strato bei mir gemeldet. Ich stelle mal deren Stellungnahmen hier zur Information ein.
Natürlich kommt es aus unterschiedlichsten Gründen vor, dass valide Nachrichten bei einem empfangenden Provider als Spam aufgefasst werden – außerhalb der Verantwortung von STRATO. Ein Beispiel: Ob der in der DNS hinterlegte Public Key korrekt ausgelesen wird, liegt auch in der Verantwortung des empfangenden E-Mail-Providers – der naturgemäß nicht bei jeder Anfrage auf STRATO DNS-Server zugreift, sondern einen lokalen Resolver hat, der unter Umständen temporär nicht oder zu langsam antwortet, weswegen im Ergebnis Fehler sporadisch auftreten. STRATO hat ebenfalls keine Kontrolle über die spezifische Konfiguration von SPAM-Filtern auf Empfängerseite.
STRATO hat überdies und gerade im Interesse der Kundinnen und Kunden vor einigen Monaten den wichtigen Schritt zur Erhöhung der Sicherheit getan und für alle Domains DMARC p=reject eingestellt, damit Spoofing von den bei STRATO gehosteten Domains aus bedeutend erschwert wird.
STRATO kommt hier seiner Verantwortung als sicherer Mailservice-Provider nach – nicht umsonst sind wir als Gold-Partner Teil der BSI/eco/Bitkom-Initiative, das Zielbild von E-Mail-Sicherheit messbar voranzubringen.
Statt dies aber zu honorieren, weil damit ein Mechanismus eingesetzt wird, der im Interesse aller das tendenziell zunehmende Phishing einschränkt, stellen Sie einen ausgewählten Fall in den Vordergrund, in dem dieser Mechanismus sehr wahrscheinlich aufgrund von unzureichenden Anpassungen in den Einstellungen oder auf Empfängerseite zur Ablehnung geführt hat.
In Ihrem Beitrag wird zudem "Strato schweigt und weiß von nichts." zitiert – und damit einer möglichen Falschdarstellung mehr Raum gegeben – mit entsprechenden weiterführenden Informationen untersuchen wir gerne den Sachverhalt des konkreten Falls. Zudem klären wir zu den Themen Phishing, DMARC und DNS-Einstellungen ausführlich und transparent in unserem Hilfebereich auf.
Lasse sich so stehen – aktuell lässt sich nicht mehr aufklären, was nun wirklich geklemmt hat. Wenn die Kunden des Dienstleisters, die den obigen Fall aufgeworfen haben, zufrieden sind, weil die Mails wieder zugestellt werden, ist das Thema vom Tisch.
MVP: 2013 – 2016
Hat er mal den Strato-Support kontaktiert?
Ich nutze Strato nur privat mit eigener Domain, habe gerade mal Testmails an meine dienstliche Adresse gesendet. Da kommt alles korrekt an. Bisher auch von keinem Empfänger etwas in die Richtung gehört.
Wir haben das ebenfalls beobachtet betrifft meist Mails die von [….]_smtp_rzone_de versendet werden was anscheinend Strato Webmail ist. Unser Mailsystem meldet bei den betreffenden ( nicht alle) Mails "DKIM falsch" und "DMARC reject" bei denen ich getestet hatte gab es keinen passenden SPF Record
Möglicherweise hat das etwas damit zutun:
https://borncity.com/blog/2025/06/06/strato-aktiviert-automatisch-eine-dmarc-pruefung-fuer-mails/
Die Antworten der DNS Server lassen sich ja leicht prüfen, hat er das konkret gemacht? Der Fall klingt sehr ungewöhnlich.
Ich konnte den Fall nicht einmal nachstellen.
Am 14.01. wurde von meinem Spamfilter eine Mail eines anderen Unternehmens abgelehnt wegen DKIM Fehler.
Das haben wir uns gestern angesehen und es lies sich gestern nicht mehr nachstellen. Der Sender war bei Ionos (gehört ja zu Strato)
Ungefähr zur gleichen Zeit bekam ich von einem meiner Kunden die Info: "Meine E-Mails landen im Spam", zusammen mit einem Screenshot seines Kunden mit Hinweis auf DKIM/SPF Prüfung. Mein Kunde ist bei Strato. Testmails bei mir kamen ohne Beanstandung an.
Als dann der Dritte Hinweis eines Dritten noch am gleichen Tag reinkam, hab ich Herrn Born informiert.
Weil die Nachstellung nicht möglich ist "sporadisch" und deshalb die Theorie, dass da ein fehlkonfigurierter Server im Round Robin steht.
DMARC ist entweder nicht gesetzt oder enthält keine Prozent-Angabe. Daran liegt es nicht. Und vorsichtig gesagt: Ich würde ja im Proxmox Mail Gateway sehen, wenn DKIM nicht korrekt ist. DMARC beschreibt ja nur, wie hoch die E-Mail das System dann nachher als Spam klassifiziert.
@Christian Krause: DKIM-Fehler der generischen Art wie "DKIM failed" sind schwer bis gar nicht im Nachhinein (also nach dem Empfang) auszuwerten. Die prüfenden Mail-Gateways sind ja häufig Blackboxen, wo man nicht erfährt, WARUM DKIM auf Fehler gegangen ist.
Es gibt ja diverse Fehlermöglichkeiten:
– Public Key kann nicht aus DNS gelesen werden (temporär/immer)
– DKIM-Signatur ist korrupt.
– DKIM-Signatur passt nicht zu den signierten Feldern (Header) – welches der vielen signierten Felder hat sich seit dem Versand geändert?
Alle diese Punkte liegen jedoch in der Hoheit von Strato.
Daher ist es mir im Prinzip egal, was die Ursache ist.
Strato muss das fixen, sperrt sich bisher aber gegen jede Anerkenntnis einer Schuld.
Hatte die Tage auch das Problem, dass die DKIM-Signatur von einem Empfänger-Server über mehrere Wochen mit Fail ausgewertet wurde. Unser Mail-Server läuft on premise. Wir haben dann das Schlüsselpaar neu mit SHA256/2048Bit erstellt, weil das bisherige noch mit SHA1/1024Bit erstellt wurde. Allerdings hatte dies bis dato keine Probleme gemacht. Stellt sich die Frage ob es inzwischen Server gibt welche Signaturen mit veralteten Schlüsselpaaren nicht mehr akzeptieren.
@ChristophH: Noch ein weiterer Punkt auf meiner Liste, warum DKIM=fail eintreten kann. Vielen Dank.
Hallo, bei mir funktioniert die Zustellung von Mails vom Strato webmailer unauffällig. Die Mailfilter schlagen nicht an.
Unser Mailserver hat ebenfalls Mails von Strato abgelehnt. Grund: DMARC rejected.
MXtoolbox sagt aber, das deren DMARC-Einträge sauber sind.
Wir schicken auch über Strato, zumindest beim Stichproben-Test sind keine Probleme aufgefallen:
Message has at least one valid DKIM or DK signature
Message has a valid DKIM or DK signature from author's domain
Message has a valid DKIM or DK signature from envelope-from domain
Very Good reputation (+4)
SPF: HELO matches SPF record
SPF: sender matches SPF record
Kommt natürlich immer drauf an, was der Empfänger so konfiguriert hat – evtl. noch eine Blocklist, auf der einige Strato-Server gelandet sind? Das kommt ja durchaus öfter mal vor, ist aber in meinen Augen eher ein Problem dieser unsinnigen "alles von dieser IP ist böse"-Listen
Nein, in beiden Fällen keine DNSBL, sondern ganz konkret der Hinweis (u.a. in meinem Proxmox Mail Gateway vom Spamassassin): DKIM
Wir haben allgemein seit Tagen mit der Telekom Probleme, was das Peering angeht.
Eventuell ist da irgendwas größeres im Argen.
Ich weiß, Strato Telekom, doch vielleicht gibt es da einen Zusammenhang.
Ich hatte wiederholt ein ähnliches Problem bei IONOS, das ja zu Strato gehört.
Von einem bestimmten Postfach aus wurde SMTP-serverseitig grundsätzlich schon beim Versand "X-Spam-Flag: YES" gesetzt bzw. der Spam-Rating hoch angesetzt, was bei manchen Empfängern gereicht hat, die Mail abzulehnen. Der Ionos-Support war leider, wie immer, völlig unfähig und schaffte es bei wiederholter Nachfrage nicht einmal, auf das Thema passend einzugehen, oder man wurde vertröstet, die "Fachabteilung" würde sich melden, was sie aber bis heute und trotz ebenfals Nachfragen nicht tat.
Tipp: Mal ein Mail an sich selbst schicken und schauen, 1. ob Spam-Flag gesetzt wurde oder X-Rating, und 2. über welchen Server das genau ging. Ggf mal mit anderer Verschlüsselung und/oder Ports versuchen.
Der Strato Support am Telefon hat mir in freundlich erklärt, dass er da nicht im Thema ist, ich solle eine Mail schreiben.
Dann hat er versucht, mir den kostenpflichtigen Domain Guard aufzuschwatzen und dabei erkennbar in schlechtem Deutsch einen Text vorgelesen.
Ich hab ihn gefragt, ob er noch alle Latten am Zaun hat, mir nicht helfen zu können und mir dann noch irgendwas aufschwatzen wollen.
Manche Leute kennen echt keine Grenzen.
Die Mail wurde noch nicht beantwortet.
Nochmal anrufen, es gibt nicht nur einen Support Mitarbeiter…
Für solche Fälle gibt es den/die Postmaster: https://postmaster-contact.ionos.de
Über den regulären Support würde ich das erst gar nicht versuchen.
Ich habe ein Problem mit meinem umgezogenen Mailserver bei Strato.
Der neue vServer hat eine IP-Adresse in einem IONOS Bereich und es gibt eine merkwürdige DNSBL UCEPROTRCTL3 auf der damit mein Mailserver auch ist weil er im IONOS-AS liegt.
Hilfe beim Strato Support ist nur: UCEPROTECT ist eine Abzocker-Firma die will nur Geld.
Ich habe daraufhin beantragt mir eine neue IP-Adresse zuzuteilen, denn mein früherer vServer dort hatte seine aus dem Strato Netz und das hatte eine bessere Reputation.
Mal sehen wann die Rückmeldung kommt.
UCEPROTECT Abzocke?
Kann man gespalten sehen, oft stehen Anbieter dort zurecht. Und es muss dann an Geld weh tun da sonst kein Lerneffekt gibt.
Ich verwende den Dienst in DNSBL zumindest 1+2, den 3er nutzt mehr eher nicht.
Ja, das ist eine Abzockfirma. Die blocken regelmäßig komplette IP Stacks. Da kann man als Endnutzer rein gar nichts dagegen machen. Jeder, der UCEPROTECT als Blacklist benutzt, landet bei uns direkt auf unserer Blacklist. Jeder schäffelt sich halt sein eigenes Grab.
Doch kann man, seriösen Anbieter verwenden der keine Spam-Kunden unterhält.
Zudem löst bei mir UCEPROTECT nicht alleine aus, nur in Kombi mit anderen Listen, zudem wird noch DNSWL verwendet und seriöse Anbieter selbst wenn dort auf Liste stehen, eben nicht zur Ablehnung führt.
Kann aber jeder gestalten wie er mag.
@Daniel schreibt: "Doch kann man, seriösen Anbieter verwenden der keine Spam-Kunden unterhält."
Den Grundsatz unterschreibe ich, allerdings haben sich dann 400 Millionen Exchange-Online-Mailuser falsch entschieden ;-)
Richtig, wer Microsoft Cloud/Mail verwendet sollte gebannt werden und muss alles als kompromittiert betrachten. Ist auch einer dieser unseriösen Spam-Schleuder genau wie GMail. Aber dazu gabs ja erst extra Beitrag mit Google Spam.
Also bei mir landet jeder, der mir eine E-Mail sendet, direkt im Spam-Ordner. Wenn es etwas Wichtiges ist, dann gibt es sicher noch ein Fax oder eine Whatsapp. Und der Staatsschutz kommt sowieso direkt mit dem Rammbock.
@Carsten: "landet bei uns direkt auf unserer Blacklist." Heißt das. dass Ihr an diese Partner (Kunden, Lieferanten …) keine ausgehenden Emails mehr schreibt/schreiben könnt? Was sagt denn die Geschäftsleistung dazu?
Problem leider nicht ganz verstanden: Ich können denen sowieso keine Mails senden, da sie uns über den ganze IP Stack mit blocken. Wer uns mit so einer Konfiguration Anfragen schickt, hat dann auch kein Angebot verdient. Ja, das ist mit der Geschäftsleitung abgesprochen. Meistens sind das auch nur irgendwelche Kleinstbetriebe, welche für uns komplett uninteressant sind.
@Carsten: Jetzt verstanden!
Ich antworte mal so ausführlich, wie es die Problembeschreibung verdient: Nö.
Reine Spekulation: Meine Vermutung wäre, dass die sehr niedrige TTL von 150 für die für DMARC, DKIM und SPF relevanten DNS-Records ab und dazu führt, dass die Records nicht mehr im Cache sind und wenn das Aktualisieren temporär fehlschlägt, kommt es bei der Validierung eben zu Fehlern.
Hier kamen doch qualitativ hochwertige antworten wie z.b. von Michael.
Darüber hinaus haben etliche Leser bestätigt, dass das Problem keine Einbildung ist.
Wozu deine Antwort, wenn du nichts beitragen kannst?
schon im ursprünglichen Kommentar musste ich mir Rückfragen durchlesen, die zeigen, dass der Teilnehmer keinen blassen Schimmer von Email hat, jenseits der Bedienung eines Email clients. Als ob es bei einer fehlerhaften DKIM Signatur darauf ankäme, welchen Email Client ich benutze oder ob anhänge oder urls im Body sind.
Was soll denn mit der TTL nicht stimmen?
Der txt Eintrag ist individuell im Hinblick auf die Domain des Absenders. Wie viele Mails soll ein kleiner KMU den täglich versenden, damit ein providerindividuelle DNS Resolver einen nennenswerten Cache Hit hat? Da muss man die TTL aber schon auf mehrere Stunden stellen, um nennenswert Cache Hits zu bekommen.
Das ist komplett unrealistisch und auch nicht die Aufgabe eines Provider DNS, so etwas mit dem Cache abzufangen.
Der Cache ist für heise.de , google.de und borncity.com, aber nicht für dkim Schlüssel oder dmarc settings.
Außerdem erschwert eine lange TTL den Schlüsselwechsel. Ich wäre als Mailadmin genervt, wenn irgendwelche offenen DNS Resolver meine dkim Schlüssel 12 Stunden im Cache hätten.
Was hat denn der Typ des DNS-Records mit der TTL zu tun? Glauben Sie, Mailserver werden professionell so betrieben, dass für jede einzelne E-Mail DNS-Abfragen an den Nameserver der Domain rausgeht? Und dann wird jedesmal neu DMARC, SPF, DKIM etc. abgefragt? Natürlich landet das im Cache. Die TTL ist real auch nur eine Empfehlung. Wie man bei den großen DNS-Providern leicht prüfen kann, werden Änderungen an DNS-Records in der Regel viel schneller propagiert als man es anhand der TTL erwarten könnte. Umgekehrt gibt es massenweise Software, die sich nicht um die TTL scherrt und im Extremfall bis zum Neustart zwischenspeichert. Die Java Runtime war früher berühmt berüchtigt dafür. Keine Ahnung, ob das heute immer noch so ist.
Für die TTL kann man übrigens auch Werte zwischen 3 Minuten und 12 Stunden (sogar darunter und darüber hinaus) wählen. Für das Rotieren der DKIM-Keys nutzt man mindestens zwei Selektoren, um einen nahtlosen Wechsel der Schlüssel zu ermöglichen. Das hat sogar Microsoft verstanden, viele andere dagegen nicht.
Eine sehr niedrige TTL bei einzelnen Domains stört nicht und ist während Migrationen und Experimenten legitim. Wenn ein Nameserver aber massenhaft Domains mit sehr niedriger TTL bedienen muss, kann es zu deutlich mehr Traffic, Last und Paketverlust kommen gerade im Zusammenspiel mit UDP.
Zum Einstieg empfehle ich diesen Artikel:
https://www.dchost.com/blog/en/dns-ttl-best-practices-for-a-mx-cname-and-txt-records/
Der vermutlich eigentliche Grund für das Problem bei STRATO wurde aber ja unten von Anonym gefunden.
Strato hat einen neuen DKIM-Schlüssel in Benutzung. Bei mxtoolbox kann man sich diesen mit dem Selector "strato-dkim-0003" anzeigen lassen. Anders als bisher wird ein Ed25519-Schlüssel (elliptische Kurve) zusätzlich zu RSA-2048 verwendet. Nach RFC 8463 ist das auch korrekt und eine performante Alternative zu RSA. Aus eigener Erfahrung (eigener Server) aber zeigt sich, dass viele andere Hoster (Microsoft, Google, …) Ed25519 Schlüssel nicht prüfen und DKIM (und deshalb auch DMARC) somit fehlschlägt. Das Problem liegt nicht per se bei Strato, sondern bei den Hostern, die Ed25519 nicht prüfen und als Fehler werten.
Tja, und das hätte man wunderbar in E-Mail-Headern oder DMARC-Reports erkennen können. Bei Stichproben in meinen Logs taucht nur strato-dkim-0002 auf und damit gibt es dementsprechend keine Probleme.
Ich breche die Diskussion im Subthread an dieser Stelle ab (da es nur noch auf gegenseitige Beharkungen hinauf läuft und ich daher eine Mail und zig weitere im Papierkorb gefunden habe) – das bringt erkennbar nichts mehr. Der OP, der im Übrigen laut meiner Beobachtung sein Bestes (auch mit Logs) gibt – wenn Du irgendwo ein Kundensystem hast und sporadisch Fehler auftreten, wird es schwierig, ist mit einem 2. Leser in direktem Kontakt.
Vielleicht ergibt sich für den OP eine Lösung. Der initiale Post dient vordergründig als Honeypot "sind noch mehr Nutzer betroffen, gibt eine es eine besondere Erkenntnis".
Wieso kommt das als Antwort auf meinen Beitrag? Das fasse ich als Vorwurf an mich auf.
Der Beitrag des OP vom 22. Januar 2026 um 19:19 Uhr ist objektiv beleidigend und zwar nicht nur in meine Richtung sondern offenbar an jeden, der es wagt Rückfragen zu stellen. Das ist unverschämt und nicht zielführend. Im übrigen hat er selbst dokumentiert, dass er auch so mit dem STRATO-Support umgeht. Das ist keine sinnvolle Methode mangelnde Analysefähigkeiten zu kompensieren.
>> Für mich sieht das so aus, als ob einige DNS Server bei Strato nicht/nicht rechtzeitig/falsch Antworten und daher DKIM oder SPF nicht geprüft werden kann.
Ich beobachte schon seit einiger Zeit, daß die Domainserver von Strato (insbesondere Docks/Shades) sehr unzuverlässig arbeite, manchmal braucht man drei Anfragen um eine verwertbare Antwort zu bekommen. Neben hoher Last könnten natürlich auch laufende DOS-Angriffe ein Grund dafür sein.