Zum Inhalt

E-Mail-Authentifizierung

E-Mail-Authentifizierung – SPF, DKIM und DMARC im Detail

Das Hauptkapitel hat SPF, DKIM und DMARC als Schutz vor Missbrauch eingeführt. Dieser Deep Dive erklärt, wie die drei Mechanismen intern zusammenarbeiten, wie du sie korrekt konfigurierst, wie du Fehler erkennst – und was passiert, wenn DMARC auf „reject" steht.

Das Problem: Warum E-Mail-Absender gefälscht werden können

Das E-Mail-Protokoll (SMTP) wurde in den 1970er Jahren entworfen – zu einer Zeit, als Vertrauen im Netz noch als selbstverständlich galt. Das Protokoll sieht keine eingebaute Authentifizierung vor: Jeder Server kann eine E-Mail mit einer beliebigen Absenderadresse versenden. absender@deinunternehmen.de als Absender bedeutet technisch nichts – es ist nur ein Textfeld.

Das ist die Grundlage für E-Mail-Spoofing: Angreifer versenden E-Mails mit deiner Absenderadresse, ohne Zugang zu deinem Konto zu haben. Deine Kunden erhalten dann gefälschte Rechnungen oder Phishing-Mails, scheinbar von dir – und du weißt davon nichts.

SPF, DKIM und DMARC sind drei unabhängige, aber zusammenwirkende Mechanismen, die dieses Problem adressieren. Sie wurden nachträglich ins DNS-System eingebaut und sind heute der Standard.

SPF – wer darf in meinem Namen senden?

Sender Policy Framework (SPF) ist ein DNS-TXT-Record, der festlegt, welche Server berechtigt sind, E-Mails für deine Domain zu versenden.

Aufbau eines SPF-Records:

v=spf1 include:_spf.google.com include:_spf.mimecast.com ~all
  • v=spf1 – Kennzeichnung als SPF-Record
  • include: – Erlaubt alle Server, die im SPF-Record des angegebenen Dienstes aufgeführt sind (hier: Google Workspace und Mimecast)
  • ip4: / ip6: – Erlaubt eine konkrete IP-Adresse oder einen IP-Bereich
  • a – Erlaubt den Server, auf den der A-Record der Domain zeigt
  • mx – Erlaubt die Server, die als MX-Records eingetragen sind
  • ~all – Soft Fail: E-Mails von nicht autorisierten Servern werden als verdächtig markiert, aber nicht abgelehnt
  • -all – Hard Fail: E-Mails von nicht autorisierten Servern werden abgelehnt

Praktischer Hinweis: Viele E-Mail-Anbieter (Google Workspace, Microsoft 365, Fastmail) liefern den exakten SPF-Record, den du eintragen musst. Kopiere ihn genau – und passe ihn an, wenn du mehrere Dienste nutzt, die E-Mails in deinem Namen senden (z. B. ein Newsletter-Tool wie Mailchimp oder ein CRM-System).

Häufiger Fehler: Für eine Domain darf es nur einen SPF-Record geben. Wenn du mehrere TXT-Records mit v=spf1 hast, ist der SPF-Record ungültig. Mehrere Dienste werden durch mehrere include:-Direktiven in einem einzigen Record kombiniert.

Prüfen: mxtoolbox.com/spf.aspx zeigt dir, ob dein SPF-Record korrekt ist und welche IP-Adressen er authorisiert.

DKIM – eine Unterschrift unter jeder E-Mail

DomainKeys Identified Mail (DKIM) ergänzt SPF um eine kryptografische Signatur: Jede ausgehende E-Mail wird vom sendenden Server mit einem privaten Schlüssel signiert. Der empfangende Server kann die Signatur mit dem öffentlichen Schlüssel verifizieren, der im DNS der Absenderdomain hinterlegt ist.

Was DKIM leistet: - Beweist, dass die E-Mail tatsächlich von einem Server deiner Domain gesendet wurde (und nicht von einem gefälschten Absender). - Beweist, dass der Inhalt der E-Mail auf dem Transportweg nicht verändert wurde.

Wie DKIM im DNS aussieht:

DKIM-Einträge sind TXT-Records an einer spezifischen Subdomain nach dem Schema selector._domainkey.deinunternehmen.de. Der „Selector" ist ein frei wählbarer Name, der es ermöglicht, mehrere DKIM-Schlüssel gleichzeitig zu betreiben.

google._domainkey.deinunternehmen.de  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb..."

Der lange String nach p= ist der öffentliche Schlüssel.

Was du tun musst: Die meisten E-Mail-Anbieter generieren das Schlüsselpaar automatisch und zeigen dir den genauen TXT-Record, der eingetragen werden muss. Du trägst ihn bei deinem DNS-Anbieter ein – fertig. Den privaten Schlüssel verwahrt der E-Mail-Anbieter; du musst ihn nicht kennen.

Mehrere Dienste: Wenn du neben deinem Hauptpostfach auch einen Newsletter-Dienst nutzt (Mailchimp, Brevo, etc.), hat dieser seinen eigenen DKIM-Selector und eigenen TXT-Record. Beide können gleichzeitig existieren, da sie unterschiedliche Subdomains nutzen.

Prüfen: mxtoolbox.com/dkim.aspx – gib Domain und Selector ein, um die Konfiguration zu prüfen.

DMARC – die Policy, die alles zusammenbringt

Domain-based Message Authentication, Reporting & Conformance (DMARC) ist der Dirigent: Er legt fest, was mit E-Mails passiert, die SPF oder DKIM nicht bestehen – und sorgt dafür, dass du über Verstöße informiert wirst.

