Phishing-Mails mit Ihrer Firmen-Adresse:
Was SPF, DKIM und DMARC verhindern

Wie der Missbrauch Ihrer Adresse technisch funktioniert

Das Versenden einer E-Mail funktioniert technisch in zwei Schritten: Der eigene Mail-Server kontaktiert den empfangenden Mail-Server und übergibt ihm eine Nachricht. Welche Absenderadresse in dieser Nachricht steht, entscheidet der versendende Server selbst — und es gibt im Grundprotokoll keine Verpflichtung, dass dieser Eintrag stimmt. Wer einen eigenen Mail-Server betreibt, kann „rechnung@ihre-firma.de" als Absender eintragen, selbst wenn ihm diese Domain nicht gehört.

In der frühen Internet-Ära war das kein Problem, weil die wenigen beteiligten Server sich gegenseitig kannten. Heute, bei Milliarden Mail-Servern, ist das die Standard-Angriffsfläche. Spam, Phishing und Business-E-Mail-Compromise setzen alle an derselben Stelle an: Sie nutzen die Vertrauenswürdigkeit eines fremden Absenders, ohne diesen je kompromittiert zu haben.

Die drei Standards SPF, DKIM und DMARC ergänzen das ursprüngliche Protokoll um die Antwort auf eine Frage, die früher nicht gestellt wurde: Darf dieser Server überhaupt im Namen dieser Domain verschicken — und falls nein, was soll der empfangende Server damit tun? Wer die drei Standards versteht, kann jedem Phishing-Versuch mit der eigenen Domain technisch den Zugang verwehren. Mehr Kontext zu Vorbeugung bei unangenehmen digitalen Vorfällen steht in unserem Beitrag zum Website-Notfallplan bei Hack und Ausfall.

Drei Standards, die das Problem lösen

SPF, DKIM und DMARC adressieren jeweils einen anderen Aspekt derselben Frage. Erst zusammen bilden sie einen vollständigen Schutz. Einer ohne die anderen zwei deckt etwa ein Drittel der Angriffsfläche ab — was in der Praxis häufig der gefährlichere Zustand ist als gar kein Schutz, weil er ein falsches Sicherheitsgefühl erzeugt.

• SPF (Sender Policy Framework) beantwortet: Welche Mail-Server dürfen in meinem Namen senden? Es wird als DNS-Eintrag hinterlegt und vom empfangenden Server geprüft.
• DKIM (DomainKeys Identified Mail) beantwortet: Stammt diese konkrete Nachricht tatsächlich von einem autorisierten Server, und wurde sie unterwegs nicht verändert? Funktioniert über eine digitale Signatur im Mail-Header.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) beantwortet: Was soll der empfangende Server tun, wenn SPF und/oder DKIM scheitern? Und: Wer bekommt einen Bericht darüber, dass das passiert ist?

Die Reihenfolge der Einführung folgt dieser Logik: erst SPF und DKIM einrichten, dann DMARC ergänzen — DMARC ist die Klammer, die ohne die anderen beiden keine Aussage treffen kann. Wie sich der DNS-Eintrag konkret macht, ist eine Frage des Domain-Verwalters; die Reihenfolge gilt unabhängig vom Hoster. Wer parallel das eigene Hosting-Setup neu sortiert, findet im Beitrag zu Hosting-Standort Deutschland eine Einordnung, an welcher Stelle DNS-Zonen üblicherweise verwaltet werden.

SPF: Wer darf in Ihrem Namen senden

Ein SPF-Eintrag ist eine Liste autorisierter Mail-Server, hinterlegt als TXT-Record in der DNS-Zone Ihrer Domain. Wenn ein empfangender Mail-Server eine Nachricht entgegennimmt, schaut er zunächst, von welchem Server die Verbindung kommt — und vergleicht diese Server-Adresse mit der SPF-Liste der Absender-Domain. Steht der sendende Server nicht auf der Liste, ist das ein klares Signal: Die Mail kommt nicht aus dem autorisierten Bereich der Domain.

Was im SPF-Record steht

Eine typische SPF-Zeile beschreibt, von welchen IP-Adressen, Servernamen oder verlinkten Drittdiensten ausgehende Mail erlaubt ist, und welcher Umgang mit Nicht-Treffern empfohlen ist. Der entscheidende letzte Teil ist die sogenannte Mechanik-Markierung am Ende — sie sagt dem empfangenden Server, ob ein Nicht-Treffer als harter Fehlschlag (~all bedeutet weich, -all bedeutet hart) oder als reine Information gilt.

Warum SPF allein nicht reicht

SPF prüft nur die Server-Adresse beim Erstkontakt, nicht den eigentlichen Mail-Inhalt. Wird eine Mail weitergeleitet — etwa über eine Mailing-Liste — kann der ursprüngliche SPF-Eintrag den neuen Versand-Server nicht abdecken, und die Authentifizierung scheitert. Genau diese Lücke schließt DKIM, weil dort die Mail selbst signiert ist und die Signatur durch Weiterleitung nicht zwingend bricht.

