Domainname mit oder ohne Akzent: Was sich für Ihre E-Mails ändert

⚡TL;DR

• Behalten Sie den Akzent bei, wenn Sie die Domain bestimmen: café.fr und cafe.fr sind zwei eigenständige Namen mit unabhängigen Konfigurationen.
• Ordnen Sie café.fr und xn--caf-dma.fr einander zu: Es sind zwei Schreibweisen desselben Namens, ohne eine zweite Registrierung kaufen zu müssen.
• Notieren Sie bei einer E-Mail die SPF-Envelope-Domain, die DKIM-Domain aus d= und die Domain der From-Adresse, bevor Sie die Ergebnisse vergleichen.
• Prüfen Sie den im DNS abgefragten Namen: xn-- in einem DMARC-Bericht belegt noch keinen Alignment-Fehler.

Sie haben eine Domain mit Akzent eingerichtet. Einige Tage später erscheint in einem E-Mail-Bericht ein Name, der mit xn-- beginnt. Sie suchen nun nach einer unbekannten Domain in Ihrem Konto oder entfernen den Akzent, um eine vertrautere Schreibweise zu erhalten. Diese beiden Reaktionen führen zu unterschiedlichen Fehlern.

Im ersten Fall behandeln Sie zwei Schreibweisen desselben Namens getrennt. Im zweiten ersetzen Sie den Namen durch einen anderen. Für DNS und E-Mail ist ein é keine Verzierung, die sich einfach weglassen lässt. café.fr entspricht xn--caf-dma.fr; der Name cafe.fr ohne Akzent hat eine andere Identität.

Dieser Unterschied entscheidet darüber, in welcher Zone Ihre Einstellungen liegen und welche Domains die Empfänger authentifizieren. Er erklärt auch, weshalb eine lesbare Oberfläche und ein technisches Protokoll einander scheinbar widersprechen. Die genannten Namen dienen ausschließlich zum Vergleich der Schreibweisen. Der Artikel beschreibt weder ihre Inhaber noch ihre Dienste oder tatsächlichen DNS-Einträge.

Ohne Akzent ist es ein anderer Domainname

café.fr und xn--caf-dma.fr bezeichnen denselben Namen; cafe.fr ist eine andere Domain. Das erste Paar verbindet eine Unicode-Form mit lesbarem Akzent mit ihrer ASCII-Darstellung. Beim zweiten Vergleich ändert sich die Schreibweise des Namens selbst. Im DNS gibt es keinen Mechanismus, der die Konfigurationen der Namen mit und ohne Akzent automatisch miteinander verknüpft.

Zwei Schreibweisen desselben Namens, aber zwei Namen, sobald der Akzent entfällt

Die technische ASCII-Form bewahrt die Identität des Namens mit Akzent. Sie entsteht also nicht durch das Entfernen von Akzenten. Die Buchstaben, Ziffern und Bindestriche in xn--caf-dma.fr stehen für genau diesen Namen. Das Präfix gehört zur Schreibweise und muss erhalten bleiben. Nur das Ende dieser Zeichenfolge zu kopieren, hilft nicht dabei, die Domain wiederzufinden.

Bei der Registrierung verhindert diese Unterscheidung, dass Sie denselben Kauf doppelt zählen. Eine Oberfläche kann während der Bestellung den Namen mit Akzent anzeigen und in der Bestellübersicht anschließend die xn---Form. Beide Angaben können sich auf eine einzige registrierte Domain beziehen. Wenn Ihnen der Name ohne Akzent gehört, erhalten Sie dadurch nicht automatisch den Namen mit Akzent, und umgekehrt ebenso wenig. Möchten Sie beide Namen nutzen, müssen Sie Registrierung und Einrichtung getrennt behandeln.

Dasselbe gilt für die Dienste. Eine Organisation, die zwei Namen kontrolliert, kann denselben DNS-Hoster und denselben E-Mail-Anbieter wählen. Sie kann auch dafür sorgen, dass Nachrichten an die jeweiligen Adressen in einem gemeinsamen Postfach ankommen. Das sind ausdrückliche Konfigurationsentscheidungen. Durch das Entfernen eines Akzents entstehen weder dieses Postfach noch ein E-Mail-Alias oder eine Kopie der DNS-Einträge.

