SPF, DKIM oder DMARC funktioniert nicht mehr? So finden Sie die Ursache

Eine Authentifizierung, die zwei Jahre lang funktionierte, kann an einem Dienstag ohne Fehlermeldung und ohne eine Änderung, an die Sie sich erinnern, scheitern. Die E-Mails verlassen weiterhin Ihre Server. Sie landen nur im Spam, als DMARC-Fehler in einem Bericht, den Sie nicht geöffnet haben, oder gar nicht. Dieser Leitfaden behandelt, was SPF, DKIM und DMARC üblicherweise bricht, nachdem sie funktioniert haben, wie Sie die Ursache mit wenigen DNS-Abfragen in Minuten finden und wie Sie vom nächsten Rückschritt erfahren, bevor Ihre Bounce-Rate es verrät.

Die kurze Antwort#

Wenn eine Authentifizierung, die funktionierte, plötzlich fehlschlägt, hat sich im DNS oder beim Absender etwas geändert. Prüfen Sie in dieser Reihenfolge: Wurde kürzlich ein DNS-Host oder Nameserver gewechselt, gibt es genau einen SPF-Record, liefert der DKIM-Selektor der fehlgeschlagenen Nachricht noch einen Schlüssel, gibt es genau einen DMARC-Record unter _dmarc, und hat ein neues Versandtool begonnen, als Ihre Domain zu senden? Diese fünf Fragen erklären die meisten Rückschritte. Lesen Sie zuerst den Authentication-Results-Header einer fehlgeschlagenen Nachricht, denn er sagt Ihnen, welche der Prüfungen SPF, DKIM oder DMARC für welche Domain gescheitert ist. Der E-Mail-Header-Analyzer zeigt diese Urteile, und der SPF-, DKIM- und DMARC-Checker zeigt, was das DNS gerade ausgibt.

Lesen Sie zuerst die fehlgeschlagene Nachricht#

Raten Sie nicht, welches Protokoll gebrochen ist. Öffnen Sie die vollständigen Header einer fehlgeschlagenen Nachricht und suchen Sie die Authentication-Results-Zeile, die der empfangende Server hinzugefügt hat.

Authentication-Results: mx.receiver.example;
  spf=fail smtp.mailfrom=bounce.example.com;
  dkim=fail header.d=example.com header.s=mail;
  dmarc=fail header.from=example.com

Drei Details sind wichtig. spf= und dkim= zeigen, welche Prüfung gescheitert ist. header.s ist der verwendete DKIM-Selektor und nennt Ihnen den genauen DNS-Namen zum Nachschlagen. Und smtp.mailfrom oder header.d zeigen, welche Domain jede Prüfung bewertet hat, was wichtig ist, wenn die Nachricht SPF für eine andere Domain besteht als die im From-Header.

Fragen Sie dann die Records über die Kommandozeile ab. Das funktioniert unter macOS und Linux.

dig +short TXT example.com
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.com

Ersetzen Sie mail durch den Selektor aus dem Header. Wenn Sie ihn nicht kennen, erklärt so finden Sie einen DKIM-Selektor Schritt für Schritt. Liefert die Abfrage nichts, ist der Record weg. Liefert sie etwas, lesen Sie es sorgfältig, denn der nächste Abschnitt behandelt, wie ein Record existieren und trotzdem defekt sein kann.

Ursache 1: Eine DNS-Migration hat Records verloren oder verstümmelt#

Der Wechsel zu einem neuen DNS-Host, einem neuen Registrar oder einer neuen Website-Plattform ist der mit Abstand häufigste Auslöser. Das Importtool kopiert, was es versteht, meist A-, CNAME- und MX-Records, und überspringt oder verändert TXT-Records stillschweigend. Die Symptome sind eine Domain ohne SPF, ohne DMARC oder mit einem DKIM-Selektor, der nicht mehr auflöst, alles ab dem Migrationsdatum.

Prüfen Sie nach jedem Umzug drei Dinge: ob die Nameserver wirklich dorthin zeigen, wohin Sie denken, ob jeder Authentifizierungs-Record auf dem neuen Host existiert und ob lange TXT-Werte unversehrt angekommen sind. Lange DKIM-Schlüssel sind das übliche Opfer: Manche Hosts kürzen sie oder fügen verirrte Leerzeichen ein, und ein abgeschnittener Schlüssel scheitert bei der Verifizierung, obwohl der Record „existiert“ (warum lange Schlüssel aufgeteilt werden müssen). Die anbieterspezifischen Anleitungen für Cloudflare und Route 53 zeigen, wie die jeweilige Plattform damit umgeht, und E-Mail-Anbieter wechseln behandelt dieselbe Falle von der Mail-Seite.

