SPF-, DKIM- & DMARC-Prüfer

SPF, DKIM und DMARC sind die drei DNS-Einträge, die darüber entscheiden, ob Post, die angeblich von Ihrer Domain stammt, vertraut oder verworfen wird. Sie wirken als Satz: SPF legt fest, welche Server für die Domain senden dürfen, DKIM signiert die Nachricht kryptografisch, sodass sie unterwegs nicht verändert werden kann, und DMARC verknüpft beide mit der sichtbaren Absenderadresse und sagt Empfängern, was bei einer fehlgeschlagenen Prüfung zu tun ist. Fehlt einer, leisten die anderen beiden weniger als gedacht: Fälscher schlüpfen durch die Lücke, und legitime Post landet im Spam.

Dieser Prüfer fragt alle drei gleichzeitig von unseren Servern ab und meldet das Ergebnis in klarer Sprache zurück. Er wertet Ihren SPF-Eintrag aus und zählt die dadurch ausgelösten DNS-Lookups gegen die harte Grenze von zehn, liest Ihren öffentlichen DKIM-Schlüssel und schätzt dessen Bitlänge, und bewertet Ihre DMARC-Richtlinie von reiner Beobachtung bis zur vollständigen Zurückweisung. Eine Domain hinein, drei Urteile heraus. Ohne Anmeldung, und nichts über Ihre Domain wird gespeichert.

SPF: welche Server für Ihre Domain senden dürfen

Ein SPF-Eintrag ist ein einzelner TXT-Eintrag auf Ihrer Domain, der mit v=spf1 beginnt und die Hosts auflistet, die als Sie Mail senden dürfen. Jeder Term benennt Quellen entweder direkt (ip4:, ip6:) oder verweist woandershin (include:_spf.google.com zieht die Bereiche Ihres Anbieters herein, a und mx autorisieren Ihre eigenen A/MX-Hosts). Ein empfangender Server geht diese Liste durch und prüft, ob die verbindende IP abgedeckt ist. Der Eintrag endet mit einem all-Mechanismus, der alles noch nicht Zugeordnete auffängt, und der Qualifizierer an diesem all ist die gesamte Richtlinie in einem Zeichen.

Die Qualifizierer, vom strengsten zum schwächsten: -all (Hard Fail) weist Empfänger an, alles von einer nicht gelisteten Quelle abzulehnen; ~all (Soft Fail) sagt, behandle es als verdächtig, nimm es aber an, die pragmatische Wahl, solange Sie noch nicht sicher sind, dass Ihre Liste vollständig ist; ?all (neutral) äußert keine Meinung und bringt Ihnen nichts; und +all autorisiert ausdrücklich das gesamte Internet, als Sie zu senden, was fast immer eine Fehlkonfiguration ist und den Zweck des Eintrags aufhebt. Die meisten gut geführten Domains stehen auf ~all oder -all.

Der Haken, der mehr SPF-Einträge zerlegt als alles andere, ist die Grenze von zehn Lookups. Jeder Term include, a, mx, ptr, exists und redirect zwingt den Empfänger zu einem DNS-Lookup, und diese verschachteln sich: Ein include kann eigene includes enthalten. RFC 7208 begrenzt die Summe über die gesamte Kette auf zehn, und ein Überschreiten ist ein permerror, der den kompletten Eintrag stillschweigend scheitern lässt. Deshalb veröffentlichen große Versender "abgeflachte" Einträge, die IP-Bereiche direkt einsetzen statt includes zu verketten. Der Prüfer zählt Ihre tatsächliche, rekursive Lookup-Summe, damit Sie wissen, wie viel Spielraum bis zum Kippen bleibt.

DKIM: eine Signatur, die die Unverändertheit der Nachricht belegt

DKIM fügt jeder ausgehenden Nachricht eine kryptografische Signatur hinzu. Ihr Mailserver hält einen privaten Schlüssel und signiert jede Nachricht; der passende öffentliche Schlüssel wird im DNS veröffentlicht, und der Empfänger prüft damit, dass die signierten Teile der Nachricht nach dem Versand nicht verändert wurden. Eine gültige Signatur belegt zwei Dinge zugleich: Die Nachricht stammt tatsächlich von einem System mit Ihrem Schlüssel, und ihre Header und ihr Inhalt sind unversehrt angekommen.

Der öffentliche Schlüssel liegt an einem Selector: einem von Ihnen gewählten Label, das den Schlüssel im DNS in einen eigenen Namensraum stellt, veröffentlicht unter <selector>._domainkey.<domain>. Selectors gibt es, damit Sie mehrere Schlüssel gleichzeitig betreiben (einen je sendendem Dienst) und sie ohne Ausfall wechseln können: neuen Selector veröffentlichen, Signierung umstellen, dann den alten außer Dienst nehmen. Der Selector-Name ist nicht geheim, aber aus der Domain allein auch nicht ableitbar; Sie finden ihn in der DNS-Anleitung Ihres Mailanbieters (Google verwendet google, Microsoft 365 verwendet selector1/selector2, viele ESPs verwenden eigene) oder indem Sie den DKIM-Signature-Header einer bereits empfangenen Nachricht lesen, wo er als s=-Tag erscheint. Dieses Werkzeug kann auch eine Liste gängiger Selectors für Sie durchprobieren, wenn Sie ihn nicht kennen.

