SPF, DKIM und DMARC einrichten: E-Mail-Authentifizierung für Ihre Domain

Warum E-Mail-Authentifizierung unverzichtbar ist

Das Simple Mail Transfer Protocol (SMTP) wurde 1982 ohne eingebaute Authentifizierung entwickelt. Jeder Server kann eine E-Mail mit einer beliebigen Absenderadresse versenden. Das macht E-Mail-Spoofing trivial: Ein Angreifer kann E-Mails versenden, die scheinbar von ihrer-firma@ihre-domain.de stammen. Die Empfänger sehen Ihre Domain als Absender und vertrauen der Nachricht.

Die Folgen sind gravierend: Phishing-E-Mails im Namen Ihres Unternehmens schädigen das Kundenvertrauen. Wenn Empfänger Spoofing-Mails als Spam markieren, sinkt der Ruf Ihrer Domain bei Mailbox-Providern. Ihre legitimen E-Mails landen dann ebenfalls im Spam. Im schlimmsten Fall wird Ihre Domain auf eine Blacklist gesetzt und keine Ihrer E-Mails wird mehr zugestellt.

SPF: Welche Server dürfen E-Mails versenden?

Das Sender Policy Framework (SPF) ist der erste Baustein der E-Mail-Authentifizierung. Es definiert über einen DNS-TXT-Record, welche IP-Adressen und Server berechtigt sind, E-Mails für Ihre Domain zu versenden. Der Empfangsserver prüft die IP-Adresse des sendenden Servers gegen den SPF-Record der Absenderdomain.

SPF-Record erstellen

Ein SPF-Record ist ein DNS-TXT-Eintrag für Ihre Domain. Er beginnt mit der Versionskennung v=spf1, gefolgt von Mechanismen, die berechtigte Sender definieren. Der Record endet mit einer Qualifier-All-Anweisung, die festlegt, wie mit nicht autorisierten Sendern umgegangen wird.

@ IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.5 -all"

In diesem Beispiel sind Google Workspace (include:_spf.google.com), Mailchimp (include:servers.mcsv.net) und ein eigener Server (ip4:203.0.113.5) als berechtigte Absender definiert. Das -all am Ende weist den Empfangsserver an, alle E-Mails von nicht autorisierten Servern abzulehnen. Verwenden Sie -all (hard fail) statt ~all (soft fail) für maximalen Schutz.

SPF-Grenzen und häufige Fehler

SPF hat eine wichtige Einschränkung: Der Record darf maximal 10 DNS-Lookups erfordern. Jedes include zählt als ein Lookup. Bei vielen externen Diensten wie E-Mail-Marketing, CRM, Helpdesk und Transaktionsmail kann dieses Limit schnell erreicht werden. Ein Überschreiten des Limits führt zu einem permanenten SPF-Fehler. XICTRAQ prüft die Anzahl der DNS-Lookups im SPF-Record und warnt bei Annäherung an das Limit.

DKIM: Digitale Signatur für E-Mail-Integrität

DomainKeys Identified Mail (DKIM) geht über SPF hinaus: Es signiert den E-Mail-Header und optional den Body kryptografisch. Der sendende Server fügt eine digitale Signatur in den E-Mail-Header ein, der empfangende Server prüft diese Signatur gegen einen öffentlichen Schlüssel, der als DNS-TXT-Record hinterlegt ist.

DKIM-Schlüsselpaar generieren

DKIM basiert auf asymmetrischer Kryptografie. Sie generieren ein Schlüsselpaar: Der private Schlüssel wird auf dem sendenden Server gespeichert und signiert ausgehende E-Mails. Der öffentliche Schlüssel wird als DNS-TXT-Record unter selector._domainkey.ihre-domain.de veröffentlicht. Der Empfangsserver ruft den öffentlichen Schlüssel ab und prüft damit die Signatur.

google._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Der Selector (hier: google) identifiziert das Schlüsselpaar. Sie können mehrere DKIM-Selektoren für verschiedene Dienste verwenden, etwa einen für Ihr E-Mail-System und einen für Ihren Newsletter-Dienst. Die empfohlene Schlüssellänge ist mindestens 2048 Bit. Kürzere Schlüssel gelten als unsicher.

DKIM bei gängigen E-Mail-Providern aktivieren

