SPF, DKIM und DMARC: Prüfungen, Richtlinien und Grenzen

Die sichtbare Absenderadresse einer E-Mail lässt sich fälschen. SPF, DKIM und DMARC helfen beim Prüfen der verwendeten Domains. Eine erfolgreiche Prüfung beweist jedoch weder einen ungefährlichen Inhalt noch die Identität einer bestimmten Person.

SPF prüft die Versandberechtigung einer IP-Adresse, DKIM eine digitale Signatur und DMARC zusätzlich die Zuordnung zur sichtbaren Absenderdomain. Über Annahme, Spamordner oder Ablehnung entscheidet das empfangende System. Auch ohne DMARC kann beispielsweise ein SPF-Fail zur Ablehnung führen.

SPF: Passt die sendende IP-Adresse zur Umschlagdomain?

Beim SMTP-Versand gibt es eine technische Umschlagadresse (MAIL FROM) und die sichtbare Absenderzeile (From). SPF prüft normalerweise die Domain der Umschlagadresse; bei leerem Umschlagabsender dient die HELO-Domain als Grundlage. Ein SPF-Pass allein bestätigt deshalb nicht die sichtbare From-Domain.

Der DNS-Eintrag beschreibt erlaubte Versandquellen. -all erzeugt für ansonsten nicht passende Quellen ein Fail, ~all ein Softfail. Ein Fail bedeutet fehlende Autorisierung nach dieser SPF-Regel, keinen sicheren Fälschungsnachweis: Auch eine legitime Weiterleitung kann SPF scheitern lassen. Neben Pass und Fail existieren unter anderem Neutral, None sowie temporäre und dauerhafte Fehler.

Die Zehnergrenze zählt ausgewertete SPF-Terme

Die Grenze betrifft insgesamt höchstens zehn ausgewertete DNS-auslösende Terme: include, a, mx, ptr, exists und redirect, einschließlich verschachtelter Auswertungen. Das ist keine allgemeine Grenze von zehn DNS-Paketen. Für bestimmte Abfragen gelten zusätzliche Begrenzungen.

ip4, ip6 und all verbrauchen dieses Budget nicht. Ein früher Treffer beendet die Auswertung; spätere Verweise zählen dann nicht mit. Ein Überschreiten liefert für die konkrete Auswertung permerror. Änderungen bei eingebundenen Versanddiensten können diesen Fehler auslösen, machen aber nicht automatisch jeden möglichen Auswertungspfad ungültig.

DKIM: Signierte Bestandteile statt vollständiger Unveränderlichkeit

Das Versandsystem signiert mit einem privaten Schlüssel. Der Empfänger prüft mit dem öffentlichen DNS-Schlüssel. Geschützt sind die signierten Header und der erfasste Nachrichtentext nach festgelegter Normalisierung. Je nach Regel dürfen dabei bestimmte Formatunterschiede, etwa bei Leerzeichen, unberücksichtigt bleiben; eine Signatur kann auch nur einen Teil des Nachrichtentextes erfassen. DKIM-Pass bedeutet daher nicht, dass jedes Zeichen der gesamten Nachricht unverändert blieb.

Bei RSA verlangt RFC 8301 mindestens 1024 Bit und empfiehlt mindestens 2048 Bit. Ein 1024-Bit-Schlüssel ist nach dieser Norm nicht automatisch ungültig, für neue RSA-Konfigurationen sind 2048 Bit die bessere Vorgabe. Ed25519 verwendet andere Schlüssellängen; ein direkter Zahlenvergleich mit RSA wäre irreführend.

Lange Schlüssel passen in einen TXT-Record aus mehreren Zeichenfolgen mit jeweils höchstens 255 Bytes. Mehrere Zeichenfolgen innerhalb desselben Records sind nicht mehrere getrennte TXT-Records. Die DNS-Oberfläche des Anbieters kann diese Aufteilung übernehmen.

Der richtige Selektor steht als s= in einer tatsächlichen DKIM-Signature; d= nennt die Signaturdomain. Daraus entsteht der DNS-Name selektor._domainkey.domain. Das Durchprobieren verbreiteter Selektoren ersetzt diese Prüfung nicht. Kein Treffer bedeutet lediglich: unter den geprüften Namen kein Schlüssel gefunden.

DMARC: Zur sichtbaren From-Domain passende Authentifizierung

DMARC besteht, sobald mindestens eine erfolgreiche SPF- oder DKIM-Prüfung zur sichtbaren From-Domain passt. Diese Zuordnung heißt Alignment. Im strengen Modus müssen die Domains identisch sein; im gelockerten Modus zählt dieselbe organisatorische Domain nach den Regeln der DMARC-Domainermittlung. Zwei beliebige Domains mit ähnlichem Namen reichen nicht.

• p=none: keine besondere Behandlung aufgrund der veröffentlichten DMARC-Policy angefordert.
• p=quarantine: fehlgeschlagene DMARC-Prüfungen sollen als verdächtig behandelt werden.
• p=reject: Ablehnung solcher Nachrichten angefordert.

Keine dieser Einstellungen garantiert Zustellung oder Ablehnung. Lokale Filter bleiben maßgeblich. Für angeforderte Sammelberichte braucht der Record ein geeignetes rua-Ziel; p=none allein richtet keinen Berichtsempfang ein. Auch mit Zieladresse sind Berichte nicht von jedem Empfänger garantiert.

Ein sinnvoller Rollout beginnt mit einem vollständigen Verzeichnis der Versanddienste und repräsentativen Tests und Berichten. Monatsrechnungen und seltene Versandwege gehören dazu. Danach folgt eine passende strengere Policy; eine feste Anzahl Wochen oder ein zwingender Zwischenschritt über Quarantine lässt sich daraus nicht ableiten.

Was eine DNS-Prüfung tatsächlich zeigt

Der E-Mail-Authentifizierungs-Prüfer liefert eine Bestandsaufnahme von DNS-Einträgen. Der derzeitige SPF-Zähler durchläuft Verweise statisch und simuliert keine konkrete Nachricht mit sendender IP. MX-Einträge belegen keine SMTP-Erreichbarkeit. Bei Subdomains kann eine übergeordnete DMARC-Policy gelten; eine fehlende direkte Fundstelle beweist deshalb keine fehlende Policy.

Für einen belastbaren Versandtest sind zusätzlich Nachrichten aus jedem legitimen Versandsystem und die Authentifizierungsergebnisse am vertrauenswürdigen Empfangssystem nötig. Eine DNS-Momentaufnahme kann nicht vorhersagen, ob jede gefälschte Nachricht abgewiesen wird.