Auch wenn N/D das nicht nativ unterstützt lässt sich das trotzdem (mit Einschränkungen) hinbekommen.
Ich habe das vor ein paar Jahren als Proof-of-Concept bei einem Kunden der das unbedingt haben wollte eingerichtet und es funktioniert auch.
Allerdings habe ich mich dabei auf einfache Umlaut-Domains beschränkt, also äöüß ohne die ganzen weiteren erlaubten Zeichen, von arabischen, kyrillischen oder japanischen Zeichen mal ganz zu schweigen.
Technisch werden dazu auf den Dominos per iQ.Suite-Job oder, wenn nicht vorhanden z.B. per Regel+nachgelagertem Agenten die betreffenden Mails 'rausgefischt, Header umcodiert und wieder freigegeben.
Das muss sowohl für aus- als auch für eingehende Mails gemacht werden da man die Umlaute in den Adressen auch inbound sehen möchte wenn man auf Antwort klickt.
In der Praxis spielt das alles, nach meiner Erfahrung, aber eher kaum eine Rolle. Zum einen beherrscht kaum ein Mailclient nativ die Konvertierung in beide Richtungen (auch Outlook aka Office 365 fällt beim Test durch) zum anderen handelt man sich etliche Folgeprobleme ein die den Nutzen mehr als aufwiegen:
- Besitzer einer Umlaut-Domain sollten immer auch Besitzer der passenden Nicht-Umlaut-Domain sein - ansonsten drohen Sicherheitsvorfälle weil garantiert im mehrstelligen Prozentsatz Mails an die jeweils falsche Domain versendet werden;
- man erhält ständig Nachfragen/freundliche Hinweise ob das mit dem Umlaut nicht vielleicht ein Schreibfehler ist; ratet mal an welche Domain-Schreibweise diese Hinweise gehen
- Mitarbeiter adressieren nicht nur die Domain sondern gleich den ganzen Empfängernamen mit Umlauten und verstehen nicht, warum die Adresse nicht müller@müllersdomain.irgendwas sondern mueller@müllersdomain.irgendwas heißen muss
...und und und...
Also ja, man bekommt es technisch schon irgendwie hin. Aber man will das alles eigentlich gar nicht.
HTH
Carsten