Die meisten E-Mail-Provider und -Dienste unterstützen DKIM nativ. Bei Google Workspace aktivieren Sie DKIM in der Admin-Konsole und hinterlegen den generierten DNS-Record. Microsoft 365 aktiviert DKIM automatisch für die Standarddomain und bietet eine manuelle Konfiguration für benutzerdefinierte Domains. Newsletter-Dienste wie Mailchimp und Sendinblue stellen DKIM-Records zur Verfügung, die Sie in Ihrem DNS hinterlegen.

DMARC: Die Richtlinie für nicht authentifizierte E-Mails

Domain-based Message Authentication, Reporting, and Conformance (DMARC) baut auf SPF und DKIM auf und definiert, was mit E-Mails geschehen soll, die weder SPF noch DKIM bestehen. Ohne DMARC entscheidet jeder Empfangsserver selbst, wie er mit nicht authentifizierten E-Mails umgeht. DMARC gibt Ihnen als Domaininhaber die Kontrolle zurück.

DMARC-Richtlinien: none, quarantine, reject

DMARC bietet drei Richtlinien: p=none beobachtet nur und liefert Reports, ohne E-Mails zu beeinflussen, ideal zum Einstieg. p=quarantine leitet nicht authentifizierte E-Mails in den Spam-Ordner. p=reject weist nicht authentifizierte E-Mails vollständig ab. Die empfohlene Vorgehensweise: Beginnen Sie mit p=none, analysieren Sie die Reports, identifizieren Sie alle legitimen Sender und erhöhen Sie schrittweise auf p=quarantine und schließlich p=reject.

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

In diesem Beispiel werden alle nicht authentifizierten E-Mails abgelehnt (p=reject). Aggregierte Reports gehen an dmarc-reports@, forensische Reports an dmarc-forensic@. Die Parameter adkim=s und aspf=s erzwingen eine strikte Ausrichtung, was bedeutet, dass die Domain im From-Header exakt mit der SPF/DKIM-Domain übereinstimmen muss.

DMARC-Reports analysieren

DMARC-Reports liefern wertvolle Einblicke in Ihren E-Mail-Verkehr. Die aggregierten Reports (rua) zeigen, welche Server E-Mails für Ihre Domain versenden und ob SPF und DKIM bestehen. Die forensischen Reports (ruf) liefern Details zu einzelnen fehlgeschlagenen E-Mails. Ohne Analyse dieser Reports fliegen Sie blind: Sie wissen nicht, ob legitime E-Mails blockiert werden oder ob Spoofing-Versuche stattfinden.

Einrichtung Schritt für Schritt

Die Einrichtung aller drei Protokolle folgt einer logischen Reihenfolge. Beginnen Sie mit SPF, fahren Sie mit DKIM fort und implementieren Sie DMARC zuletzt.

1. Bestandsaufnahme: Identifizieren Sie alle Dienste, die E-Mails über Ihre Domain versenden. Dazu gehören das primäre E-Mail-System, Newsletter-Dienste, CRM-Systeme, Helpdesk-Tools, Transaktionsmail-Provider und die Website selbst (Kontaktformulare).
2. SPF konfigurieren: Erstellen Sie einen SPF-Record, der alle identifizierten Dienste einschließt. Prüfen Sie, dass das 10-Lookup-Limit nicht überschritten wird. Beginnen Sie mit ~all und wechseln Sie nach erfolgreicher Prüfung auf -all.
3. DKIM aktivieren: Aktivieren Sie DKIM bei jedem Dienst, der E-Mails für Ihre Domain versendet. Hinterlegen Sie die öffentlichen Schlüssel als DNS-TXT-Records. Verwenden Sie mindestens 2048-Bit-Schlüssel.
4. DMARC mit p=none starten: Erstellen Sie einen DMARC-Record mit p=none und einer rua-Adresse für Reports. Beobachten Sie die Reports mindestens zwei Wochen lang.
5. Reports analysieren: Prüfen Sie, ob alle legitimen E-Mails SPF und DKIM bestehen. Identifizieren und beheben Sie Fehlkonfigurationen.
6. Richtlinie verschärfen: Erhöhen Sie die DMARC-Richtlinie schrittweise: p=quarantine mit pct=10, dann pct=50, dann pct=100, schließlich p=reject.

Häufige Konfigurationsfehler und deren Auswirkungen

Die Einrichtung von SPF, DKIM und DMARC ist technisch nicht kompliziert, aber fehleranfällig. Die häufigsten Fehler und deren Auswirkungen:

