Unterschiede zwischen SPF, DKIM und DMARC erklärt für MSPs

Kurzfassung: MSPs, die die E-Mail-Umgebungen ihrer Kunden verwalten, müssen SPF, DKIM und DMARC gemeinsam einsetzen, um sich vor Spoofing-Angriffen zu schützen und die Anforderungen von Posteingangsanbietern zu erfüllen. Diese Anleitung erklärt, wie jedes Protokoll funktioniert, warum alle drei notwendig sind und wie MSPs die E-Mail-Authentifizierung effizient für ihren gesamten Kundenstamm umsetzen können.

Wichtige Erkenntnisse:

• SPF validiert die IP-Adressen des sendenden Servers, DKIM überprüft die Integrität der Nachricht mittels kryptografischer Signatur, und DMARC erzwingt eine Richtlinie, wenn die Authentifizierung fehlschlägt
• Google und Yahoo verlangen nun SPF und DKIM für Massenversender, weshalb E-Mail-Authentifizierung für die Zustellbarkeit der Kunden-E-Mails unerlässlich ist
• MSPs sollten zuerst SPF implementieren, dann DKIM, anschließend DMARC mit p=none, bevor sie zur Durchsetzung übergehen
• Die Multi-Tenant-Architektur von Red Sift OnDMARC ermöglicht es MSPs, die Authentifizierung über alle Kundendomains hinweg über ein einziges Dashboard zu steuern und den Durchsetzungsgrad in 6-8 Wochen (statt 6-12 Monaten bei manueller Umsetzung) zu erreichen

Sie senden eine vermeintlich alltägliche Geschäftsmail im Namen eines Kunden, doch sie kommt zurück oder landet im Spam. Noch schlimmer: Die Kunden Ihres Kunden erhalten Phishing-Mails, die scheinbar von dessen Domain stammen – der Ruf ist geschädigt, bevor jemand bemerkt, dass es ein Problem gibt. Solche Szenarien treten auf, weil beim E-Mail-Protokolldesign die Überprüfung der Absenderidentität fehlt.

Die ursprünglichen E-Mail-Protokolle der 1980er Jahre basierten auf Vertrauen zwischen Mailservern. Jeder konnte behaupten, E-Mails von beliebigen Domains zu senden, und empfangende Server konnten diese Angaben nicht zuverlässig überprüfen. Diese grundlegende Schwäche macht Spoofing-Angriffe möglich, bei denen Angreifer die From-Adresse fälschen und sich so als vertrauenswürdige Absender ausgeben.

E-Mail-Authentifizierungsprotokolle schließen diese Sicherheitslücke. SPF, DKIM und DMARC arbeiten zusammen, um zu überprüfen, dass E-Mails mit der Behauptung, sie kämen von Kundendomains, tatsächlich legitim sind. Für MSPs, die mehrere Kunden-Umgebungen betreuen, ist das Verständnis der Funktionsweise jedes Protokolls und ihrer Notwendigkeit entscheidend für den Unterschied zwischen einer sicheren und einer verwundbaren E-Mail-Infrastruktur.

SPF (Sender Policy Framework) ist ein E-Mail-Authentifizierungsstandard, der Domaininhabern erlaubt, festzulegen, welche IP-Adressen berechtigt sind, im Namen ihrer Domain E-Mails zu versenden. Wenn ein empfangender Mailserver eine E-Mail erhält, die angeblich von der Domain des Kunden stammt, prüft er den SPF-Eintrag, um sicherzustellen, dass die IP-Adresse des Absenders auf der freigegebenen Liste steht.

Man kann SPF mit einer Gästeliste für ein gesichertes Gebäude vergleichen. Der empfangende Server überprüft, ob die IP-Adresse des Absenders auf der veröffentlichten Liste der autorisierten Absender steht. Ist das der Fall, besteht die E-Mail die SPF-Prüfung; ansonsten fällt sie durch.

DKIM (DomainKeys Identified Mail) geht anders vor: Es versieht E-Mail-Header mit einer digitalen Signatur. Diese kryptografische Signatur beweist, dass die Nachricht während der Übertragung nicht verändert wurde und von einem Server stammt, der Zugang zum privaten DKIM-Schlüssel hat. Der empfangende Server überprüft die Signatur mit dem in der DNS veröffentlichten öffentlichen Schlüssel.

