Das E-Mail-Sicherheitsaudit 2026: SPF, DKIM und DMARC ohne Scheinkonformität

Was SPF, DKIM und DMARC tatsächlich schützen

Diese Mechanismen authentifizieren Domänen und deren Verwendung in einer Nachricht. Sie bestätigen weder die Identität eines Menschen noch die Wahrheit des Inhalts oder die Sicherheit eines Links. DMARC begrenzt vor allem das Vortäuschen mit der exakten Domäne im Feld From:. Es blockiert weder optisch ähnliche Domänen noch den Missbrauch des Anzeigenamens, ein übernommenes Postfach oder eine legitim authentifizierte Phishing-Kampagne.

RFC 9989 sagt ausdrücklich, dass ein positives DMARC-Ergebnis nicht bedeutet, eine Nachricht sei sicher oder erwünscht. Der Empfänger nutzt weiterhin Reputation, Inhaltsanalyse, Verhaltenssignale und die eigene Richtlinie. ^[1] Untersuchungen zum SMTP-Smuggling zeigen zudem, dass uneinheitliches Parsen des Protokolls durch aufeinanderfolgende Server die Authentifizierung trotz korrekter DNS-Einträge untergraben kann. ^[12]

Ein vollständiges Audit trennt daher vier Ebenen:

• Domänenidentität: SPF, DKIM, DMARC, Delegation des Versands und Berichtswesen;
• Transport zwischen Servern: SMTP TLS, MTA-STS, TLS-RPT oder DANE;
• Sicherheit von Postfächern und Plattform: MFA, Altprotokolle, Weiterleitungsregeln, OAuth-Anwendungen, Administrationsrollen und Ereignisprotokollierung;
• Schutz des Empfängers: Inhaltsfilterung, Blockieren von Anzeigenamen-Vortäuschung, Analyse von Links und Anhängen, Meldung von Phishing und Reaktion auf Vorfälle.

SPF: Autorisierung eines Servers, nicht des sichtbaren Absenders

Sender Policy Framework (SPF) erlaubt dem Domäneninhaber festzulegen, welche IP-Adressen diese Domäne in der SMTP-Identität MAIL FROM oder HELO/EHLO verwenden dürfen. Der Eintrag wird als TXT veröffentlicht. SPF prüft für sich genommen nicht die Domäne, die der Nutzer im Kopfzeilenfeld From: sieht; diese Lücke der Identifikatorbindung schließt DMARC. ^[3]

Ein SPF-Audit umfasst weit mehr als die Prüfung der Syntax:

• für die bewertete Domäne existiert genau ein SPF-Eintrag;
• jeder include-Mechanismus, jeder ip4/ip6-Bereich und jede Umleitung hat einen fachlichen Eigentümer;
• der Eintrag autorisiert nicht unnötig ganze gemeinsam genutzte Bereiche eines Anbieters;
• der abschließende Qualifikator entspricht der beabsichtigten Richtlinie und ist kein Rest einer Testeinführung;
• die rekursive Auswertung aller include-Mechanismen bleibt innerhalb der DNS-Grenzen;
• die Envelope-Domäne passt zur Autorendomäne überall dort, wo SPF ein positives DMARC-Ergebnis liefern soll;
• ein Wechsel der Anbieterbereiche hat keine verwaisten Autorisierungen hinterlassen.

RFC 7208 begrenzt die Gesamtzahl der Terme, die während der gesamten, auch rekursiven Auswertung DNS-Abfragen auslösen, auf zehn. Das betrifft include, a, mx, ptr, exists und redirect. Eine Überschreitung ergibt permerror; die empfohlene Grenze für leere DNS-Antworten liegt bei zwei. ^[3]

Ein "Abflachen" von SPF zu einer Liste von IP-Adressen kann die Zahl der Abfragen senken, erzeugt aber eine Kopie der Anbieterdaten, die ständig abgeglichen werden muss. Ein Audit sollte den Aktualisierungsmechanismus, die Überwachung von Abweichungen und die Möglichkeit prüfen, eine fehlerhafte Änderung rasch zurückzunehmen. Die einmalige Korrektheit des Eintrags genügt nicht. Eine Studie auf Grundlage wöchentlicher Momentaufnahmen über 17 Monate für 176 Millionen Domänen aus vier Top-Level-Domänen zeigt das deutlich: rein syntaktische Fehler betrafen 0,4 Prozent der Einträge, Probleme, die erst bei der Auswertung sichtbar werden, dagegen 7,7 Prozent - fast zwanzigmal so häufig ^[11]. Ein Syntaxprüfer übersieht also die meisten Fälle, in denen SPF seine Wirkung verliert. Diese Anteile beschreiben die in jener Messung untersuchte Domänenpopulation, nicht den Anteil am Postverkehr einer beliebigen Organisation.

