E-Mail-Sicherheitsaudit 2026: SPF, DKIM, DMARC und Transportsicherheit

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

SPF, DKIM und DMARC schützen die Identität einer Domain, lösen aber nicht jedes E-Mail-Sicherheitsproblem. Sie bestätigen weder die Identität einer Person noch die Wahrheit des Inhalts, die Sicherheit eines Links oder die Lauterkeit eines Absenders, der eine authentifizierte Domain rechtmäßig nutzt. Auch eine korrekt authentifizierte Nachricht kann Phishing sein.

SPF beantwortet die Frage, ob ein bestimmter Server eine Domain in der SMTP-Identität MAIL FROM oder HELO/EHLO verwenden darf. Die für den Benutzer sichtbare Domain im From:-Feld wird dadurch allein nicht geprüft. Die SPF-Richtlinie wird als TXT-Eintrag im DNS veröffentlicht und beschreibt autorisierte Versandquellen.^[3]

DKIM ermöglicht einer Domain, ausgewählte Header und einen Hash des Nachrichtentextes kryptographisch zu signieren. Der Empfänger lädt den öffentlichen Schlüssel aus dem DNS und überprüft die Signatur; die signierende Domain wird durch das Tag d= bestimmt. Eine DKIM-Signatur kann Weiterleitungen überstehen, sofern zwischengeschaltete Systeme die signierten Bestandteile nicht so verändern, dass die Signatur ungültig wird.^[4]

DMARC verknüpft die Absenderdomain aus RFC5322.From mit dem Ergebnis von SPF oder DKIM. Eine Nachricht besteht DMARC, wenn mindestens einer dieser Mechanismen erfolgreich ist und seine Domain entsprechend dem gewählten Alignment-Modus mit der Absenderdomain übereinstimmt.^[1]

Diese Konstruktion begrenzt direktes Spoofing der Organisationsdomain, blockiert aber keine ähnlich aussehenden Domains, keinen Missbrauch des Anzeigenamens, keine übernommenen Konten und keine Phishing-Kampagne aus einer legitim authentifizierten Domain. Ein Audit sollte daher Domain-Authentisierung, Postfachsicherheit, Transportsicherheit und Schutz des Empfängers getrennt betrachten. Diese Unterscheidung ist auch für Security-Awareness-Schulungen wichtig: Benutzer dürfen nicht annehmen, dass eine im Postfach angekommene Nachricht inhaltlich geprüft wurde.

SPF: mehr als eine Syntaxprüfung

Ein gutes SPF-Audit beantwortet mindestens sechs Fragen:

• Existiert für die geprüfte Domain genau ein SPF-Eintrag?
• Werden alle Mechanismen include, a, mx, ip4, ip6 und redirect noch benötigt?
• Hat jeder externe Dienst, der im Namen der Organisation versendet, einen fachlichen Verantwortlichen?
• Autorisiert der Eintrag keine größeren Adressbereiche als tatsächlich erforderlich?
• Ermöglicht die MAIL FROM-Domain ein Alignment mit From:, wenn die Organisation für DMARC auf SPF setzt?
• Bleibt die gesamte rekursive include-Kette innerhalb der DNS-Auswertungslimits?

RFC 7208 begrenzt die Gesamtzahl der SPF-Terme, die DNS-Abfragen auslösen, auf zehn. Dazu gehören include, a, mx, ptr, exists und redirect; eine Überschreitung führt zu permerror. Der Standard empfiehlt außerdem, leere DNS-Antworten auf zwei zu begrenzen.^[3]

Das ist relevant, weil SPF-Probleme häufiger während der Auswertung als beim reinen Parsen eines Eintrags sichtbar werden. Eine auf der USENIX Security 2024 vorgestellte Studie analysierte 17 Monate lang wöchentliche Snapshots von 176 Millionen Domains aus vier Top-Level-Domains. Reine Syntaxfehler betrafen 0,4% der Einträge, Probleme in der Auswertungsphase dagegen 7,7%.^[11] Diese Werte lassen sich nicht auf eine einzelne Organisation übertragen, zeigen aber deutlich die Grenzen eines einfachen SPF-Validators.

Das Flattening von SPF in eine Liste von IP-Adressen kann DNS-Abfragen reduzieren, erzeugt aber eine lokale Kopie von Providerdaten. Ändert der Provider seine Infrastruktur, muss diese Kopie synchronisiert werden, sonst beginnt die Organisation, ihre eigene Post abzulehnen. Ein Audit sollte deshalb nicht nur das aktuelle Ergebnis, sondern auch den Pflegeprozess bewerten.