Während sich SPF auf die Identität des sendenden Servers konzentriert, validiert DKIM die Nachricht selbst. Die Signatur bezieht sich auf Header und Body der E-Mail, sodass eine Manipulation während der Übertragung die Signatur ungültig macht.

DMARC (Domain-based Message Authentication, Reporting and Conformance) baut auf SPF und DKIM auf, indem es Richtlinien durchsetzt und Berichtsfunktionen hinzufügt [1]. Während SPF und DKIM unterschiedliche Aspekte einer E-Mail prüfen, verbindet DMARC diese Prüfungen mit der im Posteingang sichtbaren Domain und gibt an, wie empfangende Server bei fehlgeschlagener Authentifizierung vorgehen sollen.

Der entscheidende Unterschied ist, dass DMARC Ihnen Kontrolle über fehlgeschlagene Authentifizierungen gibt. Sie entscheiden, ob fehlerhafte E-Mails dennoch zugestellt, im Spam-Ordner abgelegt oder komplett abgelehnt werden. Für MSPs bedeutet das, dass Sie konsistente Richtlinien für alle Kundendomains festlegen können.

Red Sift’s E-Mail-Sicherheitsleitfaden bietet weiteres Hintergrundwissen, wie DMARC mit SPF und DKIM für umfassenden Domainschutz zusammenarbeitet.

SPF-Validierung findet statt, wenn der empfangende Server die DNS nach dem SPF-Eintrag der Domain abfragt. Dieser TXT-Eintrag enthält eine Liste autorisierter IP-Adressen und Mechanismen wie "include"-Anweisungen für Drittanbieter-Services. Der Server vergleicht die Absender-IP mit dieser Liste und gibt als Ergebnis Pass, Fail oder Neutral zurück [2].

• SPF: Empfangsserver fragt DNS ab, vergleicht die Absender-IP mit der autorisierten Liste, gibt pass/fail/neutral zurück
• DKIM: Mailserver signiert Nachricht mit privaten Schlüssel, Empfangsserver holt öffentlichen Schlüssel aus DNS, prüft Signatur
• DMARC: Prüft SPF- oder DKIM-Ergebnisse, validiert Domain-Ausrichtung mit From-Header, wendet Policy entsprechend der Konfiguration an

DKIM arbeitet mit öffentlicher Schlüssel-Kryptografie. Der Mailserver signiert ausgehende Nachrichten mit einem privaten Schlüssel und empfangende Server prüfen die Signatur anhand des im DNS veröffentlichten öffentlichen Schlüssels. Schon eine Änderung eines einzigen Zeichens im E-Mail-Body führt dazu, dass die DKIM-Prüfung fehlschlägt.

DMARC koordiniert diese beiden Authentifizierungsmethoden und fügt zentrale Funktionen hinzu. Wenn Sie einen DMARC-Eintrag veröffentlichen, geben Sie eine Policy (none, quarantine oder reject) an, die sagt, wie empfangende Server mit E-Mails umgehen sollen, die bei SPF oder DKIM durchfallen. DMARC erfordert außerdem Domain-Ausrichtung, d.h. die Domain im From-Header muss mit der durch SPF oder DKIM authentifizierten Domain übereinstimmen.

Die vollständige Anleitung zu DKIM und SPF erklärt die technischen Details, wie diese grundlegenden Protokolle die Echtheit von E-Mails prüfen.

Laut FBI-Daten kosten E-Mail-Spoofing-Angriffe Unternehmen im Durchschnitt 1,6 Millionen US-Dollar pro Vorfall. Ohne Authentifizierungsprotokolle können Angreifer Domains von Kunden im From-Header leicht fälschen und sich als Führungskräfte, Kunden oder Partner ausgeben. Diese Angriffe auf geschäftliche E-Mails funktionieren, weil Standard-E-Mail-Protokolle keine integrierte Absenderüberprüfung haben.

Für MSPs vervielfacht sich das Risiko auf den gesamten Kundenstamm. Ein einziger Spoofing-Vorfall bei einem Kunden beschädigt Ihren Ruf und löst bei allen anderen Kunden Rückfragen zur eigenen Sicherheit aus. Die finanziellen Auswirkungen gehen über direkte Verluste hinaus: Kunden müssen Kosten für Incident Response, Forensik, Rechtsberatung, behördliche Bußgelder und Kundenbenachrichtigung tragen. Der Imageschaden kann lange nach der eigentlichen Krise bestehen bleiben.

