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.