E-Mail-Zustellbarkeitsprüfung
Vor der Reputation, vor dem Inhalt stellen Empfänger eine einzige Frage: Kann diese Domain beweisen, dass die Mail wirklich von ihr stammt? Diese Prüfung liest den Beweis — MX-Einträge, die SPF-Absenderliste (erweitert und so gezählt, wie ein Empfänger zählt), die DMARC-Richtlinie unter _dmarc und DKIM-Schlüssel unter den üblichen Selektoren — und liefert Befunde in einfacher Sprache, geordnet so, wie ein Betreiber sie beheben würde.
Lieber laufend überwachen lassen? Kostenlos mit myeventwatch überwachen — Ablauf- und Ausfallwarnungen, keine Karte nötig.
Was die Prüfung misst
Spamfilterung beginnt bei der Identität, weil sich Identität in Millisekunden prüfen lässt. Wenn Mail eintrifft, die vorgibt, von einer Domain zu stammen, schlägt der empfangende Server die veröffentlichten Regeln dieser Domain nach. SPF benennt die Server, die senden dürfen. DKIM bietet eine Signatur, die gegen einen veröffentlichten Schlüssel geprüft werden kann. DMARC verlangt, dass die sichtbare From-Domain mit einem dieser beiden Beweise übereinstimmt, und legt die Strafe — keine, Quarantäne, Ablehnung — für Mail fest, die keinen von beiden hat. Die Seite ruft GET /api/check/email-auth auf dem Server von sysosx auf, der dieselben Einträge über die DNS-Parser liest, die der Gesundheitscheck nutzt, und sie in Befunde übersetzt: jedes Protokoll, jedes Problem, ein Schweregrad, in der Reihenfolge, in der sie sich beheben lassen.
Zwei der Befunde verdienen ein Wort zur Ehrlichkeit, weil beides Stellen sind, an denen Prüfer gern Präzision vortäuschen. Die SPF-Lookup-Zählung ist echt: Der Prüfer erweitert include- und redirect-Ketten Glied für Glied nach denselben Regeln, die ein Empfänger anwendet, sodass die gemeldete Zahl die ist, die ein strenger Empfänger berechnen würde — auch dann, wenn der Eintrag still über das Limit von zehn Lookups gedriftet ist, während Anbieter ihre eigenen Einträge geändert haben. Und das DKIM-Ergebnis ist eine Sondierung, keine Volkszählung: Schlüssel werden unter Selektornamen veröffentlicht, die der Besitzer wählt, die Prüfung versucht die üblichen, und keinen davon zu finden beweist nicht, dass DKIM fehlt — ein Schlüssel unter einem anderen Selektor ist von außen unsichtbar, und das Ergebnis sagt das unmissverständlich, statt eine Domain als unsigniert zu erklären. Der einzige vollständige DKIM-Test bleibt eine echte Nachricht und ihr Authentication-Results-Header.
So lesen Sie ein Ergebnis
Beginnen Sie mit den Fehlern; sie sind die Lieblingsursachen des Spamordners. Kein MX heißt, die Domain kann überhaupt keine Mail empfangen. Kein SPF, oder ein SPF-Eintrag, der auf +all endet, heißt, jeder kann behaupten, Sie zu sein — das zweite ist schlimmer, weil die Behauptung offiziell erlaubt ist. Mehrere SPF-Einträge machen die SPF-Auswertung still komplett ungültig. Ein fehlender DMARC-Eintrag heißt, fehlschlagende Mail hat keine festgelegte Strafe und — genauso teuer — niemand sammelt die Aggregatberichte, die zeigen, wer als Ihre Domain sendet — diese Berichte sind es, durch die Spoofing-Kampagnen meist entdeckt werden. Wenn die Berichte ankommen, dann als rohes XML; der DMARC-Berichtsanalysator öffnet die .xml-, .gz- und .zip-Dateien lokal und verwandelt sie in eine Tabelle nach Quelle, wer bestanden hat, wer durchgefallen ist und was zu beheben ist. Warnungen sind der Zwischenzustand: p=none ist ein guter Ort, um DMARC zu beginnen, und ein schlechter, um stehen zu bleiben; ~all ist Testmodus, kein Ziel. Nehmen Sie dann die zweite Hälfte des Bildes: Authentifizierung beweist Identität, während der DNS-Blacklist-Prüfer die Reputation misst — führen Sie beides aus, denn eine perfekt authentifizierte Domain auf einer gelisteten IP landet trotzdem im Spam, und eine saubere IP mit kaputtem SPF auch. Der Leitfaden, der alles verbindet, ist warum Ihre E-Mail im Spam landet.
Häufige Fragen
Was sind SPF, DKIM und DMARC, und wie greifen sie ineinander?
Sie sind drei in DNS veröffentlichte Antworten auf die Frage „Stammt diese Mail wirklich von der Domain, die sie vorgibt?“. SPF listet die Server, die für eine Domain senden dürfen. DKIM lässt eine Domain Nachrichten kryptografisch signieren, sodass ein Empfänger die Signatur gegen einen in DNS veröffentlichten Schlüssel prüfen kann. DMARC verbindet sie: Es verlangt, dass die Absenderdomain im sichtbaren From-Header mit dem SPF- oder DKIM-Ergebnis übereinstimmt, und sagt Empfängern, was zu tun ist — überwachen, in Quarantäne stecken oder ablehnen —, wenn keines von beiden übereinstimmt. SPF ohne DMARC ist ein unsignierter Vorschlag; DMARC ist das, was aus den anderen beiden eine Richtlinie macht.
Meine Mail landet trotzdem im Spam, obwohl alle drei bestehen. Warum?
Weil Authentifizierung die Eintrittskarte ist, nicht der Sitzplan. SPF, DKIM und DMARC zu bestehen heißt, Empfänger glauben, die Mail ist wirklich Ihre — danach hängt die Platzierung von Reputation und Inhalt ab: Blacklist-Einträge (prüfen Sie sie mit dem Blacklist-Prüfer auf dieser Site), Empfängerinteraktion, Beschwerdequoten, Sendemengenmuster und die Nachricht selbst. Authentifizierungsfehler sind die häufigste behebbare Ursache für Spam-Platzierung, deshalb kommt diese Prüfung zuerst, aber ein sauberes Ergebnis hier plus anhaltende Spam-Platzierung heißt, das Problem liegt in Reputation oder Inhalt, nicht in der Identität.
Die Prüfung sagt, es wurde kein DKIM-Schlüssel gefunden. Heißt das, meine Domain signiert nicht?
Nein — und das Ergebnis sagt das ausdrücklich. DKIM-Schlüssel liegen unter Selektornamen, die der Domainbesitzer wählt, und es gibt keine Möglichkeit, die Selektoren einer Domain von außen aufzuzählen. Diese Prüfung sondiert die üblichen Selektoren großer Anbieter (default, google, selector1, selector2, mail, dkim, s1, s2, k1, mandrill und einige mehr). Ein Schlüssel unter einem anderen Namen ist für die Sondierung unsichtbar. Der endgültige Test ist eine echte Nachricht: Senden Sie Mail an ein Postfach, das Sie kontrollieren, und prüfen Sie den Authentication-Results-Header, der den verwendeten Selektor und, ob die Signatur verifiziert wurde, meldet.
Warum zählt die Prüfung SPF-Lookups, und warum ist 10 das Limit?
Die Auswertung eines SPF-Eintrags kann weitere DNS-Lookups erfordern — jedes include-, a-, mx-, ptr-, exists- und redirect-Glied kostet einen. RFC 7208 begrenzt die Gesamtzahl auf 10; darüber geben Empfänger einen permanenten Fehler zurück und das SPF-Ergebnis ist ungültig, was schlimmer sein kann als ein bescheidener Eintrag, der sauber ausgewertet wird. Einträge sammeln Lookups still an, wenn Anbieter hinzukommen (jedes include bringt seine eigenen Glieder mit), sodass ein Eintrag, der bei der Einrichtung legal war, über das Limit driften kann, während Anbieter ihre Einträge ändern. Diese Prüfung erweitert den Eintrag so, wie es ein Empfänger täte, und meldet die echte Zahl, sodass die Drift sichtbar wird, bevor sie Ihre Authentifizierung ungültig macht.
Was soll ich zuerst beheben, wenn mehrere Befunde Fehler sind?
In dieser Reihenfolge: mehrere SPF-Einträge (zu einem zusammenführen — alles Nachgelagerte ist unzuverlässig, bis das behoben ist), ein fehlender oder +all-SPF-Eintrag (die echte Absenderliste veröffentlichen, beendet mit -all), ein fehlender DMARC-Eintrag (mit p=none und einer Berichtsadresse beginnen, damit Sie sehen, wer als Sie sendet, bevor Sie durchsetzen), dann DMARC von p=none in Richtung p=reject anheben, während die Berichte sauber hereinkommen. Blacklist-Einträge, falls vorhanden, sind parallele Arbeit — beheben Sie ihre Ursache und beantragen Sie die Streichung, während die Einträge repariert werden. Unser Leitfaden geht die Reihenfolge mit Begründung durch: warum Ihre E-Mail im Spam landet.