Ursache 2: Zwei SPF-Records oder zwei DMARC-Records#

Eine Domain darf genau einen SPF-Record und genau einen DMARC-Record veröffentlichen. Das bricht unbemerkt, wenn die Einrichtungsseite eines neuen Tools sagt „fügen Sie diesen TXT-Record hinzu“ und jemand einen zweiten v=spf1-Eintrag anlegt, statt den ersten zu bearbeiten.

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  TXT  "v=spf1 include:sendgrid.net ~all"

Bei zwei solchen Records liefern Empfänger für SPF einen permanenten Fehler, sodass SPF für jede Nachricht fehlschlägt, auch für E-Mails der aufgelisteten Tools. Die Lösung ist, sie zu einem einzigen Record zusammenzuführen, mit beiden Includes vor ~all. Dieselbe Regel gilt bei _dmarc: Zwei DMARC-Records bedeuten, dass Empfänger beide ignorieren. Behalten Sie beim Zusammenführen das Abfragebudget im Auge, denn jedes zusätzliche include: kostet DNS-Abfragen, und das Limit liegt bei 10. SPF: zu viele DNS-Abfragen erklärt das Zählen.

Ursache 3: Ein DKIM-Schlüssel wurde rotiert, verschoben oder entfernt#

DKIM signiert jede Nachricht mit einem privaten Schlüssel und veröffentlicht die öffentliche Hälfte unter selector._domainkey.yourdomain.com. Verschwindet der DNS-Record, während der Absender weiter mit diesem Selektor signiert, scheitert jede Nachricht bei DKIM.

Das passiert auf mehreren Wegen. Ein Anbieter rotiert zu einem neuen Selektor, und Sie räumen den alten Record zu früh auf. Jemand löscht beim DNS-Aufräumen „ungenutzte“ _domainkey-Einträge. Ein CNAME, der auf einen vom Anbieter gehosteten Schlüssel zeigt, löst nicht mehr auf, weil der Anbieter ihn geändert hat oder Sie den Dienst verlassen haben. Oder der Schlüssel wurde widerrufen, was als leerer p=-Wert veröffentlicht wird.

Der Test ist einfach: Nehmen Sie den Selektor aus header.s der fehlgeschlagenen Nachricht, fragen Sie selector._domainkey.yourdomain.com ab und bestätigen Sie, dass es einen p=-Wert mit echten Schlüsseldaten gibt. Stimmt der Selektor nicht, weil der Absender zu einem neuen gewechselt ist, veröffentlichen Sie den neuen Record, den der Anbieter Ihnen nennt. Eine saubere Rotation lässt alten und neuen Schlüssel überlappen, was die Selektor-Anleitung beschreibt.

Ursache 4: Ein neuer Absender hat begonnen, als Ihre Domain zu senden#

Manchmal sind Ihre Records in Ordnung, und der Absender hat sich geändert. Ein Team aktiviert ein CRM, einen Helpdesk, ein Rechnungstool oder eine Newsletter-Plattform, und jedes beginnt, mit Ihrer Domain in der From-Adresse zu senden. Hat niemand diesen Dienst in SPF aufgenommen und seinen DKIM-Schlüssel eingerichtet, scheitern seine E-Mails am SPF-Alignment, bestehen möglicherweise gar nichts und erscheinen als Fehlschläge in DMARC-Berichten.

Das erkennen Sie nicht, indem Sie das DNS ansehen, denn das DNS ist unverändert. Sie erkennen es, indem Sie ansehen, wer tatsächlich sendet. Dafür sind DMARC-Aggregatberichte da: Eine neue Quelle mit niedriger Erfolgsquote ist das Erkennungsmerkmal. Für jede solche Quelle authentifizieren Sie sie entweder richtig (Include in SPF, wo angebracht, und vor allem DKIM-Signierung mit Ihrer eigenen Domain) oder unterbinden, dass sie als Sie sendet.

Ursache 5: Ein abgelaufener oder geänderter unterstützender Record#

Einige Fehler liegen neben der Authentifizierung statt in ihr.

