E-Mail-Spoofing verhindern mit SPF, DKIM und DMARC

1Einleitung

Das klingt erstmal kontraintuitiv: Der beste erste DMARC-Schritt ist nicht p=reject.

Genau das wird aber oft suggeriert. Nach dem Motto: Haken dran, DNS-Eintrag setzen, Spoofing erledigt. Schön wär’s.

In der Praxis ist der schnellste Weg zu p=reject oft der schnellste Weg zu kaputten Rechnungs-Mails, verlorenen Shop-Bestellungen oder Newslettern, die plötzlich im Nirvana landen.

Wenn du E-Mail-Spoofing wirklich sauber verhindern willst, musst du SPF, DKIM und DMARC als zusammenhängendes System sehen. Nicht als drei Buzzwords, die man einmal ins DNS kippt.

Gerade bei Unternehmen in Aachen und der Städteregion sehe ich oft gewachsene Mail-Landschaften: Microsoft 365 für den Alltag, vielleicht noch Google Workspace in einer Abteilung, dazu Shop, ERP, Buchhaltung, Agentur-Tool, Newsletter-Dienst und irgendein Scanner, der „auch E-Mails verschickt“. Genau da entscheidet sich, ob DMARC Schutz bringt oder Ärger macht.

2Warum SPF, DKIM und DMARC zusammengehören

Kurz gesagt:

SPF prüft, ob ein Mailserver für deine Domain senden darf.

DKIM signiert E-Mails kryptografisch, damit der Empfänger prüfen kann, ob die Nachricht von einem autorisierten System stammt und unterwegs nicht verändert wurde.

DMARC setzt oben drauf die Regeln. Es prüft das sogenannte Alignment zwischen sichtbarer From-Domain und SPF oder DKIM – und sagt dem empfangenden Server, was bei Fehlern passieren soll.

Genau hier liegt der Denkfehler vieler Firmen. Sie haben SPF oder DKIM irgendwo aktiviert und glauben, das Thema sei erledigt. Ist es nicht.

Ohne DMARC fehlt die klare Anweisung. Dann erkennt ein empfangender Server vielleicht Auffälligkeiten, weiß aber nicht zwingend, ob er die Mail zustellen, in Spam legen oder ablehnen soll. Erst mit p=quarantine oder p=reject wird aus Diagnose echter Schutz.

Mailgun erklärt das in seinem DMARC-Guide ziemlich klar: Der sinnvolle Weg geht von Beobachtung zu Durchsetzung, nicht andersherum (Mailgun). Auch Google empfiehlt ausdrücklich einen gestuften Rollout mit p=none am Anfang (Google Workspace Help).

3Risiko-Lage: Wie viele Domains sind wirklich geschützt?

Die Verbreitung von DMARC sieht auf den ersten Blick okay aus. Auf den zweiten eher nicht.

Laut dmarcian haben in Deutschland 12% der Domains gar keinen DMARC-Record. 18% sind nur im Monitoring mit p=none. 15% haben Fehler oder folgen nicht den Best Practices. 15% stehen bei p=quarantine, und 40% bei p=reject.

Das ist interessant, aber noch wichtiger ist die breite Landschaft. DMARCguard hat 5.499.028 Domains betrachtet. Ergebnis: Nur 30,4% veröffentlichen überhaupt DMARC. Und nur 12,8% aller gescannten Domains erzwingen Schutz mit p=quarantine oder p=reject.

Unter den Domains, die DMARC überhaupt aktiviert haben, bleiben 57,9% beziehungsweise 967.474 Domains im reinen Monitoring-Modus p=none. Das heißt: sichtbar, aber noch nicht wirklich geschützt.

Dazu kommen Branchenlücken. PowerDMARC nennt ungefähr 32,3% Domains ohne DMARC, über 42% bei Behörden, über 53% im Gesundheitswesen und rund 34% in Transport und Logistik (PowerDMARC). Wenn du mit solchen Branchen arbeitest, ist das nicht nur deren Problem. Es ist Teil deiner Lieferkette.

