E-Mail-Sicherheit: SPF, DKIM, DMARC und Verschlüsselung richtig einrichten

Warum E-Mail der häufigste Angriffsvektor ist

E-Mail ist das Kommunikationsmittel Nummer eins in Unternehmen. Und genau das macht sie zum bevorzugten Ziel von Angreifern. Über 90 Prozent aller Cyberangriffe beginnen mit einer E-Mail, sei es eine Phishing-Mail mit gefälschtem Absender, ein Anhang mit Schadsoftware oder eine täuschend echte Nachricht, die den Empfänger zur Überweisung eines Geldbetrags auffordert.

Die Gründe liegen in der Architektur des E-Mail-Protokolls selbst. SMTP (Simple Mail Transfer Protocol), das Protokoll, über das E-Mails versendet werden, stammt aus den frühen 1980er Jahren. Es wurde für ein vertrauenswürdiges akademisches Netzwerk entworfen, nicht für ein Internet voller Krimineller. In seiner Grundform bietet SMTP keinerlei Authentifizierung: Jeder kann eine E-Mail senden und dabei eine beliebige Absenderadresse angeben. Es gibt keinen eingebauten Mechanismus, der prüft, ob der Absender tatsächlich derjenige ist, der er vorgibt zu sein.

Das ist so, als könnte jeder einen Brief verschicken und einen beliebigen Absender auf den Umschlag schreiben, ohne dass die Post das jemals überprüft. Genau das passiert bei E-Mail, und genau dieses Problem adressieren SPF, DKIM und DMARC.

Phishing nutzt gefälschte Absenderadressen, um Empfänger zu täuschen. Die Mail sieht aus, als käme sie von der Hausbank, vom Geschäftsführer oder von Microsoft, stammt aber von einem Angreifer. Das Ziel: Login-Daten abgreifen, Malware installieren oder zu einer Handlung verleiten.

Business Email Compromise (BEC) ist die gezielte Variante: Der Angreifer gibt sich als Geschäftsführer oder Lieferant aus und weist die Buchhaltung an, eine Überweisung auf ein geändertes Konto auszuführen. BEC-Angriffe verursachen weltweit Milliardenschäden, weil sie keine Schadsoftware benötigen und von technischen Schutzmaßnahmen oft nicht erkannt werden.

E-Mail-Spoofing bedeutet, dass ein Angreifer E-Mails mit der Domain deines Unternehmens als Absender versendet, ohne dass du davon weißt. Deine Kunden und Partner erhalten dann Phishing-Mails, die aussehen, als kämen sie von dir. Das beschädigt nicht nur deren Sicherheit, sondern auch deinen Ruf und dein Vertrauen.

SPF, DKIM und DMARC sind die drei Protokolle, die dieses Grundproblem lösen. Sie sind keine optionalen Nice-to-haves, sondern gehören zur Grundhygiene der E-Mail-Sicherheit. Und sie sind mit überschaubarem Aufwand konfigurierbar, wenn du weißt, wie.

SPF: Wer darf E-Mails für deine Domain senden?

SPF (Sender Policy Framework) ist die erste Verteidigungslinie gegen E-Mail-Spoofing. Es beantwortet eine einfache Frage: Welche Server sind berechtigt, E-Mails im Namen deiner Domain zu versenden?

Wie SPF funktioniert

SPF arbeitet über einen DNS-TXT-Record. In diesem Record listest du alle IP-Adressen und Server auf, die berechtigt sind, E-Mails mit deiner Domain als Absender zu senden. Wenn ein empfangender Mailserver eine E-Mail erhält, die angeblich von deiner Domain stammt, prüft er den SPF-Record deiner Domain und vergleicht die IP-Adresse des sendenden Servers mit der Liste der berechtigten Server. Stimmt die IP überein, besteht die SPF-Prüfung. Stimmt sie nicht überein, schlägt die Prüfung fehl.

SPF-Record erstellen

