SPF, DKIM und DMARC

Was sind SPF, DKIM und DMARC?

SPF autorisiert sendende Hosts für bestimmte SMTP-Domainidentitäten, DKIM versieht ausgewählte Nachrichtenteile mit einer prüfbaren Domainsignatur und DMARC verlangt die Ausrichtung eines bestandenen SPF- oder DKIM-Ergebnisses auf die sichtbare From-Domain.

Technische Einordnung: Die drei Verfahren erfüllen unterschiedliche Aufgaben. SPF prüft den SMTP-Versandweg anhand einer im DNS veröffentlichten Richtlinie. DKIM ermöglicht die Überprüfung einer Domainsignatur mit einem über Signaturdomain und Selector auffindbaren öffentlichen Schlüssel. DMARC verbindet die Ergebnisse mit der im RFC5322.From-Feld sichtbaren Absenderdomain, einer veröffentlichten Behandlungspräferenz und Reporting-Anfragen.

Wie unterscheiden sich SPF, DKIM und DMARC?

SPF prüft, ob ein sendender Host eine Domain als HELO/EHLO- oder MAIL-FROM-Identität verwenden darf. DKIM prüft die Signatur ausgewählter Header und Nachrichtenbestandteile; es verschlüsselt die E-Mail nicht. DMARC bewertet, ob mindestens eine bestandene Authentifizierung zur sichtbaren From-Domain ausgerichtet ist. Für den SPF-Anteil von DMARC zählt ausschließlich die MAIL-FROM-Domain.

Wann ist DMARC anwendbar und wann besteht eine Nachricht die Prüfung?

DMARC darf nur angewandt werden, wenn für die betreffende Domain ein gültiger Policy Record gefunden wird. Ein DMARC-Pass setzt mindestens einen bestandenen und zur Author Domain ausgerichteten Identifier voraus: entweder die SPF-validierte MAIL-FROM-Domain oder die Domain einer gültigen DKIM-Signatur. Fehlt ein anwendbarer Policy Record, endet die DMARC-Auswertung als nicht anwendbar.

Was bedeutet Alignment bei DMARC?

Alignment vergleicht die durch SPF oder DKIM authentifizierte Domain mit der sichtbaren From-Domain. Beim Relaxed Alignment müssen beide dieselbe Organizational Domain haben; beim Strict Alignment müssen die Domains identisch sein. Ein isolierter SPF- oder DKIM-Pass ohne dieses Alignment ist kein DMARC-Pass.

Muss ein Empfänger die veröffentlichte DMARC-Präferenz befolgen?

Nein. Die DMARC-Policy ist eine veröffentlichte Behandlungspräferenz des Domaininhabers. Der empfangende Maildienst trifft die endgültige lokale Zustellentscheidung und darf von der Präferenz abweichen, etwa wegen Erkenntnissen über komplexe Mailflüsse. Anforderungen einzelner Empfangsdienste sind gesondert zu beurteilen und gelten nicht automatisch für den gesamten E-Mail-Verkehr.

Welche Grenzen haben SPF, DKIM und DMARC?

Die Verfahren authentifizieren Domains, nicht Personen, Nachrichteninhalte oder die allgemeine Vertrauenswürdigkeit eines Absenders. DMARC erfasst bestimmte Formen des Spoofings der exakten Domain, aber keine ähnlich aussehenden Domains und keine reine Täuschung über den Anzeigenamen. Weiterleitungen können SPF scheitern lassen; Änderungen an signierten Bestandteilen können DKIM ungültig machen. Auch ein kompromittierter oder zu weit autorisierter legitimer Versandweg kann eine Authentifizierungsprüfung bestehen.

Für Domains mit p=reject darf ein DMARC-Pass nicht ausschließlich auf SPF gestützt werden; sie müssen gültige DKIM-Signaturen einsetzen. Auswirkungen auf Weiterleitungen und Mailinglisten sind deshalb vor einer Verschärfung zu prüfen.