DKIM: Signatur, Umfang und Schlüssellebenszyklus

DomainKeys Identified Mail (DKIM) signiert ausgewählte Kopfzeilen und einen Hash des Nachrichtentextes. Der Empfänger holt den öffentlichen Schlüssel aus einem TXT-Eintrag unter einem Namen aus Selektor und _domainkey und liest die signierende Domäne aus dem Parameter d=. Die Signatur kann eine Weiterleitung überstehen, sofern der Vermittler die signierten Elemente nicht verändert. ^[4]

RFC 8301 untersagt RSA-SHA1. Für RSA verlangt es einen Schlüssel von mindestens 1024 Bit und empfiehlt mindestens 2048. RFC 8463 ergänzt Ed25519-SHA256. ^[4] Nutzt eine Organisation Ed25519, sollte das Audit die Unterstützung bei den wichtigsten Empfängern bestätigen; aus Interoperabilitätsgründen kann eine parallele RSA-Signatur nötig sein.

Eine DKIM-Prüfung sollte umfassen:

• ob jedes versendende System mit einer eigenen, kontrollierten und zu From: passenden Domäne signiert;
• Algorithmus, Schlüssellänge, Schutz des privaten Schlüssels und die Verantwortung dafür;
• den Umfang der signierten Kopfzeilen, insbesondere From:, sowie die Kanonisierung;
• das Fehlen des unsicheren Längenparameters l=;
• eindeutige Selektoren je Anbieter und Umgebung statt eines gemeinsamen Schlüssels;
• das Verfahren für Rotation, Kompromittierung und Außerbetriebnahme eines Selektors;
• wie lange der alte Schlüssel veröffentlicht bleibt, abgeleitet aus realen Laufzeiten und Warteschlangen.

Keine allgemeine DKIM-Norm schreibt eine Rotation "alle sechs Monate" oder "jährlich" vor. Der Zeitplan sollte sich aus dem Bedrohungsmodell, den Möglichkeiten des Anbieters, dem Schutz des Schlüssels und dem Vorfallverfahren ergeben. Wichtiger als ein willkürlicher Kalender ist eine Rotation, die sich ohne Unterbrechung durchführen lässt, mit zwei Selektoren und der Bestätigung der neuen Signatur vor dem Entfernen des alten Eintrags.

DMARC nach RFC 9989

DMARC bewertet die Autorendomäne aus dem Feld RFC5322.From. Eine Nachricht besteht DMARC, wenn mindestens ein Mechanismus ein positives Ergebnis liefert und dessen Domäne zur Autorendomäne passt:

• SPF: positives Ergebnis für die Domäne MAIL FROM und Übereinstimmung dieser Domäne mit From:;
• DKIM: gültige Signatur und Übereinstimmung der Domäne d= mit From:.

Die Übereinstimmung kann locker sein, also auf Ebene derselben Organisationsdomäne, oder streng, also eine identische Domäne verlangen. Locker ist die Voreinstellung. Für p=reject sollte man sich nicht allein auf SPF stützen, denn eine übliche Weiterleitung ändert die IP-Adresse und häufig die Envelope-Domäne; der aktuelle Standard verlangt von einem vollwertigen DMARC-Teilnehmer gültige DKIM-Signaturen. ^[1]

Was sich 2026 änderte

• RFC 9989 hat den Status Proposed Standard und ersetzt das informative RFC 7489 sowie die PSD-Erweiterung aus RFC 9091.
• Die Richtliniensuche nutzt einen Aufstieg im DNS-Baum statt der bisherigen Abhängigkeit von der Public Suffix List.
• Die Richtlinie np kann nicht existierende Subdomänen betreffen.
• Der Parameter pct wurde entfernt und gilt als historisch. Das neue t=y signalisiert den Testbetrieb; es ist keine prozentuale Stichprobe.
• rf und ri wurden ebenfalls aus der Kernspezifikation entfernt.
• Das Format aggregierter Berichte legt RFC 9990 fest, das einzelner Fehlerberichte RFC 9991.