Stellen Sie sich zwei Domains Ihrer Organisation vor, eine mit und eine ohne Akzent. Die zweite empfängt bereits E-Mails, während die erste gerade erst registriert wurde. Eine Adresse mit Akzent auf Ihren Geschäftsunterlagen richtet ihren Empfang noch nicht ein. Der E-Mail-Anbieter muss diese Domain kennen, und ihre DNS-Einstellungen müssen zur geplanten Nutzung passen. Der vorhandene Dienst unter dem anderen Namen gleicht das nicht aus.

Die Abbildung zeigt deshalb zwei voneinander unabhängige Beispielzonen. Das erfordert weder zwei Anbieter noch zwei physische Server: Dieselbe Infrastruktur kann mehrere Zonen betreiben. Die Unabhängigkeit betrifft die Namen und ihre Daten. Eine Änderung an einem Namen wird nicht aufgrund ähnlicher Schreibweise auf den anderen übertragen.

Den Namen in der DNS-Zone und in Protokollen zuordnen

Die xn---Form bietet einen gemeinsamen Bezugspunkt, um eine DNS-Zone, ein Protokoll und eine Oberfläche mit Akzentanzeige einander zuzuordnen. Sie kennzeichnet den internationalisierten Namen, ohne seine Domain zu ändern.

In einer DNS-Konsole kann der Titel der Zone in Unicode erscheinen. Ein Export oder ein Anfrageprotokoll kann dagegen die ASCII-Form verwenden. Vergleichen Sie die vollständigen Namen, bevor Sie nach einem fehlenden Eintrag suchen. Vielleicht haben Sie die richtige Zone unter einer anderen Darstellung geöffnet. Vielleicht ist es aber auch eine tatsächlich andere Zone, deren Name keinen Akzent enthält.

Der Zonenname und der Name eines Eintrags werden nicht immer zusammen angezeigt. Manche Konsolen erwarten einen relativen Namen und ergänzen die aktuelle Zone. In einer fiktiven Zone example.com kann die Eingabe _dmarc deshalb _dmarc.example.com bezeichnen. Das kurze Label _dmarc sieht in zwei Konsolen gleich aus. Der vollständige Name hängt jedoch von der geöffneten Zone ab. An diesem vollständigen Namen erkennen Sie, welche Richtlinie Sie geändert haben.

Ein Dokumentationsbeispiel ohne Werte einer fremden Domain zeigt den Unterschied:

Geöffnete Zone: example.com
Relativer Name: _dmarc
Vollständiger Name: _dmarc.example.com
Gesuchter Typ: TXT

Übertragen Sie diese Betrachtung auf Ihre eigenen Namen mit Akzent. Zeigt die Oberfläche die Zone in Unicode und den vollständigen Namen in ASCII, prüfen Sie vor einem zweiten Eintrag, ob beide zusammengehören. Ein zusätzlicher Eintrag zur Korrektur eines reinen Anzeigeunterschieds kann ein Duplikat erzeugen. Eine Veröffentlichung unter dem Namen ohne Akzent würde die eigentlich gemeinte Zone unverändert lassen.

Auch ein Protokolleintrag braucht etwas Kontext. Der abgefragte Name, der angeforderte Typ und die erhaltene Antwort beschreiben einen bestimmten Vorgang. Ein fehlender TXT-Eintrag bedeutet nicht automatisch, dass die Domain fehlt. Ein Auflösungsfehler sagt nicht aus, dass der Akzent abgelehnt wurde. Bewahren Sie den genauen Namen und das Ergebnis auf. Wenn Sie beides durch eine ungefähre Beschreibung ersetzen, wird die Fehlersuche unzuverlässiger.