Meine klare Meinung: Viele Firmen feiern schon die Veröffentlichung eines DMARC-Records. Ehrlich gesagt ist das ungefähr so, als würdest du eine Alarmanlage montieren und sie dann nicht scharf schalten. Sichtbarkeit ist gut. Schutz ist besser.

4Bestandsaufnahme: Alle legitimen Absender finden

Das hier ist der Abschnitt, den fast alle unterschätzen.

Bevor du SPF, DKIM oder DMARC änderst, brauchst du eine Absender-Inventur. Nicht grob. Vollständig.

Dazu gehören typischerweise:

• Microsoft 365 oder Google Workspace
• Website-Formulare und Shop-Systeme
• CRM und Vertriebssoftware
• Ticketsystem oder Helpdesk
• Newsletter-Tool
• ERP und Buchhaltung
• Scanner, Multifunktionsgeräte, Alarmanlagen
• externe Agentur-Tools
• transaktionale Maildienste für Shop, Login, Passwort-Reset oder Rechnungen

Viele Unternehmen in der Region Aachen haben genau diese Mischung. Über Jahre gewachsen, oft mit verschiedenen Dienstleistern. Da ist selten „die eine Mail-Plattform“ im Einsatz. Und genau deshalb scheitern SPF/DKIM/DMARC-Projekte nicht an Technik, sondern an fehlender Transparenz.

Ebenso heikel: mehrere Tenants. Wenn du mehrere Microsoft-365- oder Google-Workspace-Umgebungen parallel betreibst, darfst du das nicht einfach zusammenwürfeln. Jede Domain und jeder Tenant braucht eine saubere Zuordnung, sonst wird’s spätestens bei DKIM und Alignment unsauber.

Wenn du Prozesse ohnehin gerade sortierst, hilft oft auch ein Blick auf angrenzende Digitalisierungsthemen. Genau da setze ich in der Digitalisierung oft an: erst Klarheit in die Systemlandschaft bringen, dann absichern.

5SPF richtig konfigurieren: ein Record, 10-Lookup-Limit

SPF ist simpel, bis es in echten Unternehmen auf echte Tool-Landschaften trifft.

Für Microsoft 365 ist der typische SPF-Record v=spf1 include:spf.protection.outlook.com -all. Für Google Workspace meist v=spf1 include:_spf.google.com ~all. Diese Beispiele tauchen konsistent in mehreren Quellen auf, unter anderem bei zapmail.ai und dmarc.com.

Der erste große Fehler: mehrere SPF-TXT-Records für dieselbe Domain. SPF erlaubt genau einen gültigen Record pro Domain. Wenn drei Dienstleister jeweils „mal eben“ einen TXT-Eintrag anlegen, hast du kein Mehr an Sicherheit, sondern ein Konfigurationsproblem.

Der zweite große Fehler ist das 10-Lookup-Limit. SPF zählt bei include, a, mx, exists und redirect nur bis zehn DNS-Lookups. Danach droht ein SPF-PermError. Und der ist nicht nur theoretisch unschön, sondern kann Zustellung und DMARC-Prüfung beeinträchtigen.

Hier die Kurzorientierung:

6DKIM einrichten und testen: Microsoft 365 vs. Google Workspace

DKIM ist der Teil, der oft „eigentlich schon eingerichtet“ sein soll – bis man in den Header schaut.

Bei Google Workspace erzeugst du den DKIM-Schlüssel in der Admin-Konsole. Empfohlen werden 2048-Bit-Schlüssel. Das ist sinnvoll, kann aber bei manchen DNS-Providern nerven, weil TXT-Strings häufig auf 255 Zeichen pro String begrenzt sind.

IRONSCALES beschreibt das Problem gut: Ein 2048-Bit-Key ist oft rund 400 Zeichen lang und muss dann in mehrere direkt aneinanderhängende TXT-Strings gesplittet werden. Prüfen kannst du das sauber mit dig TXT selector._domainkey.deinedomain.tld.

Microsoft 365 geht meist einen anderen Weg. Statt eines langen TXT-Public-Keys setzt du in der Regel zwei CNAME-Einträge pro Domain beziehungsweise Selector. Das ist im Alltag oft etwas angenehmer zu verwalten.

