SPF: wer senden darf
RFC 7208 geht von einer Feststellung aus: Nichts im E-Mail-Protokoll hindert einen Server daran, eine beliebige Absenderadresse anzugeben. SPF ermöglicht es dem Inhaber einer Domain, im DNS die Liste der Server zu veröffentlichen, die in ihrem Namen senden dürfen, und dem empfangenden Server, diese Berechtigung zu prüfen.
Zwei Präzisierungen ändern alles:
- SPF prüft die Umschlagadresse (die aus dem Dialog zwischen Servern, „MAIL FROM“ genannt) und den vom Server angekündigten Namen, nicht die Adresse, die der Empfänger im Feld „Von“ liest.
- SPF beurteilt den letzten Server, der die Nachricht zugestellt hat. Wird eine Nachricht von einem anderen Server weitergeleitet, stellt sie kein von der ursprünglichen Domain autorisierter Server mehr zu: Die Prüfung kann fehlschlagen, obwohl die Nachricht legitim ist.
Eine Domain veröffentlicht nur einen einzigen SPF-Eintrag. Alle Versandquellen müssen darin stehen: E-Mail-System, Fakturierungssoftware, Newsletter-Werkzeug, CRM, Kopierer mit Scan-to-Mail.
DKIM: Die Nachricht ist signiert
Laut RFC 6376 ermöglicht DKIM dem Inhaber einer signierenden Domain, mittels einer kryptografischen Signatur einen Teil der Verantwortung für eine Nachricht zu übernehmen. Der öffentliche Schlüssel liegt im DNS. Die Prüfung der Signatur belegt, dass sich die signierten Teile seit der Signatur nicht geändert haben.
Die Signatur reist mit der Nachricht. Sie übersteht daher ein Relay oder eine Weiterleitung besser als SPF, solange dieses Relay Betreff oder Text nicht verändert. Eine Verteilerliste, die unten an der Nachricht einen Hinweis anfügt, bricht sie.
Was DKIM laut derselben RFC nicht tut: Es verschlüsselt die Nachricht nicht, ein Fehlschlag erzwingt keine Ablehnung, und die signierende Domain muss nicht die im Feld „Von“ angezeigte sein. Genau diese Lücke schließt DMARC.
DMARC: Ausrichtung und Richtlinie
RFC 7489 definiert DMARC als ein Mittel, mit dem der Inhaber einer Domain eine Richtlinie auf Domainebene ausdrückt. Der Mechanismus beruht auf der Ausrichtung (Alignment): Die Domain der im Feld „Von“ angezeigten Adresse muss mit der durch SPF oder DKIM validierten Domain übereinstimmen. Ist keines von beiden ausgerichtet, schlägt DMARC fehl.
Die Domain veröffentlicht dann, was sie wünscht:
- none: keine Maßnahme verlangt, man beobachtet;
- quarantine: die Nachricht als verdächtig behandeln;
- reject: die Nachricht ablehnen.
DMARC sieht auch Berichte vor: aggregierte Berichte, die zusammenfassen, welche Server im Namen der Domain gesendet haben und mit welchem Ergebnis, und Fehlerberichte, Nachricht für Nachricht. Mit ihnen entdeckt man ein vergessenes Werkzeug, das für Sie sendet, oder jemanden, der Ihre Domain missbraucht.
| Mechanismus | Was er prüft | Was er nicht betrachtet |
|---|
| SPF | Der zustellende Server ist für die Umschlag-Domain autorisiert | Die angezeigte Adresse, den Inhalt |
| DKIM | Die signierte Nachricht wurde nicht verändert; eine Domain übernimmt die Verantwortung | Die angezeigte Adresse, die Redlichkeit des Inhalts |
| DMARC | Die angezeigte Domain ist mit SPF oder DKIM ausgerichtet; Richtlinie bei Fehlschlag | Ähnliche Domains, den Anzeigenamen, den Text |
Blockiert DMARC Phishing?
Es blockiert einen Teil des Domainmissbrauchs, nicht Phishing im Allgemeinen. RFC 7489 sagt es ausdrücklich: DMARC behandelt weder optisch ähnliche Domainnamen noch den Missbrauch des Anzeigenamens, und die Inhaltsanalyse liegt außerhalb seines Anwendungsbereichs. Es will nicht alle Probleme betrügerischer E-Mails lösen.
Konkret sieht DMARC nicht:
- eine ähnliche Domain: Der Betrüger authentifiziert seine eigene Domain, die Ihrer ähnelt, einwandfrei;
- einen gefälschten Anzeigenamen: „Buchhaltung“, geschrieben von einer Adresse ohne jeden Bezug;
- ein kompromittiertes Konto, das korrekt signiert, da der echte Server sendet;
- eine Nachricht ohne Bezug zu Ihrer Domain: Eine gefälschte Benachrichtigung eines Paketdienstes kommt von einer Domain, die mit Ihrer nichts zu tun hat;
- eine Domain ohne Richtlinie: Veröffentlicht die imitierte Domain „none“, hat der Empfänger keine Anweisung zur Ablehnung.
Diese Fälle erfordern andere Analysen: Ähnlichkeit von Domains, Reputation, Inhalt, Verhalten. Siehe Spam, Phishing, Malware und kompromittiertes Konto.
Weiterleitungen und Verteilerlisten: ARC
Eine Weiterleitung bricht oft SPF, eine Liste, die die Nachricht verändert, bricht DKIM, und DMARC schlägt dann bei einer legitimen Nachricht fehl. ARC, beschrieben in RFC 8617 (experimenteller Status), ermöglicht es jedem Zwischenglied, das von ihm festgestellte Authentifizierungsergebnis zu bezeugen. Der letzte Server kann entscheiden, dies zu berücksichtigen.
Die eigene Domain schützen, eingehende E-Mails filtern
Diese beiden Themen werden oft verwechselt.
- Die sendende Domain schützen: SPF, DKIM und DMARC für Ihre Domain veröffentlichen, damit andere Nachrichten ablehnen können, die sie missbrauchen. Sie veröffentlichen; die Empfänger wenden an.
- Eingehende E-Mails filtern: die Einträge anderer Domains bei den E-Mails prüfen, die Sie empfangen, und dann alle übrigen Analysen anwenden.
Schrittweise Einführung
- Bestandsaufnahme von allem, was im Namen der Domain sendet.
- Ein einziger SPF-Eintrag, der sie autorisiert; eine DKIM-Signatur für jeden Dienst, der signieren kann.
- DMARC auf „none“, mit einer Adresse für den Empfang der Berichte.
- Auswertung der Berichte über mehrere Wochen; Korrektur vergessener Quellen.
- Umstellung auf „quarantine“, dann auf „reject“, wenn alle legitimen Sendungen ausgerichtet sind.
Ein Beispiel zur Veranschaulichung. Eine Kanzlei veröffentlicht DMARC auf „none“ und liest ihre ersten Berichte. Darin entdeckt sie drei Quellen: ihr E-Mail-System, korrekt ausgerichtet; ihre Fakturierungssoftware, die Rechnungen mit der Domain der Kanzlei ohne DKIM-Signatur versendet; und einen unbekannten Server im Ausland, der Hunderte von Nachrichten in ihrem Namen sendet. Sie korrigiert die Fakturierungssoftware, wartet einen sauberen Berichtszyklus ab und stellt dann auf „quarantine“ um: Empfänger, die DMARC anwenden, behandeln die Nachrichten des unbekannten Servers nun als verdächtig.
Wenn das E-Mail-System gewechselt wird, werden diese Einträge vor der Änderung des MX vorbereitet. Der Leitfaden ein E-Mail-System ohne Unterbrechung migrieren beschreibt diesen Moment; er wird hier nicht wiederholt.
Häufige Fragen
Schützt eine DMARC-Richtlinie „none“?
Nein. Sie ermöglicht die Beobachtung über die Berichte. Der Schutz beginnt mit „quarantine“ oder „reject“.
Warum schlägt DMARC bei einer legitimen Nachricht fehl?
Meistens wegen einer Weiterleitung, einer Verteilerliste oder eines Dienstes, der für Sie sendet, ohne in SPF eingetragen zu sein oder mit DKIM zu signieren.
Unser E-Mail-System signiert nicht mit DKIM: Was tun?
Ein Gateway auf dem Versandweg kann an seiner Stelle signieren. Siehe Das vorhandene E-Mail-System schützen.
Wo lese ich das Ergebnis dieser Prüfungen bei einer empfangenen Nachricht?
In den Headern der Nachricht. Für Klytic MTA siehe Eine Filterentscheidung lesen und exportieren.
Wo Klytic steht
Klytic MTA behandelt beide Themen, vor jedem beliebigen E-Mail-System:
- Basis und Erweitert: DKIM-, SPF- und MX-Kontrolle; DMARC-Überprüfung, auch für weitergeleitete Nachrichten dank ARC; DKIM-Signatur ausgehender E-Mails, auch wenn Ihr E-Mail-System dies nicht tut.
- Erweitert: DMARC-Konsole mit den Berichten Ihrer Domains, Warnungen und Korrekturhinweisen, um die schrittweise Umstellung auf „reject“ zu steuern.
DMARC ist nur eine Schicht: Klytic MTA ergänzt die Erkennung ähnlicher Domains, des Anzeigenamens und von Betrugsszenarien, beschrieben in Identitätsmissbrauch und CEO-Betrug.
Wenn Sie Klytic Mail nutzen, sind SPF, DKIM und DMARC für Ihre Domain konfiguriert: Das ist der Schutz der sendenden Domain. Klytic MTA dagegen buchen Sie mit oder ohne Klytic Mail.
Quellen
Abgerufen im Oktober 2026.
- RFC 7208, SPF: Der Inhaber einer Domain veröffentlicht die Hosts, die seine Domain in der Identität „MAIL FROM“ oder „HELO“ verwenden dürfen, und der Empfänger prüft diese Berechtigung. rfc-editor.org
- RFC 6376, DKIM: Eine Domain übernimmt durch eine kryptografische Signatur die Verantwortung für eine Nachricht; keine Verschlüsselung, keine erzwungene Ablehnung, signierende Domain kann vom angezeigten Autor abweichen. rfc-editor.org
- RFC 7489, DMARC: Ausrichtung der „From“-Domain mit SPF oder DKIM, Richtlinien none, quarantine und reject, aggregierte und Fehlerberichte; optisch ähnliche Domains, Anzeigename und Inhaltsanalyse außerhalb des Anwendungsbereichs. rfc-editor.org
- RFC 9989 (Mai 2026), die RFC 7489 ersetzt: dieselben Richtlinienwerte und dieselben Ausschlüsse (ähnliche Domains, Anzeigename). rfc-editor.org
- RFC 8617, ARC (experimentell): authentifizierte Weiterleitungskette; ein DMARC-Empfänger kann die von einer gültigen ARC-Kette übermittelten Bewertungen akzeptieren. rfc-editor.org
- Klytic, Seite Klytic MTA: Authentifizierungsprüfungen, ausgehende DKIM-Signatur und DMARC-Konsole der Angebote Basis und Erweitert, Optionen, Bereitstellungsmodi, Inbetriebnahme über den MX. klytic.com