Authentifizierungsprotokolle schützen den Domainruf und die Zustellbarkeit im gesamten Kundenportfolio. Große E-Mail-Anbieter wie Google, Microsoft und Yahoo verlangen nun für Massenversender SPF und DKIM und nutzen DMARC-Compliance als Signal bei der Entscheidung, ob E-Mails im Posteingang oder im Spam landen [3].

Neben dem Schutz ausgehender E-Mails schützen diese Protokolle die Kunden und Partner Ihrer Kunden davor, gefälschte Nachrichten zu erhalten. DMARC-Berichte geben einen Überblick darüber, wer alles E-Mails im Namen jeder Kundendomäne versendet – einschließlich legitimer Dienste und potenzieller Angreifer. Für MSPs bietet diese zentrale Übersicht eine starke Differenzierung am Markt.

SPF und DKIM nehmen komplementäre Rollen in der Authentifizierungsarchitektur ein. SPF prüft die Berechtigung des sendenden Servers anhand der IP-Adresse, aber weder die Nachricht selbst noch der im Postfach sichtbare From-Header werden dadurch validiert. DKIM bestätigt die Integrität des Inhalts und führt eine kryptografische Authentifizierung durch, verlangt aber keine Übereinstimmung der signierenden Domain mit der From-Header-Domain.

Hier wird DMARC unerlässlich. DMARC verlangt eine "Ausrichtung" zwischen der durch SPF oder DKIM authentifizierten Domain und der im From-Header sichtbaren Domain. Diese Überprüfung verhindert typische Spoofing-Techniken, bei denen Angreifer SPF bestehen, indem sie ihre eigene Domain im Mail-from, aber die Kundendomäne im sichtbaren From-Header einsetzen.

• Ebene 1: Infrastrukturvalidierung (SPF) Prüft die IP-Adresse des sendenden Servers. Schnelle Validierung durch einen DNS-Check. Funktionsverlust bei E-Mail-Weiterleitung.
• Ebene 2: Nachrichtenvalidierung (DKIM) Prüft, dass die Nachricht nicht verändert wurde. Verwendet eine kryptografische Signatur. Bleibt bei Weiterleitung erhalten.
• Ebene 3: Richtliniendurchsetzung (DMARC) Verlangt Ausrichtung zum From-Header. Erzwingt Pass/Quarantäne/Ablehnungs-Policies. Koordiniert die Ergebnisse von SPF und DKIM.

MSPs setzen die drei Protokolle üblicherweise stufenweise in Kunden-Umgebungen um: Zuerst werden SPF- und DKIM-Einträge veröffentlicht, dann ein DMARC-Eintrag mit der Policy "none", um zunächst Daten zu sammeln, ohne den Mailfluss zu beeinträchtigen. Während Sie für jeden Kunden nach und nach alle legitimen Absender identifizieren und autorisieren, schärfen Sie die Richtlinie sukzessive.

Die Protokolle bieten je nach Mailflow unterschiedliche Vorteile: SPF eignet sich gut für den Direktversand von Kunden-Infrastruktur, stößt aber bei Weiterleitung an Grenzen. DKIM übersteht Weiterleitungen, da die Signatur an der E-Mail haftet.

Die Einrichtung von SPF beginnt damit, alle Dienste und Server aufzudecken, die im Namen einer Kundendomain E-Mails versenden – dazu gehören Mailserver, Marketingplattformen, CRM-Systeme und Drittanbieterdienste. Jeder legitime Absender muss im SPF-Record per IP-Adresse oder "include"-Mechanismus eingetragen werden.

In dieser Entdeckungsphase kommen oft unerwartete Absenderquellen ans Licht. MSPs stellen häufig fest, dass Kunden mehr E-Mail-Dienste nutzen, als ihnen bewusst war – von automatisierten Benachrichtigungssystemen über Helpdesks bis hin zu HR-Tools. Das dokumentierte Wissen über die Kundenlandschaft erleichtert die Übernahme in wiederverwendbare Vorlagen.

