Deine Rechnungen landen beim Kunden im Spam-Ordner, und obendrein verschickt jemand im Namen deiner Firma Mails mit ausgetauschter Kontonummer. Das ist kein Pech und keine Bosheit des Schicksals — das sind meist drei fehlende Einträge in deinem DNS.
SPF, DKIM und DMARC klingen wie Schlagworte von einer Konferenz für Administratoren. In der Praxis sind sie der günstigste und am meisten unterschätzte Schutz, den eine kleine Firma an einem einzigen Tag einführen kann. Sie entscheiden über zwei Dinge, die jeder KMU-Inhaber am eigenen Leib spürt: ob deine Mails überhaupt beim Kunden ankommen, und ob ein Fremder sich als deine Domain ausgeben und eine gefälschte Rechnung „von dir" verschicken kann.
Hier gibt es keine Magie und keine KI. Es ist langweilige Hygiene, die fast niemand korrekt konfiguriert hat — und die Firmen echtes Geld kostet, wenn man sie vernachlässigt.
Warum das überhaupt ein Problem ist
Eine typische Firma mit 20 Leuten verschickt Mails aus mehreren Quellen gleichzeitig, auch wenn der Inhaber das meist nicht weiß. Da ist Microsoft 365 oder Google Workspace für das Team. Da ist das Hosting (OVH, home.pl), von dem die Mails von der Website und vom Kontaktformular kommen. Da ist das ERP oder die Buchhaltungssoftware, die Rechnungen direkt an den Kunden schickt. Manchmal kommt noch ein Newsletter-Tool (FreshMail, MailerLite) und irgendein CRM dazu.
Jede dieser Quellen verschickt Mails „im Namen" deiner Domain. Der Server des Empfängers — Gmail, Outlook, das Postfach des Kunden — muss irgendwie entscheiden, welche dieser Nachrichten echt sind und welche von jemandem stammen, der sich als du ausgibt. Wenn du ihm die Werkzeuge für diese Einschätzung nicht gegeben hast, hat er zwei Möglichkeiten: die Nachricht „zur Sicherheit" in den Spam werfen oder den Betrüger ebenfalls durchlassen. Beide sind schlecht.
Bei einem unserer Kunden — ein Baustoffgroßhandel mit 18 Mitarbeitern — landeten rund 30 % der Rechnungen beim Kunden im Spam. Die Vertriebler riefen Kunden an mit der Bitte, „den Junk-Ordner zu prüfen", was bei Dutzenden Rechnungen pro Tag Stunden fraß. Dann kam das Schlimmere: Ein Betrüger verschickte an die Kunden des Großhandels Nachrichten, die aussahen wie dessen Rechnungen, mit ausgetauschter Kontonummer. Zwei Kunden zahlten auf das falsche Konto, bevor jemand es merkte. Nach der Einführung von SPF, DKIM und DMARC mit Reject-Policy war die Zustellbarkeit innerhalb von zwei Wochen wieder normal, und das Fälschen der Domain erreichte die Postfächer schlicht nicht mehr.
SPF — wer in deinem Namen senden darf
SPF (Sender Policy Framework) ist einfach eine Liste. Du veröffentlichst im DNS, welche Server in deinem Namen Mails versenden dürfen — zum Beispiel die Server von Microsoft 365, dein Hosting und dein Newsletter-Tool. Der Server des Empfängers prüft diese Liste: Kam eine Nachricht von einer Adresse, die nicht draufsteht, weiß er, dass etwas nicht stimmt.
Das ist ein Text-Eintrag (TXT) im DNS. Der häufigste Fehler, den wir sehen, sind mehrere getrennte SPF-Einträge auf einer Domain — dann funktioniert keiner mehr richtig. Es muss genau einen Eintrag geben, der alle Quellen zusammenfasst. Der zweite Fehler ist das Überschreiten des Limits von 10 DNS-Abfragen, in die sich ein SPF-Eintrag auflöst — bei zu vielen Diensten wird der Eintrag ungültig und das Ganze bricht zusammen.
DKIM — ein Siegel, das sich nicht fälschen lässt
SPF sagt „von welchem Server". DKIM (DomainKeys Identified Mail) geht weiter und signiert jede Mail kryptografisch. Das ist ein bisschen wie ein Wachssiegel auf dem Umschlag: Der Empfänger prüft, dass die Nachricht wirklich von deiner Domain kam und dass unterwegs niemand Inhalt oder Absender verändert hat.
Den öffentlichen Schlüssel dieses Siegels veröffentlichst du im DNS, während der private Schlüssel auf deinem Mailserver bleibt. In Microsoft 365 und Google Workspace ist das Aktivieren von DKIM buchstäblich ein paar Klicks plus ein DNS-Eintrag. Der Haken ist, dass du es für jede Quelle einzeln machen musst — getrennt für M365, getrennt für den Newsletter, getrennt für das ERP, wenn es Rechnungen von deiner Domain verschickt.
DMARC — was mit einer Fälschung zu tun ist
SPF und DKIM prüfen nur. DMARC trifft die Entscheidung. Es ist eine Policy, in der du den Empfänger-Servern sagst: „Wenn eine Nachricht weder SPF noch DKIM bestanden hat, dann tu nichts / pack sie in Quarantäne / weise sie ab." Ohne DMARC blockieren selbst korrektes SPF und DKIM keine Fälschungen — weil niemand weiß, was mit einer Nachricht zu tun ist, die den Test nicht bestanden hat.
DMARC hat noch eine zweite, unterschätzte Funktion: Berichte. Täglich bekommst du eine Übersicht, wer im Namen deiner Domain Mails verschickt hat und ob sie die Authentifizierung bestanden haben. Für viele Inhaber ist das der einzige Moment, in dem sie schwarz auf weiß sehen, dass jemand seit Monaten versucht, sich als sie auszugeben — oder dass ihre eigene Buchhaltungssoftware Rechnungen ohne DKIM verschickt.
Wie du das einführst, ohne deine eigenen Mails abzuschneiden
Der gefährlichste Fehler ist, DMARC sofort auf „abweisen" (p=reject) zu stellen, bevor du weißt, wer wirklich in deinem Namen sendet. Dann blockierst du deine eigenen Rechnungen aus dem ERP oder deinen Newsletter — und erfährst es von wütenden Kunden. Deshalb geht man Schritt für Schritt vor:
- Inventarisiere alle Versandquellen: Team-Mail, Hosting, ERP/Buchhaltung, Newsletter, CRM, das Formular auf der Website.
- Konfiguriere SPF (ein Eintrag, alle Quellen) und aktiviere DKIM für jede Quelle einzeln.
- Stelle DMARC zunächst in den Beobachtungsmodus (
p=none) mit aktivierten Berichten. - Lies 2–4 Wochen lang die Berichte und ergänze die fehlenden Quellen, die du nicht kanntest.
- Erst wenn die Berichte sauber sind, verschärfe die Policy — erst Quarantäne, dann Abweisen.
Für eine Firma mit 20 Leuten ist die ganze Operation meist ein paar Stunden Arbeit, verteilt über einen Monat — die meiste Zeit ist Warten auf Berichte, nicht Konfiguration.
Die häufigsten Patzer
Neben dem Sprung direkt auf p=reject sehen wir am häufigsten: eine vergessene Quelle (jemand hat vor zwei Jahren ein Mailing-Tool angeschlossen und niemand erinnert sich daran), mehrere SPF-Einträge statt eines, das Sprengen des 10-DNS-Abfragen-Limits und — der Klassiker — DMARC einführen und die Berichte ignorieren. Berichte, die du nie liest, sind wie eine Überwachungskamera ohne Aufzeichnung: Es sieht nach Schutz aus, und nach dem Einbruch stellt sich heraus, dass sie nichts gebracht hat.
Die zweite Falle ist organisatorisch. Diese Einträge leben im DNS, und das DNS hält oft „die Website-Firma" von vor fünf Jahren, die niemand mehr erreicht. Bevor du irgendetwas einführst, stell sicher, dass du Zugang zum DNS-Panel deiner Domain hast — ohne ihn bleibst du gleich am Start stecken.
Womit du anfängst
Wenn du nicht weißt, ob deine Domain geschützt ist, dauert der schnellste Test eine Minute: Bitte jemanden von außen, die SPF-, DKIM- und DMARC-Einträge deiner Domain in einem kostenlosen Online-Tool zu prüfen. Fehlt eines davon — und im KMU fehlt meist mindestens DMARC — ist deine Firma zugleich ein leichtes Ziel für Fälschungen und ein Kandidat für den Spam-Ordner deiner Kunden.
Das ist kein Projekt für ein Quartal. Es ist eine gut organisierte Woche, nach der deine Mails ankommen und deine Domain aufhört, ein kostenloses Werkzeug für Betrüger zu sein. Wenn jemand deine Versandquellen inventarisieren und das einführen soll, ohne deine Rechnungen abzuschneiden — melde dich. Das erste Gespräch ist kostenlos und dauert eine halbe Stunde.
Ohne DMARC ist deine Domain ein kostenloses Werkzeug für jeden, der eine gefälschte Rechnung „von dir" verschicken will.