Aber der Klassiker bleibt derselbe: DNS-Einträge existieren, DKIM ist im Adminbereich trotzdem nicht aktiviert. Dann kommt schlicht keine Signatur raus.

Ein praktischer Nebeneffekt: Wenn du Header einmal sauber lesen kannst, verstehst du Mail-Probleme plötzlich viel schneller. Das gilt übrigens auch für andere Web- und Formular-Themen. Wer schon einmal bei Tracking oder Formularen nach einem Relaunch nach Fehlern gesucht hat, kennt ähnliche Muster – ich habe das beim Thema Google Consent Mode v2 für KMU einrichten schon an anderer Stelle beschrieben.

7DMARC-Record bauen: Tags, Reports und Subdomains

Ein guter Start-Record ist unspektakulär:

v=DMARC1; p=none; rua=mailto:dmarc@deinedomain.tld

Das ist kein Schutz auf voller Härte, aber es ist der richtige Anfang. E-Mails werden normal zugestellt, gleichzeitig sammelst du Aggregate-Reports.

Google nennt als sauberen Rollout erst p=none, dann p=quarantine; pct=5 und später p=reject (Google Workspace Help). Genau so sollte man das auch angehen.

Die wichtigsten Tags im Überblick:

• p= definiert die Policy für die Hauptdomain
• rua= legt fest, wohin Aggregate-Reports gehen
• pct= steuert den prozentualen Anteil der betroffenen fehlgeschlagenen Mails bei Quarantine oder Reject
• sp= regelt Subdomains
• adkim= und aspf= steuern DKIM- und SPF-Alignment, standardmäßig relaxed

Viele Firmen setzen nur p= und wundern sich später, warum sie keine Transparenz haben. Ohne rua verschenkst du einen großen Teil des Nutzens.

1. 1
   Absender erfassen

   Alle legitimen Systeme sammeln: M365, Google, Shop, CRM, Helpdesk, Newsletter, ERP, Scanner, Agentur-Tools.
2. 2
   SPF und DKIM je Quelle sauber setzen

   Nur autorisierte Sender aufnehmen, DKIM wirklich aktivieren und nicht nur DNS-Einträge anlegen.
3. 3
   DMARC mit p=none starten

   RUA-Reports empfangen und unbekannte oder fehlerhafte Versandquellen identifizieren.
4. 4
   Schrittweise härten

   Erst nach bereinigten Reports über quarantine zu reject gehen, idealerweise mit pct-Rampe.

8Rollout von p=none zu p=reject: sicher statt schnell

Das ist der eigentliche Kern des Ganzen.

Ein vernünftiger Rollout beginnt mit Beobachtung. Mehrere Quellen empfehlen zunächst Wochen im Modus p=none. Mailgun nennt als Beispiel sechs Wochen Datensammlung, bevor p=quarantine; pct=5 ins Spiel kommt (Mailgun). Google empfiehlt ebenfalls tägliche Report-Prüfung und schrittweise Erhöhung des pct-Werts.

In komplexeren Umgebungen findest du oft Rampen wie pct=10 → 25 → 50 → 75 → 100. Laut AutoSPF kann der vollständige Weg 90 bis 180 Tage dauern. Klingt lang. Ist aber immer noch besser als ein halber Tag „Sicherheitsprojekt“ mit danach kaputter Mailzustellung.

Hier meine ehrliche Einschätzung aus Projekten mit kleineren und mittleren Unternehmen: Der Erfolg ist nicht der härteste DNS-Eintrag. Der Erfolg ist eine saubere, dokumentierte Absender-Inventur.

Ich hatte schon Fälle, in denen jemand „mal eben“ auf p=reject wechseln wollte. Auf dem Papier war alles da: SPF, DKIM, DMARC. In der Realität hätte ein externer Dienst für Rechnungen oder Shop-Mails ohne korrektes DKIM-Alignment legitime Nachrichten blockiert. Das merkst du nicht im DNS-Editor. Das merkst du erst, wenn Kunden keine wichtigen E-Mails mehr bekommen. Und dann wird’s teuer .

9Typische Fehler, die legitime E-Mails blockieren