Geben Sie in einer Supportanfrage die eingegebene Schreibweise und die zugehörige ASCII-Form an, anschließend den vollständigen Namen des betroffenen Eintrags. Ergänzen Sie das Datum der Beobachtung, wenn Sie die Zone gerade geändert haben. Diese Angaben helfen, eine Namensverwechslung von einer alten Antwort im Cache zu unterscheiden. Keine Wartezeit lässt eine Korrektur in einer Zone erscheinen, die Sie gar nicht geändert haben.

Eine Namenskonvertierung fragt außerdem nicht das DNS ab. Sie kann eine korrekte ASCII-Form liefern, ohne nachzuweisen, dass die Domain registriert ist, eine veröffentlichte Zone besitzt oder E-Mails empfängt. Dafür sind eigene Prüfungen nötig. Die Schreibweise eines Ziels zu kennen, belegt nicht, dass dort ein Dienst antwortet.

SPF, DKIM und DMARC: die richtige Domain für E-Mails prüfen

E-Mail-Prüfungen verwenden mehrere Domainidentitäten. Ihre Schreibweise hängt vom jeweiligen Verarbeitungsschritt ab. RFC 8616 legt getrennte Regeln für DNS, SPF, DKIM und DMARC fest. Wer diese Schritte verwechselt, sucht beispielsweise einen Schlüssel in der falschen Zone oder verändert einen Header, der unverändert bleiben müsste.

Zwei Begriffe helfen beim Lesen der RFC. Ein U-label ist die Unicode-Form eines internationalisierten Namensteils, etwa café. Das zugehörige A-label ist die ASCII-Darstellung, hier xn--caf-dma. Punkte trennen die Teile der Domain; fr bleibt unverändert. Diese Begriffe beschreiben zwei Schreibweisen, niemals zwei Domainregistrierungen, die Sie kaufen müssten.

Die im DNS abgefragten Namen

Abschnitt 3 der RFC 8616 schreibt ASCII für die Zeichenfolgen vor, die in den von diesen Protokollen verwendeten DNS-Einträgen gespeichert werden. Enthält ein aus einem Header übernommener Name U-labels, wird er vor der DNS-Abfrage konvertiert. Die Software, die einen Eintrag abfragt, darf nicht davon ausgehen, dass nur ein E-Mail-System mit internationalisierten Headern die Antwort liest.

Diese Regel beschreibt nicht das Format aller Felder einer E-Mail. Sie betrifft die veröffentlichten Daten und die DNS-Abfrage. Dieselbe Nachricht kann eine lesbare Unicode-Adresse enthalten und eine Anfrage mit dem entsprechenden ASCII-Namen auslösen. Dabei ändern sich weder Inhaber noch Ziel.

Unterscheiden Sie beim Lesen einer Konfiguration zwischen dem Namen des Eintrags und seinem Wert. Der Name beantwortet die Frage, wo gesucht wird; der Wert enthält die Richtlinie oder den Schlüssel. Ein formal einwandfreier SPF-Text unter dem falschen Namen ist nicht der Eintrag, den der Empfänger abfragt. Auch ein DKIM-Schlüssel irgendwo in Ihrem DNS-Konto genügt nicht. Sein Speicherort muss zur Domain und zum Selektor der Signatur passen.

Die folgenden Stellen gehören zu einem vollständig fiktiven Szenario mit example.com. Die Tabelle nennt abzufragende Namen und liefert keine Konfiguration zum Kopieren.

Prüfung	Identität im Szenario	Zugehöriger DNS-Name
SPF	Envelope-Domain example.com	example.com, Typ TXT
DKIM	d=example.com, Selektor s=septembre	septembre._domainkey.example.com, Typ TXT
DMARC	From-Adresse unter example.com	_dmarc.example.com, Typ TXT

In Ihrem E-Mail-System können diese Domains unterschiedlich sein. Ein Dienstleister kann die Envelope-Domain verwalten oder mit seiner eigenen Domain signieren. Erfassen Sie deshalb zuerst die Identitäten, die eine empfangene Nachricht tatsächlich verwendet. Nur nach dem Namen oben in Ihrer Konsole zu suchen, beantwortet nicht unbedingt die Frage des jeweiligen Protokolls.

