Inhaltsverzeichnis
Warum E-Mail-Authentifizierung Pflicht ist
E-Mail ist über Jahrzehnte gewachsen — und wurde ursprünglich ohne jeden Schutz gegen Absenderfälschung entworfen. Das Absenderfeld einer E-Mail ist zunächst nichts weiter als ein Textfeld, das der versendende Server frei ausfüllen kann. Ohne zusätzliche Schutzmechanismen kann also technisch jeder eine Mail verschicken, die aussieht, als käme sie von [email protected]. Das ist keine theoretische Lücke, sondern die Grundlage der meisten erfolgreichen Angriffe auf Unternehmen.
Genau hier setzen die drei Protokolle SPF, DKIM und DMARC an. Sie ergänzen das E-Mail-System um eine Absenderprüfung: Der empfangende Server kann nachvollziehen, ob eine eingehende Mail wirklich von einem Server stammt, der für die angebliche Absender-Domain senden darf. Wer diese Schutzschicht nicht einrichtet, überlässt die eigene Domain praktisch zur freien Nutzung durch jeden, der sie missbrauchen möchte.
Zwei Angriffsformen machen das besonders greifbar. Beim E-Mail-Spoofing fälschen Angreifer die Absenderadresse, um im Namen einer bekannten Firma oder Behörde Phishing-Mails an Dritte oder an deren Kunden zu versenden — der Reputationsschaden trifft den Domain-Inhaber, obwohl seine Systeme gar nicht kompromittiert wurden. Beim CEO-Fraud (auch Business E-Mail Compromise) täuschen Angreifer vor, die Mail komme von der Geschäftsführung, und weisen die Buchhaltung zu einer dringenden, vertraulichen Überweisung an. Eine korrekt gesetzte DMARC-Policy verhindert, dass solche gefälschten Mails aus dem eigenen Domainnamen überhaupt zugestellt werden.
Hinzu kommt ein handfester geschäftlicher Grund: Große Mailanbieter wie Google und Microsoft verlangen inzwischen von versendenden Domains eine funktionierende Authentifizierung, sonst landen die Nachrichten im Spam oder werden abgewiesen. E-Mail-Authentifizierung ist damit nicht mehr nur Sicherheitsmaßnahme, sondern Voraussetzung für zuverlässige Zustellbarkeit. Wir haben die Rolle dieser Protokolle bereits im Beitrag zu Phishing-Mails erkennen gestreift — hier vertiefen wir die Technik dahinter.
SPF erklärt: Wer darf für Ihre Domain senden?
SPF steht für Sender Policy Framework. Der Grundgedanke ist einfach: Sie hinterlegen in Ihrem DNS eine öffentlich abrufbare Liste der Server und Dienste, die berechtigt sind, E-Mails im Namen Ihrer Domain zu versenden. Empfängt ein Mailserver eine Nachricht, schaut er in dieser Liste nach, ob der sendende Server dort aufgeführt ist.
Technisch handelt es sich um einen TXT-Eintrag im DNS Ihrer Domain. Ein einfacher SPF-Eintrag sieht etwa so aus:
v=spf1 include:_spf.google.com include:servers.mailanbieter.de -all
Die Bestandteile lassen sich gut lesen: v=spf1 kennzeichnet die SPF-Version. Die include:-Einträge verweisen auf die Sendedienste, die Sie tatsächlich nutzen — zum Beispiel Ihren Mailanbieter, ein Newsletter-Tool oder ein CRM. Der Abschluss -all ist entscheidend: Er weist empfangende Server an, alle nicht gelisteten Absender als unzulässig zu behandeln. Ein ~all (Softfail) markiert sie nur als verdächtig, ein +all würde alles erlauben und macht SPF wirkungslos.
Zwei praktische Grenzen sollten Sie kennen. Erstens gilt SPF für den technischen Envelope-Absender, nicht zwingend für die im Client sichtbare Adresse — deshalb reicht SPF allein nicht aus. Zweitens überlebt SPF keine klassischen Weiterleitungen: Leitet ein Empfänger Ihre Mail an eine andere Adresse weiter, ändert sich der sendende Server, und die SPF-Prüfung schlägt fehl. Genau diese Lücke schließt DKIM.
DKIM erklärt: Die kryptografische Signatur
DKIM steht für DomainKeys Identified Mail und arbeitet mit asymmetrischer Kryptografie. Ihr sendender Mailserver signiert jede ausgehende Nachricht mit einem privaten Schlüssel. Der zugehörige öffentliche Schlüssel liegt als DNS-Eintrag in Ihrer Domain. Der empfangende Server ruft diesen öffentlichen Schlüssel ab und prüft damit die Signatur.
Diese Prüfung leistet zweierlei. Sie belegt erstens, dass die Mail tatsächlich über einen Server versendet wurde, der Zugriff auf den privaten Schlüssel Ihrer Domain hat. Und sie belegt zweitens, dass zentrale Teile der Nachricht — etwa Absender, Betreff und Inhalt — seit dem Versand nicht verändert wurden. Wird auch nur ein signiertes Feld nachträglich manipuliert, passt die Signatur nicht mehr, und die DKIM-Prüfung schlägt fehl.
Der öffentliche Schlüssel wird unter einem sogenannten Selector im DNS abgelegt, etwa selector1._domainkey.ihre-firma.de. Der Selector erlaubt es, mehrere Schlüssel parallel zu betreiben und Schlüssel geordnet auszutauschen (Key-Rotation), ohne die Zustellung zu unterbrechen. Anders als SPF übersteht eine DKIM-Signatur in der Regel auch Weiterleitungen, solange der signierte Inhalt unverändert bleibt. Aus Sicht der Netzwerkpraxis ist DKIM damit die robustere Prüfung — aber auch sie entfaltet ihre volle Wirkung erst gemeinsam mit DMARC, das beide Ergebnisse an die sichtbare Absenderadresse bindet.
DMARC erklärt: Regeln und Reports
DMARC steht für Domain-based Message Authentication, Reporting & Conformance. Es ist die Klammer, die SPF und DKIM zusammenführt und praktisch nutzbar macht. DMARC leistet drei Dinge: Es verlangt, dass die sichtbare Absenderadresse zu den SPF- oder DKIM-Ergebnissen passt (Alignment), es legt fest, was mit nicht bestandenen Mails geschehen soll, und es sorgt für Berichte.
Der zentrale Parameter ist die Policy. Sie kennt drei Stufen:
- none — Es passiert nichts. Nicht authentifizierte Mails werden trotzdem zugestellt. Diese Stufe dient ausschließlich der Beobachtung: Sie erhalten Reports, aber keinen aktiven Schutz.
- quarantine — Verdächtige Mails, die die Prüfung nicht bestehen, werden in den Spam-Ordner verschoben. Ein Zwischenschritt auf dem Weg zum vollen Schutz.
- reject — Nicht authentifizierte Mails werden bereits vom empfangenden Server abgewiesen und erreichen den Posteingang gar nicht erst. Das ist das eigentliche Schutzziel.
Ein DMARC-Eintrag ist ebenfalls ein TXT-Record, hinterlegt unter _dmarc.ihre-firma.de, und sieht zum Beispiel so aus:
v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s
Besonders wertvoll ist der Reporting-Teil. Über die rua-Adresse erhalten Sie aggregierte Berichte darüber, welche Server im Namen Ihrer Domain senden, wie viele Mails SPF und DKIM bestanden haben und wie viele nicht. Diese Reports sind das entscheidende Werkzeug: Sie machen sichtbar, welche legitimen Dienste Sie noch nicht korrekt eingebunden haben — und ob jemand Ihre Domain missbraucht. Ohne diese Sichtbarkeit lässt sich eine strenge Policy nicht gefahrlos aktivieren.
Der häufigste Fehler: DMARC auf "none"
In der Praxis sehen wir immer wieder dasselbe Muster: SPF ist gesetzt, DKIM signiert, ein DMARC-Eintrag existiert — aber die Policy steht auf p=none und bleibt dort. Formal ist DMARC damit "vorhanden". Wirksam ist es nicht.
Bei none zieht das System keinerlei Konsequenzen: Eine gefälschte Mail, die vorgibt, von Ihrer Domain zu stammen, besteht die Prüfung nicht — und wird trotzdem zugestellt. Der einzige Effekt der none-Stufe ist, dass Sie Reports erhalten. Das ist als Startpunkt sinnvoll und richtig, denn ohne diese Beobachtungsphase riskieren Sie, eigene legitime Mails zu blockieren. Der Fehler liegt nicht darin, mit none zu beginnen, sondern darin, dort dauerhaft stehenzubleiben.
Der Grund für diesen Stillstand ist meist Unsicherheit: Die Verantwortlichen fürchten, mit einer strengeren Policy versehentlich Rechnungen, Newsletter oder Systemmails abzuschneiden. Diese Sorge ist berechtigt — aber sie löst sich genau über die Reports auf. Wer die aggregierten Berichte einige Wochen auswertet, sieht präzise, welche Dienste noch fehlen, korrigiert die SPF- und DKIM-Einträge und kann die Policy anschließend gefahrlos verschärfen. Eine Domain, die dauerhaft auf none bleibt, hat den eigentlichen Schutz nie aktiviert — sie beobachtet nur zu, wie sie missbraucht werden könnte.
Einrichtung in der Praxis: DNS, Reihenfolge, Monitoring
Die Einrichtung findet vollständig im DNS Ihrer Domain statt — dort, wo auch Ihre Webseiten- und Mailserver-Einträge liegen. Wer aus der Netzwerkpraxis kommt, erkennt schnell, dass es hier nicht um komplexe Software geht, sondern um saubere, korrekt gesetzte TXT-Records und eine disziplinierte Reihenfolge. Genau diese Reihenfolge ist der Schlüssel zu einer Umstellung ohne Zustellausfälle.
Bewährt hat sich dieser Ablauf:
- Bestandsaufnahme: Erfassen Sie alle Dienste, die in Ihrem Namen senden — Mailserver, Newsletter-Tool, CRM, Ticketsystem, Buchhaltungssoftware, Monitoring-Systeme. Jeder übersehene Dienst wird später zum Zustellproblem.
- SPF setzen: Erstellen Sie einen SPF-TXT-Eintrag, der alle diese Dienste über
include:abdeckt, und schließen Sie ihn zunächst mit~allab. Achten Sie auf das Limit von zehn DNS-Lookups pro SPF-Eintrag. - DKIM aktivieren: Aktivieren Sie DKIM-Signierung bei jedem sendenden Dienst und hinterlegen Sie die jeweils bereitgestellten öffentlichen Schlüssel als DNS-Einträge unter dem passenden Selector.
- DMARC mit "none" starten: Legen Sie den DMARC-Eintrag zunächst mit
p=noneund einerrua-Reportadresse an. Jetzt beobachten Sie, ohne etwas zu blockieren. - Reports auswerten: Werten Sie die aggregierten Berichte über mehrere Wochen aus. Ergänzen Sie fehlende legitime Sender in SPF und DKIM, bis in den Reports nur noch autorisierte Quellen bestehen.
- Policy stufenweise verschärfen: Wechseln Sie zunächst auf
p=quarantine, beobachten Sie erneut, und stellen Sie erst dann aufp=rejectum. Wer möchte, kann über den Parameterpctzunächst nur einen Teil der Mails der Policy unterwerfen. - Dauerhaft überwachen: Behalten Sie die Reports auch danach im Blick. Neue Dienste, geänderte Anbieter oder Missbrauchsversuche zeigen sich zuerst hier.
Das Monitoring ist kein einmaliger Schritt, sondern ein laufender Prozess — vergleichbar mit der Beobachtung von Interface- und Routing-Zuständen im Netzwerkbetrieb: Ein Zustand ist nie "fertig", sondern will kontinuierlich verifiziert werden. Für die Auswertung der maschinenlesbaren XML-Reports gibt es spezialisierte Dienste, die die Berichte aufbereiten und Auffälligkeiten hervorheben — gerade für KMU ohne eigene Mailadministration eine sinnvolle Ergänzung.
Wenn Sie diese Umstellung nicht selbst begleiten möchten, unterstützen wir Sie im Rahmen unserer IT-Sicherheitsberatung von der Bestandsaufnahme bis zur reject-Policy. E-Mail-Authentifizierung ist zudem nur ein Baustein — sie greift am besten zusammen mit weiteren Schutzmaßnahmen wie einem durchdachten Ransomware-Schutz und geschulten Mitarbeitern. Bei Fragen zur konkreten Konfiguration Ihrer Domain erreichen Sie uns jederzeit über das Kontaktformular.