Der SPF-Eintrag ist als TXT-Record im DNS hinterlegt und folgt einer bestimmten Syntax. Ein einfacher Eintrag könnte lauten: "v=spf1 ip4:192.0.2.1 include:_spf.google.com -all", wobei "-all" bedeutet, dass nicht autorisierte IPs durchfallen sollen. Der Record muss unter 255 Zeichen bleiben und darf maximal 10 DNS-Lookups enthalten – sonst funktioniert er nicht mehr.

Das 10er-Limit für DNS-Lookups ist ein häufiger Stolperstein, der unbemerkt die E-Mail-Authentifizierung zerstören kann. Jeder "include"-Mechanismus zählt dabei als Lookup, und einige Dienste verschachteln mehrere davon. Sobald ein SPF-Record dieses Limit überschreitet, behandeln empfangende Server ihn als dauerhaft durchgefallen – legitime E-Mails können blockiert werden. Es kann erforderlich sein, SPF-Records zu "flatten" (Includes durch IP-Adressen ersetzen) oder Dienste zu konsolidieren, um im Limit zu bleiben. Für MSPs mit vielen Kundendomains wird die Nachverfolgung der Lookups zu einer wichtigen operativen Aufgabe.

Für DKIM benötigen Sie ein Schlüsselpaar (privat/öffentlich) und konfigurieren den Mailserver so, dass ausgehende Nachrichten mit dem privaten Schlüssel signiert werden. Der öffentliche Schlüssel wird als TXT-Record unter einem Selector-Subdomain wie "selector1._domainkey.clientdomain.com" im DNS veröffentlicht. Die meisten E-Mail-Plattformen bieten Tools zur Schlüsselerstellung und DKIM-Konfiguration an.

SPF-Einrichtung

• Alle E-Mail-Dienste pro Kunde erfassen
• IP-Adressen und Include-Mechanismen dokumentieren
• SPF-Record mit v=spf1-Präfix erstellen
• Sicherstellen, dass die Lookup-Anzahl unter 10 bleibt
• Mit SPF-Validator testen
• Im DNS publizieren und Übertragung überprüfen

DKIM-Einrichtung

• 2048-Bit-Schlüsselpaar generieren
• Mailserver mit privatem Schlüssel konfigurieren
• Öffentlichen Schlüssel ins DNS stellen
• DKIM-Signierung für alle ausgehenden Mails aktivieren
• Testmails senden und Header überprüfen
• Mit Drittanbietern koordinieren

DMARC-Einrichtung

• Mit p=none starten (nur Monitoring)
• Adresse für Aggregatberichte konfigurieren (rua=)
• DMARC-Record im DNS veröffentlichen
• Berichte für 2-4 Wochen beobachten
• Fehlgeschlagene Authentifizierungen beheben
• Zur Policy p=quarantine und dann p=reject fortschreiten

Die Schlüssellänge ist für die DKIM-Sicherheit relevant. Verwenden Sie mindestens 1.024 Bit, besser 2.048 Bit für Zukunftssicherheit. Einige MSPs rotieren DKIM-Schlüssel regelmäßig als Best Practice für alle Kundendomains.

Für DMARC erstellen Sie einen TXT-Record unter "_dmarc.clientdomain.com" mit Policy und Reporting-Präferenzen. Starten Sie z.B. mit "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourmsp.com", so sammeln Sie Daten, ohne Mails zu blockieren. Der rua-Tag leitet die Sammelberichte an Ihr Postfach, um die Authentifizierungsergebnisse aller Kunden zentral zu überwachen.

Die Berichte kommen als XML-Dateien, die Authentifizierungserfolge und -fehler pro Domain zeigen. Ohne automatisiertes Parsen sind sie in großen Umgebungen schwer auswertbar. Sie sehen, welche Quellen SPF und DKIM bestehen oder scheitern, und können Fehlkonfigurationen erkennen, bevor Sie härtere Policies einsetzen.

Der komplette DMARC-Leitfaden führt durch alle Phasen vom Start bis zur Durchsetzung mit p=reject.

Die Frage ist nicht, welches Protokoll Sie auswählen, sondern in welcher Reihenfolge Sie sie einführen. Alle drei Protokolle sind für ganzheitliche Sicherheit notwendig: SPF und DKIM stellen die Authentifizierungsmechanismen, DMARC verbindet sie mit Richtliniendurchsetzung und zentraler Transparenz.

