SPF, DKIM & DMARC erklärt

Das Problem: SMTP vertraut jedem

Beim klassischen E-Mail-Versand kann der Absender im „Von"-Feld frei eingetragen werden, ähnlich wie ein Absender auf einem Briefumschlag. Ein Angreifer kann so E-Mails im Namen Ihrer Domain verschicken (Spoofing), ohne Zugriff auf Ihr Postfach zu haben. Genau das nutzen Phishing und CEO-Fraud aus.

SPF, DKIM und DMARC schließen diese Lücke. Sie sind drei sich ergänzende DNS-basierte Verfahren, mit denen eine Domain nachweist, welche Server in ihrem Namen senden dürfen und dass die Nachricht unterwegs nicht verändert wurde.

Die drei im Zusammenspiel

Erst alle drei zusammen ergeben wirksamen Spoofing-Schutz. Große Anbieter (u. a. Google, Microsoft, Yahoo) verlangen für Massenversender inzwischen SPF, DKIM und DMARC, ohne diese landen Mails eher im Spam oder werden abgewiesen.

Wie es funktioniert

SPF ist ein TXT-Record im DNS der Domain, der die erlaubten sendenden Server auflistet. Der empfangende Server vergleicht die IP-Adresse des einliefernden Servers mit dieser Liste (geprüft wird die Domain aus dem MAIL FROM / Envelope-Sender, nicht die sichtbare Absenderadresse).

Syntax im Detail

• v=spf1, Version, immer am Anfang.
• ip4: / ip6:, erlaubte IP-Adresse oder -Bereich.
• include:, bindet die SPF-Regeln eines anderen Dienstes ein (z. B. Microsoft 365, Mailversand-Provider).
• a / mx, erlaubt die in A- bzw. MX-Records genannten Hosts.
• Mechanismus am Ende, legt fest, was mit nicht gelisteten Servern geschieht.

-all vs. ~all

• -all (Hard Fail): Alles Nicht-Gelistete wird als unautorisiert markiert, der strengste und empfohlene Endzustand.
• ~all (Soft Fail): Nicht-Gelistetes ist „verdächtig", wird aber nicht hart abgelehnt, gut für die Einführungsphase.
• ?all (Neutral) und +all (alle erlaubt) bieten praktisch keinen Schutz.

Wie es funktioniert

Der sendende Mailserver fügt jeder Nachricht eine digitale Signatur im Header hinzu (DKIM-Signature), erzeugt mit einem privaten Schlüssel. Der passende öffentliche Schlüssel liegt als TXT-Record im DNS. Der Empfänger holt ihn ab und prüft damit die Signatur: Stimmt sie, stammt die Mail nachweislich von der Domain und wurde unterwegs nicht verändert.

Der Selector bestimmt, welcher Schlüssel verwendet wird, so sind mehrere Schlüssel parallel und eine Rotation möglich. Der Empfänger findet den Public Key unter <selector>._domainkey.<domain>.

Bestandteile

• v=DKIM1, Version.
• k=rsa, Schlüsseltyp (RSA; teils auch Ed25519).
• p=…, der öffentliche Schlüssel (Base64).
• Der Selector steht nicht im Record, sondern im Hostnamen und in der Signatur der Mail (s=selector1).

Wichtig: Der private Schlüssel bleibt ausschließlich auf dem Mailserver / beim Provider, nur der öffentliche Teil gehört ins DNS. Bei M365 wird DKIM meist zentral vom Dienst verwaltet (siehe unten).

Wie es funktioniert

DMARC (Domain-based Message Authentication, Reporting & Conformance) baut auf SPF und DKIM auf. Es beantwortet zwei Fragen: Was soll passieren, wenn die Prüfungen fehlschlagen? Und: wohin werden Reports geschickt? Eine Mail besteht DMARC, wenn SPF oder DKIM passt und das Ergebnis „aligned" ist.

Alignment, der entscheidende Punkt

Alignment heißt: Die durch SPF bzw. DKIM authentifizierte Domain muss zur sichtbaren Absenderdomain (dem From:-Header) passen. Erst das verhindert, dass jemand mit einer fremden, korrekt signierten Domain in Ihrem Namen auftritt. Alignment kann relaxed (Subdomains erlaubt, Standard) oder strict (exakte Übereinstimmung) sein.

Die Richtlinie (p=)

• p=none, Monitor nur beobachten und Reports sammeln, keine Auswirkung auf die Zustellung. Startpunkt.
• p=quarantine, Quarantäne fehlschlagende Mails in den Spam/Junk.
• p=reject, Reject fehlschlagende Mails werden abgewiesen. Der wirksamste Endzustand.

Wichtige Parameter

• rua=, Adresse für aggregierte Reports (täglich, XML), zeigt, wer in Ihrem Namen sendet.
• ruf=, Adresse für forensische/Fehler-Reports (datenschutzsensibel, oft nicht genutzt).
• pct=, Prozentsatz der Mails, auf den die Policy angewendet wird (zum schrittweisen Ausrollen).
• sp=, eigene Richtlinie für Subdomains; adkim/aspf, Alignment-Modus (r/s).

1. SPF einrichten. Alle sendenden Systeme erfassen, TXT-Record anlegen, zunächst mit ~all. Auf das 10-Lookup-Limit achten.
2. DKIM aktivieren. Schlüssel beim Mailprovider erzeugen, Public-Key-Record(s) im DNS veröffentlichen, Signierung einschalten und mit einer Testmail prüfen.
3. DMARC mit p=none. Record mit rua anlegen und einige Wochen Reports auswerten, so finden Sie alle legitimen Absender.
4. Lücken schließen. Jeden legitimen Sender in SPF/DKIM aufnehmen, bis die Reports sauber sind.
5. Schrittweise verschärfen. Auf p=quarantine (ggf. mit pct= hochstufend), dann auf p=reject. SPF am Ende auf -all.

SPF für Exchange Online

Microsoft 365 wird über einen einzigen Include eingebunden:

DKIM: selector1 & selector2

M365 nutzt zwei Selektoren (selector1 und selector2), damit die Schlüssel rotiert werden können, ohne die Signierung zu unterbrechen. Statt der eigentlichen Schlüssel legt man zwei CNAME-Records an, die auf die von Microsoft verwalteten Schlüssel zeigen:

Die exakten Zielwerte zeigt das Microsoft-Defender-/Exchange-Admin-Center an. Danach DKIM im Portal aktivieren („Enable"). Erst nach dem Anlegen der CNAMEs lässt es sich einschalten.

DMARC bei M365

DMARC ist bei M365 nicht vorkonfiguriert, der _dmarc-TXT-Record wird wie bei jeder anderen Domain manuell angelegt (Start mit p=none, siehe oben).