Im August 2026 ist dies eine frische Normänderung. Dokumentation und Implementierungen großer Anbieter können weiterhin pct aus RFC 7489 beschreiben. Ein Audit sollte daher Konformität mit dem Zielstandard und betriebliche Konformität mit konkreten Empfängern getrennt festhalten. Man sollte nicht annehmen, der neue Parameter werde bereits einheitlich unterstützt.

p=none, quarantine und reject

p=none dient der Beobachtung: Es verlangt keine geänderte Behandlung von Nachrichten, die DMARC nicht bestehen. p=quarantine bittet darum, sie als verdächtig zu behandeln, p=reject darum, sie abzuweisen. Das sind Erklärungen des Domäneninhabers, doch der Empfänger behält seine eigene Richtlinie und kann anders entscheiden.

Der Übergang zur Durchsetzung sollte erst nach Inventarisierung der Systeme, Korrektur der SPF- oder DKIM-Übereinstimmung, Tests von Weiterleitungen und Verteilerlisten sowie der Zuweisung von Eigentümern für Ausnahmen erfolgen. Das sichere Ergebnis ist nicht p=reject an sich, sondern p=reject ohne Verlust legitimer Post und mit einem messbaren Verfahren für neue Quellen.

DMARC-Berichte: Betriebsdaten und nicht vertrauenswürdige Eingabe

Die Adresse in rua bittet Empfänger um aggregierte Berichte. Sie enthalten unter anderem IP-Adressen der Quellen, Nachrichtenzahlen sowie die Ergebnisse von SPF, DKIM und Identifikatorübereinstimmung. Ein Bericht ist kein vollständiges Versandprotokoll: Empfänger sind nicht verpflichtet, ihn zu senden, die Daten sind aggregiert, und Verzögerungen sowie Implementierungsunterschiede sind normal. ^[2]

Gehen Berichte an eine andere Domäne als die, welche die Richtlinie veröffentlicht, ist eine Bestätigung des Berichtsempfängers im DNS erforderlich. Eine fehlende Autorisierung ist eine häufige Ursache für ein leeres Dashboard trotz korrekter Adresse. ruf betrifft Berichte über einzelne Fehlschläge, die mehr über eine Nachricht offenlegen können; ihre Nutzung verlangt eine gesonderte Bewertung von Vertraulichkeit, Rechtsgrundlage, Aufbewahrung und Zugriff.

Ein XML-Bericht und sein komprimierter Anhang sind Daten aus dem Internet. Der Parser sollte Größen- und Zeitgrenzen haben, das Laden externer Entitäten abschalten, in einem isolierten Konto laufen und Duplikate erkennen. Eine auf der USENIX Security 2023 vorgestellte Untersuchung zeigte, dass fehlerhafte Implementierungen der DMARC-Berichterstattung betriebliche Risiken und Verstärkungsmechanismen erzeugen können. ^[10]

Das Dashboard eines Berichtsanbieters ist ein Hilfsmittel. Ein Audit sollte eine Stichprobe der Quell-XML ziehen, sie mit der Aggregation vergleichen und Zeitzonen, als "unknown" gekennzeichnete Quellen sowie die Eskalation eines neuen oder verdächtigen Stroms prüfen.

MTA-STS, TLS-RPT und DANE schützen den SMTP-Transport

STARTTLS im gewöhnlichen SMTP ist opportunistische Verschlüsselung. Ein aktiver Angreifer kann versuchen, das STARTTLS-Angebot zu entfernen oder die Verbindung umzuleiten. MTA-STS erlaubt einer empfangenden Domäne, über DNS und eine HTTPS-Richtlinie zu erklären, dass ihre MX-Server TLS mit gültigem Zertifikat unterstützen und wie im Fehlerfall zu verfahren ist. TLS-RPT liefert Berichte über Probleme der TLS-Aushandlung. DANE für SMTP bindet den Transport an TLSA-Einträge, die durch DNSSEC geschützt sind. ^[5]

Ein MTA-STS-Audit prüft den Eintrag _mta-sts, die Versionskennung, die Erreichbarkeit von https://mta-sts.ihre-domain/.well-known/mta-sts.txt, das Zertifikat, die vollständige MX-Liste, den Modus testing beziehungsweise enforce, den Wert max_age und ein sicheres Verfahren für Änderung oder Rücknahme. Für TLS-RPT prüft es den Eintrag _smtp._tls, den Empfang der Berichte und die Alarmierung. DANE ergibt nur bei korrekt gepflegtem DNSSEC und TLSA-Einträgen für jeden einschlägigen MX-Host Sinn.