SPF und die Domain des SMTP-Envelopes

Abschnitt 4 verlangt, jedes U-label vor der SPF-Validierung in ein A-label umzuwandeln. Die in EHLO angegebene Domain muss bereits aus A-labels bestehen. Die Domain in MAIL FROM darf bei einem internationalisierten Austausch eine der beiden Formen verwenden. Die Konvertierung gilt auch für Namen aus SPF-Makroexpansionen, nicht nur für die erste Abfrage.

SPF untersucht Identitäten aus der SMTP-Sitzung. Mit EHLO stellt sich der sendende Server vor. MAIL FROM enthält die Envelope-Adresse, die unter anderem für Fehlerrückmeldungen dient. Diese Adresse unterscheidet sich von der From-Adresse, die der Leser im E-Mail-Programm sieht. Eine für die Anzeige konfigurierte Domain ist deshalb nicht automatisch die von SPF geprüfte Domain.

Warum muss EHLO von Anfang an die ASCII-Form verwenden? Der Befehl kommt vor der Antwort, in der der Server mitteilt, ob er die für internationalisierte E-Mails nötige Erweiterung unterstützt. Diese Information liegt der Versandsoftware noch nicht vor. Das an dieser Stelle vorgeschriebene Format legt nicht fest, welche Formate in späteren Schritten möglich sind.

In einem fiktiven Szenario versendet eine Plattform für example.com mit einer Envelope-Adresse unter ruecklauf.example.com. Zu prüfen ist der SPF-TXT-Eintrag der tatsächlich verwendeten Envelope-Domain. Maßgeblich ist nicht eine Domain, die nur deshalb gewählt wurde, weil sie auf der Startseite der Website steht. Nutzt die Plattform eine internationalisierte Domain, verwendet dieselbe Abfrage nach der Konvertierung deren ASCII-Form. Das Protokoll versucht anschließend nicht ersatzweise den Namen ohne Akzent.

Ermitteln Sie deshalb zuerst die geprüfte Identität, bevor Sie die Einzelheiten einer SPF-Richtlinie lesen. Ein pass bedeutet, dass die IP-Adresse für diese Identität autorisiert war. Es bestätigt weder, dass diese Identität zur From-Adresse gehört, noch dass das gesamte E-Mail-System korrekt eingerichtet ist. Der Vergleich mit From gehört zu DMARC.

Auch internationalisierte Namen innerhalb eines SPF-Eintrags müssen als A-labels geschrieben werden. Eine Verwaltungsoberfläche, die im Zonennamen einen Akzent akzeptiert, erlaubt damit nicht dessen beliebige Verwendung im TXT-Wert. Das Eingabefeld für die Domain und der veröffentlichte Inhalt erfüllen unterschiedliche Aufgaben.

Wenn Sie beide Namen mit und ohne Akzent verwalten, kopieren Sie Richtlinien nicht automatisch. Für beide können dieselben Server autorisiert sein, sofern die tatsächlichen Versandwege das rechtfertigen. Eine Domain, die ausschließlich E-Mails empfängt, hat nicht unbedingt dieselben Anforderungen wie eine Versanddomain. Die Ähnlichkeit der Namen ersetzt keine Bestandsaufnahme Ihrer Absender.

DKIM und die signierten Werte

Abschnitt 5 unterscheidet herkömmliche Nachrichten von Nachrichten mit internationalisierten Headern. Für internationalisierte Namen in d=, im Domainteil von i= und in s= sind bei herkömmlichen Nachrichten A-labels vorgeschrieben. Die RFC verwendet dafür MUST. Bei internationalisierten Headern werden U-labels empfohlen (SHOULD); A-labels bleiben gültig.

Diese Tags erfüllen unterschiedliche Aufgaben. d= gibt die signierende Domain an, s= den Selektor zum Auffinden des Schlüssels und i=, falls vorhanden, eine Identität aus lokalem Teil und Domainteil. Im fiktiven Beispiel i=service@example.com ist nur example.com die Domain. Die Regel zu ihrer Schreibweise bedeutet nicht, dass auch service auf dieselbe Weise konvertiert werden müsste.