Starten Sie mit SPF, da es am einfachsten umzusetzen ist. Sie können SPF meist in wenigen Stunden einführen, indem Sie die Absenderquellen bestimmen und einen DNS-Record veröffentlichen. SPF allein bietet bereits grundlegenden Schutz und verbessert die Zustellbarkeit bei großen E-Mail-Anbietern.

DKIM führen Sie als Nächstes ein, da es eine stärkere Authentifizierung liefert als SPF allein. Die kryptographische DKIM-Signatur kann kaum gefälscht werden und – anders als SPF – bleibt DKIM auch bei E-Mail-Weiterleitung erhalten. Die Kombination aus SPF und DKIM bietet zwei unabhängige Authentifizierungsmechanismen, auf die DMARC aufsetzen kann.

DMARC implementieren Sie zuletzt, da es für eine effektive Funktion auf SPF und DKIM angewiesen ist. Beginnen Sie mit einer reinen Monitoring-Policy (p=none), identifizieren Sie legitime Absenderquellen und gehen Sie schrittweise zu Quarantäne- und Ablehnungspolicies über, sobald Sie sich sicher sind.

Manche MSPs fragen sich, ob sie Zeit sparen, indem sie Protokolle überspringen oder nur eines einsetzen. Dieses Vorgehen lässt große Lücken: SPF allein verhindert viele Spoofing-Angriffe nicht. DKIM allein erzwingt keine Übereinstimmung mit dem From-Header. Nur DMARC stellt die Richtliniendurchsetzung bereit, mit der gefälschte E-Mails tatsächlich geblockt werden.

E-Mail-Authentifizierung manuell für Dutzende oder Hunderte Kundendomains einzuführen bedeutet, diverse DNS-Einträge zu pflegen, komplexe XML-Berichte zu analysieren und für jeden Kunden Drittanbieterdienste zu koordinieren. Die Red Sift OnDMARC-Plattform automatisiert den Prozess und bringt MSPs in 6-8 Wochen zur DMARC-Policy-Durchsetzung (statt 6-12 Monate bei manueller Umsetzung).

Die Plattform beginnt mit dem Monitoring des E-Mail-Ökosystems und erkennt automatisiert alle Quellen, die im Namen des Kunden Mails versenden. Statt roher DMARC-Berichte sehen Sie ein Dashboard, das für das gesamte Portfolio den Authentifizierungsstatus aller Absender visuell darstellt.

OnDMARC kategorisiert Absenderquellen automatisch, unterscheidet interne Mailserver, autorisierte Drittanbieter und potenziell schädliche Quellen. Sie sehen für jeden Kunden, welche Dienste authentifiziert sind und wo noch Konfigurationsbedarf besteht.

Die Plattform erkennt Konfigurationsfehler in SPF-, DKIM- und DMARC-Records und bietet klare Schritte zur Behebung. Bei Aktivierung der DMARC-Durchsetzung überwacht OnDMARC die Auswirkungen und warnt, falls legitime Mails betroffen wären. Systemprognosen zum Policy-Wechsel verringern das Risiko, versehentlich legitime Mails der Kunden zu blockieren.

Für MSPs mit vielen Kunden und komplexen Umgebungen bietet OnDMARC zentrale Steuerung und Reporting. Sie behalten den Überblick über den Authentifizierungsstatus aller Domains und setzen konsistente Sicherheitsregeln um. Dank Multi-Tenant-Architektur können Sie alle Kunden aus einer Oberfläche betreuen und dennoch die Daten sauber trennen.

Die Red Sift OnDMARC-Plattform skaliert von kleinen MSPs bis hin zu großen Managed Security Service Providern mit Hunderten von Kundendomains.

[1] „DMARC vs SPF vs DKIM – Der ultimative Vergleich.“ courier.com. https://www.courier.com/guides/dmarc-vs-spf-vs-dkim

[2] „Was sind DMARC, DKIM und SPF?“ Cloudflare. https://www.cloudflare.com/learning/email-security/dmarc-dkim-spf/

[3] „SPF, DKIM, DMARC: Die 3 Säulen der E-Mail-Authentifizierung.“ higherlogic.com, 01.01.2024. https://www.higherlogic.com/blog/spf-dkim-dmarc-email-authentication/