Ein SPF-Record ist ein DNS-TXT-Eintrag für deine Domain. Er beginnt immer mit der Versionsangabe v=spf1, gefolgt von den berechtigten Quellen, und endet mit einer Anweisung, wie mit nicht-berechtigten Absendern umgegangen werden soll.

Ein typischer SPF-Record für ein mittelständisches Unternehmen sieht so aus:

v=spf1 mx a:mail.example.de ip4:203.0.113.10 include:_spf.google.com include:spf.protection.outlook.com -all

Die einzelnen Bestandteile bedeuten:

mx erlaubt allen Servern, die im MX-Record deiner Domain stehen, E-Mails zu senden. Das ist der naheliegendste Eintrag, denn dein Mailserver ist per Definition ein berechtigter Absender.

a:mail.example.de erlaubt dem Server mit dem Hostnamen mail.example.de, E-Mails zu senden. Nützlich, wenn du einen Server hast, der E-Mails sendet, aber nicht im MX-Record steht (z. B. ein Applikationsserver, der Benachrichtigungen verschickt).

ip4:203.0.113.10 erlaubt einer bestimmten IPv4-Adresse das Senden. Verwende das für Server, die keinen eigenen Hostnamen haben oder die du explizit benennen möchtest.

include:_spf.google.com bindet den SPF-Record eines anderen Dienstes ein. Wenn du Google Workspace für deine E-Mails nutzt, musst du Googles SPF-Record einbinden, damit die Google-Server als berechtigte Absender gelten. Gleiches gilt für Microsoft 365, Mailchimp, HubSpot oder jeden anderen Dienst, der in deinem Namen E-Mails versendet.

-all ist der Abschluss und bedeutet: Alle Server, die nicht in diesem Record aufgeführt sind, sind nicht berechtigt, und E-Mails von diesen Servern sollen abgelehnt werden (Hard Fail). Die mildere Variante ~all (Soft Fail) markiert nicht-konforme Mails als verdächtig, lehnt sie aber nicht ab. Für die Einführungsphase ist ~all sinnvoll, für den Dauerbetrieb empfiehlt sich -all.

SPF-Grenzen

SPF hat eine wichtige technische Einschränkung: Es prüft die Envelope-From-Adresse (den technischen Absender), nicht die From-Adresse im Header (die der Empfänger sieht). Ein Angreifer kann eine E-Mail senden, bei der die Envelope-From-Adresse eine eigene Domain ist (SPF-Prüfung bestanden), aber die angezeigte From-Adresse deine Domain vortäuscht. Deshalb reicht SPF allein nicht aus. Du brauchst zusätzlich DKIM und DMARC.

Außerdem gibt es ein DNS-Lookup-Limit: Ein SPF-Record darf maximal zehn DNS-Lookups auslösen. Jedes include, a, mx und redirect zählt als ein Lookup. Bei Unternehmen, die viele externe Dienste nutzen (Marketing-Plattform, Helpdesk, CRM, Buchhaltungssoftware, Newsletter-Tool), stößt man schnell an diese Grenze. Die Lösung ist SPF-Flattening, also das Auflösen der Include-Ketten in direkte IP-Adressen, was aber regelmäßig aktualisiert werden muss, wenn sich die IP-Adressen der Dienste ändern.

DKIM: Kryptografische Signatur für E-Mails

DKIM (DomainKeys Identified Mail) ergänzt SPF um eine kryptografische Komponente. Während SPF prüft, ob der sendende Server berechtigt ist, prüft DKIM, ob die E-Mail unterwegs manipuliert wurde und ob sie tatsächlich von der angegebenen Domain autorisiert wurde.

Wie DKIM funktioniert

DKIM basiert auf asymmetrischer Kryptografie. Dein Mailserver signiert jede ausgehende E-Mail mit einem privaten Schlüssel. Der zugehörige öffentliche Schlüssel wird als DNS-TXT-Record veröffentlicht. Der empfangende Mailserver liest die Signatur aus dem E-Mail-Header, holt den öffentlichen Schlüssel aus dem DNS und verifiziert die Signatur. Wenn die Signatur gültig ist, weiß der Empfänger: Diese E-Mail wurde tatsächlich von einem Server gesendet, der den privaten Schlüssel der Domain besitzt, und der Inhalt wurde unterwegs nicht verändert.