Die DKIM-Prüfung umfasst eine DNS-Abfrage nach dem öffentlichen Schlüssel und eine kryptografische Berechnung anhand der Nachricht. Für diese beiden Vorgänge gelten unterschiedliche Umwandlungsregeln. Der Abfragename muss die vom DNS erwartete Form haben. Für das Berechnen oder Prüfen des Hashwerts verlangt die RFC dagegen die Domain genau in der Schreibweise des Headers, unter Anwendung der jeweiligen DKIM-Kanonisierungsregeln.

Damit scheidet eine naheliegende vermeintliche Reparatur aus: vor der Signaturprüfung sämtliche Unicode-Namen in einer rohen E-Mail durch ihre ASCII-Form zu ersetzen. Selbst wenn die Namen dieselbe Domain bezeichnen, unterscheiden sich ihre Darstellungen in den signierten Daten. Gleichwertige Namen machen zwei Bytefolgen für eine kryptografische Berechnung nicht austauschbar.

Angenommen, eine Nachricht mit internationalisierten Headern enthält eine signierende Domain in Unicode. Die Prüfsoftware findet den Schlüssel mit dem entsprechenden ASCII-Namen und prüft dann die Signatur unter Beibehaltung der Headerdarstellung. Eine Oberfläche kann beide Schreibweisen nebeneinander anzeigen, damit sie sich leichter zuordnen lassen. Diese Anzeige erlaubt keine Änderung der ursprünglichen Nachricht.

Bewahren Sie für die Fehlersuche deshalb eine unveränderte Rohkopie der empfangenen Nachricht auf. Ein Screenshot mit vom E-Mail-Programm umformatierten Adressen erleichtert das Lesen, gibt aber nicht unbedingt die signierten Werte wieder. Lesen Sie d= und s= im DKIM-Header ab und suchen Sie den Schlüssel an der daraus gebildeten Stelle. Ein Schlüssel unter dem Namen ohne Akzent wird nicht zum Schlüssel der Domain mit Akzent.

Achten Sie auf den Selektor ebenso genau wie auf die Domain. Zwei Nachrichten derselben Domain können unterschiedliche Selektoren verwenden. Ein gefundener Schlüssel für den einen bestätigt keine Signatur mit dem anderen. Im Szenario mit example.com sind septembre._domainkey.example.com und archives._domainkey.example.com zwei verschiedene Stellen. Der Fehler läge dann im falschen Selektor, selbst wenn die Domain korrekt geschrieben wäre.

DMARC und die sichtbare Domain in From

Abschnitt 6 verlangt, alle U-labels der Domain in der From-Adresse vor der weiteren DMARC-Verarbeitung in A-labels umzuwandeln. Außerdem bleiben in den Berichtstags rua und ruf herkömmliche Adressen vorgeschrieben. Diese letzte Regel betrifft die Berichtsziele, nicht die überall in der Nachricht zulässige Schreibweise.

Ausgangspunkt ist die Domain der From-Adresse hinter dem @-Zeichen. Der angezeigte Personenname, etwa "Vertriebsteam", wird nicht für diesen Vergleich verwendet. In diesem Anzeigenamen kann ein Akzent vorkommen, obwohl die Adresse keine internationalisierte Domain enthält. Öffnen Sie die Absenderdetails, damit Sie nicht das falsche Element untersuchen.

DMARC sucht nach einer erfolgreichen SPF- oder DKIM-Authentifizierung, die mit dieser From-Domain übereinstimmt. Striktes Alignment vergleicht die genauen Domains; gelockertes Alignment berücksichtigt die organisatorische Domain. Je nach gewähltem Modus kann also ein Unterschied bei der Subdomain zulässig sein. Das Entfernen eines Akzents ist keine Regel des gelockerten Alignments. Es macht aus zwei unabhängigen Namen keinen gemeinsamen Namen.