Gibt es allgemeine Fristen oder Schwellenwerte?

Nein. Die technischen Spezifikationen setzen weder eine allgemeine Einführungsfrist noch eine allgemeine Versandmengenschwelle. Reporting-Intervalle sind Konfigurationswerte und keine Compliance-Fristen. Das aus der früheren DMARC-Spezifikation bekannte Tag pct wurde in RFC 9989 entfernt und darf nicht als Grundlage für einen stufenweisen Rollout dargestellt werden.

Häufige Fehlannahmen

• „Ein SPF-Pass reicht für DMARC.“ Nur eine bestandene Prüfung mit Alignment zur sichtbaren From-Domain kann zu einem DMARC-Pass beitragen; DMARC berücksichtigt bei SPF ausschließlich MAIL FROM.
• „DKIM verschlüsselt die Nachricht.“ DKIM stellt eine überprüfbare Domainsignatur für ausgewählte Bestandteile bereit, aber keine Inhaltsverschlüsselung.
• „DMARC verhindert jede Absendertäuschung.“ Ähnlich aussehende Domains, Display-Name-Angriffe und der Missbrauch legitim autorisierter Systeme bleiben möglich.
• „Eine Reject-Policy erzwingt bei jedem Empfänger eine Ablehnung.“ Die veröffentlichte Policy ist eine Präferenz; der Empfänger bestimmt die tatsächliche Behandlung nach seiner lokalen Policy.
• „Das DMARC-Tag pct ermöglicht weiterhin den stufenweisen Rollout.“ RFC 9989 hat dieses Tag entfernt. Eine schrittweise Einführung muss organisatorisch und über Policy- sowie Versandstromkontrollen gestaltet werden.

Was die Geschäftsleitung tun sollte

Praxisempfehlung: Die folgenden Maßnahmen sind eine risikobasierte technische Empfehlung und keine aus den RFCs abgeleitete allgemeine Leitungspflicht.

1. Verantwortlichkeiten für E-Mail-Domains, DNS, Versanddienste und die laufende Authentifizierungsprüfung festlegen.
2. Alle legitimen internen und externen Versandquellen sowie verwendeten Absenderdomains inventarisieren.
3. SPF und DKIM so konfigurieren, dass die für DMARC benötigten Identifier zur sichtbaren From-Domain ausgerichtet sind.
4. DMARC zunächst im Monitoring-Modus mit Aggregate Reporting betreiben, Berichte auswerten und unbekannte oder nicht ausgerichtete Mailströme bereinigen.
5. Eine Verschärfung der Policy risikobasiert entscheiden und zuvor Auswirkungen auf Drittversender, Weiterleitungen und Mailinglisten prüfen.
6. Bei p=reject gültige DKIM-Signaturen sicherstellen und den DMARC-Pass nicht ausschließlich auf SPF stützen.

Für die Geschäftsleitung

SPF, DKIM und DMARC bilden gemeinsam eine technische Kontrollkette für die Nutzung eigener E-Mail-Domains, beseitigen aber nicht jede Form von Phishing oder Absendermissbrauch. Entscheidend sind ein vollständiges Versandquelleninventar, korrektes Alignment und eine kontrollierte Policy-Entscheidung. Als Nachweis eignen sich dokumentierte Zuständigkeiten, freigegebene DNS-Konfigurationen, DKIM-Schlüsselprozesse, ausgewertete Aggregate Reports sowie protokollierte Tests vor jeder Verschärfung.

Quellen

• RFC 7208 – Sender Policy Framework (SPF), insbesondere Abschnitte 1 und 2.1–2.4
• RFC 6376 – DomainKeys Identified Mail (DKIM), insbesondere Abschnitte 1, 1.5 und 6.1
• RFC 9989 – Domain-based Message Authentication, Reporting, and Conformance (DMARC), insbesondere Abschnitte 4.3–4.5, 4.10, 5.1, 5.3.2–5.3.6 und 7.3–7.4 sowie Anhänge A.6 und C.5.2