Die meisten Ausfälle sind erstaunlich unspektakulär.

Fehler 1: Sofort p=reject setzen.

Wenn Newsletter, Shop, CRM, Helpdesk, Scanner oder Agentur-Tools noch nicht sauber aligned senden, blockierst du im Zweifel deine eigenen Prozesse.

Fehler 2: Mehrere SPF-Records oder zu viele Includes.

Das Ergebnis kann ein SPF-PermError sein. Dann hilft dir auch ein „eigentlich richtig gemeinter“ SPF nicht mehr viel.

Fehler 3: DKIM im DNS veröffentlichen, aber im Adminbereich nicht aktivieren.

Das sehe ich häufiger, als man denkt. Besonders nach Handover-Situationen zwischen Agentur, Hoster und internem Admin.

Fehler 4: Subdomains vergessen.

Wenn Systeme über shop., mail. oder support. senden, musst du das bewusst planen. Dazu gehören sp= im DMARC-Kontext und oft eigene SPF-/DKIM-Einträge.

Fehler 5: Reports nicht auswerten.

Ein DMARC-Record ohne laufende Analyse ist nur halbe Arbeit. Die eigentliche Erkenntnis steckt in den RUA-Daten.

10Praxis-Checkliste für KMU: testen, dokumentieren, warten

Der dauerhafte Schutz entsteht nicht beim ersten DNS-Eintrag, sondern im Betrieb.

Viele Aachener Betriebe haben nicht „zu wenig IT“, sondern zu viele kleine Einzelentscheidungen aus den letzten Jahren. Genau deshalb hilft eine pragmatische Checkliste mehr als jede Hochglanz-Grafik.

1. Erstelle eine Versandquellenliste.

Pflege pro Tool den Eigentümer, die Domain, die technische Versandmethode und den Business-Zweck. Das ist besonders wichtig bei parallelem Einsatz von Microsoft 365, Google Workspace, Newsletter-Diensten, Shops und Agentur-Tools.

2. Dokumentiere die DNS-Konfiguration.

SPF-Record, DKIM-Selectoren, DMARC-Record, TTL, zuständiger Dienstleister und Testdatum gehören in eine nachvollziehbare Doku. Kein Hexenwerk. Aber Gold wert.

3. Teste nach jeder Änderung.

Prüfe DNS-Lookups, verschicke Testmails an externe Empfänger und kontrolliere die Header auf SPF-, DKIM- und DMARC-Pass. Danach in die Reports schauen.

4. Plane einen Quartals-Review.

Neue SaaS-Tools, Marketingkampagnen, Shop-Erweiterungen oder ein neuer Steuerberater mit Versandfunktion – all das verändert deine Mail-Landschaft.

5. Halte Verantwortlichkeiten fest.

Wer darf DNS ändern? Wer darf neue Versandtools einkaufen? Wer prüft Reports? Wenn das niemandem gehört, bleibt DMARC schnell auf halber Strecke stehen.

1. 1
   Versandquellenliste pflegen

   Jedes sendende System inkl. Verantwortlichem dokumentieren.
2. 2
   DNS sauber dokumentieren

   SPF, DKIM-Selectoren, DMARC, TTL und Testdatum zentral festhalten.
3. 3
   Nach jeder Änderung testen

   Header prüfen, externe Tests machen und Reports auswerten.
4. 4
   Quartalsweise prüfen

   Neue Tools und Subdomains regelmäßig in SPF, DKIM und DMARC einbeziehen.

11Meine Einschätzung

SPF, DKIM und DMARC sind kein „nice to have“ mehr. Sie sind Basishygiene für deine Domain .

Aber ich halte nichts davon, Firmen mit maximaler Härte zu beeindrucken. Der bessere Weg ist der nüchterne: erst Sichtbarkeit schaffen, dann aufräumen, dann durchsetzen.

Wenn du nur einen Punkt aus diesem Guide mitnimmst, dann diesen: Nicht der schärfste DMARC-Record schützt dich am besten, sondern die sauberste Kenntnis darüber, wer in deinem Namen Mails verschickt. Alles andere ist DNS-Kosmetik.