Über 90 % aller Cyberangriffe beginnen mit einer E-Mail. Phishing, Spoofing und Business Email Compromise (BEC) gehören zu den häufigsten Angriffsmethoden — und sie funktionieren, weil E-Mail von Haus aus kein Authentifizierungsverfahren mitbringt. Jeder SMTP-Server kann behaupten, im Namen einer beliebigen Domain zu senden. Genau hier setzen SPF, DKIM und DMARC an: Drei DNS-basierte Protokolle, die zusammen sicherstellen, dass nur autorisierte Server E-Mails im Namen Ihrer Domain versenden dürfen. Dieser Artikel zeigt, wie KMU alle drei korrekt einrichten.

Warum E-Mail-Authentifizierung unverzichtbar ist

Ohne SPF, DKIM und DMARC kann ein Angreifer E-Mails versenden, die exakt so aussehen, als kämen sie von Ihrer Domain. Der Empfänger sieht im Absenderfeld geschaeftsfuehrung@ihrefirma.de — und vertraut der Nachricht. Die Folgen reichen von gefälschten Rechnungen über Zugangsdaten-Diebstahl bis zu Überweisungsbetrug.

Seit Februar 2024 verlangen Google und Yahoo SPF und DMARC für alle Absender, die mehr als 5.000 E-Mails pro Tag senden. Microsoft 365 zog im April 2025 nach. Ohne diese Einträge landen E-Mails zunehmend im Spam oder werden komplett abgelehnt — auch legitime.

SPF: Wer darf im Namen Ihrer Domain senden?

Das Sender Policy Framework (SPF) definiert per DNS-TXT-Eintrag, welche IP-Adressen und Server E-Mails für eine Domain senden dürfen. Der empfangende Mailserver prüft den SPF-Record und vergleicht die IP des sendenden Servers.

DNS-Eintrag erstellen

ihrefirma.de.  IN TXT  "v=spf1 mx ip4:203.0.113.10 include:_spf.google.com ~all"

Bestandteile erklärt:

v=spf1 — Kennzeichnung als SPF-Record
mx — Alle MX-Server der Domain dürfen senden
ip4:203.0.113.10 — Diese spezifische IP darf senden
include:_spf.google.com — Google Workspace als autorisierter Absender
~all — Soft-Fail: Nicht autorisierte Server werden markiert, aber nicht blockiert
-all — Hard-Fail: Nicht autorisierte Server werden abgelehnt (Ziel nach Test)

Häufige SPF-Fehler

SPF erlaubt maximal 10 DNS-Lookups. Jedes include und redirect zählt als Lookup. Bei vielen Drittanbietern (Newsletter-Tool, CRM, Helpdesk) ist dieses Limit schnell erreicht. Prüfen Sie die Anzahl mit Tools wie MXToolbox. Alternativen bei Überschreitung: SPF-Flattening oder Subdomains für verschiedene Dienste.

DKIM: Digitale Signatur für jede E-Mail

DomainKeys Identified Mail (DKIM) signiert jede ausgehende E-Mail kryptografisch. Der sendende Server fügt eine Signatur in den Mail-Header ein, der empfangende Server verifiziert sie gegen einen öffentlichen Schlüssel im DNS.

So funktioniert DKIM

Beim Versand berechnet der Mailserver einen Hash über Header und Body der E-Mail
Der Hash wird mit dem privaten DKIM-Schlüssel signiert
Die Signatur wird als DKIM-Signature-Header eingefügt
Der Empfänger ruft den öffentlichen Schlüssel per DNS ab und verifiziert die Signatur

DNS-Eintrag für den öffentlichen Schlüssel

selector1._domainkey.ihrefirma.de.  IN TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."

Der Selector (z. B. selector1) ermöglicht mehrere DKIM-Schlüssel pro Domain — nützlich bei der Schlüsselrotation oder wenn verschiedene Systeme mit eigenen Schlüsseln senden.

DKIM in der Praxis

Die meisten Mailserver und Hosted-Dienste erzeugen DKIM-Schlüsselpaare automatisch. Bei Google Workspace, Microsoft 365 oder Postfix muss der öffentliche Schlüssel lediglich als DNS-TXT-Eintrag hinterlegt werden. Die Schlüssellänge sollte mindestens 2048 Bit betragen — 1024-Bit-Schlüssel gelten als veraltet.

DMARC: Die Schaltzentrale für SPF und DKIM

Domain-based Message Authentication, Reporting and Conformance (DMARC) baut auf SPF und DKIM auf und definiert, was mit E-Mails passieren soll, die beide Prüfungen nicht bestehen. Zusätzlich liefert DMARC Berichte über alle Sendeversuche im Namen Ihrer Domain.

DNS-Eintrag konfigurieren

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

DMARC-Policies im Überblick