DKIM: Die unsichtbare Signatur auf jeder Mail

DKIM funktioniert über asymmetrische Kryptografie: Beim Versand wird die Nachricht mit einem privaten Schlüssel signiert; der zugehörige öffentliche Schlüssel liegt als DNS-Eintrag in der Zone Ihrer Domain. Der empfangende Server holt sich diesen öffentlichen Schlüssel und prüft, ob die Signatur im Mail-Header zur Nachricht passt — und damit zwei Aussagen trifft: erstens, die Nachricht stammt aus einem System, das den privaten Schlüssel kennt; zweitens, der Inhalt wurde nach der Signatur nicht verändert.

Was beim Einrichten passiert

Der Mail-Anbieter erzeugt ein Schlüsselpaar; den öffentlichen Teil tragen Sie als TXT-Record in der DNS-Zone ein, der private Teil bleibt im Versand-System. Üblich sind 2048-Bit-Schlüssel — kürzere (1024 Bit) gelten zunehmend als zu schwach und werden von einigen großen Anbietern bereits als Warnung markiert.

Schlüsselrotation

Wie jeder kryptografische Schlüssel sollte auch der DKIM-Schlüssel regelmäßig erneuert werden — typischerweise alle sechs bis zwölf Monate. Saubere Mail-Anbieter unterstützen dafür mehrere parallele Selektoren, sodass der neue Schlüssel eingeführt werden kann, ohne dass eingehende Mails mit dem alten Schlüssel auf einmal als ungültig gelten.

DMARC: Was passiert, wenn etwas nicht passt

DMARC ist die Klammer um SPF und DKIM. Der DMARC-Record sagt dem empfangenden Server zwei Dinge: Was soll mit Mails passieren, deren SPF- oder DKIM-Prüfung fehlschlägt? Und an welche Adresse sollen die täglichen Berichte über die eingehenden Versuche geschickt werden?

Die drei Policy-Stufen

• p=none — Beobachten ohne Konsequenz. Die Reports kommen, gefälschte Mails werden nicht abgewiesen. Standard-Einstieg.
• p=quarantine — Verdächtige Mails landen im Spam-Ordner. Sichtbar, aber gedämpft.
• p=reject — Verdächtige Mails werden komplett abgewiesen. Höchster Schutz, höchstes Risiko bei unvollständiger Vorarbeit.

Warum die Reports der eigentliche Wert sind

Die Aggregate-Reports, die nach Einrichtung täglich eintreffen, sind XML-Dateien mit einer Übersicht über alle Server, die im Namen Ihrer Domain gesendet haben — autorisiert oder nicht. Wer diese Reports systematisch auswertet, sieht: erstens, welche legitimen Versender bisher nicht im SPF stehen (etwa ein vergessenes Newsletter-Tool); zweitens, ob und in welchem Umfang fremde Server versuchen, Ihre Domain zu missbrauchen. Ohne Auswertung ist der ganze Aufwand lediglich Selbstbeobachtung ohne Erkenntnis.

BIMI und MTA-STS — was darüber hinausgeht

Wer die DMARC-Reise abschließt, hat zwei weitere optionale Schritte offen: BIMI macht in unterstützten Mail-Programmen ein verifiziertes Marken-Logo neben dem Absender sichtbar (und braucht ein verifiziertes Markenrecht-Zertifikat). MTA-STS verhindert, dass die Transportverschlüsselung zwischen Mail-Servern durch Downgrade-Angriffe ausgehebelt wird. Beide sind Kür, nicht Pflicht — SPF, DKIM und DMARC auf p=reject sind die eigentliche Schutzlinie.

Die drei häufigsten Konfigurations-Fehler

In der Praxis zeigt sich, dass die meisten Domains nicht den falschen Mechanismus haben — sondern eine unsaubere Kombination. Drei Muster wiederholen sich.

1. SPF-Record überschreitet das Lookup-Limit

SPF erlaubt maximal zehn DNS-Lookups pro Auswertung. Wer mehrere Drittdienste einbindet (etwa über mehrere include-Direktiven), läuft schnell darüber — und der gesamte SPF-Eintrag wird vom empfangenden Server als ungültig verworfen. Die eigene Domain steht damit faktisch ohne SPF da, obwohl ein Eintrag existiert. Lösung: Konsolidieren, weniger Drittdienste über Aliase einbinden oder mit den jeweiligen Anbietern abklären, ob alternative Verfahren ohne Lookup möglich sind.

2. DKIM-Schlüssel zu kurz oder nie rotiert

Schlüssel mit 1024 Bit waren vor zehn Jahren Standard und werden inzwischen von mehreren großen Mail-Anbietern als unsicher markiert. Wer den DKIM-Eintrag vor Jahren einmal gemacht hat und seitdem nie wieder angefasst hat, fährt mit hoher Wahrscheinlichkeit einen veralteten Stand. Rotation alle sechs bis zwölf Monate, Schlüssellänge mindestens 2048 Bit — beides ohne Diskussion.

3. DMARC bleibt dauerhaft auf p=none

