Kurze Information und Frage an die Leserschaft, ob noch jemand in das Problem gelaufen ist. Seit Anfang September 2025 scheint es bei IONOS-Probleme mit der Unterstützung von IDN-Domains zu geben. Dann ist plötzlich kein Mailversand mehr möglich.
Was sind IDN-Domains?
Das Kürzel IDN steht für "internationalized domain name" (also internationalisierte Domainnamen). Umgangssprachlich sind dies Domain-Namen mit Umlauten oder Sonderzeichen im Bezeichner. Im Domainnamen sind Umlaute, diakritische Zeichen oder Buchstaben aus anderen Alphabeten als dem lateinischen Alphabet enthalten.
Wenn ich eine Domain mit einem Namen beantragen würde, käme ich in die "Teufelsküche IDN", da solche Konstrukte immer wieder für Ärger gut sind. Denn solche Zeichen waren ursprünglich im Domain Name System nicht vorgesehen. Sie wurden nachträglich durch den Internetstandard Internationalizing Domain Names in Applications (IDNA) ermöglicht.
Leserbericht über Probleme bei IONOS
Blog-Leser Sebastian hatte mich zum 6. September 2025 per Mail kontaktiert (danke dafür), und über das im Beitrag Nextcloud: Datenschutzkritischer Bug in Android-App? angesprochene Problem informiert. In dieser Mail erwähnte der auch, dass einer seiner Kunden für seine Zahnarztpraxis seit Gründung 2021 eine Domain mit Umlaut verwendet. Diese Domain und angeschlossene Mailkonten liegen bei IONOS.
Laut Leser ist es seit dem 5. September 2025 nicht mehr möglich, E-Mails an diese Domain zu senden. Externe Absender erhalten vom IONOS-Mailserver die Antwort
"Remote-MTA: dns; mx00.ionos.de / Diagnostic-Code: smtp; 554-Transaction failed 554-Reject due to policy restrictions."
Versucht man, IONOS-intern zu mailen, lautet die Fehlermeldung
"(550 - 550-Requested action not taken: mailbox unavailable 550 invalid DNS MX or A/AAAA resource record"
Beim ersten Kontakt mit dem Support von IONOS, am 5. September 2025, gab es noch die Behauptung, dass die obigen Fehler "an der allgemeinen, größeren E-Mail-Störung" liege. Laut Leser gab es auf der IONOS-Status-Webseite tatsächlich eine Meldung über eine Störung. Später war diese Störung aber durch IONOS behoben und der Support kann sich natürlich nicht mehr auf eine angebliche Störung zurückziehen.
Bei einer weiteren telefonischen Kontaktaufnahme mit dem Support erhielt der Leser von zwei (nach seiner Wahrnehmung technisch inkompetenten) Support-Mitarbeitern, die Antwort:
Zitat: "Wir möchten doch bitte alles auf eine Domain ohne Umlaut umstellen, diesen Fehler könne man nicht beheben. Selbst wenn man ihn beheben könnte, er würde bei Updates immer wieder kommen."
Um welche Art "Updates" es genau gehen soll, konnten die Support-Mitarbeiter dem Leser nicht beantworten. Da sich der zweite Mitarbeiter der Hotline mehrfach aus dem Telefonat zurückzog, um sich vermutlich mit Kollegen oder Teamleitung zu besprechen, scheint die ganze Sache aber keine Fehlinterpretation einzelner Mitarbeiter zu sein, so der Schluss des Lesers.
Der Leser kam zum Schluss: "Ich muss also konstatieren, dass IONOS die Unterstützung für IDN-Domains zumindest für E-Mail eingestellt hat, ohne seine Kunden darüber zu informieren. Hier nimmt man offenbar bewusst in Kauf, dass Kunden ins offene Messer laufen und per Mail nicht mehr erreichbar sind."
Hilfeseiten wissen nichts
Die offiziellen Hilfe-Seiten des Providers wissen übrigens noch nichts von der neuen Situation.
Das Thema scheint den Support bei IONOS zu überfordern. Laut Leser habe der erste Hotline-Mitarbeiter das Gespräch beendet, als der Leser fragte, warum IONOS einen über 20 Jahre alten Standard urplötzlich nicht mehr unterstützt.
Wie schaut es bei Euch aus?
An dieser Stelle interessiert mich, ob jemand aus der Leserschaft ähnliche Beobachtungen gemacht hat, oder vielleicht etwas näheres weiß? Der Leser merkte zu obigem Sachverhalt an: Sollte sich die ganze Sache bestätigen, kann man IONOS aus meiner Sicht keinesfalls mehr als verlässlichen Provider betrachten, schon gar nicht für geschäftliche Zwecke.
Der Leser hat seinem Kunden jedenfalls die Migration zu einem anderen Anbieter empfohlen, hegt aber Zweifel, dass dieser oben skizzierte Sachverhalt bei IONOS wirklich so beabsichtigt ist. Ich schaue mal, ob es noch weitere Rückmeldungen bekomme und frage ggf. bei der IONOS-Presseabteilung nach.
MVP: 2013 – 2016
ionos kann man auch aus anderem gründen nicht als verlässlichen Provider betrachten.
bei Schwester strato hatte ich Probleme, dass Ordner aus einem pst import in outlook partout nicht via IMAP synchronisiert wurden. es Hälfte nur Postfach in strato löschen und neu anlegen und neu importieren. support nicht vorhanden. keine Logs, nichts.
die abzocke mit dem php extended support sprechen ohnehin für sich.
Das ist keine Abzocke, denn irgendwann läuft für eine bestimmte php-Version der Support schlicht aus, d.h. es gibt keinerlei Updates mehr.
Strato bastelt dann für nicht mehr offiziell supportete php-Versionen eigene Sicherheitsupdates. Und den Aufwand lassen die sich natürlich bezahlen.
Jede php-Version ab 8.1 hat eine Laufzeit von 4 Jahren (bis 8.0 waren es nur 2 Jahre):
Ab Veröffentlichung gibt es 2 Jahre Feature- und Sicherheitsupdates, danach 2 Jahre lang nur noch Sicherheitsupdates.
Das Supportende einzelner php-Versionen kann man auf der offiziellen php Homepage nachlesen:
https://www.php.net/supported-versions.php
php 7.4 = bis 31.12.2022 (also schon EOL)
php 8.0 = bis 31.12.2023 (also schon EOL)
php 8.1 = bis 31.12.2025 (nur noch Sicherheitsupdates)
php 8.2 = bis 31.12.2026 (nur noch Sicherheitsupdates)
php 8.3 = bis 31.12.2027
php 8.4 = bis 31.12.2028
Und wer eine php-Version nutzt, die nicht mehr supportet wird, handelt schlicht grob fahrlässig!
Was das Problem mit IDN-Domains angeht:
Ich vermeide im Internet immer Umlaute und Sonderzeichen, denn das bereitet die wenigsten Probleme.
Es betraf kunden, die gar keine Webseite hatten.
Die haben nur mail genutzt und halt den Regler nicht regelmäßig hochgedreht.
Man hätte auch die PHP Version automatisch hoch stellen können, wer die alte Version benötigt, muss einen kostenpflichtigen Vertrag abschließen und es extra buchen.
Oftmals ist es auch so, dass der Webmaster nur Zugriff zu WordPress und keine logindaten für ionos hat. Automatisch hoch drehen wäre da nur förderlich. Zumindest hätte man eine button einfuhren können "immer empfohlene Version benutzen" und da wäre dann die letzte stable drin.
Hochdrehen der Version wiederum hat lange Zeit den extended support Vertrag nicht beendet.
Alles selbstlos für den Kunden. Kein nutzen für ionos. In welcher Welt lebst du?
Verstehe nicht, wie man die Praktik gutheißen kann.
Wer eine php-Version nutzt, die kürzlich aus dem Support gefallen ist, bekommt eine Email von Strato, das man doch bitte die php-Version hochsetzen soll und wenn man das bis Stichtag X nicht macht, Extra-Kosten berechnet werden.
Wer auf die Email nicht reagiert, ist selbst Schuld!
Im Kundenportal kann man die php-Version hochsetzen oder man macht es in der php.ini auf seinem Webspace.
Wenn der Provider da eine Eigenleistung erbringt, ist es klar, dass er dafür was verlangen kann – aber nur von denen, die diese Leistung beanspruchen. Meine eigene Erfahrung mit einer GoDaddy-Tochter war jedoch: Den kostenpflichtigen PHP-Legacy-Support bekommt man dort ungefragt aufgedrückt, auch wenn man überhaupt keine PHP-Version nutzt! Da hatte man sich von früheren Update-Ankündigungen eben nicht betroffen gefühlt, außerdem hieß es immer, die Unterstützung für veraltete Versionen würde eingestellt, und plötzlich kriegte man mitgeteilt, dass man ab nächstem Monat regelmäßig für ein Legacy-Paket zahlen muss, das man gar nicht verwendet. Ok, ließ sich dann irgendwo auf der Konfigurationsseiten deaktivieren, kostete aber einige Sucherei.
Ich empfand das auch als klaren Abzock-Versuch. Das ist so, als würde MS Linux-Nutzern Win10-ESU-Kosten in Rechnung stellen, allein aufgrund der Tatsache, dass sie kein Windows 11 verwenden.
"Und wer eine php-Version nutzt, die nicht mehr supportet wird, handelt schlicht grob fahrlässig!"
Die offiziellen PHP EOL-Angaben sind nebensächlich, solange man ein Betriebssystem auf Red Hat-Basis verwendet. PHP erhält dort über Backports bis zum EOL des Betriebssystems Sicherheitsupdates.
AlmaLinux 8, PHP 7.2, bis 31.03.2029
AlmaLinux 9, PHP 8.0, bis 31.05.2032
AlmaLinux 10, PHP 8.3, bis 31.05.2035
>> die abzocke mit dem php extended support sprechen ohnehin für sich.
Aha – alte PHP Version die EOL ist benutzen, aber dann die individuelle und mit Kosten behaftete Absicherung nicht haben wollen? Warum nicht einfach auf eine aktuelle PHP Version umschalten?
Aber zum Thema: IONOS scheint heftig an seiner Technik zu arbeiten. Sende-/Empfangsprobleme sind stellenweiße noch vorhanden (Hosted Exchange). Ebenfalls Probleme mit Public Foldern – sehr langsam!. Support bei PF gibt es aber tatsächlich unterirdisch wenig. Ggf. ein weiteres normales Postfach als PF Speicher missbrauchen?
Um den 04./05. September herum wurden plötzlich haufenweise reguläre Mails als Junk markiert und entsprechend einsortiert. Am 08./09. September war das dann wieder besser.
Was auch immer IONOS tut, es ist ziemlich umfassend und ob alles so gewollt ist, wer weiß.
siehe Kommentar oben.
die gewählte Lösung von ionos ist einmalig in der Branche und maximal ungünstig für den Kunden.
Zumindest ich versuche alle Kunden seit dem von dort weg zu migrieren.
Genau – siehe oben – man wird nun weiß Gott rechtzeitig vorgewarnt. Wer dann nicht in sein Kundencenter schaut und nicht handelt…
lies meinen Beitrag.
es trifft Leute, die haben nur mail benutzt.
dein moralischer Kompass scheint mal irgendwann aus dem Ruder gelaufen zu sein.
ich persönlich meide die Zusammenarbeit mit solchen unternehmen.
ich bin mir ziemlich sicher, dass auch nach dem Gesetz kein wirksamer Vertrag zustande gekommen ist.
>>> dein moralischer Kompass scheint mal irgendwann aus dem Ruder gelaufen zu sein.
Na klar – keine Argumente auf der Hand, also persönlich werden! So von wegen moralischer Kompass ;)
>>> ich bin mir ziemlich sicher, dass auch nach dem Gesetz kein wirksamer Vertrag zustande gekommen ist.
Dann kläre das doch einfach. Anwälte, Verbraucherschutz usw. usf.
Betr. "Das Thema scheint den Support bei IONOS zu überfordern. Laut Leser habe der erste Hotline-Mitarbeiter das Gespräch beendet, als der Leser fragte, warum IONOS einen über 20 Jahre alten Standard urplötzlich nicht mehr unterstützt.":
Und solche Buden bauen die Bundes-Cloud (1); dann doch lieber was US-amerikanisches.
_
(1) https://vergabeblog.de/2024-04-09/bundes-cloud-itzbund-erteilt-zuschlag-an-ionos/
Betr. "Die offiziellen Hilfe-Seiten des Providers wissen übrigens noch nichts von der neuen Situation.":
Die offiziellen Seiten – dazu gehört auch (1) – treffen überhaupt keine Aussagen zur IDNA2003- bzw. IDNA2008-Kompatibilität der erbrachten eMail-Dienste – weder abschlägig noch zusichernd.
An den Leser: Nur wenn der Vertrag die Zustellung an alle gültigen E-Mail-Adressen vorsieht, könnte eine pauschale Sperre von IDN-Adressen eine privatrechtliche Leistungspflichtverletzung darstellen.
_
(1) https://www.ionos.de/digitalguide/domains/domainverwaltung/was-ist-ein-internationalisierter-domain-name-idn/
Leider fehlt dem Artikel alles, was spannend wäre um zu helfen.
Ohne Kenntnis der Domain, bzw. DNS ist es unmöglich sinnvoll zu sagen worum es geht.
Für IDN Domains in Puny-Code brauchen auf SMTP Seite keine Unterstützung und sind 100% Abwärtskompatibel.
Sicher dass es hier um ein Umlaut Problem geht? Beide Fehlermeldungen sind dies bzgl. nichtssagend.
Ich würde hier eher auf ein DNS Problem tippen.
Ich bitte um Verständnis, dass ich die konkrete Domain nicht nennen möchte. Aber um mehr Hintergrund zu liefern: Der Kunde hat bei Ionos zwei ähnliche Domains:
1. zahnaerzte-xyz.de
2. zahnärzte-xyz.de
Ich habe bei der Einrichtung der Mailkonten selbst darauf hingewiesen, dass die Umlaut-Domain höchstens als Weiterleitung verwendet werden sollte. Es wurde aber anders gewünscht und dementprechend andersherum aufgebaut. Dies funktionierte dann über drei Jahre lang auch problemlos.
Der jetzige Status ist schlicht so, dass Mails an "zahnaerzte-xyz.de" zugestellt werden, Mails an "zahnärzte-xyz.de" aber auf den beschriebenen Fehler laufen. Ich habe dies von verschiedenen Mailkonten bei unterschiedlichen Providern getestet.
Das Senden von dem Mailkonto unter "zahnärzte-xyz.de" funktioniert nach wie vor, aber natürlich wiederum nicht, wenn man sich selbst (also an *@zahnärzte-xyz.de) schreibt. Hier gibt es dann auch im Webmailer von Ionos eine Fehlermeldung, sodass DNS-Probleme höchsten Ionos-intern sein können.
Irgendwie kann ich mir beim besten Willen nicht vorstellen, dass man einfach so, sämtliche IDN Domains ohne weitere Informationen einfach abschaltet.
Ist denn ein Versand von Emails möglich?
Die beiden Fehlermeldungen bedeuten (Zitat von IONOS):
1.
" 554 Reject due to policy restrictions
Problem:
The email was rejected as it violates IONOS policy. The sending server is mostly sending spam messages.
Solution:
Contact us IONOS to have the facts of the case examined."
—
2.
" 550 Invalid DNS MX or A/AAAA resource record
Problem:
The sender domain of the email server you are using is not configured in the domain name service (DNS) in accordance with RFC.
Solution:
Check the following DNS problems and correct them if necessary:
Neither an A nor an MX record is configured in the DNS for the sender domain.
The MX record points to a domain name that cannot be resolved.
The MX record refers directly to an IP address.
The MX server does not have a valid A record but only a CNAME record
For more information about your DNS configuration, for example, contact http://www.intodns.com."
—
ionos. com/help/index.php?id=2425&ip=213.183.169.170&c=hd
Zu 1:
Hat der Absender echten Spam versendet oder ist es nur ein Spam-Verdacht aufgrund der Sonderzeichen?
Zu 2:
Der DNS kennt die Adresse nicht.
Vielleicht wurde IDN nicht in ACE umgewandelt und der DNS erhielt dann Umlaute, die er nicht versteht?
Bei beiden Fehlermeldungen soll man den IONOS-Support kontaktieren.
Das ist zwar bereits geschehen, aber dann eskalioert man das eben nochmal und nochmal bis es eine passende Antwort von einem echten Techniker mit Hard-Skills statt eines Call-Center-Supporters mit Soft-Skills gibt.
Weitere Möglichkeit:
IONOS hat als Schutz vor "Unicode Domain Phishing Attack" generell Unicode-Sonderzeichen verboten und konvertiert IDN deswegen nicht mehr.
Das sollte dann aber auch im Klartext geschrieben werden.
Sonst könnte man nämlich echt aussehende Domains basteln, etwa indem man das deutsche "o" durch das kyrillische "o" ersetzt. Dann sieht man zwar zB "google.com" als Adresse, aber tatsächlich wird ganz woandershin geleitet.
3.
Alle Browser konvertieren automatisch IDN nach ACE, zeigen aber im Standard diese Konvertierung nicht an.
Beim Firefox kann man im about:config-Dialog die Variable
network.IDN_show_punycode
auf true setzen, damit er die Konvertierung anzeigt.
4.
Die Benutzung von Umlauten im Domainnamen ist aber tatsächlich sehr ungeschickt.
Wie soll dann ein Ausländer diese Seite bzw diese email-Adresse eintippen, wenn er nur arabische oder kyrillische Schriftzeichen auf seinem Smartphone hat und die ACE nicht kennt?
Auch die Telekom empfiehlt, keine Umlaute zu verwenden:
homepagecenter. telekom. de/hilfe/domains/domains-verwalten/idn-domain-umlautdomain
Danke für den Kommentar, ich fange mal hinten an:
4.: Ist mir bekannt und ich hatte den Kunden seinerzeit auch gewarnt. Es wurde trotzdem so gewollt und hat dann ja auch über drei Jahre problemlos funktioniert.
Mich irritiert jetzt schlicht, dass Ionos offenbar den Support für IDN-Domains auf ihren Mailservern streicht, darüber aber nicht einmal im Ansatz informiert.
3.: Um Browser geht es nicht, das Problem äußert sich dadurch, dass man keine Mails mehr an Konten auf der IDN-Domain senden kann.
2.: Wenn es ein DNS-Problem ist, existiert dies aber schon bei Ionos selbst. Ich kann schon im Ionos-Webmail keine E-Mail an das betroffene Konto mehr senden. Der Bounce, den ich über SMTP erhalte, deutet für mich auch eindeutig nicht auf DNS-Probleme hin.
Das mit der Eskalation beim Support ist sicherlich ein brauchbarer Ansatz. Allerdings waren meine drei Telefonate mit dem Support so zeitraubend und ernüchternd, dass ich wenig Lust darauf verspüre. Zumals es gegenüber meinem Kunden natürlich auch eine Grenze dessen gibt, was ich ihm guten Gewissens in Rechnung stellen kann. Die bisherigen erweiterten Bemühungen habe ich schon finanziell auf die eigene Kappe genommen, noch mehr verschenkte Arbeit mag ich da nicht reinstecken.
1.: Aus Sicht der "problematischen" Domain geht es ausschließlich um den Empfang. Senden funktioniert. Und meine Testmails sind ganz sicher nicht alle als Spam erkannt worden, ich sende von Domains, die per SPF, DMARC und DKIM abgesichert sind und bei drei verschiedenen Providern liegen.
Aus meiner Sicht sagt x "554 Reject due to policy restrictions" auch ziemlich klar, dass es hier nicht um eine Spam-Problematik geht.
Mein Wissen in diesem Bereich ist aber zugegebener Maßen auch begrenzt.
Auf Auskünfte des IONOS Supports würde ich hier gar nix geben. Ich habe schon mehrfach Informationen und Hilfe vom Ionos-Support benötigt. Aus meiner Erfahrung kann ich guten Gewissens sagen, dass die Support-Mitarbeiter und deren oft zu Rate gezogenen Vorgesetzten meist nicht einmal an mein über einige Jahre beim nebenbei Webseite Frickeln gesammelten Halbwissen rankommen. Es war bislang immer so, dass die mir nicht weiter helfen konnten. Teils fehlt denen auch die ordentliche Fachkenntnis über die eigenen Produkte. Unter anderem weiß keiner von denen, dass ein Transfer einer bestehenden WordPress-Installation vom Normal-Webspace auf deren dedizierten WordPress-Webspace schlichtweg unmöglich ist (…zumindest ohne zusätzliche Kosten in irgendwelche Backup-Plugins zu investieren, das dem neuen Webspace beigefügte Plugin tuts jedenfalls so nicht und die Limits kostenloser Plugins reichen nie!).