Die Signatur umfasst definierte Header-Felder (From, To, Subject, Date) und den Body der E-Mail. Wenn irgendetwas davon nach dem Signieren verändert wird, schlägt die DKIM-Prüfung fehl.

DKIM einrichten

Die Einrichtung von DKIM besteht aus zwei Schritten: Schlüsselpaar generieren und den öffentlichen Schlüssel im DNS veröffentlichen.

Schritt 1: Schlüsselpaar generieren. Dein Mailserver oder dein E-Mail-Provider generiert ein Schlüsselpaar. Bei Microsoft 365 geschieht das automatisch in der DKIM-Konfiguration im Security-Portal. Bei einem eigenen Mailserver kannst du das Schlüsselpaar mit OpenSSL generieren. Verwende mindestens eine Schlüssellänge von 2048 Bit.

Schritt 2: DNS-Record erstellen. Der öffentliche Schlüssel wird als TXT-Record unter einem speziellen Hostnamen veröffentlicht. Das Format ist: selector._domainkey.example.de. Der Selector ist ein frei wählbarer Name, der den Schlüssel identifiziert (z. B. „s1" oder „mail2024"). Der Record enthält den öffentlichen Schlüssel im Base64-Format.

Ein DKIM-DNS-Record sieht beispielsweise so aus:

s1._domainkey.example.de IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Schritt 3: Signierung aktivieren. Konfiguriere deinen Mailserver so, dass er ausgehende E-Mails mit dem privaten Schlüssel signiert. Bei Microsoft 365 und Google Workspace ist das ein Schalter in der Administrationsoberfläche. Bei Postfix oder Exim konfigurierst du OpenDKIM oder rspamd als Milter.

DKIM-Schlüsselrotation