Diese Mechanismen schützen den Abschnitt zwischen Servern. Sie gewährleisten keine Verschlüsselung vom Absender bis zum Empfänger und schützen keine im Postfach abgelegte Nachricht. Wird Ende-zu-Ende-Verschlüsselung verlangt, braucht es eine eigene Architektur, etwa S/MIME oder OpenPGP, samt Schlüsselverwaltung.

ARC und Weiterleitung: Nachweis aus einer Kette, kein automatisches Vertrauen

Die Weiterleitung von Nachrichten bricht häufig SPF, und eine Verteilerliste kann den Text ändern und DKIM entwerten. Authenticated Received Chain (ARC) erlaubt es Vermittlern, die auf den einzelnen Stufen gesehenen Authentifizierungsergebnisse festzuhalten und zu signieren. Der Empfänger kann diese Kette in seine Entscheidung einbeziehen. ^[6]

ARC macht aus einem DMARC-fail kein pass, bestätigt nicht die Wahrheit der Urheberschaft und verpflichtet niemanden, einem Siegel zu vertrauen. Zu bewerten sind Reputation des Vermittlers, Korrektheit und Kontinuität der Kette sowie die lokale Richtlinie des Empfängers. RFC 8617 bleibt ein experimentelles Dokument.

Ein Audittest sollte die tatsächlichen Wege erfassen: automatische Weiterleitung zwischen Organisationen, Verteilerlisten, Schutz-Gateways, Ticketsysteme und Transportregeln. Die Analyse allein einer direkt aus Microsoft 365 oder Google Workspace gesendeten Nachricht ergibt ein unvollständiges Bild.

BIMI: eine Markenebene, kein Ersatz für Schutz

Brand Indicators for Message Identification (BIMI) erlaubt unterstützenden Clients, ein mit einer authentifizierten Domäne verknüpftes Logo anzuzeigen. BIMI ist nicht in RFC 9091 beschrieben. Diese Nummer betraf die DMARC-Erweiterung für Domänen öffentlicher Suffixe und wurde durch RFC 9989 ersetzt. BIMI wird als Branchenspezifikation entwickelt.

In Gmail verlangt die Einführung DMARC sowie ein VMC- oder CMC-Zertifikat, eine Datei im geforderten Format und einen BIMI-Eintrag; das Prüfzeichen ist an das VMC gebunden. ^[9] Andere Betreiber können andere Anforderungen stellen, und die Anzeige des Logos bleibt ihre Entscheidung. Ohne eine auf die betreffende Population, Kampagne und den Mailclient bezogene Untersuchung lässt sich kein bestimmter Zuwachs bei Öffnungen oder Klicks versprechen.

BIMI sollte erst eingeführt werden, wenn SPF, DKIM, DMARC und die Versandreputation geordnet sind. Es ist ein Element der Markendarstellung, keine Maßnahme, die Phishing, ähnliche Domänen oder übernommene Konten blockiert.

Was Gmail, Yahoo und Outlook.com verlangen

Die Anforderungen der Postfachbetreiber sind technische Zustellbedingungen, kein Gesetz. Sie können sich unabhängig von den RFCs ändern, deshalb hält ein Audit das Datum der Prüfung und die Empfängergruppe fest.

• Gmail: Alle Absender an private Konten müssen SPF oder DKIM, TLS, korrektes DNS und das Format nach RFC 5322 verwenden. Absender mit mehr als 5.000 Nachrichten täglich an private Gmail-Konten benötigen SPF und DKIM, DMARC mindestens p=none, Domänenübereinstimmung und - bei Marketing- und Abonnementnachrichten - eine Abmeldung mit einem Klick. Google verlangt, die Spam-Rate in den Postmaster Tools unter 0,3 Prozent zu halten. ^[7]
• Yahoo: verlangt von allen Absendern mindestens SPF oder DKIM, korrektes DNS und ein niedriges Beschwerdeniveau. Massenversender müssen SPF und DKIM nutzen, DMARC mindestens mit p=none veröffentlichen und Übereinstimmung erreichen; Marketing verlangt eine funktionierende Abmeldung mit einem Klick. Yahoo veröffentlicht keinen festen Zahlenwert für die Kategorie "bulk". ^[8]
• Outlook.com: Die Anforderungen von Microsoft gelten für Domänen, die mehr als 5.000 Nachrichten täglich an Verbraucheradressen bei Outlook.com, Hotmail.com und Live.com senden. Sie umfassen gültiges SPF, DKIM und mindestens DMARC p=none; nicht konforme Nachrichten können mit Code 550 5.7.515 abgewiesen werden. Diese Schwelle ist nicht automatisch auf geschäftliche Exchange-Online-Empfänger zu übertragen. ^[13]

