SPF, DKIM, DMARC: Die drei Säulen der Mail-Authentifizierung

Drei Mechanismen, ein Ziel

SPF, DKIM und DMARC sind drei unabhängige Mechanismen, die zusammen eine Frage beantworten: Kommt diese E-Mail wirklich von der Domain, die sie behauptet?

Ohne sie kann jeder Mailserver der Welt behaupten, eine Mail von deiner Domain zu senden. Mit ihnen kann der empfangende Server prüfen, ob das stimmt.

Alle drei leben als DNS-Records. Und genau das macht sie angreifbar.

SPF: Wer darf senden?

SPF (Sender Policy Framework) ist eine Liste von IP-Adressen und Servern, die berechtigt sind, Mails für deine Domain zu versenden. Der empfangende Server prüft: Steht der sendende Server in der SPF-Liste?

Ein typischer SPF Record:

v=spf1 include:_spf.google.com include:amazonses.com -all

Das sagt: Google Workspace und Amazon SES dürfen senden. Alle anderen nicht (-all).

Was passiert bei Manipulation: Ein Angreifer fügt einen zusätzlichen Server zur SPF-Liste hinzu. Ab jetzt darf auch sein Server Mails in deinem Namen versenden – und sie bestehen die SPF-Prüfung. Phishing-Mails von deiner Domain landen im Posteingang, nicht im Spam.

DKIM: Ist die Mail unverändert?

DKIM (DomainKeys Identified Mail) signiert jede ausgehende Mail kryptografisch. Der öffentliche Schlüssel liegt als DNS-Record. Der empfangende Server prüft: Stimmt die Signatur mit dem öffentlichen Schlüssel überein?

Ein DKIM Record sieht so aus:

selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

Was passiert bei Manipulation: Ein Angreifer tauscht den öffentlichen Schlüssel im DNS aus. Jetzt kann er Mails mit seinem eigenen privaten Schlüssel signieren – und die DKIM-Prüfung besteht. Oder er entfernt den DKIM Record komplett. Dann schlägt die Prüfung fehl, aber ohne DMARC-Policy passiert trotzdem nichts.

DMARC: Was tun bei Versagen?

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist die Policy-Schicht. Sie sagt dem empfangenden Server: Was sollst du tun, wenn SPF oder DKIM fehlschlagen?

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Die drei Policies:

• none – nichts tun, nur berichten (Monitoring-Modus)
• quarantine – in Spam verschieben
• reject – Mail komplett ablehnen

Was passiert bei Manipulation: Ein Angreifer ändert die DMARC-Policy von "reject" auf "none". Ab jetzt werden Mails, die SPF und DKIM nicht bestehen, trotzdem zugestellt. Die Schutzwirkung ist aufgehoben – ohne dass du es merkst, weil deine eigenen Mails weiterhin funktionieren.

Die Vertrauenskette

SPF, DKIM und DMARC bilden zusammen eine Kette:

1. SPF prüft: Darf dieser Server senden?
2. DKIM prüft: Ist die Mail authentisch und unverändert?
3. DMARC entscheidet: Was passiert, wenn 1 oder 2 fehlschlagen?

Bricht ein Glied, bricht die Kette. Und alle drei Glieder sind DNS-Records – TXT-Einträge, die sich mit einem kompromittierten DNS-Zugang in Sekunden ändern lassen.

Schleichende Degradation

Das Tückische: Mail-Authentifizierung kann schleichend degradieren, ohne dass es auffällt.

• Ein Mitarbeiter fügt einen neuen Mail-Service hinzu, vergisst aber den SPF Record zu aktualisieren. Mails von diesem Service landen im Spam.
• Ein DKIM-Key wird rotiert, aber der alte DNS-Record bleibt stehen. Zwei Keys sind aktiv – einer davon vielleicht kompromittiert.
• Die DMARC-Policy wird zum Testen auf "none" gesetzt und nie wieder auf "reject" zurückgestellt.

Keiner dieser Fälle löst einen Alarm aus. Alles "funktioniert" – nur der Schutz ist weg.

Was Driftguard erkennt

Driftguard überwacht alle drei als Teil deiner DNS-Baseline:

SPF: Neue includes, entfernte Server, Wechsel von -all zu ~all (von strict zu soft-fail).

DKIM: Geänderte öffentliche Schlüssel, entfernte Records, neue Selektoren.

DMARC: Policy-Änderungen (reject → none), geänderte Report-Adressen, entfernte Records.

Jede Änderung wird erkannt und dokumentiert. Damit du siehst, ob deine Mail-Authentifizierung noch so stark ist wie am Tag, an dem du sie eingerichtet hast.

Weiterlesen

SPF, DKIM und DMARC schützen den Absender – aber wer kontrolliert den Empfänger? Das erklärt unser Artikel zum MX Record. Wenn du gerade erst startest und alles von Anfang an richtig machen willst, hilft unsere DNS-Checkliste für den guten Start.

Häufige Fragen

Was leisten SPF, DKIM und DMARC zusammen?

Sie beantworten die Frage, ob eine E-Mail wirklich von der Domain kommt, die sie behauptet. SPF prüft den sendenden Server, DKIM die Unverändertheit der Mail, DMARC entscheidet, was bei einem Fehlschlag passiert.

Was passiert, wenn ein Angreifer den SPF Record manipuliert?

Fügt er einen zusätzlichen Server zur SPF-Liste hinzu, darf dieser Server Mails in deinem Namen versenden und besteht die SPF-Prüfung – Phishing-Mails landen im Posteingang statt im Spam.

Was passiert, wenn der DKIM-Schlüssel im DNS ausgetauscht wird?

Ein Angreifer kann dann Mails mit seinem eigenen privaten Schlüssel signieren, und diese bestehen die DKIM-Prüfung – die Signatur täuscht Authentizität vor.

Warum ist eine DMARC-Policy-Änderung von 'reject' auf 'none' gefährlich?

Damit werden Mails, die SPF oder DKIM nicht bestehen, trotzdem zugestellt. Die Schutzwirkung ist aufgehoben, ohne dass die eigenen legitimen Mails betroffen sind – der Angriff bleibt unbemerkt.

Warum reicht es nicht, SPF, DKIM und DMARC einmal einzurichten?

Alle drei leben als DNS-Records und können sich mit kompromittiertem DNS-Zugang in Sekunden ändern. Ohne kontinuierliche Überwachung degradiert der Schutz schleichend, ohne dass es auffällt.