SPF, DKIM & DMARC einrichten – Schritt-für-Schritt Anleitung

Was ist SPF und warum brauche ich es?

SPF (Sender Policy Framework, definiert in RFC 7208) ist ein DNS-basiertes Authentifizierungsverfahren, das festlegt, welche Mailserver im Namen einer Domain E-Mails versenden dürfen. Ohne SPF-Record kann jeder beliebige Mailserver E-Mails mit Ihrer Absenderadresse versenden – der Empfänger hat keine Möglichkeit, die Echtheit zu prüfen. Der SPF-Record wird als TXT-Eintrag in der DNS-Zone Ihrer Domain hinterlegt. Empfangende Mailserver prüfen bei jeder eingehenden E-Mail, ob die IP-Adresse des sendenden Servers im SPF-Record der Absenderdomain autorisiert ist. Stimmt die IP nicht überein, schlägt die SPF-Prüfung fehl und die E-Mail kann als verdächtig markiert oder abgelehnt werden.

SPF-Record erstellen: Schritt für Schritt

Ein SPF-Record beginnt immer mit der Versionsangabe v=spf1 und endet mit einer Policy-Direktive. Dazwischen stehen die autorisierten Sendequellen. Hier ein typisches Beispiel für eine Domain, die Google Workspace und einen eigenen Mailserver nutzt:

v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all

Häufige SPF-Fehler vermeiden

Der häufigste Fehler bei SPF-Records ist die Überschreitung der 10-DNS-Lookup-Grenze. Jeder include:-Mechanismus löst einen DNS-Lookup aus, und diese können verschachtelt sein. Google Workspace allein verbraucht bereits 3-4 Lookups. Wird die Grenze überschritten, ist der gesamte SPF-Record ungültig – nicht nur der Teil, der die 10 überschreitet. Prüfen Sie Ihren SPF-Record regelmäßig mit dem Webalyzr SPF Generator. Weitere Fehler: mehrere SPF-Records für dieselbe Domain (nur einer ist erlaubt), fehlende Sendequellen (Newsletter-Dienste, CRM-Systeme), und der gefährliche +all-Mechanismus, der jeden Server autorisiert.

Was ist DKIM und wie funktioniert es?

DKIM (DomainKeys Identified Mail, definiert in RFC 6376) ist ein kryptographisches Verfahren, bei dem ausgehende E-Mails mit einer digitalen Signatur versehen werden. Der sendende Mailserver signiert den E-Mail-Header und wahlweise den Body mit einem privaten Schlüssel. Der dazugehörige öffentliche Schlüssel wird als DNS-TXT-Record unter [selektor]._domainkey.[domain] veröffentlicht. Empfangende Mailserver können die Signatur prüfen und so verifizieren, dass die E-Mail tatsächlich vom angegebenen Absender stammt und unterwegs nicht verändert wurde. Im Gegensatz zu SPF, das nur die IP-Adresse prüft, schützt DKIM auch vor Manipulation des E-Mail-Inhalts auf dem Transportweg.

DKIM einrichten

Die DKIM-Einrichtung hängt vom verwendeten Mailserver oder E-Mail-Provider ab. Bei Google Workspace generiert Google den Schlüssel automatisch – Sie müssen nur den angezeigten TXT-Record in Ihrer DNS-Zone anlegen. Bei Microsoft 365 werden zwei CNAME-Records unter selector1._domainkey und selector2._domainkey benötigt. Bei eigenen Mailservern (Postfix, Exim) nutzen Sie OpenDKIM oder rspamd, um Schlüsselpaare zu generieren und die Signierung zu konfigurieren. Verwenden Sie RSA-Schlüssel mit mindestens 2048 Bit Länge – 1024-Bit-Schlüssel gelten seit 2024 als unsicher. Nutzen Sie den Webalyzr DKIM Generator zur Schlüsselgenerierung und den DKIM Validator zur anschließenden Prüfung.

DKIM Best Practices

• Rotieren Sie DKIM-Schlüssel mindestens jährlich. Legen Sie den neuen Schlüssel im DNS an, warten Sie 48 Stunden, stellen Sie dann den Mailserver um und löschen Sie den alten Record nach weiteren 48 Stunden.
• Wählen Sie sprechende Selektor-Namen mit Datum (z.B. google2026), damit Sie bei der Rotation den Überblick behalten.
• Der private Schlüssel darf niemals öffentlich zugänglich sein – speichern Sie ihn nicht in Git-Repositories oder auf öffentlichen Servern.
• Testen Sie nach jeder Änderung mit einem Test-E-Mail an einen Gmail-Account: Im E-Mail-Header sollte dkim=pass stehen.

Was ist DMARC und wie richtet man es ein?

DMARC (Domain-based Message Authentication, Reporting and Conformance, definiert in RFC 7489) baut auf SPF und DKIM auf und schließt eine entscheidende Lücke: Ohne DMARC kann ein Empfänger zwar prüfen, ob SPF und DKIM bestehen, weiß aber nicht, was er tun soll, wenn sie fehlschlagen. DMARC ermöglicht dem Domain-Inhaber, eine Policy festzulegen: durchlassen (p=none), in den Spam verschieben (p=quarantine) oder ablehnen (p=reject). Zusätzlich sendet DMARC täglich aggregierte XML-Berichte über alle E-Mails, die im Namen der Domain versendet wurden – einschließlich unautorisierter Sendungen.

DMARC schrittweise einführen

Eine übereilte DMARC-Einführung mit p=reject kann dazu führen, dass legitime E-Mails abgelehnt werden – etwa von Newsletter-Diensten, CRM-Systemen oder Weiterleitungen, die noch nicht korrekt authentifiziert sind. Deshalb empfiehlt sich ein schrittweises Vorgehen:

v=DMARC1; p=none; rua=mailto:dmarc@ihredomain.de; fo=1;

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@ihredomain.de;

v=DMARC1; p=reject; rua=mailto:dmarc@ihredomain.de; fo=1;

Nutzen Sie den Webalyzr DMARC Generator um Ihren DMARC-Record zu erstellen und zu validieren.

Wie SPF, DKIM und DMARC zusammenspielen

Die drei Standards ergänzen sich und sollten immer gemeinsam eingesetzt werden. SPF prüft, ob der sendende Server autorisiert ist. DKIM prüft, ob die E-Mail unterwegs nicht verändert wurde. DMARC definiert, was bei Fehlschlägen passiert, und liefert Reporting. Erst zusammen bieten sie einen wirksamen Schutz gegen E-Mail-Spoofing und Phishing. Google und Yahoo haben seit Februar 2024 verschärfte Anforderungen: Domains, die mehr als 5.000 E-Mails pro Tag an Gmail-Adressen senden, müssen alle drei Standards korrekt implementiert haben – andernfalls werden E-Mails abgelehnt. Auch für kleinere Absender verbessern SPF, DKIM und DMARC die Zustellbarkeit erheblich und schützen die Reputation der Domain.

Checkliste: E-Mail-Authentifizierung prüfen

Mit dem Webalyzr Website-Scan können Sie alle drei Standards automatisch prüfen lassen. Der Scan analysiert SPF-, DKIM- und DMARC-Records und gibt konkrete Handlungsempfehlungen, falls Konfigurationsfehler gefunden werden.