DKIM: eine Signatur ist auch Schlüsselmanagement

RFC 8301 verbietet RSA-SHA1. Für RSA sind mindestens 1024 Bit vorgeschrieben und mindestens 2048 Bit empfohlen.^[4] RFC 8463 ergänzte Ed25519-SHA256.^[5] Eine Organisation muss dennoch die Interoperabilität mit wichtigen Empfängern berücksichtigen, insbesondere bei weniger verbreiteten Algorithmen.

Ein DKIM-Audit umfasst:

• die signierende Domain d= und ihr Alignment mit der Absenderdomain;
• Algorithmus und Schlüssellänge;
• Schutz des privaten Schlüssels;
• getrennte Selektoren für Anbieter und Umgebungen, wenn dadurch die Auswirkungen einer Kompromittierung begrenzt werden;
• den Umfang signierter Header einschließlich From:;
• das Fehlen einer unbegründeten Verwendung des Tags l= zur Begrenzung der signierten Nachrichtenlänge;
• Rotation, Widerruf und Wiederherstellung nach einer Kompromittierung;
• die Bestätigung, dass ein alter DNS-Eintrag nicht gelöscht wird, bevor der Verkehr auf den neuen Selektor umgestellt wurde.

Es gibt keine allgemeine Vorgabe, DKIM-Schlüssel alle sechs oder zwölf Monate zu rotieren. Das Intervall sollte sich aus Schlüsselschutz, Fähigkeiten des Providers, Bedrohungsmodell und der Fähigkeit zur sicheren Rotation ergeben. Wer "keine Rotation alle 6 Monate" als Abweichung in einen Bericht schreibt, sollte die Anforderung dahinter benennen können und nicht nur eine Gewohnheit.

DMARC nach RFC 9989

Alignment bleibt das zentrale Konzept. SPF kann für eine Domain pass liefern. Ist die MAIL FROM-Domain jedoch nicht mit From: ausgerichtet, führt dies nicht zu einem DMARC-Pass. Ebenso hilft eine DKIM-Signatur für DMARC nur dann, wenn ihre d=-Domain mit der Absenderdomain aligned ist.^[1]

Relaxed Alignment ist der Standard und erlaubt Übereinstimmung auf Ebene derselben organisatorischen Domain. Strict Alignment verlangt eine engere Übereinstimmung. Die Entscheidung sollte aus der Versandarchitektur folgen und nicht aus der vereinfachten Regel "strict ist immer sicherer": In einer Umgebung mit vielen Subdomains und Dienstleistern kann Strict Alignment legitime Korrespondenz abschneiden.

RFC 9989 änderte außerdem die Policy-Ermittlung und löste die frühere Abhängigkeit von der Public Suffix List ab. Eingeführt wurden unter anderem eine Policy für nicht existente Subdomains über np und das Tag t zur Kennzeichnung eines Testmodus. Der historische pct-Mechanismus gehört nicht zum neuen Policy-Modell.^[1]

Das ist 2026 praktisch relevant. Die Spezifikation ist neu, während Providerdokumentation und Implementierungen DMARC teilweise noch nach RFC 7489 beschreiben. Ein Audit sollte daher Standardkonformität und operative Interoperabilität mit wichtigen Empfängern getrennt dokumentieren. In einer Übergangsphase können beide auseinanderlaufen.

DMARC-Berichte sind Daten, keine Dekoration

Aggregierte DMARC-Berichte zeigen, welche Quellen mit der Domain versenden, wie Empfänger SPF und DKIM bewerten und wo Alignment-Probleme auftreten. RFC 9990 definiert das aktuelle Format aggregierter Berichte.^[2]

Nur eine rua-Adresse einzutragen, ohne einen Prozess zur Berichtsauswertung zu haben, ändert wenig. Die Organisation benötigt einen Verantwortlichen, Aufbewahrungsregeln, Normalisierung und einen Eskalationsprozess für neu auftauchende Quellen. Bei großen Domains können die Berichte Marketingplattformen, Multifunktionsgeräte, SaaS-Dienste oder Altanwendungen sichtbar machen, die dem Sicherheitsteam bislang unbekannt waren. Das ist meist der wertvollste Einzeleffekt eines E-Mail-Audits.

Berichte sind als nicht vertrauenswürdige externe Daten zu behandeln. Ein Parser sollte enthaltene Werte nicht ungeprüft ausführen, keine beliebigen referenzierten Ressourcen abrufen und Rohdaten nicht ohne Schutz in hochprivilegierte Automatisierung einspeisen.

SMTP-Transport: TLS, MTA-STS, TLS-RPT und DANE