DMARC führt das Konzept des „Alignment" ein: Es reicht nicht, dass SPF oder DKIM irgendwie passt – der geprüfte Absender muss mit dem im From:-Header sichtbaren Absender übereinstimmen. Das schließt eine Angriffstechnik, bei der Angreifer einen anderen, legitimen Absender für SPF/DKIM verwenden, aber im From:-Header deine Domain anzeigen.

Aufbau eines DMARC-Records:

_dmarc.deinunternehmen.de  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@deinunternehmen.de; pct=100"
  • v=DMARC1 – Kennzeichnung
  • p= – Die Policy: none (nur beobachten), quarantine (in Spam verschieben), reject (ablehnen)
  • rua= – Adresse, an die Aggregate-Reports geschickt werden (tägliche Zusammenfassung)
  • ruf= – Adresse für Forensic-Reports (detaillierte Berichte über einzelne Verstöße) – optional
  • pct= – Prozentsatz der E-Mails, auf die die Policy angewendet wird (100 = alle)

Die drei Policy-Stufen – und warum du nicht sofort auf „reject" gehen solltest:

p=none – Monitoring-Modus. Keine E-Mail wird abgelehnt, aber du erhältst Reports über alle E-Mails, die in deinem Namen versendet werden – legitime und illegitime. Das ist der richtige Einstieg: Du beobachtest zuerst, welche Dienste E-Mails in deinem Namen senden, und stellst sicher, dass alle in SPF und DKIM konfiguriert sind.

p=quarantine – E-Mails, die SPF/DKIM nicht bestehen, landen beim Empfänger im Spam-Ordner. Ein guter Zwischenschritt.

p=reject – E-Mails, die SPF/DKIM nicht bestehen, werden vom empfangenden Server vollständig abgelehnt. Das ist die stärkste Schutzmaßnahme – aber wenn ein legitimer Dienst (z. B. ein CRM-System oder ein Partnerunternehmen, das in deinem Namen sendet) nicht korrekt in SPF/DKIM konfiguriert ist, werden dessen E-Mails ebenfalls abgelehnt.

Empfohlene Vorgehensweise: 1. Starte mit p=none und einer rua=-Adresse. 2. Werte die Reports aus – entweder manuell oder mit einem kostenlosen Tool wie dmarcian.com oder dmarc.postmarkapp.com. 3. Stelle sicher, dass alle legitimen Absender in SPF und DKIM konfiguriert sind. 4. Wechsle zu p=quarantine, beobachte weiter. 5. Wechsle zu p=reject, wenn du sicher bist, dass alle legitimen Dienste korrekt konfiguriert sind.

DMARC-Reports lesen

Die täglichen Aggregate-Reports kommen als XML-Datei per E-Mail. Sie sind nicht für direkte Lektüre gedacht – ein Tool wie dmarc.postmarkapp.com (kostenlos, ohne Registrierung) oder dmarcian.com (kostenloser Einstieg) visualisiert sie lesbar.

Was du in den Reports siehst: - Welche IP-Adressen E-Mails in deinem Namen gesendet haben - Ob SPF und DKIM bestanden wurden - Wie viele E-Mails von welchem Dienst kamen

Das ist wertvoll: Du siehst nicht nur Angriffe, sondern auch legitime Dienste, die du vielleicht vergessen hast zu konfigurieren – zum Beispiel ein Buchungssystem, das Bestätigungsmails in deinem Namen sendet.

Zusammenspiel der drei Mechanismen

SPF, DKIM und DMARC ergänzen sich – keiner ersetzt den anderen:

Mechanismus Was er prüft Was er nicht abdeckt
SPF Ob der sendende Server authorisiert ist Ob der Inhalt verändert wurde; Weiterleitungen
DKIM Ob Inhalt und Absender authentisch sind Ob der Server überhaupt senden darf
DMARC Policy-Durchsetzung und Alignment Nichts – er koordiniert SPF und DKIM

Warum SPF alleine nicht reicht: Bei E-Mail-Weiterleitungen (z. B. wenn ein Kunde seine E-Mail weiterleitet) schlägt SPF oft fehl, weil der weiterleitende Server nicht im SPF-Record steht. DKIM überlebt Weiterleitungen in der Regel, weil die Signatur am Inhalt hängt.

Warum DKIM alleine nicht reicht: DKIM prüft nicht, ob der sendende Server legitimerweise E-Mails für die Domain senden darf. Ein Angreifer könnte seinen eigenen DKIM-Schlüssel für eine andere Domain nutzen.

Erst zusammen sind sie stark: DMARC mit p=reject und korrektem SPF + DKIM macht E-Mail-Spoofing deiner Domain praktisch unmöglich.

Checkliste: E-Mail-Authentifizierung

  • SPF-Record ist eingetragen und korrekt – geprüft mit mxtoolbox.com.
  • Alle Dienste, die E-Mails in meinem Namen versenden (E-Mail-Anbieter, Newsletter-Tool, CRM), sind im SPF-Record aufgeführt.
  • Es gibt nur einen SPF-Record für meine Domain.
  • DKIM ist für alle sendenden Dienste eingerichtet und die TXT-Records sind eingetragen.
  • DMARC ist eingerichtet – mindestens mit p=none und einer rua=-Adresse.
  • Ich werte DMARC-Reports aus – entweder direkt oder mit einem Visualisierungstool.
  • Ich habe einen Plan, schrittweise zu p=quarantine und p=reject zu wechseln.