• Mehrere SPF-Records: Es darf nur einen SPF-TXT-Record pro Domain geben. Mehrere Records führen zu einem permanenten SPF-Fehler.
• SPF-Lookup-Limit überschritten: Mehr als 10 include- oder redirect-Anweisungen verursachen einen permanenten Fehler. Konsolidieren Sie Dienste oder verwenden Sie SPF-Flattening.
• DKIM-Schlüssel nicht rotiert: DKIM-Schlüssel sollten alle 6 bis 12 Monate rotiert werden. Veraltete Schlüssel erhöhen das Risiko einer Kompromittierung.
• DMARC ohne Reports: p=reject ohne rua-Adresse bedeutet, dass Sie nicht erfahren, welche E-Mails abgelehnt werden. Legitimate E-Mails könnten unbemerkt verloren gehen.
• Subdomain-Policy vergessen: DMARC gilt standardmäßig nur für die Hauptdomain. Setzen Sie sp=reject, um auch Subdomains zu schützen.

Auswirkungen auf E-Mail-Zustellrate und Domain-Reputation

Korrekt konfigurierte E-Mail-Authentifizierung verbessert die Zustellrate messbar. Laut einer Studie von Valimail erreichen Domains mit DMARC p=reject eine Zustellrate von über 95 %, während Domains ohne DMARC bei 70 bis 80 % liegen (Valimail). Google und Yahoo filtern seit 2024 E-Mails ohne SPF und DKIM aggressiver in den Spam-Ordner (Google). Die Blacklist-Wahrscheinlichkeit sinkt deutlich, wenn Spoofing-E-Mails durch DMARC p=reject verhindert werden.

Für Unternehmen, die auf E-Mail-Marketing setzen, ist die Zustellrate ein direkter Umsatzfaktor. Wenn 20 % Ihrer Newsletter im Spam landen, verlieren Sie 20 % der potenziellen Leser und Kunden. Eine korrekte SPF/DKIM/DMARC-Konfiguration in Kombination mit einer sauberen Website-Compliance maximiert die Zustellrate und schützt gleichzeitig den Domainruf.

E-Mail-Authentifizierung und Website-Security

E-Mail-Authentifizierung und Website-Security sind eng verknüpft. Wenn ein Angreifer per DNS-Hijacking die DNS-Records Ihrer Domain manipuliert, kann er sowohl die Website umleiten als auch SPF- und DKIM-Records ändern, um Spoofing-E-Mails zu ermöglichen. DNSSEC schützt die Integrität Ihrer DNS-Records. XICTRAQ überwacht DNS-Records auf unerwartete Änderungen und benachrichtigt Sie sofort.

Auch der Domain-Ablaufschutz spielt eine Rolle: Eine abgelaufene Domain kann von Dritten registriert und für Spoofing missbraucht werden. XICTRAQ überwacht Domainablaufdaten und warnt rechtzeitig. In Kombination mit SSL-Monitoring und Security-Header-Prüfung entsteht ein ganzheitliches Sicherheitskonzept für Domain, Website und E-Mail.

Monitoring: SPF, DKIM und DMARC dauerhaft überwachen

DNS-Records können sich unbeabsichtigt ändern, etwa durch Hosting-Migrationen, DNS-Provider-Wechsel oder manuelle Fehler. Ein fehlender oder fehlerhafter SPF-Record kann innerhalb von Stunden die Zustellrate einbrechen lassen. XICTRAQ überwacht Ihre DNS-Records bei jedem Scan und prüft:

• SPF-Record vorhanden, syntaktisch korrekt und unter dem 10-Lookup-Limit
• DKIM-Records für alle konfigurierten Selektoren vorhanden und gültig
• DMARC-Record vorhanden mit empfohlener Policy (quarantine oder reject)
• DMARC-Alignment korrekt konfiguriert (adkim, aspf)
• Keine widersprüchlichen oder doppelten DNS-Records
• DNS-Änderungen erkannt und protokolliert

Bei Statusverschlechterungen, etwa wenn ein SPF-Record versehentlich gelöscht wird oder ein DKIM-Schlüssel abläuft, werden Sie per E-Mail benachrichtigt. Die Kombination aus E-Mail-Authentifizierungs-Monitoring und Website-Security-Scan in einer Plattform eliminiert blinde Flecken.

Häufig gestellte Fragen zu SPF, DKIM und DMARC