Eine gute DNS-Fehlersuche für E-Mail beginnt mit einer unbequemen Tatsache: Wenn SPF, DKIM oder ein Tracking-CNAME sich nicht verifizieren lässt, liegt die Ursache selten in dem Eintrag, den Sie veröffentlichen wollten. Meist liegt sie darin, wie Ihr DNS-Panel ihn gespeichert hat. Ein Schlüssel war länger als 255 Zeichen, ein Domainname wurde doppelt angehängt, ein Paar Anführungszeichen wurde Teil des Werts, ein zweiter SPF-Eintrag kam hinzu, oder eine alte Antwort ist in einem Cache noch nicht abgelaufen. Wir gehen jeden dieser Fälle durch, zeigen, wie Sie ihn mit dig und nslookup prüfen, und schließen mit einer Tabelle, die Sie nach Symptomen nutzen können.
Wie E-Mail-Einträge im DNS abgelegt sind
Jede E-Mail-Authentifizierungsmethode beruht auf einigen wenigen Eintragstypen. SPF und DKIM werden als TXT-Einträge veröffentlicht, DMARC ist ein TXT-Eintrag unter einem Namen, der mit _dmarc beginnt, und viele Versandplattformen verlangen CNAME-Einträge für einen Return-Path- oder Tracking-Hostnamen. MX-Einträge leiten eingehende Mails. Ein Resolver fragt nach einem Namen und einem Typ, und die Antwort trägt eine Time to Live (TTL), die jedem Cache sagt, wie lange er sie wiederverwenden darf.
Drei Details erklären die meisten Probleme. Erstens sind DNS-Panels freundliche Oberflächen über einer Zone, und jedes trifft eigene Entscheidungen zu Namen, Anführungszeichen und Aufteilung. Zweitens gibt es Caches auf mehreren Ebenen, sodass derselbe Name eine Zeit lang an verschiedenen Orten unterschiedliche Antworten liefern kann. Drittens schließen sich manche Eintragstypen unter demselben Namen gegenseitig aus. Den vollständigen Satz an Einträgen behandeln wir in unserer Authentifizierungsanleitung und den Verifizierungsablauf unter Ihre Absenderdomain verifizieren. Dieser Artikel ist die diagnostische Ergänzung dazu.
Zuerst am richtigen Ort prüfen: die autoritativen Nameserver
Bevor Sie etwas ändern, finden Sie heraus, was tatsächlich veröffentlicht ist. Ein öffentlicher Resolver, etwa der Ihres Laptops, hält möglicherweise eine ältere Antwort. Die autoritativen Nameserver sind die Server, die Ihre Zone halten und die maßgebliche Antwort geben, deshalb fragen wir immer zuerst sie.
# 1. Find the authoritative nameservers for the domain
dig NS example.com +short
# 2. Ask one of them directly for the record (no cache involved)
dig TXT selector1._domainkey.example.com @ns1.dns-host.example +noall +answer
# 3. Compare with what a public resolver says
dig TXT selector1._domainkey.example.com @9.9.9.9 +noall +answer
# 4. Check the TTL and the negative caching value
dig SOA example.com @ns1.dns-host.example +noall +answer
# nslookup equivalent
nslookup -type=TXT selector1._domainkey.example.com ns1.dns-host.exampleIst die autoritative Antwort falsch, liegt das Problem im Panel: Korrigieren Sie den Eintrag. Ist die autoritative Antwort richtig und weicht der öffentliche Resolver ab, liegt das Problem an einem Cache: Warten Sie. Sind beide richtig und die Verifizierung schlägt trotzdem fehl, prüfen Sie wahrscheinlich den falschen Namen, oder die Plattform erwartet einen anderen Eintragstyp. Dieser eine Vergleich beseitigt mehr Rätselraten als alles andere in diesem Artikel.
Tipp: Prüfen Sie von einem Rechner aus, der nicht Ihren eigenen DNS-Cache nutzt, und denken Sie daran, dass das Ergebnis eines webbasierten Checkers den Resolver dieses Checkers widerspiegelt, nicht Ihren.
TXT-Strings über 255 Zeichen und DKIM-Schlüssel mit 2048 Bit
Ein TXT-Eintrag enthält einen oder mehrere Character-Strings, und jeder ist auf 255 Bytes begrenzt. Das stammt aus dem ursprünglichen DNS-Format in RFC 1035, das jeden String mit einem Ein-Byte-Längenfeld speichert. Ein Eintrag kann mehrere Strings enthalten, und bei SPF und DKIM fügt der Empfänger sie der Reihe nach ohne Leerzeichen zusammen. Die Spezifikationen beider Verfahren legen das fest (RFC 7208 für SPF, RFC 6376 für DKIM).
Die praktische Auswirkung betrifft vor allem DKIM. Ein 1024-Bit-RSA-Public-Key in Base64 liegt mit den Tags für Version und Schlüsseltyp nahe an der Grenze, ein 2048-Bit-Schlüssel ist etwa doppelt so lang, sodass allein der p=-Wert mehrere hundert Zeichen umfasst. Er muss als mehr als ein String gespeichert werden. Unsere Anleitung zu DKIM-Schlüsselrotation, Selektoren und Schlüssellänge erklärt, warum sich 2048-Bit-Schlüssel lohnen.
| Verhalten Ihres Panels | Was Sie tun sollten | So prüfen Sie es |
|---|---|---|
| Teilt lange Werte automatisch auf | Fügen Sie den vollständigen Wert einmal ein, ohne Anführungszeichen und ohne Zeilenumbrüche | dig zeigt mehrere Strings in Anführungszeichen, die zusammen den vollständigen Schlüssel ergeben |
| Erwartet Teilstücke in Anführungszeichen | Teilen Sie an beliebiger Stelle unter 255 Zeichen, setzen Sie jeden Teil in Anführungszeichen und trennen Sie mit einem einzelnen Leerzeichen | Der zusammengefügte Text entspricht genau dem ursprünglichen Schlüssel |
| Lehnt Werte über 255 Zeichen ab | Suchen Sie eine Einstellung für lange Einträge oder einen anderen Eintrags-Editor; fragen Sie den Anbieter, falls es keine gibt | Die Abfrage liefert den vollständigen Schlüssel, nicht einen abgeschnittenen |
| Kürzt den Wert stillschweigend | Geben Sie ihn erneut in Teilstücken ein und lesen Sie das Ergebnis zurück | Ein zu früh endender Schlüssel lässt DKIM mit einem Schlüssel- oder Syntaxfehler scheitern |
So sieht eine korrekte Aufteilung aus
Das folgende Beispiel zeigt die Form eines aufgeteilten Eintrags. Der Schlüsseltext ist erfunden und zur Veranschaulichung gekürzt. In einem echten Eintrag ergeben die Teilstücke zusammen den vollständigen Schlüssel, den Ihre Plattform liefert.
selector1._domainkey.example.com. 3600 IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
"q1x2example0invented0key0chunk0one0aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
"IDAQAB" )Zwei Fallen sind häufig. Fügen Sie beim Aufteilen kein Leerzeichen in den Schlüssel ein, denn der Empfänger verkettet die Strings, und ein Leerzeichen würde Teil des Schlüssels. Und trennen Sie den Eintrag nicht mitten in Selektor- oder Tag-Namen. Schlägt ein aufgeteilter Schlüssel fehl, vergleichen Sie das zusammengefügte Ergebnis Zeichen für Zeichen mit dem Original, und zwar mit einem Text-Diff statt mit bloßem Auge.
Eigenheiten von Registraren und DNS-Panels
Derselbe Eintrag lässt sich in vier Panels auf vier verschiedene Arten eingeben. Dies sind die Eigenheiten, die uns am häufigsten begegnen.
Die Domain wird doppelt angehängt
Viele Panels hängen den Zonennamen automatisch an. Geben Sie selector1._domainkey.example.com ins Host-Feld ein, speichert das Panel womöglich selector1._domainkey.example.com.example.com. Das Symptom: Der Eintrag existiert im Panel, aber eine Abfrage des richtigen Namens liefert nichts. Geben Sie nur den relativen Teil selector1._domainkey ein und verwenden Sie für den Apex je nach Panel @ oder lassen Sie das Feld leer. Ein abschließender Punkt kennzeichnet in Zonendateien normalerweise einen vollqualifizierten Namen, aber Web-Panels unterscheiden sich, also lesen Sie den gespeicherten Namen mit dig zurück.
Anführungszeichen, Zeilenumbrüche und unsichtbare Zeichen
Beim Kopieren eines Werts von einer Webseite oder aus einem Dokument können typografische Anführungszeichen, geschützte Leerzeichen oder ein Zeilenumbruch mitkommen. Setzt das Panel zusätzlich eigene Anführungszeichen, steht am Anfang des Werts womöglich ein wörtliches Anführungszeichen, und ein Eintrag, der mit einem Anführungszeichen beginnt, startet nicht mit v=spf1 oder v=DKIM1 und wird daher nicht erkannt. Fügen Sie den Wert zuerst in einen reinen Texteditor ein, dann ins Panel, und lesen Sie das Ergebnis zurück.
Falscher Eintragstyp oder falscher Name
Plattformen verlangen manchmal einen TXT-Eintrag, wo Sie einen CNAME erwarten würden, oder umgekehrt. Verwenden Sie den Typ genau wie vorgegeben. Prüfen Sie außerdem, ob Sie in der richtigen Zone arbeiten: Nutzt die Domain Nameserver bei einem Anbieter, Sie haben die Zone aber bei Ihrem Registrar bearbeitet, wird die Änderung nie ausgeliefert. Die weiter oben gezeigte NS-Abfrage verrät, wo die aktive Zone liegt.
| Symptom im Panel | Wahrscheinliche Ursache | Lösung |
|---|---|---|
| Eintrag zeigt die Domain doppelt im Namen | Das Panel hat die Zone an einen vollständigen Namen angehängt | Nur den relativen Namen eingeben |
| Wert beginnt und endet nur in der Abfrageausgabe mit Anführungszeichen | Normal für TXT-Ausgaben von dig | Keine Änderung nötig |
| Wert enthält maskierte Anführungszeichen oder eines am Anfang | Sie haben Anführungszeichen gesetzt, und das Panel hat eigene ergänzt | Ihre Anführungszeichen entfernen |
| Eintrag gespeichert, Abfrage liefert nichts | Eine Zone bearbeitet, die die aktiven Nameserver nicht ausliefern | Die Zone bei dem Anbieter bearbeiten, den die NS-Einträge nennen |
| Panel akzeptiert keinen Unterstrich im Namen | Regel zur Namensvalidierung im Panel | Anderen Editor-Modus nutzen oder den DNS-Anbieter fragen |
CNAME am Apex, Flattening und Eintragskonflikte
Ein CNAME besagt, dass ein Name ein Alias für einen anderen Namen ist, der Resolver also folgen und die dortigen Antworten verwenden soll. Deshalb kann ein CNAME nicht neben einem anderen Eintrag unter demselben Namen bestehen (RFC 1034 und RFC 2181). Der Root Ihrer Domain, der Apex, muss SOA- und NS-Einträge tragen und hat meist auch MX und TXT, daher ist ein CNAME am Apex nicht zulässig.
Manche DNS-Anbieter umgehen das mit Flattening oder einem Alias-Eintragstyp. Der Anbieter schlägt das Ziel selbst nach und gibt am Apex gewöhnliche Adresseinträge zurück. Das hilft, wenn Sie Ihre Root-Webadresse auf einen gehosteten Dienst zeigen lassen. Für die E-Mail-Authentifizierung hilft es nicht. Verlangt eine Plattform einen CNAME für einen Hostnamen wie eine Subdomain, setzen Sie ihn auf diese Subdomain. Verlangt sie einen CNAME auf die nackte Domain, fragen Sie nach einer Alternative wie TXT- und Adresseinträgen.
Der Konflikt funktioniert auch umgekehrt. Fügen Sie einen CNAME für einen Namen hinzu, der bereits einen TXT-Eintrag hat, zum Beispiel einen DKIM-Selektor, den Sie zuvor als TXT veröffentlicht haben, wird je nach Panel einer von beiden abgelehnt oder ignoriert. Löschen Sie den alten Eintrag, bevor Sie den CNAME hinzufügen. Diese Situation ist bei einem Anbieterwechsel verbreitet, und unsere Migrationsanleitung behandelt die Reihenfolge der Schritte.
Doppelte SPF-Einträge und andere Duplikate
Eine Domain darf nur einen SPF-Eintrag veröffentlichen, also einen TXT-Eintrag, der mit v=spf1 beginnt. Finden Empfänger zwei, lautet das Ergebnis ein permanenter Fehler (RFC 7208), und SPF schlägt für jede Nachricht fehl, nicht nur für die eines Anbieters. Das passiert, wenn zwei Teams jeweils den Eintrag hinzufügen, den ihr Anbieter verlangt hat.
| Situation | Was Empfänger sehen | Lösung |
|---|---|---|
| Zwei TXT-Einträge, die beide mit v=spf1 beginnen | Permanenter Fehler, SPF besteht nicht | In einem Eintrag mit allen include-Mechanismen zusammenführen |
| Ein Eintrag, mehr als 10 Lookups | Permanenter Fehler nach Erreichen des Lookup-Limits | Flatten oder includes entfernen; siehe die Anleitung zum SPF-Lookup-Limit |
| Zwei DMARC-Einträge unter _dmarc | Die Richtlinie wird möglicherweise ignoriert | Nur einen Eintrag behalten |
| Derselbe Selektor zweimal mit unterschiedlichen Schlüsseln veröffentlicht | Unvorhersehbare Schlüsselauswahl | Den alten Schlüssel löschen oder einen neuen Selektor verwenden |
Das Zusammenführen ist im Prinzip einfach: Nehmen Sie die include- und ip4-Mechanismen aus jedem Eintrag, fassen Sie sie in einem v=spf1-Eintrag zusammen und beenden Sie ihn mit einem einzigen all-Qualifier. Der schwierigere Teil ist die Zahl der Lookups, die wir in der Anleitung zum SPF-Permerror und unter mehrere Anbieter auf einer Domain verwalten erklären.
Proxy-Einträge: DNS-Proxy für Mail ausschalten
Manche DNS-Anbieter bieten einen Proxy-Modus an, oft als farbiges Wolkensymbol neben einem Eintrag dargestellt. In diesem Modus beantwortet der Anbieter Abfragen für den Namen mit seinen eigenen Adressen und leitet Webverkehr durch sein Netzwerk. Für Websites ist das nützlich, für Mail nicht.
Läuft ein mailbezogener CNAME über den Proxy, liefert die Abfrage nicht mehr das Ziel, das Ihre Versandplattform erwartet. Die Verifizierung schlägt fehl, Tracking- oder Return-Path-Hostnamen lösen nicht zum richtigen Server auf, und HTTPS-Zertifikate für Tracking-Domains werden möglicherweise nicht ausgestellt. Ein Mailserver-Hostname hinter dem Proxy nimmt überhaupt keine SMTP-Verbindungen an, weil der Proxy Webports statt Mail bedient. Stellen Sie daher jeden E-Mail-bezogenen Eintrag auf den Modus „Nur DNS“: MX-Ziele, A-Einträge von Mailservern, die CNAMEs für Return-Path- und Tracking-Hostnamen sowie DKIM-CNAMEs. TXT-Einträge laufen nie über einen Proxy und sind daher nicht betroffen. Unsere Anleitung zu Return-Path- und Tracking-Domains erklärt, warum diese Hostnamen direkt zur Plattform aufgelöst werden müssen.
Prüfung: Eine dig-Abfrage für einen über den Proxy laufenden Namen liefert Adressen, die nicht zu Ihrer Plattform gehören, obwohl Sie einen CNAME gespeichert haben. Daran erkennen Sie, dass der Proxy aktiv ist.
TTL-Wahl und Änderungsplanung
Die TTL ist die Anzahl der Sekunden, die ein Resolver eine Antwort behalten darf. Eine lange TTL reduziert Abfragen und macht den Eintrag widerstandsfähiger, falls Ihre Nameserver kurz ausfallen. Eine kurze TTL ermöglicht eine schnelle Erholung nach einem Fehler. Sinnvoll ist es, sie je nach Phase zu variieren.
| Phase | Empfohlene TTL | Warum |
|---|---|---|
| Aufbau oder Test eines neuen Eintrags | 300 bis 600 Sekunden | Korrekturen werden schnell sichtbar |
| Vor einer geplanten Änderung | Die TTL rechtzeitig vor der Änderung senken, mindestens so lange wie die aktuelle TTL | Alte Caches laufen ab, bevor Sie umschalten |
| Am Tag der Änderung | Kurz halten | Sie können zurückrollen |
| Stabile Einträge | 3600 Sekunden bis zu einem Tag | Weniger Abfragen und geringere Anfälligkeit bei Ausfällen |
Der Kernpunkt der Änderungsplanung: Das Senken einer TTL wirkt nicht sofort. Caches, die den Eintrag bereits halten, behalten ihn für die alte TTL. Hat ein Eintrag eine TTL von 86400 Sekunden, senken Sie sie mindestens einen Tag vor der Änderung. Ändern Sie dann den Wert, warten Sie, verifizieren Sie und erhöhen Sie die TTL wieder.
Propagation und negatives Caching
DNS-Änderungen breiten sich nicht von einem einzelnen Punkt aus. Es gibt keinen globalen Push. Was man Propagation nennt, ist schlicht die Zeit, bis Caches ablaufen. Die autoritativen Server antworten mit dem neuen Wert, sobald die Zone gespeichert und geladen ist, und jeder Resolver wechselt, wenn seine zwischengespeicherte Kopie endet. Manche Resolver ignorieren sehr niedrige TTLs oder behalten Antworten etwas länger, planen Sie also einen Puffer ein.
Es gibt einen zweiten Cache, den man leicht vergisst: den negativen Cache. Hat ein Resolver einen Namen abgefragt, der noch nicht existierte, merkt er sich die „nicht gefunden“-Antwort, und nach RFC 2308 richtet sich die Dauer nach dem SOA-Eintrag (der kleinere Wert aus der SOA-TTL und deren Minimum-Feld). Hat Ihre Plattform den Eintrag einige Minuten vor dem Hinzufügen geprüft, kann der Fehler bis zum Ablauf dieser Zeit im Cache bleiben, obwohl der Eintrag inzwischen existiert.
Ein durchgerechnetes Beispiel
Stellen Sie sich eine Domain vor, deren DKIM-TXT-Eintrag um 10:00 Uhr mit einer TTL von 3600 Sekunden veröffentlicht wurde und deren SOA-Zeit für negatives Caching 900 Sekunden beträgt. Um 10:05 Uhr prüft die Plattform zu früh und erhält „nicht gefunden“, sodass dieser Resolver den Fehler bis etwa 10:20 Uhr zwischenspeichert. Um 10:10 Uhr bemerken Sie einen Tippfehler, korrigieren den Schlüssel und speichern ihn. Die autoritativen Server geben nun die neue Antwort. Ein Resolver, der den ersten Eintrag um 10:00 Uhr zwischengespeichert hat, liefert die alte Antwort womöglich bis 11:00 Uhr. Einer, der „nicht gefunden“ zwischengespeichert hat, liefert sie womöglich bis 10:20 Uhr. Ein vollständig sauberes Ergebnis bei allen Resolvern kann also bis 11:00 Uhr dauern, eine Prüfung direkt bei den autoritativen Servern besteht aber um 10:10 Uhr. In diesem Fall bestätigen Sie anhand des autoritativen Ergebnisses, dass Ihre Änderung korrekt ist, und warten dann die längste Cache-Zeit von 60 Minuten ab, bevor Sie erneut auf die Verifizierungsschaltfläche klicken.
Wiederholt die Plattform Prüfungen automatisch, müssen Sie womöglich nichts tun. Prüft sie nur auf Knopfdruck, warten Sie die längste von Ihnen berechnete Cache-Dauer ab. Ändern Sie den Eintrag währenddessen nicht erneut, denn jede Änderung startet die Uhr für Caches, die sich aktualisieren, neu.
Eine Diagnosetabelle nach Symptomen
| Symptom | Wahrscheinlichste Ursache | Erste Prüfung | Lösung |
|---|---|---|---|
| Plattform meldet, der DKIM-Eintrag sei nicht gefunden | Name doppelt, falsche Zone oder noch nicht propagiert | Den exakten Selektornamen per dig beim autoritativen Server abfragen | Host-Feld korrigieren oder auf Caches warten |
| DKIM wird verifiziert, aber die Signatur scheitert mit einem Schlüsselfehler | Schlüssel abgeschnitten oder mit einem Leerzeichen aufgeteilt | TXT-Strings zusammenfügen und mit dem Original vergleichen | Erneut in Teilstücken ohne Leerzeichen eingeben |
| SPF liefert Permerror | Zwei SPF-Einträge oder über 10 Lookups | TXT am Apex per dig abfragen und v=spf1-Einträge zählen | Einträge zusammenführen, Lookups reduzieren |
| SPF-Eintrag wird scheinbar ignoriert | Wörtliches Anführungszeichen oder führendes Leerzeichen im Wert | Nach einem Wert suchen, der nicht mit v=spf1 beginnt | Überflüssige Zeichen entfernen |
| CNAME lässt sich nicht speichern | Unter dem Namen existiert ein weiterer Eintrag, oder der Name ist der Apex | Alle Eintragstypen unter dem Namen auflisten | Konflikt entfernen oder eine Subdomain verwenden |
| CNAME existiert, aber die Verifizierung scheitert | DNS-Proxy aktiv oder Ziel falsch geschrieben | Liefert dig das erwartete Ziel? | Auf „Nur DNS“ stellen, Ziel korrigieren |
| Funktioniert auf Ihrem Rechner, scheitert bei der Plattform | Unterschiedliche Resolver-Caches | Den autoritativen Server und zwei öffentliche Resolver abfragen | Die ältere TTL abwarten |
| Eintrag existiert, die Prüfung meldet aber weiter „nicht gefunden“ | Negatives Caching | SOA-Werte und den Zeitpunkt der ersten Prüfung ansehen | Die Zeit für negatives Caching abwarten |
| DMARC-Report zeigt keine Richtlinie | Eintrag unter dem falschen Namen | Prüfen, ob der Name mit _dmarc beginnt | Nach _dmarc.ihredomain verschieben |
Probleme auf Header-Ebene lassen sich, anders als Probleme auf Eintragsebene, in der Nachricht selbst leichter bestätigen. Was die Authentifizierungsergebnisse bedeuten, sobald das DNS stimmt, lesen Sie unter E-Mail-Header lesen.
Ein praktischer Ablauf zum Wiederholen
- Identifizieren. Notieren Sie den genauen Namen und Typ, den Ihre Plattform verlangt.
- Lokalisieren. Ermitteln Sie die aktiven Nameserver per NS-Abfrage und bestätigen Sie, dass Sie diese Zone bearbeiten.
- Eingeben. Verwenden Sie den relativen Hostnamen, fügen Sie den Wert ohne zusätzliche Anführungszeichen ein und teilen Sie lange Strings nur auf, wenn Ihr Panel es verlangt.
- Zurücklesen. Fragen Sie den autoritativen Server ab und vergleichen Sie das Ergebnis mit dem Original.
- Aufräumen. Entfernen Sie Duplikate, alte Selektoren mit demselben Namen und konfliktierende Eintragstypen.
- Proxy aus. Bestätigen Sie, dass mailbezogene Einträge auf „Nur DNS“ stehen.
- Gezielt warten. Berechnen Sie den längeren Wert aus alter TTL und Zeit für negatives Caching.
- Verifizieren. Führen Sie die Plattformprüfung aus und senden Sie eine Testnachricht. Die genauen Eintragsnamen und -werte, die Sie veröffentlichen müssen, finden Sie in Ihrem MigoSMTP-Konto oder in der API-Dokumentation.
Checkliste, bevor Sie um Hilfe bitten
- Der Eintragsname wurde beim autoritativen Nameserver zurückgelesen und entspricht exakt dem, was die Plattform verlangt hat.
- Kein Domain-Suffix erscheint doppelt im gespeicherten Namen.
- Der Wert enthält keine eingefügten Anführungszeichen, keine Zeilenumbrüche und keine Leerzeichen innerhalb langer Schlüssel.
- Lange TXT-Werte sind beim Zusammenfügen der Strings vollständig vorhanden.
- Unter dem Namen existiert nur ein SPF-Eintrag, und die Zahl der Lookups liegt innerhalb des Limits.
- Kein CNAME teilt sich einen Namen mit einem anderen Eintrag, und kein CNAME liegt am Apex.
- Jeder mailbezogene Eintrag steht auf „Nur DNS“ und läuft nicht über einen Proxy.
- Sie haben vor der erneuten Prüfung die alte TTL und die Zeit für negatives Caching abgewartet.
- Die Zone, die Sie bearbeitet haben, ist die, auf die die NS-Einträge verweisen.
Ein Eintrag lässt sich nicht verifizieren? Senden Sie uns den Eintragsnamen, den genauen veröffentlichten Wert und die Ausgabe einer dig-Abfrage gegen Ihren autoritativen Nameserver, dann helfen wir Ihnen, den Unterschied zu finden.
Weiterführende Literatur und Quellen
Häufig gestellte Fragen
Warum meldet mein DKIM-Eintrag, er sei zu lang?
Ein einzelner DNS-Character-String kann höchstens 255 Bytes enthalten, und ein 2048-Bit-RSA-Public-Key ist in Base64 länger als das. Der Eintrag selbst kann mehrere Strings enthalten, die Empfänger ohne Leerzeichen zusammenfügen. Manche Panels teilen den Wert für Sie auf, manche verlangen die Eingabe in Anführungszeichen gesetzter Teilstücke, und manche lehnen einen langen Wert ganz ab. Prüfen Sie, wie Ihr Panel damit umgeht, und kontrollieren Sie das Ergebnis mit einer TXT-Abfrage.
Soll ich meinen TXT-Wert in Anführungszeichen setzen?
Das hängt vom Panel ab. Viele Weboberflächen setzen die Anführungszeichen selbst. Fügen Sie eigene hinzu, steht ein wörtliches Anführungszeichen im Wert, und der Eintrag lässt sich nicht auswerten. Editoren für Zonendateien und manche Kommandozeilenwerkzeuge erwarten dagegen Anführungszeichen. Lesen Sie den Eintrag nach dem Speichern mit dig zurück, und entfernen Sie Ihre eigenen Anführungszeichen, wenn doppelte oder maskierte erscheinen.
Warum lautet mein Eintrag jetzt selector._domainkey.example.com.example.com?
Das Panel hängt Ihre Domain an alles an, was Sie ins Host-Feld eingeben. Geben Sie den vollständigen Namen ein, wird die Domain doppelt angehängt. Tragen Sie nur den Teil vor Ihrer Domain ein, zum Beispiel selector._domainkey, oder folgen Sie dem Hinweis im Panel. Ein abschließender Punkt signalisiert einem Panel meist, dass der Name vollständig ist, aber nicht jedes Panel behandelt ihn so. Testen Sie es daher mit einer Abfrage.
Kann ich einen CNAME auf meine Root-Domain setzen?
Standardmäßig erlaubt DNS das nicht, weil ein CNAME nicht mit anderen Einträgen unter demselben Namen koexistieren kann und die Root-Domain SOA- und NS-Einträge tragen muss. Manche Anbieter bieten eine Flattening- oder Alias-Funktion, die am Root Adresseinträge zurückgibt. Nutzen Sie sie bei Bedarf für Webverkehr, aber nicht als Ersatz für die TXT- und MX-Einträge, die E-Mail am Root benötigt.
Ich habe zwei SPF-Einträge. Ist das wirklich ein Problem?
Ja. Eine Domain darf nur einen SPF-Eintrag veröffentlichen, und Empfänger, die mehr als einen finden, geben einen permanenten Fehler zurück, statt einen auszuwählen. Führen Sie die Mechanismen in einem einzigen Eintrag zusammen. Unsere Anleitung zu mehreren Anbietern auf einer Domain erklärt, wie das gelingt, ohne das Lookup-Limit zu überschreiten.
Wie lang sollte ich die TTL setzen?
Verwenden Sie eine kurze TTL von etwa 300 bis 3600 Sekunden, solange Sie Einträge aufbauen oder ändern, und eine längere von mehreren Stunden bis zu einem Tag, sobald alles stabil läuft. Der passende Wert ist ein Kompromiss zwischen der Geschwindigkeit eines Rollbacks und der Last auf Ihren Nameservern.
Ich habe den Eintrag korrigiert, aber die Prüfung schlägt weiter fehl. Warum?
Entweder hält ein Resolver die alte Antwort noch, bis deren TTL abläuft, oder er hält eine zwischengespeicherte „nicht gefunden“-Antwort, bis die Zeit für das negative Caching endet, oder Sie prüfen einen anderen Namen als den, den die Plattform abfragt. Fragen Sie die autoritativen Nameserver ab, um die tatsächliche Lage zu sehen, und warten Sie dann auf die Caches.
Warum dürfen Mail-CNAMEs nicht über einen Proxy laufen?
Ein DNS-Proxy beantwortet Abfragen mit seinen eigenen Adressen statt mit dem tatsächlichen Ziel Ihres Eintrags. Eine Mail-Plattform muss das CNAME-Ziel oder die echte Serveradresse sehen. Ein über den Proxy geleiteter Eintrag besteht daher die Verifizierung nicht und kann Tracking oder Bounce-Verarbeitung stören. Stellen Sie diese Einträge auf „Nur DNS“.
Welchem Werkzeug soll ich vertrauen: dig, nslookup oder einem Web-Checker?
Alle sind brauchbar, wenn Sie wissen, was sie abfragen. Mit dig und nslookup können Sie den Server selbst wählen, und genau das trennt ein Veröffentlichungsproblem von einem Caching-Problem. Web-Checker fragen meist von einem Standort über einen öffentlichen Resolver ab. Weicht ihr Ergebnis von Ihrem lokalen ab, liegt das daher oft nur an unterschiedlichen Caches.