Im Vergleich dieses Artikels können café.fr und xn--caf-dma.fr bei der Verarbeitung der Namen übereinstimmen. cafe.fr bleibt eigenständig. Der Besitz beider Domains, derselbe Server oder derselbe angezeigte Firmenname ändern diese Beziehung nicht. Soll Ihr Absender den Namen mit Akzent verwenden, signiert aber für den anderen, korrigieren Sie die Einrichtung des betreffenden Versandwegs.

Bei Berichten zeigt ein Dokumentationsziel wie rua=mailto:rapports@example.com das Format einer herkömmlichen Adresse. Ist die Empfängerdomain internationalisiert, verwendet ihr Domainteil die ASCII-Form. Ein Akzent im lokalen Teil würde der Regel aus Abschnitt 6 widersprechen. Die Adresse muss die Berichte außerdem empfangen können. Ihre Syntax erzeugt kein Postfach.

Betrachten Sie schließlich den Fall, der oft Zweifel auslöst: Sie haben den Namen mit Akzent eingerichtet, doch ein DMARC-Bericht oder der Header Authentication-Results zeigt xn--caf-dma.fr. Die Zuordnung zur Oberfläche kann vollkommen stimmen. Ermitteln Sie das Feld mit diesem Wert und lesen Sie dann das zugehörige Ergebnis. From-Domain, SPF-Domain und signierende Domain sind nicht austauschbar.

Stimmen die Namen nach der Konvertierung überein, verfolgen Sie die in den Ergebnissen genannten Ursachen: nicht autorisierte IP-Adresse, fehlender Schlüssel, ungültige Signatur oder eine authentifizierte Identität, die tatsächlich von der From-Domain abweicht. Ändern Sie Ihre Richtlinie nicht allein wegen des Präfixes. Die Anzeige von xn-- anstelle des Akzents ist für sich genommen kein Alignment-Fehler.

Was die Werkzeuge bei der Eingabe von café.fr prüfen

Die DNS-Abfrage und die DMARC-Prüfung von CaptainDNS akzeptieren café.fr und fragen dessen ASCII-Form ab. Für DMARC lautet der Abfragename _dmarc.xn--caf-dma.fr. Die DNS-Abfrage zeigt daneben die Unicode-Form an. Die DMARC-Prüfung zeigt den abgefragten Namen in ASCII. Diese Namen veranschaulichen die Verarbeitung der Eingabe, ohne tatsächliche Ergebnisse zu dieser fremden Domain zu zeigen.

Die DNS-Abfrage beantwortet eine Frage zur Veröffentlichung: Welche Einträge werden für den angeforderten Namen und Typ zurückgegeben? Die DMARC-Prüfung konzentriert sich auf die veröffentlichte Richtlinie und deren Syntax. Beide helfen, die richtige Zone zu prüfen. Ein gültiger DMARC-TXT-Eintrag belegt aber nicht, dass jede Versandplattform Ihre Nachrichten mit der richtigen Domain signiert.

Diese Grenze ist bei einem Anbieterwechsel relevant. Sie können genau den verlangten Wert veröffentlicht haben und trotzdem bei manchen E-Mails Fehler sehen. Die Plattform, die diese Nachrichten verschickt, verwendet möglicherweise noch eine alte Identität. Vergleichen Sie dann die DNS-Veröffentlichung mit den Headern einer Nachricht dieser Plattform. Eine Domainprüfung und eine Nachrichtenprüfung ergänzen sich; sie untersuchen nicht dasselbe.

Auch ein leeres Ergebnis muss zusammen mit dem abgefragten Namen betrachtet werden. Haben Sie die Domain ohne Akzent eingegeben, hat das Werkzeug diesen eigenständigen Namen untersucht. Haben Sie die richtige Domain eingegeben, sollten Sie bei einem fehlenden Eintrag dessen Veröffentlichung prüfen. In beiden Fällen steht die Identität der Zone vor jeder Änderung eines Werts.