SPF, DKIM und DMARC betreffen vor allem Domain-Authentisierung und Nachrichtenbewertung. Sie stellen keine Transportverschlüsselung zwischen Mailservern bereit.

MTA-STS erlaubt einer Empfängerdomain, Anforderungen an TLS und die Serveridentität bei der Zustellung zu veröffentlichen. TLS-RPT ermöglicht Berichte über Probleme bei TLS-Aushandlung, Routing und MTA-STS- oder DANE-Policies. DANE for SMTP stützt sich auf DNSSEC und TLSA-Einträge.^[6]

Diese Mechanismen schützen bestimmte Server-zu-Server-Transportwege. Sie sind keine Ende-zu-Ende-Verschlüsselung. Administratoren der Mailserver und das Zielsystem können weiterhin Zugriff auf den Nachrichteninhalt haben, was bei der Bewertung von Maßnahmen nach Art. 32 DSGVO zu berücksichtigen ist.^[15]

ARC und Weiterleitung

Weiterleitungen, Mailinglisten und Gateways können Nachrichten so verändern, dass SPF oder DKIM scheitern. ARC speichert eine authentisierte Kette früherer Authentisierungsergebnisse und kann dem Empfänger zusätzlichen Kontext liefern.^[7]

ARC repariert DMARC nicht und erlaubt die Annahme einer Nachricht nicht automatisch. Der Empfänger muss entscheiden, ob er den Systemen vertraut, die die Kette erzeugt haben, und ob die Informationen konsistent sind. RFC 8617 hat den Status Experimental; auch das sollte in der Architektur dokumentiert werden, statt ARC als fertige Lösung des Weiterleitungsproblems darzustellen.^[7]

SMTP Smuggling und die Grenzen der Authentisierungsschicht

Eine auf der USENIX Security 2025 veröffentlichte Untersuchung zeigte, dass unterschiedliche Interpretation von SMTP-Nachrichtengrenzen durch verschiedene Server Spoofing trotz SPF und DMARC ermöglichen kann. Die Autoren untersuchten öffentliche und private Maildienste, Open-Source-Software und Security Gateways und zeigten, dass sich das Problem nicht auf einen fehlerhaften DNS-Eintrag reduzieren lässt.^[12]

Für ein Audit folgt daraus: Korrektes SPF, DKIM und DMARC beweist nicht die Sicherheit der gesamten Mailstrecke. Auch Zwischenserver, Softwareversionen, SMTP-Parsing und Patchstand müssen erfasst werden. Das ist gemeinsames Gebiet mit Schwachstellenscanning und Hardening und nicht mit DNS-Konfiguration.

Postfachsicherheit und Schutz des Empfängers

Domain-Authentisierung schützt nicht vor Kontoübernahme, und ein übernommenes Konto versendet Nachrichten, die SPF, DKIM und DMARC einwandfrei bestehen. Ein E-Mail-Audit muss deshalb die Plattform selbst umfassen:

• MFA für alle Konten, mit besonderem Augenmerk auf administrative Rollen;
• Legacy-Protokolle, die moderne Authentisierung umgehen;
• von Benutzern angelegte Weiterleitungsregeln nach außen;
• OAuth-Anwendungen mit Postfachzugriff und der Umfang ihrer Berechtigungen;
• Protokollierung von Ereignissen, Aufbewahrung der Logs und Alarme bei ungewöhnlichen Anmeldungen;
• das Verfahren nach einer Kontoübernahme: Widerruf von Sitzungen, Prüfung der Regeln, Benachrichtigungen.

Der Schutz des Empfängers ist eine eigene Schicht: Erkennung von Anzeigenamen-Imitation, Analyse von Links und Anhängen, Kennzeichnung externer Nachrichten sowie ein einfacher Meldeweg mit einem Klick. Dieses letzte Element kostet weniger als die meisten technischen Maßnahmen und fehlt am häufigsten gerade in Organisationen, die bereits einen korrekten DMARC-Eintrag besitzen.

Gmail, Yahoo und Outlook.com: Zustellanforderungen, kein Recht

Seit dem 1. Februar 2024 verlangt Gmail von allen Absendern unter anderem SPF oder DKIM, TLS und korrektes DNS. Absender mit mehr als 5.000 Nachrichten täglich an Gmail-Konten müssen zusätzlich SPF, DKIM und DMARC einsetzen und für direkte Nachrichten Alignment erfüllen.^[8]

Yahoo verlangt von Bulk-Sendern SPF und DKIM sowie eine gültige DMARC-Policy von mindestens p=none; außerdem ist Alignment zwischen From: und der SPF- oder DKIM-Domain erforderlich.^[9]

