Kurze Frage an die Leserschaft, die Microsoft 365 verwenden und dort Mails austauschen. Ist in den letzten Tagen aufgefallen, dass Mails automatisch gelöscht wurden, wenn bestimmte Zeichen im Absendernamen vorkommen? Ergänzung: Scheint mit iOS und dem Apple iPhone in Verbindung mit Outlook aufzutreten.
Blog-Leser Holger S. hat mich am 29. Januar 2026 per E-Mail kontaktiert, weil ihm ein merkwürdiges Verhalten bei Microsoft 365 aufgefallen ist. Er schrieb mir unter dem Betreff "Microsoft 365 löscht anscheinend seit Tagen E-Mails, bei denen als Absendername in Outlook folgende Zeichen vorkommen: ( & ä" folgendes:
Heute haben wir einen sehr 'lustigen' Fehler gefunden: Microsoft 365 löscht anscheinend seit einigen Tagen E-Mails, bei denen im Absendernamen folgende Zeichen vorkommen: ( & ä
Laut Leser ist es dabei egal, ob andere Zeichen dazwischen stehen (z.B.: Absender (Flugzeug & Fähre) etc.). Der Sender erhält keine Unzustellbarkeitsbenachrichtigung, schrieb der Leser.
Anschließend meinte er: "Vielleicht können Sie den Fehler nachvollziehen und finden eine Lösung, bzw. Ihr Blog informiert Leute, die evtl. betroffen sind." Ich selbst habe kein Microsoft 365 und werde mir das auch nicht zulegen. Aber in der Leserschaft gibt es sicherlich genügend Leute, die Zugriff auf Microsoft 365 haben. Ist jemand etwas bezüglich der obigen Informationen in den letzten Tagen aufgefallen?
Ergänzung: Inzwischen kristallisiert sich ja heraus, dass das Problem auf das iPhone von Apple und Microsoft Outlook beschränkt ist, denn mit Thunderbird klappt beim Leser. Dieser hat mir noch obigen Screenshot aus iOS zukommen lassen.
Der Fall aus iOS und Apple-Mail
Mich erinnert das Ganze etwas an das in meinem Beitrag Outlook for iOS stürzt ab; Outlook-Umlauteproblem in Apple Mail von Ende Januar 2026 angerissene Problem mit Apple Mail. Blog-Leser Martin B. hatte mich bereits Ende November 2025 wegen dieses Themas per E-Mail kontaktiert und schrieb unter dem Betreff "Apples Mail App versagt bei Outlook.com-Adressen mit Umlauten im Namen", dass es seit Jahren einen unschönen Bug gebe.
Wenn Nutzer ein neu erstelltes Outlook-Konto mit Umlauten im Anzeigenamen zur iOS-Mail-App auf einem iPhone hinzufügen, werden ausgehende E-Mails mit dem Namen "Von: [Name mit Umlaut geändert]@outlook.de" versendet. Der Umlaut im Namen wird durch ein Fragezeichen ersetzt. Das Thema ist im Microsoft Q&A-Thread Outlook mailbox with an umlaut in its name does not show up correctly in iOS mail (umlaut turns into ?) ausführlicher beschrieben. Aber das scheint ein Thema zu sein, was sich ausschließlich auf Apple und iOS bezieht.
Ähnliche Artikel:
Outlook 365 Classic-Bug, der Zugriff auf verschlüsselte Mails verhindert, behoben
Outlook Classic kann keine verschlüsselten E-Mails öffnen
Outlook for iOS stürzt ab; Outlook-Umlauteproblem in Apple Mail
Exchange Online: Optimierte Moderationsgenehmigungen in allen Outlook-Clients
Outlook OST-Dateien in PST-Dateien konvertieren
Windows 11 24H2/25H2: Outlook Classic POP3-Abrufe hängen nach Update KB5074109
Windows: Out-of-Band-Updates sollen Outlook-Hänger beseitigen (24.1.2026)
Outlook Classic: Problem mit Anhängen und Verschlüsselung?
Outlook New nach Update bei mehreren Postfächern unbrauchbar?
Outlook 2024 Termineinladungen endet mit "Unbekannter Fehler der Nachrichtenschnittstelle bei Termineinladungen"
Outlook erkennt keine Umlaute – Problem bei Microsoft bekannt
MVP: 2013 – 2016
Moin,
Nein das funktioniert wunderbar, aber wenn ich mir den Screenshot so anschaue scheint der MUA schon etwas angestaubt zu sein, da drängt sich mir eher ein Zeichsatzproblem auf.
vg
Guten Morgen Max,
die Nachricht muss von außerhalb Microsoft 365 gesendet werden.
Der Fehler (Nachricht wird ohne NDR gelöscht) tritt nachvollziehbar mit Outlook (egal welche Version, im Screenshot 2003) oder iOS auf.
Hallo Holger,
ich habe es via Thunderbird & Postfix an 365 Tenant gesendet und daruf geantwort (in meinem Test hies der Anzeige Absender: Finden & Ändern) das wurd korrekt hin/her gesandt. Kann es sein das ggf. eigene Transportregeln im Tenant bzw. die Default Sicherheits/Spamfeatures dazwischen gehen? Wenn ein NDR kommt kann man sich doch im admin Panel einen Report ziehen wo der Grund für den NDR drin steht, sprich welche Regel ihn ausgelöst hat.
vg
Hallo Max,
in der Tat: Mit Thunderbird klappt es mit den Zeichen im Absendernamen.
Bei Verwendung von iOS bzw. Outlook werden die Nachrichten nach wie vor ohne NDR gelöscht.
Hmm dann kann es doch an der Kodiuerung liegen, checke mal im Outlook
Datei > Optionen > Erweitert > Internationale Optionen
die Kodierung für ausgehende Nachrichten. Die Menuführung kann je nach Outlook Version etwas abweichen, hier das aktuellste Outlook Classic.
vg
>>> Nachricht wird ohne NDR gelöscht
Hast Du Zugang zur Exchange-Konsole des Tenants?
Dort sollte im Log sichtbar sei, wenn /irgendeine/ Mail eingeht. Möglicherweise wird ja durch irgendwelche Kodierungsprobleme der Absender nicht erkannt und die NDR "irgendwo" hin geschickt.
Die Kodierung vom Umlauten im Headerzeilen (From, To und Subject) führt zwar zu Zeichenmonstern (Subject: =?utf-8?…) funktioniert aber i.d.R ohne Probleme (hier laufen Thunderbird, Apple Mail und Outlook).
Da sowohl mein Name als auch der der Firma einen Umlaut enthalten (die ich im geschäftlichen Verkehr auch konsequent verwende) achte ich darauf.
Möglicherweise setzt der Leser eine Firewall bzw. Virenscanner mit zusätzlichem Regelwerk ein, die solche Nachrichten ausfiltert oder es gibt Grenzfälle, in denen ein kodierter Betreff die maximale Zeichenlänge überschreitet. Jedenfalls erhalte ich reichlich Nachrichten von unseren chinesischen Kollegen (da kann ich allerdings nicht auf Vollständigkeit prüfen, es ist aber noch keine wichtige "weggekommen") bei denen ebenfalls Sonderzeichen im Betreff und Absendernamen enthalten sind. Letztere (die Absender) lassen sich auch so mit chinesischen Textzeichen im Adressbuch speichern.
Guten Morgen Fritz,
der Betroffene, mit den genannten Zeichen im Absendernamen, hat mich um Hilfe gebeten, weil er seit Tagen an verschiedene Empfänger keine E-Mail mehr zustellen kann. Wir haben herausgefunden, dass es sich bei den nicht erreichbaren Empfängern durch die Bank um Microsoft 365 (office.com) Konten handelt.
Tests haben ergeben, dass Microsoft E-Mail ohne NDR löscht, wenn sie von einem Absender (Outlook oder iPhone) stammen, in dessen Absendernamen die drei Zeichen ( & ä (Klammer, Und, A-Umlaut) vorkommen.
Hallo Fritz,
wenn das wirklich outlook 2003 ist dann sind wir in XP Zeiten, da war UTF8 noch futuristisch, da gabs Windows-1252 oder CP850.
Ja diese Kodierungskonstrukte kenne ich auch. Da ich viel DB Migrationen mache sind Kodierungsprobleme an der Tagesordnung, man glaubt nicht welche Seiteneffekte das haben kann, da kommen manchmal die wildesten Fehlermeldungen.
Naja war nur eine Idee zur Fehlersuche.
vg
Hallo Max,
wahrscheinlich war der Screenshot ungünstig gewählt. Das Problem tritt nachvollziehbar auch in Outlook 2021 und iOS auf. Neuere Versionen von Outlook habe ich nicht geprüft.
In Headerfeldern erlaubt der SMTP RFC bis heute nur 7 bit.
Zeichen mit 8 bit wie Umlaute müssen entsprechend umcodiert werden.
Meine Vermutung:
Eine entsprechend eingestellte DKIM Anweisung im DNS der Absendedomain alles stillschweigend wegzuwerfen, was nicht vom Absender signiert ist und Absender und Empfänger SMTP Server berechnen den Hash über die nicht standardkonformen 8-bit Header unterschiedlich: Der eine mit und der andere ohne die 8. bit.
Muss man dann im DNS des Absenders so umstellen, dass die Absendedomain zumindest eine Info erhält. Geht aber nicht an den Absender selbst, sondern die im DNS DKIM angegebene Spam-Kontaktadresse. Dort kommt dann zumindest ein Hinweis darauf an, aber ohne die vollständige Mail selbst. Oft aber erst mit Verzögerung. Z. B. einmal pro Monat aggregiert um Spammer nicht bei der Arbeit zu unterstützen.
Wer Umlaute außer im Content selbst auch irgendwo im Header verwendet sollte nur RFC konforme Mailprogramme verwenden, die das sicher in 7 bit umkodieren:
Exchange macht bei mir daraus:
Subject: =?iso-8859-1?Q?WG:_Test_=F6=E4=FC?=
Betterbird dagegen:
Subject: =?UTF-8?B?VGVzdCDDtsOkw7w=?=
Das ist aber unerheblich, da beide nur 7-bit Zeichen verwenden. Welche ist SMTP völlig egal.
Viele E-Mailclients vermeiden zur Sicherheit auch nach wie vor 8-bit im Content selbst. Obwohl das zulässig wäre. Sicher ist sicher.
Habe als "Test (Flugzeug & Fähre)" eine Mail von Outlook Classic 365 über T-Online an meinen Microsoft 365-Tenant gesandt, diese ist angekommen. Allerdings nutzen wir nicht den Microsoft-Spam-Filter, sondern einen Virencheck eines Drittanbieters.
Ohne hier lange herum zu probieren.. würde ich mir das E-Mail das erzeugt wird Mal genauer ansehen, also ob die Kodierung korrekt ist.
Am einfachsten das Mail an einen Server schicken wo ein Thunderbird das Mail via IMAP/POP3 abholen kann, und dort den Nachrichten Quelltext ansehen.
am einfachsten wäre eine kleine VM mit linux und postfix/exim und outlook dorthin senden lassen, dann steckt niemand dazwischen und im linux mittels vi das mail spool anschauen da hast dann 100% pur was outlook draus gemacht hat.
Am Besten die gleiche Mail an (oder CC) zwei Empfänger schicken, von denen einer bekanntermaßen funktioniert (GMX, T-Online o.ä.). Dann hat man den exakten Quelltext der ausgehenden Mail und bis zu einem bestimmten Punkt auch das gleiche Routing.
Aus dem E-Mail Header habe ich folgende Info (die xx wurden ersetzt):
From: =?iso-8859-1?Q?xx_=28xx_&_Partner_Rechtsanw=E4lte=29?=
Microsoft 365 (office.com) löscht derartige Nachrichten ohne Unzustellbarkeitsbenachrichtigung (NDR). Der Betroffene hat die Klammer(n) aus dem Namen entfernt, damit E-Mails wieder bei Microsoft 365 zugestellt werden.
Vielleicht hilft Euer Beitrag ja mit, dass Betroffene (E-Mails werden ohne NDR gelöscht) schnell eine Lösung finden.
Danke
Holger
Sag ich doch, Kodierungsproblem,
iso-8859-1 oder besser Westeuropäisch Latin-1
sollte huetzutage nirgends mehr benutzt werden, das ist ein Garant für Probleme, strikt UTF-8, dann klappts auch mit dem E-Mail.
vg
Bin zwar nicht von diesem konkreten Problem betroffen, aber wegen ähnlicher Erfahrungen habe ich die Übermittlungsbestätigung als default eingestellt.
Leider nützt das auch nicht sehr viel, weil viele Empfänger-Server/-Konten keine Antwort senden.
E-Mail ist tendenziell ein Lottospiel :-(
Bei einem Kunden haben wir heute festgestellt, sendet er Mails mit Umlauten raus, waren in den gesendete Elementen bei manchen Mails nur ein ? anstelle des Umlauts.
Geprüft, was die Empfänger gemeinsam haben, alle hatten einen Tennant auf Amerikanischen Servern. Sendeten wir Test Mails zu Strato, DomainFactory, Outlook.de oder M365 Deutschland Tennants gab es keine Probleme.
Im Mail Client Outlook war Westeuropäisch (ISO) eingestellt, wir stellen auch auf UTF-8 um und beobachten.
Vielleicht hat das auch jemand beoabchtet.
Ich habe noch einen Artikel auf Lager – Ihr seid nicht die Einzigen. Muss mal schauen, ob ich es morgen in den Blog einstelle.
Outlook erkennt keine Umlaute – Problem bei Microsoft bekannt
Habe eben ein Ticket bei M365 aufgemacht und direkt einen Rückruf erhalten, das Problem sei bekannt, ist Global und seit ca. einer Woche intern bekannt, es wird dran gearbeitet, auf Kundenseitig sei nichts zu tun außer zu warten.
Sehr geehrter Herr Florian,
vielen Dank für Ihre Rückmeldung.
Wir möchten Sie darüber informieren, dass wir seit etwa einer Woche – inzwischen über acht Tage – vermehrt identische Meldungen von mehreren Kunden erhalten haben, die ebenfalls Probleme mit der Darstellung deutscher Umlaute (z. B. Ä, Ö, Ü) in E Mails an bestimmte M365 Empfänger beobachten.
Aufgrund der Anzahl der eingegangenen Fälle können wir bestätigen, dass aktuell ein Service Incident auf unserer Seite vorliegt, der speziell die Verarbeitung deutscher Sprachzeichen betrifft. Unser Eskalationsteam arbeitet bereits aktiv an der Analyse und Behebung der Ursache.
Für Sie bedeutet das:
Es handelt sich nicht um ein Problem in Ihrer Umgebung oder Ihren Systemeinstellungen. Sie müssen derzeit keine weiteren Maßnahmen durchführen. Sobald die Störung auf unserer Seite behoben ist, wird sich das Verhalten automatisch auch in Ihrer Umgebung normalisieren.
Wir halten Sie selbstverständlich auf dem Laufenden und informieren Sie, sobald das Incident vollständig gelöst wurde.
Vielen Dank für Ihre Geduld und Ihr Verständnis.