Wenn Sie nur die Schreibweisen zuordnen möchten, liefert der Punycode-/IDN-Konverter beide Formen ohne DNS-Abfrage. Um die von der Registry veröffentlichten Daten zu sehen, können Sie die Domainregistrierung mit RDAP abfragen. RDAP validiert weder SPF noch DMARC. Ein Registrierungseintrag beschreibt die registrierte Domain, nicht die korrekte Funktion ihrer E-Mails.

Unter .fr gilt eine Tabelle lateinischer Zeichen

Die Namensrichtlinie von Afnic erlaubt unter .fr eine Tabelle lateinischer Zeichen einschließlich Buchstaben mit Akzenten, aber keine kyrillischen Zeichen. In diesem Vergleich zwischen einem Namen mit Akzent und seiner Schreibweise ohne Akzent betrachten wir als Gegenstück nur den eigenständigen ASCII-Namen ohne Akzent; dieser Vergleich schützt nicht vor anderen visuellen Ähnlichkeiten. Zu irreführenden Namen und verdächtigen Links außerhalb dieses Falls finden Sie weitere Informationen in unseren Artikeln zum Erkennen von Phishing-E-Mails und zum Prüfen von Weiterleitungen und verdächtigen Links.

Ein Akzent vor dem @-Zeichen ist ein anderes Thema

Im fiktiven Beispiel élise@example.com gehört der Akzent zum lokalen Teil, der das Postfach bezeichnet; dieser wird nicht wie eine Domain konvertiert. Die Internationalisierung von E-Mail-Adressen (EAI) unterscheidet den Nachrichtenaustausch mit einer internationalisierten Adresse von der Möglichkeit, dieses Postfach bei einem Anbieter anzulegen. Gmail unterstützt das Senden an solche Adressen und den Empfang von ihnen, schließt aber Akzente bei der Erstellung von Nutzernamen aus. Für Microsoft 365 kündigt Exchange Online diesen Austausch mit internationalisierten Adressen an, während die Regeln zur Nutzererstellung Akzente in der Adresse ausschließen. Möglicher Nachrichtentransport erlaubt also nicht das Anlegen eines Postfachs mit Akzent bei diesen Anbietern und garantiert keine Kompatibilität aller Zwischenstationen.

Auch das Zertifikat verwendet die ASCII-Form der Domain

Das Feld dNSName in der SAN-Erweiterung eines Zertifikats enthält die ASCII-Form der internationalisierten Domain. RFC 5280, Abschnitt 7.2, schreibt dieses Speicherformat vor. xn-- in den Zertifikatsdetails kann deshalb zu genau der Domain gehören, die der Browser mit Akzent anzeigt.

Ein Zertifikat für den Namen mit Akzent deckt den Namen ohne Akzent nicht automatisch ab. Soll ein Dienst beide Identitäten anbieten, müssen die abgedeckten Namen diesem Bedarf entsprechen. Es gilt dasselbe Prinzip wie bei E-Mail: Eine ähnliche Schreibweise ersetzt keine ausdrückliche Konfiguration.

Mit der CSR, dem Antrag auf Ausstellung eines Zertifikats, lassen sich die angeforderten Namen vor der Ausstellung untersuchen. Sie belegt nicht, welche Namen später tatsächlich im installierten Zertifikat stehen. Unterscheide bei der Fehlersuche zwischen dem Antrag und dem Zertifikat, das der Server tatsächlich präsentiert. Auf eine korrekte CSR kann die Installation eines anderen Zertifikats gefolgt sein.

Der CaptainDNS-Parser kennzeichnet eine rohe Unicode-Form in einem SAN dNSName als ungültig und zeigt neben einer korrekten xn---Form die Unicode-Schreibweise an. Sie können die Zertifikatsnamen in der CSR untersuchen, um diese Darstellung zu prüfen. Die Prüfung betrifft den Antrag und erlaubt keine Aussage über die SPF- oder DMARC-Einstellungen der Domain.

Was dieser Artikel nicht behandelt