DMARC garantiert keine Zustellbarkeit. Die Entscheidung beeinflussen auch Einwilligungen der Empfänger, Beschwerden, Reputation von Domäne und IP, Inhalt, Versandtempo, funktionierende Abmeldungen und die Antworten der Server. Ein Audit sollte einen Authentifizierungsfehler von einem Reputationsproblem trennen.

Wie ein E-Mail-Sicherheitsaudit aussieht

1. Inventar der Domänen. Hauptdomänen, Subdomänen, ungenutzte Domänen, Marken, Kampagnendomänen, Envelope-Domänen, DKIM-Selektoren und Eigentümer der DNS-Zonen.
2. Versandkarte. Büroplattform, CRM, Rechnungsstellung, Helpdesk, Überwachung, Geräte, Anwendungen, Marketingdienstleister, Gateways und Weiterleitungsmechanismen.
3. DNS-Test. Autoritative Antworten mehrerer Resolver, DNSSEC, TTL, Delegationsfehler, mehrfache Einträge und Autorisierungen externer Berichtsadressen.
4. SPF-Bewertung. Syntax, vollständige Rekursion, DNS-Grenzen, Umfang der Autorisierung, verwaiste Anbieter, Übereinstimmung von MAIL FROM und die Art der Pflege.
5. DKIM-Bewertung. Signaturen aus jedem Strom, Domäne d=, Selektor, Algorithmus, Schlüssellänge, Kopfzeilen, l=, Rotation und Reaktion auf Kompromittierung.
6. DMARC-Bewertung. Richtliniensuche nach RFC 9989, lockere oder strenge Übereinstimmung, p, sp, np, Testbetrieb, Berichte und Umgang mit inaktiven Domänen.
7. Nachrichtenanalyse. Stichproben aus allen Quellen und bei verschiedenen Empfängern, vollständige Kopfzeilen Authentication-Results, direkte Szenarien, Weiterleitung und Listen.
8. Transport. MX, Zertifikate, STARTTLS, MTA-STS/TLS-RPT oder DANE sowie Nachweise aus Berichten, nicht nur das Vorhandensein von Einträgen.
9. Eingangsschutz, Plattform und Postfächer. DMARC-Prüfung eingehender Post, Ausnahmen für vertrauenswürdige Relays, Erkennung von Domänen- und Anzeigenamen-Vortäuschung, MFA, Zugriff über Altprotokolle, privilegierte Konten, Anwendungen, Weiterleitungen, Postfachregeln, Protokollauswertung und das Verfahren bei Kontoübernahme.
10. Pflegeprozess. Eigentümer, Freigabe neuer Absender, Überwachung von Berichten und DNS-Änderungen, Reaktionszeiten, Datenaufbewahrung und Nachtests.

Der Bericht sollte Normabweichung, Zustellrisiko, Sicherheitslücke und Optimierungsempfehlung trennen. Ein "SPF pass" von einer Anbieterdomäne, die nicht zu From: passt, ist kein DMARC-Erfolg. Ebenso bietet ein korrekter MTA-STS-Eintrag ohne funktionierende HTTPS-Richtlinie keinen Transportschutz.

Verlangt das Recht DMARC

In Polen gibt es keine allgemeine Vorschrift, die jede Organisation zur Veröffentlichung von SPF, DKIM oder DMARC verpflichtet. Das Gesetz über das nationale Cybersicherheitssystem sieht für die von ihm erfassten Einrichtungen Risikomanagementmaßnahmen vor, die dem Risiko angemessen und verhältnismäßig sind; Artikel 32 der DSGVO verlangt ebenso Maßnahmen, die dem Verarbeitungsrisiko angemessen sind. Beide nennen DMARC nicht beim Namen. ^[14]

Die Authentifizierung der Domäne kann gleichwohl eine gerechtfertigte Maßnahme sein, wenn E-Mail der Kommunikation mit Kunden, der Übermittlung von Daten, dem Zurücksetzen von Passwörtern oder der Freigabe von Transaktionen dient. Ein Audit sollte die Maßnahme mit einem konkreten Risiko und einer konkreten Pflicht der Organisation verknüpfen, statt zu behaupten, "NIS2 verlange DMARC". Die Anforderungen von Gmail, Yahoo und Microsoft bleiben eigenständige Bedingungen ihrer Dienste.