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 Sie sie korrekt konfigurieren, wie Sie Fehler erkennen – 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. info@ihrpraxis.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 Ihrer Absenderadresse, ohne Zugang zu Ihrem Konto zu haben. Ihre Patienten erhalten dann gefälschte Rechnungen oder Phishing-Mails, scheinbar von Ihrer Praxis – und Sie wissen 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 Ihre 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 Sie eintragen müssen. Kopieren Sie ihn genau – und passen Sie ihn an, wenn Sie mehrere Dienste nutzen, die E-Mails in Ihrem Namen senden (z. B. ein Buchungssystem für Patienten oder ein CRM-System).

Häufiger Fehler: Für eine Domain darf es nur einen SPF-Record geben. Wenn Sie mehrere TXT-Records mit v=spf1 haben, 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 Ihnen, ob Ihr SPF-Record korrekt ist und welche IP-Adressen er autorisiert.

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 Ihrer Absenderdomain hinterlegt ist.

Was DKIM leistet: - Beweist, dass die E-Mail tatsächlich von einem Server Ihrer 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.ihrpraxis.de. Der „Selector" ist ein frei wählbarer Name, der es ermöglicht, mehrere DKIM-Schlüssel gleichzeitig zu betreiben.

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

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

Was Sie tun müssen: Die meisten E-Mail-Anbieter generieren das Schlüsselpaar automatisch und zeigen Ihnen den genauen TXT-Record, der eingetragen werden muss. Sie tragen ihn bei Ihrem DNS-Anbieter ein – fertig. Den privaten Schlüssel verwahrt der E-Mail-Anbieter; Sie müssen ihn nicht kennen.

Mehrere Dienste: Wenn Sie neben Ihrem Hauptpostfach auch ein Buchungssystem oder Laborergebnis-System nutzen (die E-Mails versenden), hat dieses seinen eigenen DKIM-Selector und eigenen TXT-Record. Beide können gleichzeitig existieren, da sie unterschiedliche Subdomains nutzen.

Prüfen: mxtoolbox.com/dkim.aspx – geben Sie 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 Sie über Verstöße informiert werden.

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 Ihre Domain anzeigen.

Aufbau eines DMARC-Records:

_dmarc.ihrpraxis.de  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@ihrpraxis.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 Sie nicht sofort auf „reject" gehen sollten:

p=none – Monitoring-Modus. Keine E-Mail wird abgelehnt, aber Sie erhalten Reports über alle E-Mails, die in Ihrem Namen versendet werden – legitime und illegitime. Das ist der richtige Einstieg: Sie beobachten zuerst, welche Dienste E-Mails in Ihrem Namen senden, und stellen 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 Buchungssystem für Patiententermine oder ein Laborverbindungsdienst) nicht korrekt in SPF/DKIM konfiguriert ist, werden dessen E-Mails ebenfalls abgelehnt.

Empfohlene Vorgehensweise: 1. Starten Sie mit p=none und einer rua=-Adresse. 2. Werten Sie die Reports aus – entweder manuell oder mit einem kostenlosen Tool wie dmarcian.com oder dmarc.postmarkapp.com. 3. Stellen Sie sicher, dass alle legitimen Absender in SPF und DKIM konfiguriert sind. 4. Wechseln Sie zu p=quarantine, beobachten Sie weiter. 5. Wechseln Sie zu p=reject, wenn Sie sicher sind, 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 Sie in den Reports sehen: - Welche IP-Adressen E-Mails in Ihrem Namen gesendet haben - Ob SPF und DKIM bestanden wurden - Wie viele E-Mails von welchem Dienst kamen

Das ist wertvoll: Sie sehen nicht nur Angriffe, sondern auch legitime Dienste, die Sie vielleicht vergessen haben zu konfigurieren – zum Beispiel ein Buchungssystem, das Bestätigungsmails in Ihrem 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 autorisiert 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 Patient 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 legitim 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 Ihrer 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, Buchungssystem, Laborverbindung), 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.