Dieser Artikel hilft Ihnen festzustellen, zu welcher Domain Ihre DNS- und E-Mail-Einstellungen gehören. Er ist weder eine Schritt-für-Schritt-Anleitung zur Konvertierung noch ein Leitfaden zu irreführenden Links oder zur HTTP-Konfiguration. Die verlinkten Seiten behandeln diese Themen gesondert.

Die vollständige Internationalisierung von Postfächern erfordert außerdem Prüfungen, die über die Domain hinausgehen. Hier bleibt das Ziel konkret: feststellen, ob zwei Schreibweisen denselben Namen bezeichnen, dessen Zone finden und anschließend die tatsächlich vom Absender verwendeten Identitäten vergleichen. Bewahren Sie die ursprünglichen Header auf, wenn das Problem eine Signatur betrifft.

FAQ

Ist ein Domainname mit Akzent derselbe wie ohne Akzent?

Nein. Wenn Sie den Akzent entfernen, ändert sich die Domain: café.fr und cafe.fr sind eigenständig. café.fr und xn--caf-dma.fr sind dagegen zwei Schreibweisen desselben Namens.

Muss ich die Domain mit Akzent und die ohne Akzent getrennt registrieren?

Ja, wenn Sie beide Namen besitzen möchten und sie registrierbar sind. Der Kauf des einen weist Ihnen den anderen nicht automatisch zu. Die Unicode- und die xn---Form derselben Domain entsprechen hingegen einer einzigen Registrierung.

Warum zeigt mein DMARC-Bericht xn--, obwohl ich den Namen mit Akzent eingerichtet habe?

Der Bericht kann die ASCII-Darstellung der eingerichteten internationalisierten Domain anzeigen. Vergleichen Sie die Namen nach der Konvertierung und lesen Sie anschließend die SPF- und DKIM-Ergebnisse sowie ihr Alignment mit From. Das Präfix allein zeigt keinen Fehler an.

Gelten SPF, DKIM und DMARC der Domain ohne Akzent auch für die Domain mit Akzent?

Nein, diese Namen haben unabhängige Konfigurationen. Sie können für beide dieselben Dienste einrichten, aber DNS-Veröffentlichungen und Versandidentitäten müssen zur jeweiligen Domain passen. Durch das Entfernen des Akzents wird nichts automatisch gemeinsam genutzt.

Kann ich meine Domain mit Akzent in ein DNS- oder DMARC-Prüfwerkzeug eingeben?

Ja, die DNS-Abfrage und die DMARC-Prüfung von CaptainDNS akzeptieren diese Eingabe und fragen die entsprechende ASCII-Form ab. Prüfen Sie den im Ergebnis angezeigten vollständigen Namen. Eine erfolgreiche DNS-Prüfung ersetzt nicht die Analyse einer versendeten Nachricht.

Ist ein Akzent in der Domain einer E-Mail-Adresse dasselbe wie ein Akzent vor dem @-Zeichen?

Nein. Hinter dem @-Zeichen gehört der Akzent zur Domain, die eine ASCII-Darstellung besitzt. Davor gehört er zum lokalen Teil des Postfachs und unterliegt EAI sowie den Möglichkeiten des E-Mail-Anbieters.

Welche Form der Domain gehört in das Zertifikat?

Das SAN dNSName verwendet die ASCII-Form der internationalisierten Domain. Eine Software kann daneben Unicode anzeigen, um das Lesen zu erleichtern. Prüfen Sie die Namen in der CSR und die Namen im installierten Zertifikat getrennt.

Quellen

• RFC 8616 - DNS-, SPF-, DKIM- und DMARC-Regeln für internationalisierte E-Mails, Abschnitte 3 bis 6.
• Afnic - Namensrichtlinie vom 6. Juli 2026, Artikel 2.2, zulässige Zeichen.
• RFC 5280 - internationalisierte Namen im Zertifikatsfeld dNSName, Abschnitt 7.2.
• Gmail-Hilfe - zulässige Zeichen beim Erstellen eines Nutzernamens.
• RFC 9989 - authentifizierte Domains und DMARC-Alignment, Abschnitt 4.4.