Der „temporäre" Beobachtungsmodus wird nicht selten zum Dauerzustand. Das ist verständlich — wer aus p=none rausgeht, übernimmt Verantwortung für Mails, die durchfallen — bringt aber faktisch keinen Schutz. Phishing-Mails kommen weiterhin durch, der einzige Unterschied ist, dass Sie jetzt Reports darüber bekommen. Der saubere Weg: p=none als Lern-Phase, danach p=quarantine, am Ende p=reject. Wer die Reports nicht auswerten kann oder will, sollte das Setup an einen Dienstleister übergeben — der Effekt ohne Auswertung ist null.

Den Status Ihrer Domain in fünf Minuten prüfen

Bevor irgendetwas eingerichtet oder geändert wird, lohnt eine schnelle Bestandsprüfung. Sie kostet keine fünf Minuten und liefert eine ehrliche Ausgangslage. Drei Werkzeuge reichen:

1. DNS-Abfrage in einem öffentlichen MX-/Auth-Checker: Es gibt mehrere kostenlose Web-Tools, die für eine eingegebene Domain anzeigen, welche SPF-, DKIM- und DMARC-Records existieren. Wenn an irgendeiner Stelle „kein Eintrag gefunden" steht, ist hier die größte Lücke.
2. Test-Mail an einen Authentifizierungs-Checker: Verschiedene Dienste bieten eine Wegwerf-Mailadresse, an die Sie eine Test-Mail aus jedem Postfach senden — die Antwort zeigt, ob SPF, DKIM und DMARC bestanden haben und welche Versand-Quelle den Test ausgelöst hat.
3. Reports einsammeln: Selbst wenn ein DMARC-Record existiert, fließen die Reports nur, wenn die rua-Adresse korrekt gesetzt ist. Ohne hinterlegtes Postfach bleiben die XML-Berichte ungelesen — der gesamte Schutz wird damit blind. Die hinterlegte Adresse sollte regelmäßig kontrolliert werden, idealerweise mit Auswertungs-Tool im Hintergrund.

Wer im Rahmen einer breiteren Bestandsaufnahme der Website-Infrastruktur arbeitet, kann diese Prüfung mit anderen Routinen kombinieren — die Übersicht im Beitrag Jahres-Audit für Ihre Website führt SPF/DKIM/DMARC als einen von zwölf Audit-Punkten.

Reihenfolge der Einführung — vom Audit bis Reject

Eine saubere Einführung folgt einer festen Sequenz. Sie nicht abzukürzen ist der wichtigste Erfolgsfaktor — der Versuch, in einem Aufwasch von „nichts" auf „p=reject" zu kommen, scheitert in der Mehrzahl der Fälle und führt zu Mail-Ausfall, der oft erst spät bemerkt wird.

1. Bestandsaufnahme aller Versand-Quellen: eigene Postfächer, Marketing-Tools, CRM, Buchhaltungs-Software, Karriereseiten-Modul, Bewerbermanagement, Helpdesk, Online-Shop. Jede Quelle, die in Ihrem Namen verschickt, muss bekannt sein.
2. SPF-Record erstellen oder konsolidieren: autorisierte Sender eintragen, Lookup-Limit beachten, mit ~all (Soft-Fail) starten, später auf -all (Hard-Fail) ziehen.
3. DKIM für alle Versand-Quellen aktivieren: 2048-Bit-Schlüssel generieren, öffentlichen Schlüssel in DNS hinterlegen, Rotations-Routine vereinbaren.
4. DMARC mit p=none und Reporting starten: Aggregate- und Forensik-Reports an überwachtes Postfach, Auswertungs-Tool im Hintergrund.
5. Zwei bis vier Wochen Reports auswerten: unbekannte Versender klären, SPF/DKIM bei Bedarf nachziehen, Drittdienste sauber authentifizieren.
6. Stufe auf p=quarantine ziehen: erneut Reports auswerten, Beschwerden klären, falls verdächtige Mails legitime Sender betreffen.
7. Stufe auf p=reject ziehen: Endzustand. Phishing-Mails mit Ihrer Domain werden vom empfangenden Server abgewiesen, bevor sie den Posteingang erreichen.
8. Im Kalender vermerken: Schlüsselrotation alle sechs bis zwölf Monate, Reports mindestens einmal pro Quartal komplett durchsehen.

Wer den Roll-out parallel mit einer Domain-Übernahme nach einem Firmenkauf kombiniert, sollte beides nicht vermischen — die Prozesse haben unterschiedliche Risiken und Zeitachsen. Der dafür passende Ablauf steht im Beitrag Domain bei Firmenkauf, Inhaberwechsel oder Insolvenz.

Fünf Anzeichen, dass das Mail-Setup nicht trägt

In Bestandsaufnahmen taucht eine kleine Zahl von Mustern immer wieder auf. Wer eines davon erkennt, sollte nicht warten, bis ein gefälschter Absender das Thema von außen aufmacht.

Punkte 1 bis 3 sind die typischen Gründe, warum Phishing mit Ihrer Domain trotz vermeintlich vorhandener Schutzmechanismen funktioniert.