Policy	Verhalten	Einsatz
`p=none`	Nur überwachen, keine Aktion	Phase 1: Beobachten, wer im Namen der Domain sendet
`p=quarantine`	In Spam verschieben	Phase 2: Verdächtige E-Mails isolieren
`p=reject`	Komplett ablehnen	Phase 3: Voller Schutz (Ziel)

Wichtige DMARC-Parameter

rua — Adresse für aggregierte Berichte (tägliche XML-Zusammenfassungen)
ruf — Adresse für forensische Berichte (einzelne fehlgeschlagene E-Mails)
adkim=s — Strict Alignment: DKIM-Domain muss exakt mit der Absenderdomain übereinstimmen
aspf=s — Strict Alignment für SPF
pct — Prozentsatz der E-Mails, auf die die Policy angewendet wird (nützlich für schrittweise Einführung)

Richtige Reihenfolge der Implementierung

Eine übereilte Einführung kann dazu führen, dass legitime E-Mails blockiert werden. Die empfohlene Vorgehensweise:

Phase 1 — SPF einrichten (Woche 1–2): Alle autorisierten Absender erfassen (Mailserver, Newsletter-Tool, CRM, Helpdesk) und SPF-Record mit ~all (Soft-Fail) veröffentlichen.

Phase 2 — DKIM aktivieren (Woche 2–4): DKIM-Schlüsselpaar generieren, öffentlichen Schlüssel im DNS hinterlegen, Signierung auf dem Mailserver aktivieren. Testen, ob Signaturen korrekt verifiziert werden.

Phase 3 — DMARC mit p=none starten (Woche 4–6): DMARC-Record mit p=none und rua-Adresse veröffentlichen. Berichte auswerten: Welche Server senden im Namen der Domain? Fehlen SPF-Includes oder DKIM-Signaturen?

Phase 4 — Policy verschärfen (nach 4–8 Wochen Beobachtung): Von p=none auf p=quarantine wechseln. Nach weiteren 4 Wochen ohne Fehlalarme auf p=reject umstellen.

Subdomains nicht vergessen

Ein häufiger Fehler: DMARC wird nur für die Hauptdomain konfiguriert. Angreifer weichen dann auf Subdomains aus (z. B. rechnung.ihrefirma.de). Die Lösung:

_dmarc.ihrefirma.de.  IN TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@ihrefirma.de"

Der Parameter sp=reject wendet die Policy auch auf alle Subdomains an.

Testen und Validieren

Nach der Einrichtung sollten alle Records geprüft werden:

MXToolbox — SPF-, DKIM- und DMARC-Records prüfen, SPF-Lookup-Limit validieren
mail-tester.com — Test-E-Mail senden und Gesamtbewertung erhalten
dmarcian — DMARC-Berichte visualisieren und auswerten
Google Postmaster Tools — Zustellrate und Reputation bei Gmail überwachen

Ein vollständiger Test umfasst: SPF-Record-Syntax prüfen, DKIM-Signatur verifizieren, DMARC-Alignment testen und eine Test-E-Mail an ein externes Postfach senden.

Monitoring mit DATAZONE Control

E-Mail-Authentifizierung ist keine einmalige Einrichtung. DNS-Einträge können sich durch Provider-Wechsel, neue Dienste oder versehentliche Änderungen unbemerkt verändern. Mit DATAZONE Control lassen sich DNS-Records kontinuierlich überwachen: Änderungen an SPF-, DKIM- oder DMARC-Einträgen werden sofort erkannt und gemeldet. Gleichzeitig überwacht das System die Erreichbarkeit der Mailserver und prüft TLS-Zertifikate — ein lückenloses Monitoring der gesamten E-Mail-Infrastruktur.

Häufige Fehler vermeiden

Zu aggressiver DMARC-Start: Beginnen Sie immer mit p=none und beobachten Sie die Berichte mindestens 4 Wochen lang
SPF-Lookup-Limit überschritten: Mehr als 10 DNS-Lookups führen zu einem PermError — der gesamte SPF-Check schlägt fehl
Fehlende Drittanbieter: Newsletter-Tools, Ticketsysteme oder Marketing-Plattformen senden oft im Namen Ihrer Domain — alle müssen im SPF-Record enthalten sein
Kein DKIM für Subdomains: Wenn Anwendungen über Subdomains senden, brauchen auch diese eigene DKIM-Schlüssel
DMARC-Berichte ignorieren: Die rua-Berichte sind der Schlüssel zur Fehlersuche — richten Sie eine dedizierte Adresse ein und werten Sie regelmäßig aus

Sie möchten SPF, DKIM und DMARC für Ihre Domain korrekt einrichten? Kontaktieren Sie uns — wir konfigurieren Ihre E-Mail-Authentifizierung und überwachen sie dauerhaft mit DATAZONE Control.

E-Mail-Sicherheit: SPF, DKIM und DMARC richtig konfigurieren