• Ein CNAME-Ziel hat sich geändert. Viele Anbieter bitten Sie, einen Record auf ihren Hostnamen zu richten. Stellen sie ihn ein oder löschen Sie den CNAME, löst der Schlüssel oder die Return-Path-Domain nicht mehr auf.
• Ein MX-Host hat seine Adresse verloren. E-Mails an Ihre Domain beginnen zu bouncen, obwohl die ausgehende Authentifizierung perfekt ist, weil der im MX genannte Host weder einen A- noch einen AAAA-Record hat.
• MTA-STS-Richtlinie und DNS laufen auseinander. Der _mta-sts-TXT-Record ist noch da, aber die HTTPS-Richtliniendatei nennt Ihre aktuellen MX-Hosts nicht mehr, oder das Zertifikat eines Mailservers ist abgelaufen. Absender mit einer Richtlinie im Enforce-Modus stellen dann zurück oder verweigern die E-Mail, während Absender ohne zwischengespeicherte Richtlinie einfach auf unverschlüsselte Zustellung zurückfallen, der Schaden ist also lückenhaft. Siehe MTA-STS und TLS-RPT.
• DMARC wurde verschärft. Jemand ist von p=none auf quarantine oder reject gewechselt. Fehler, die schon immer da waren, etwa ein nicht authentifiziertes Tool oder weitergeleitete E-Mails, kosten nun Zustellung. Der Fehler war nicht neu. Neu waren die Folgen.

Den nächsten Rückschritt früh erkennen#

Das meiste davon lässt sich allein aus dem DNS erkennen, vor dem ersten Bounce, weil der gebrochene Zustand ein fehlender oder fehlerhafter Record ist. Die Ausnahme ist alles, was hinter dem DNS-Record liegt, etwa eine MTA-STS-Richtliniendatei. Prüfen Sie in dieser Reihenfolge der Dringlichkeit:

1. MX ist vorhanden und jeder Host löst auf.
2. Genau ein SPF-Record, gültige Syntax, höchstens 10 Abfragen.
3. Jeder DKIM-Selektor, auf den Sie sich verlassen, liefert einen Schlüssel mit einem p=-Wert.
4. Genau ein DMARC-Record mit gültiger Richtlinie und einer rua=-Adresse.

Das können Sie nach jeder DNS-Änderung von Hand ausführen, und Sie sollten es tun. Die Schwäche einer manuellen Prüfung ist, dass der Rückschritt, der Sie interessiert, dann passiert, wenn niemand hinsieht. Die Domain-Zustand-Überwachung wiederholt diese Prüfungen einmal täglich für jede abgedeckte Domain und benachrichtigt Sie per E-Mail, wenn ein Problem auftritt und erneut, wenn es verschwindet. Die Issue-Codes entsprechen dieser Liste: fehlender oder mehrfacher SPF, SPF über dem Abfragelimit, ein SPF-Include ohne veröffentlichten Record, ein konfigurierter DKIM-Selektor ohne Schlüssel oder mit widerrufenem Schlüssel, fehlendes oder ungültiges DMARC und MX-Probleme. Ein Übersichtsartikel, E-Mail-Domain-Zustand überwachen, erklärt das größere Bild und wie oft Sie prüfen sollten.

Zwei Details sind gut zu wissen. Sie geben an, welche DKIM-Selektoren überwacht werden sollen, denn ein fehlender Selektor lässt sich nur für einen von Ihnen genannten melden. Und ein DNS-Timeout führt zu „konnte nicht geprüft werden“ und nicht zu einem Alarm, sodass ein unzuverlässiger Resolver Sie nicht aus dem Schlaf reißt.

Was die Überwachung nicht erkennt#

DNS-Überwachung liest nur öffentliches DNS. Sie kann nicht wissen, dass ein neues CRM in Ihrem Namen zu senden begonnen hat, dass einem gültigen SPF-Record ein Absender fehlt oder dass ein Anbieter einen Schlüssel rotiert hat, den Sie ihr nie genannt haben. DMARC-Aggregatberichte zeigen, wer wirklich in Ihrem Namen sendet, und der E-Mail-Zustellbarkeitstest zeigt, wie sich eine echte Nachricht authentifiziert. Die vollständige Liste der Grenzen steht im Leitfaden zur Domain-Zustand-Überwachung.

Funktionierende Authentifizierung beweist, dass Ihre E-Mails von Ihnen stammen, nicht dass Ihre Liste den Versand wert ist. Wenn Sie die Liste selbst ansehen wollen, bietet der kostenlose Tarif auf der Preisseite 100 Credits, die die vollständige Verifizierung durchführen. Korrekte Records brauchen weiterhin eine gesunde Liste dahinter.