Wie bei allen kryptografischen Schlüsseln empfiehlt es sich, DKIM-Schlüssel regelmäßig zu rotieren. Die Kryptografie-Richtlinie deines Unternehmens sollte auch die DKIM-Rotation abdecken. Ein jährlicher Wechsel ist gängige Praxis. Dafür nutzt du den Selector: Du generierst ein neues Schlüsselpaar mit einem neuen Selector (z. B. „s2"), veröffentlichst den neuen öffentlichen Schlüssel im DNS, konfigurierst den Mailserver auf den neuen Selector und entfernst nach einer Übergangszeit den alten DNS-Record. Durch die Verwendung verschiedener Selectoren können alter und neuer Schlüssel parallel existieren, was eine unterbrechungsfreie Rotation ermöglicht.

DMARC: Das Zusammenspiel von SPF und DKIM

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist das Dach über SPF und DKIM. Es löst zwei Probleme, die SPF und DKIM allein nicht adressieren: Was soll mit E-Mails passieren, die die Prüfungen nicht bestehen? Und wie erfährt der Domain-Inhaber, ob seine Domain für Spoofing missbraucht wird?

Wie DMARC funktioniert

DMARC prüft, ob eine eingehende E-Mail entweder die SPF-Prüfung oder die DKIM-Prüfung bestanden hat und ob die dabei verifizierte Domain mit der From-Adresse im Header übereinstimmt. Diese Übereinstimmung nennt sich Alignment. SPF-Alignment bedeutet, dass die Domain in der Envelope-From-Adresse mit der Domain in der From-Header-Adresse übereinstimmt. DKIM-Alignment bedeutet, dass die Domain in der DKIM-Signatur (d=) mit der From-Header-Domain übereinstimmt.

Das Alignment ist der entscheidende Fortschritt gegenüber SPF und DKIM allein. SPF allein prüft nur die Envelope-From-Domain, die der Empfänger gar nicht sieht. DKIM allein prüft nur die signierte Domain, die ebenfalls nicht zwingend die angezeigte Absenderdomain sein muss. DMARC verknüpft beide Prüfungen mit der Domain, die der Empfänger tatsächlich im From-Feld sieht.

DMARC-Policy und DNS-Record

Der DMARC-Record wird als DNS-TXT-Eintrag unter _dmarc.example.de veröffentlicht. Er definiert die Policy (was mit nicht-konformen Mails passieren soll) und die Reporting-Adresse (wohin die Berichte gesendet werden).

Ein DMARC-Record sieht so aus:

_dmarc.example.de IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.de; ruf=mailto:dmarc-forensic@example.de; pct=100; adkim=s; aspf=s"

Die Parameter bedeuten:

p=reject ist die Policy. Drei Stufen stehen zur Verfügung: none (nur beobachten, keine Aktion), quarantine (verdächtige Mails in den Spam-Ordner verschieben), reject (nicht-konforme Mails ablehnen). Die Einführung erfolgt schrittweise von none über quarantine zu reject.

rua=mailto:dmarc-reports@example.de definiert die Adresse für aggregierte Berichte. Empfangende Mailserver senden tägliche oder wöchentliche Zusammenfassungen, die zeigen, welche Server E-Mails mit deiner Domain gesendet haben und ob sie SPF/DKIM bestanden haben. Diese Berichte sind Gold wert für die Analyse.

ruf=mailto:dmarc-forensic@example.de definiert die Adresse für forensische Berichte. Diese enthalten Details zu einzelnen fehlgeschlagenen E-Mails. Nicht alle Mailserver senden forensische Berichte, und sie können sensible Informationen enthalten.

pct=100 gibt an, auf wie viel Prozent der E-Mails die Policy angewendet wird. In der Einführungsphase kannst du mit pct=10 beginnen und schrittweise erhöhen, um das Risiko zu minimieren.

adkim=s und aspf=s setzen das Alignment auf strict. Im strikten Modus müssen die Domains exakt übereinstimmen (example.de = example.de). Im relaxed Modus (adkim=r) reicht es, wenn die Organisationsdomain übereinstimmt (sub.example.de passt zu example.de). Für den Anfang ist relaxed sinnvoll, für maximale Sicherheit wechselst du auf strict.

DMARC schrittweise einführen

Die Einführung von DMARC sollte niemals mit p=reject beginnen. Der Grund: Du weißt möglicherweise nicht alle Server, die legitimerweise E-Mails mit deiner Domain senden. Wenn du sofort auf reject gehst, könnten legitime E-Mails (Newsletter, Rechnungen aus dem Buchhaltungssystem, Benachrichtigungen aus dem Helpdesk) plötzlich abgelehnt werden.

Der empfohlene Fahrplan:

Woche 1 bis 2: SPF und DKIM einrichten. Stelle sicher, dass alle legitimen sendenden Server im SPF-Record stehen und DKIM aktiviert ist.

Woche 3: DMARC mit p=none aktivieren. In diesem Modus werden keine E-Mails blockiert, aber du erhältst Berichte. Analysiere die DMARC-Reports über zwei bis vier Wochen und identifiziere alle Server, die E-Mails mit deiner Domain senden. Ergänze fehlende Server im SPF-Record und aktiviere DKIM dort, wo es noch fehlt.

Woche 5 bis 6: Auf p=quarantine umstellen. Nicht-konforme Mails landen jetzt im Spam-Ordner statt im Posteingang. Beobachte die Reports weiter und reagiere auf Beschwerden (z. B. „Meine Rechnungs-Mails kommen nicht mehr an"). Beginne mit pct=25 und erhöhe schrittweise auf 100.

Ab Woche 8: Auf p=reject umstellen. Nicht-konforme Mails werden jetzt abgelehnt. Der empfangende Server nimmt sie gar nicht erst an. Beginne auch hier mit pct=25 und erhöhe schrittweise. Wenn nach einigen Wochen bei pct=100 keine Probleme auftreten, hast du eine vollständige DMARC-Implementierung erreicht.

DMARC-Reports lesen und auswerten

Die aggregierten DMARC-Reports (rua) kommen als XML-Dateien per E-Mail. Im Rohformat sind sie schwer lesbar, aber es gibt kostenlose und kostenpflichtige Tools, die sie aufbereiten: DMARC Analyzer, Postmark DMARC, dmarcian, Valimail oder das Open-Source-Tool parsedmarc.

Die Reports zeigen dir für jeden sendenden Server: IP-Adresse, Anzahl der gesendeten Mails, SPF-Ergebnis (pass/fail), DKIM-Ergebnis (pass/fail), DMARC-Ergebnis (pass/fail), angewandte Policy. Das ist die Grundlage für die Analyse: Welche Server senden legitim? Welche Server sind nicht autorisiert? Gibt es Spoofing-Versuche?

Richte dir einen wöchentlichen Review-Termin ein, an dem du die DMARC-Reports durchgehst. In der Einführungsphase ist das besonders wichtig, weil du damit fehlende SPF-Einträge und DKIM-Konfigurationen erkennst. Im laufenden Betrieb zeigen die Reports Spoofing-Versuche und Konfigurationsänderungen (z. B. ein neuer Dienstleister, der E-Mails mit deiner Domain senden will).

TLS-Verschlüsselung: Transport absichern

SPF, DKIM und DMARC kümmern sich um Authentizität und Integrität. Die Vertraulichkeit des E-Mail-Transports wird durch TLS (Transport Layer Security) sichergestellt.

Opportunistisches TLS

Die meisten Mailserver unterstützen heute STARTTLS, eine Erweiterung von SMTP, die die Verbindung zwischen zwei Mailservern verschlüsselt. Das Problem: STARTTLS ist opportunistisch. Wenn der empfangende Server kein TLS unterstützt oder die TLS-Verhandlung fehlschlägt, wird die E-Mail unverschlüsselt übertragen. Ein Angreifer, der die Verbindung kontrolliert (Man-in-the-Middle), kann die TLS-Verhandlung gezielt stören und die Verschlüsselung verhindern.

MTA-STS: TLS erzwingen

MTA-STS (SMTP MTA Strict Transport Security) löst dieses Problem. Es teilt sendenden Mailservern mit, dass deine Domain TLS zwingend erfordert. Wenn die TLS-Verhandlung fehlschlägt, wird die E-Mail nicht unverschlüsselt gesendet, sondern die Zustellung schlägt fehl. Das ist ein deutlich höheres Sicherheitsniveau.

Die Einrichtung von MTA-STS besteht aus zwei Teilen: einer Policy-Datei, die unter https://mta-sts.example.de/.well-known/mta-sts.txt erreichbar sein muss, und einem DNS-TXT-Record unter _mta-sts.example.de, der auf die Policy verweist. Die Policy-Datei definiert den Modus (testing oder enforce), die berechtigten Mailserver und die maximale Cache-Dauer.

DANE und TLSA

DANE (DNS-Based Authentication of Named Entities) ist eine alternative Methode zur TLS-Absicherung, die auf DNSSEC aufbaut. Über TLSA-Records im DNS wird das TLS-Zertifikat des Mailservers direkt verifiziert, ohne dass eine Certificate Authority (CA) vertraut werden muss. DANE bietet ein höheres Sicherheitsniveau als MTA-STS, setzt aber DNSSEC voraus, was die Einrichtung komplexer macht. Für den Mittelstand ist MTA-STS in den meisten Fällen der pragmatischere Weg.

Ende-zu-Ende-Verschlüsselung: S/MIME vs. PGP

TLS verschlüsselt den Transport, nicht den Inhalt. Auf dem Mailserver liegt die E-Mail im Klartext. Für Situationen, in denen die E-Mail selbst verschlüsselt sein muss (z. B. vertrauliche Verträge, personenbezogene Daten, Geschäftsgeheimnisse), brauchst du Ende-zu-Ende-Verschlüsselung. Die beiden etablierten Verfahren sind S/MIME und PGP.

S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extensions) nutzt X.509-Zertifikate, die von einer Certificate Authority ausgestellt werden. Jeder Mitarbeiter bekommt ein persönliches Zertifikat, das im E-Mail-Client installiert wird. Ausgehende E-Mails werden mit dem Zertifikat des Absenders signiert und mit dem öffentlichen Schlüssel des Empfängers verschlüsselt.

Der Vorteil von S/MIME: Es ist in die gängigen E-Mail-Clients integriert (Outlook, Apple Mail, Thunderbird) und wird im Unternehmensumfeld weithin unterstützt. Zertifikate können zentral über eine interne CA oder einen kommerziellen Anbieter verwaltet werden.

Der Nachteil: Jeder Kommunikationspartner braucht ein eigenes Zertifikat. Die Einrichtung und Verwaltung ist aufwändig, besonders wenn du mit vielen externen Partnern kommunizierst, die selbst kein S/MIME einsetzen. Außerdem muss der öffentliche Schlüssel des Empfängers vorab bekannt sein, was den Erstkontakt erschwert.

PGP / OpenPGP

PGP (Pretty Good Privacy) und sein offener Standard OpenPGP funktionieren nach dem gleichen Prinzip wie S/MIME, nutzen aber ein dezentrales Vertrauensmodell (Web of Trust) statt zentraler Certificate Authorities. Schlüssel werden von den Benutzern selbst erstellt und über Keyserver oder direkte Weitergabe verteilt.

PGP wird im Unternehmensumfeld seltener eingesetzt als S/MIME, weil die Schlüsselverwaltung dezentral und dadurch schwerer zu kontrollieren ist. In der Open-Source-Community und bei technisch versierten Anwendern ist PGP dagegen verbreitet. Für den Unternehmenseinsatz mit zentraler Verwaltung ist S/MIME in der Regel die bessere Wahl.

Pragmatische Empfehlung

Für die meisten mittelständischen Unternehmen ist Ende-zu-Ende-Verschlüsselung nicht für den gesamten E-Mail-Verkehr praktikabel. Der Aufwand für Schlüsselmanagement und die Anforderung, dass beide Seiten das Verfahren unterstützen müssen, machen einen flächendeckenden Einsatz schwierig. Ein pragmatischer Ansatz: S/MIME für die Kommunikation mit definierten Partnern einrichten, bei denen regelmäßig vertrauliche Daten ausgetauscht werden (die Verschlüsselungsstrategie deines Unternehmens sollte das abdecken) (z. B. Steuerberater, Rechtsanwälte, Geschäftspartner mit NDA). Für den allgemeinen E-Mail-Verkehr reicht die Kombination aus TLS-Transportverschlüsselung und SPF/DKIM/DMARC.

E-Mail-Gateway und Filterung

SPF, DKIM und DMARC schützen vor Absenderfälschung. Sie schützen nicht vor dem Inhalt einer E-Mail: einer Phishing-URL, einem Malware-Anhang oder einem Social-Engineering-Text. Dafür brauchst du ein E-Mail-Security-Gateway.

Was ein E-Mail-Gateway leistet

Ein E-Mail-Security-Gateway (auch Secure Email Gateway, SEG) sitzt zwischen dem Internet und deinem Mailserver. Es prüft jede eingehende und ausgehende E-Mail auf verschiedene Bedrohungen:

Spam-Filterung: Die Grundfunktion. Das Gateway klassifiziert E-Mails anhand von Absender-Reputation, Inhaltsanalyse, Bayes-Filtern und Blacklists als Spam oder Ham.

Malware-Scanning: Anhänge werden auf Schadsoftware geprüft, idealerweise in einer Sandbox, die den Anhang in einer isolierten Umgebung ausführt und das Verhalten analysiert.

URL-Rewriting und Time-of-Click-Schutz: URLs in E-Mails werden umgeschrieben, sodass sie über das Gateway geleitet werden. Wenn der Empfänger auf den Link klickt, prüft das Gateway in Echtzeit, ob die Zielseite zwischenzeitlich als Phishing-Seite eingestuft wurde.

Impersonation Detection: Das Gateway erkennt Versuche, sich als interne Mitarbeiter oder bekannte Kontakte auszugeben, auch wenn die Domain nicht exakt gefälscht ist (z. B. example-de.com statt example.de).

DLP (Data Loss Prevention): Ausgehende E-Mails werden auf vertrauliche Inhalte geprüft (Kreditkartennummern, Sozialversicherungsnummern, als vertraulich klassifizierte Dokumente). E-Mails, die gegen die DLP-Policy verstoßen, werden zurückgehalten.

Gateway-Lösungen für den Mittelstand

Für Unternehmen, die Microsoft 365 einsetzen, bietet Microsoft Defender for Office 365 ein integriertes E-Mail-Security-Gateway mit Safe Attachments, Safe Links und Anti-Phishing-Policies. Für Google Workspace gibt es vergleichbare Funktionen in der Enterprise-Lizenz.

Eigenständige Lösungen wie Barracuda Email Security Gateway, Proofpoint Essentials, Mimecast oder NoSpamProxy bieten erweiterte Funktionen und lassen sich unabhängig vom E-Mail-Provider einsetzen. Für KMU mit einem On-Premise-Mailserver ist NoSpamProxy eine verbreitete Lösung im deutschsprachigen Raum.

Die Kosten liegen typischerweise bei 2 bis 5 Euro pro Postfach und Monat. Angesichts der Schäden, die ein erfolgreicher Phishing-Angriff verursachen kann, ist das eine Investition, die sich vielfach rechnet.

Testen und Monitoring

Die Konfiguration von SPF, DKIM und DMARC ist kein einmaliger Akt, sondern erfordert regelmäßige Überprüfung und Pflege.

SPF, DKIM und DMARC testen

Nach der Einrichtung prüfst du die Konfiguration mit dafür vorgesehenen Testtools. MXToolbox, Mail Tester (mail-tester.com), DMARC Analyzer und Google Admin Toolbox bieten kostenlose Online-Tests, die deinen SPF-Record auf Syntax-Fehler prüfen, DKIM-Signaturen verifizieren und den DMARC-Record validieren.

Ein einfacher Praxistest: Sende eine E-Mail an eine Gmail-Adresse und prüfe den E-Mail-Header (in Gmail unter „Original anzeigen"). Dort siehst du die Ergebnisse der SPF-, DKIM- und DMARC-Prüfung. Alle drei sollten „PASS" anzeigen.

Teste auch die Negativ-Fälle: Was passiert, wenn jemand eine E-Mail mit deiner Domain von einem nicht autorisierten Server sendet? Bei einer korrekt konfigurierten DMARC-Policy mit p=reject sollte diese E-Mail abgelehnt werden.

Laufendes Monitoring

DMARC-Reports: Wie beschrieben, erhältst du regelmäßig aggregierte Berichte. Richte einen wöchentlichen Review ein und achte auf neue, nicht autorisierte Absender, steigende Fehlerzahlen und Veränderungen im Mailvolumen.

SPF-Record-Pflege: Jedes Mal, wenn du einen neuen Dienst einführst, der E-Mails mit deiner Domain sendet (neues Marketing-Tool, neues Ticketsystem, neuer externer Dienstleister), muss der SPF-Record aktualisiert werden. Vergisst du das, schlagen die SPF-Prüfungen für diese E-Mails fehl, und bei p=reject werden sie abgelehnt.

DKIM-Schlüsselrotation: Plane eine jährliche Rotation der DKIM-Schlüssel. Dokumentiere den Prozess und die Zeitpunkte, damit du im Audit nachweisen kannst, dass die Schlüssel regelmäßig gewechselt werden.

Zertifikate für TLS und MTA-STS: TLS-Zertifikate auf dem Mailserver und die MTA-STS-Policy haben ein Ablaufdatum. Überwache diese Fristen, denn ein abgelaufenes Zertifikat kann den gesamten E-Mail-Empfang stilllegen.

E-Mail-Sicherheit im ISMS dokumentieren

Für ISO 27001 und NIS2 brauchst du eine nachvollziehbare Dokumentation deiner E-Mail-Sicherheitsmaßnahmen. In ISMS Lite lässt sich der DMARC-Rollout als Maßnahme mit Zeitplan und Verantwortlichem anlegen, sodass der Fortschritt für den Auditor jederzeit nachvollziehbar ist. Folgende Elemente gehören ins ISMS:

E-Mail-Sicherheitsrichtlinie: Definiert die Anforderungen an SPF, DKIM, DMARC, TLS, Verschlüsselung und E-Mail-Gateway. Legt fest, welche Dienste E-Mails mit der Unternehmens-Domain senden dürfen und wer Änderungen am SPF-Record genehmigen muss.

Technische Dokumentation: Aktueller SPF-Record mit Erläuterung jedes Eintrags, DKIM-Konfiguration mit Selector und Schlüsselrotationsplan, DMARC-Policy mit Begründung der gewählten Stufe, MTA-STS-Konfiguration, E-Mail-Gateway-Einstellungen.

DMARC-Rollout-Plan: Dokumentiere den schrittweisen Rollout von p=none über p=quarantine zu p=reject mit Zeitplan, Verantwortlichkeiten und Kriterien für die Eskalation zur nächsten Stufe.

Regelmäßige Reviews: Protokolliere die wöchentlichen DMARC-Report-Auswertungen und die Maßnahmen, die daraus resultieren. Das zeigt dem Auditor, dass du den Prozess nicht nur eingerichtet hast, sondern aktiv betreibst.

E-Mail-Sicherheit ist ein Zusammenspiel

SPF, DKIM und DMARC sind keine isolierten Maßnahmen, sondern ein Zusammenspiel. SPF allein hat Lücken, DKIM allein hat Lücken, aber zusammen mit DMARC bilden sie eine robuste Verteidigung gegen Absenderfälschung. Ergänzt durch TLS-Verschlüsselung für den Transport und ein E-Mail-Security-Gateway für die Inhaltsprüfung entsteht ein mehrschichtiger Schutz, der die E-Mail-Sicherheit deines Unternehmens auf ein zeitgemäßes Niveau hebt.

Die Einrichtung ist kein Hexenwerk. SPF und DKIM lassen sich in wenigen Stunden konfigurieren. DMARC erfordert eine Einführungsphase von einigen Wochen, um alle legitimen Absender zu identifizieren. Der größte Aufwand liegt nicht in der technischen Konfiguration, sondern in der Analyse der DMARC-Reports und der Pflege des SPF-Records bei Änderungen in der Dienstleisterlandschaft.

Fang heute an. Prüfe, ob deine Domain bereits einen SPF-Record hat und ob er korrekt ist. Prüfe, ob DKIM aktiviert ist. Setze einen DMARC-Record mit p=none und analysiere die Reports. Mit jedem Schritt wird die E-Mail-Sicherheit deines Unternehmens besser und die Wahrscheinlichkeit, dass deine Domain für Spoofing missbraucht wird, geringer.

Weiterführende Artikel

• Phishing erkennen und melden: Leitfaden für Mitarbeiter
• Top 10 Informationssicherheitsrisiken für den Mittelstand
• TOMs dokumentieren: Technische und organisatorische Maßnahmen nach DSGVO
• Security Awareness Programm aufbauen: Was Mitarbeiter wirklich wissen müssen
• Netzwerksegmentierung für KMU: Warum und wie du dein Netz aufteilst

Prüfe als Erstes den SPF-Record deiner Domain mit einem Online-Tool. Du wirst überrascht sein, wie viele Unternehmen entweder gar keinen SPF-Record haben oder einen, der seit Jahren nicht mehr gepflegt wurde. Von dort aus arbeitest du dich über DKIM zu DMARC vor und hebst die E-Mail-Sicherheit deines Unternehmens Schritt für Schritt auf das Niveau, das sie verdient.