Die Schlüssellänge zählt. Ein RSA-Schlüssel mit 1024 Bit war der historische Standard und gilt heute als schwach: Er liegt in Reichweite eines entschlossenen Angreifers, und einige Anbieter stufen ihn inzwischen als nicht vertrauenswürdig ein. 2048 Bit ist die aktuelle Grundlinie und das, was Sie veröffentlichen sollten; manche Installationen nutzen ed25519-Schlüssel, die kurz, aber stark sind. Wechseln Sie Schlüssel unabhängig von der Länge regelmäßig, denn ein Schlüssel, der sich nie ändert, erholt sich nie von einem Leck. Der Prüfer liest Ihren veröffentlichten Schlüssel und schätzt seine Größe, damit Sie einen modernen 2048-Bit-Schlüssel auf einen Blick von einem alten 1024-Bit-Schlüssel unterscheiden.

DMARC: Ausrichtung, Richtlinie und Berichte

DMARC ist der Eintrag, durch den SPF und DKIM überhaupt erst zusammen etwas ergeben. Er liegt unter _dmarc.<domain> als TXT-Eintrag, beginnt mit v=DMARC1 und erfüllt drei Aufgaben: Er verlangt Ausrichtung, die Domain, die SPF oder DKIM bestanden hat, muss mit der sichtbaren Absenderdomain übereinstimmen, was die Lücke schließt, durch die eine Nachricht SPF für eine fremde Domain besteht und trotzdem Ihre fälscht; er erklärt eine Richtlinie, die Empfängern sagt, wie sie mit einer durchgefallenen Nachricht verfahren sollen; und er fordert Berichte an, damit Sie sehen, wer als Sie sendet.

Die Richtlinie ist der p=-Tag, und sie ist eine Leiter, die man erklimmt, kein Schalter, den man umlegt. p=none bedeutet reine Beobachtung: Empfänger stellen durchgefallene Post weiter zu, senden Ihnen aber Berichte, und genau dort sollte jede Einführung beginnen, damit Sie den Verkehr beobachten können, ohne etwas zu brechen. p=quarantine weist Empfänger an, durchgefallene Post als verdächtig zu behandeln und sie typischerweise in den Spam zu leiten. p=reject weist sie an, sie rundheraus abzulehnen, und ist der Endzustand, der Fälschungen tatsächlich unterbindet. Zwei weitere Tags steuern die Einführung: pct= wendet die Richtlinie nur auf einen Prozentsatz der Post an (eine Möglichkeit, reject ab 10% hochzufahren), und ein pct unter 100 bedeutet, dass die meiste durchgefallene Post weiterhin durchkommt.

Der rua=-Tag legt fest, wohin aggregierte Berichte gehen: tägliche XML-Zusammenfassungen von Empfängern, die jede Quelle auflisten, die als Ihre Domain sendet, welche bestehen oder durchfallen und auf welche Weise. Ohne rua setzen Sie eine Richtlinie blind durch; mit rua finden Sie jeden legitimen Absender, bevor Sie auf reject verschärfen, damit Sie nicht versehentlich Ihre eigenen Rechnungen oder Newsletter blockieren. Ein DMARC-Eintrag ohne Berichtsadresse ist der häufigste Grund, warum eine Einführung für immer bei p=none stehen bleibt.

Die drei in der richtigen Reihenfolge einführen

Die Reihenfolge zählt, weil jeder Eintrag auf den vorherigen aufbaut. Bringen Sie zuerst SPF und DKIM zum Bestehen und zur Ausrichtung, legen Sie dann DMARC im Beobachtungsmodus darüber, und verschärfen Sie danach. Direkt zu p=reject zu springen, bevor Sie bestätigt haben, dass jeder legitime Absender ausgerichtet ist, ist der Weg, die eigene Post zu blockieren.

Ein minimaler, korrekter Ausgangspunkt sieht aus wie die Einträge unten: ein SPF-Eintrag, der Ihren Anbieter autorisiert und den Rest weich durchfallen lässt, ein DKIM-Schlüssel am Selector Ihres Anbieters und ein DMARC-Eintrag im Beobachtungsmodus mit einer Berichtsadresse, damit Sie hinsehen können, bevor Sie durchsetzen.

• Veröffentlichen Sie zuerst SPF: Listen Sie jede sendende Quelle auf und schließen Sie mit ~all ab, z. B. v=spf1 include:_spf.google.com ~all. Prüfen Sie erneut, dass die Lookup-Anzahl unter zehn bleibt.
• Fügen Sie DKIM hinzu: Aktivieren Sie die Signierung bei Ihrem Mailanbieter und veröffentlichen Sie den öffentlichen Schlüssel am Selector, den er Ihnen nennt (z. B. google._domainkey.example.com). Bevorzugen Sie einen 2048-Bit-Schlüssel.
• Fügen Sie DMARC im Beobachtungsmodus hinzu: v=DMARC1; p=none; rua=mailto:reports@example.com. Sammeln Sie einige Wochen Berichte und bestätigen Sie, dass alle echten Absender bestehen.
• Verschärfen Sie schrittweise: p=none → p=quarantine → p=reject, optional mit pct= hochgefahren, erst wenn die Berichte zeigen, dass jede legitime Quelle ausgerichtet ist.