Outlook.com führte 2025 SPF-, DKIM- und DMARC-Anforderungen für Domains ein, die mehr als 5.000 Nachrichten täglich an Microsoft-Verbraucherdienste senden; die Durchsetzung begann am 5. Mai 2025.^[10]

Das sind Anforderungen von Dienstanbietern an Zustellbarkeit und Missbrauchsschutz. Sie sind keine allgemeinen gesetzlichen Pflichten. Für Organisationen, die zuverlässig an diese Empfänger zustellen müssen, werden sie aber zu realen operativen Anforderungen, deren Verletzung sofort in Form nicht zugestellter Nachrichten sichtbar wird.

Verlangt polnisches Recht DMARC?

Es gibt keine allgemeine Vorschrift, die jede polnische Organisation zur Einführung von DMARC verpflichtet.

Das KSC verlangt nach der seit 3. April 2026 geltenden Novelle von wesentlichen und wichtigen Einrichtungen Maßnahmen zum Management von Cybersicherheitsrisiken, darunter sichere Kommunikation, Zugriffskontrolle und Schutz von Systemen.^[13] Die Auswahl von SPF, DKIM, DMARC, MTA-STS oder DANE hängt von Architektur und Risiko ab und nicht von einem Werkzeugkatalog.

Für bestimmte digitale Dienstanbieter, die unmittelbar der Durchführungsverordnung (EU) 2024/2690 unterliegen, sind die Vorgaben konkreter. Die Verordnung verlangt einen Plan zur Einführung moderner, interoperabler Standards für E-Mail-Kommunikation, um E-Mail abzusichern und entsprechende Bedrohungen zu reduzieren.^[14] Auch dies reduziert die Anforderung nicht auf einen einzelnen DMARC-Eintrag.

Die DSGVO verlangt dem Risiko angemessene Maßnahmen zum Schutz personenbezogener Daten.^[15] DMARC kann das Risiko der exakten Domain-Imitation reduzieren, wird aber nicht als allgemeine Pflicht genannt.

Der Nationale Interoperabilitätsrahmen verlangt von erfassten Stellen unter anderem Schutz von Informationen und Systemen, Risikomanagement, Aktualisierung, Erkennung nicht autorisierter Aktivitäten und geeignete interne Regelungen.^[16] Ein E-Mail-Sicherheitsaudit kann im KRI-Audit Nachweise für einen Teil dieser Mechanismen liefern, ersetzt es aber nicht.

Wie ein belastbares E-Mail-Audit aussieht

Das Audit sollte mit einer Inventarisierung von Domains, Subdomains und Versandquellen beginnen. Zu identifizieren sind nicht nur der zentrale Mailserver, sondern auch Marketingplattformen, CRM, Helpdesk, Multifunktionsgeräte, Fachanwendungen, Monitoring-Systeme und Dienstleister, die im Namen der Organisation versenden.

Anschließend werden geprüft:

1. DNS und Versandquellen - SPF, DKIM, DMARC, MX, Delegationen und transportbezogene Einträge.
2. Reale Nachrichten - Header Authentication-Results, Received, DKIM-Signature und Return-Path.
3. Alignment - ob legitime Nachrichtenströme DMARC mit der vorgesehenen Methode bestehen.
4. Berichte - ob alle Quellen bekannt sind und Anomalien erklärt werden können.
5. Transport - TLS, MTA-STS mit TLS-RPT oder DANE, sofern eingesetzt.
6. Mailplattform - MFA, Administratorrollen, Legacy-Protokolle, Weiterleitungsregeln, OAuth-Anwendungen, Logging und Alarme.
7. Benutzerschutz - Anti-Phishing, Erkennung von Anzeigenamen-Imitation, Link- und Anhangsanalyse sowie Meldewege.
8. Prozesse - Onboarding von Dienstleistern, DNS-Änderungen, Schlüsselkompromittierung, Kontoübernahme und Stilllegung alter Quellen.

Erst nachdem legitime Versandströme bestätigt sind, sollte die Durchsetzung verschärft werden. Direkt von p=none auf reject zu wechseln, ohne die tatsächlichen Quellen zu kennen, kann eine Rechnung, eine Systembenachrichtigung oder die Korrespondenz des Vertriebs ablehnen, und die Ursache wird oft erst Tage später gefunden.

Bei E-Mail-Audits von 4crypto ist es sinnvoll, die DNS-Ebene mit der Analyse realer Header und Berichte zu verbinden. Ein Screenshot eines Validators mit drei grünen Symbolen ist kein Nachweis, dass sämtliche Nachrichtenströme korrekt funktionieren.