SPF, DKIM und DMARC: was die drei wirklich tun

Fast jede Firma, deren Mailkonfiguration wir uns ansehen, hat SPF. Viele haben zusätzlich DKIM. Und trotzdem kann jeder Fremde in ihrem Namen Rechnungen verschicken.

Das liegt nicht daran, dass die Einträge falsch wären. Es liegt daran, dass SPF und DKIM ohne DMARC folgenlos bleiben: Sie stellen fest, dass etwas nicht stimmt — sagen dem Empfänger aber nicht, was er dann tun soll. Also stellt er zu.

Die kurze Antwort

SPF legt fest, welche Server für eure Domain senden dürfen. DKIM unterschreibt jede Mail kryptografisch. DMARC verbindet beides, sagt dem Empfänger was bei einem Durchfall zu tun ist, und schickt euch Berichte darüber.

Alle drei sind TXT-Einträge im DNS. Keiner davon kostet Geld. Zusammen brauchen sie einen Nachmittag — plus einige Wochen Beobachtung, bevor man scharf stellt.

SPF: wer darf senden

Ein SPF-Eintrag ist eine Liste erlaubter Absender:

v=spf1 include:spf.protection.outlook.com include:_spf.mailjet.com -all

Übersetzt: „Microsoft 365 und Mailjet dürfen für uns senden. Alle anderen nicht." Das -all am Ende ist der entscheidende Teil — es sagt „alles Übrige ablehnen". Steht dort ~all, heißt das nur „verdächtig, aber zustellen". Fehlt das all ganz, ist die Liste eine Empfehlung ohne Wirkung.

Die Grenze von zehn Lookups

Hier liegt der Fehler, den wir am häufigsten finden und der am wenigsten bekannt ist:

Ein SPF-Eintrag darf beim Auswerten höchstens zehn DNS-Abfragen auslösen. Wer darüber liegt, dessen SPF gilt als fehlerhaft — manche Empfänger ignorieren ihn dann vollständig.

Jedes include: zählt. Und zwar nicht nur einmal: Was hinter dem include steht, bindet oft selbst wieder etwas ein. Microsoft 365 allein kostet mehrere Lookups. Wer dazu ein Newslettersystem, ein CRM, einen Shop und einen Rechnungsdienst einbindet, ist über der Grenze, ohne es zu merken — der Eintrag sieht ja weiterhin richtig aus.

Ausweg: nicht mehr benötigte Systeme entfernen, include-Ketten durch konkrete IP-Bereiche ersetzen (ip4:/ip6: kosten keinen Lookup), oder Subdomains für einzelne Dienste nutzen.

DKIM: die Unterschrift

DKIM hängt an jede ausgehende Mail eine kryptografische Signatur. Der Empfänger holt sich den öffentlichen Schlüssel aus eurem DNS und prüft, ob die Mail unterwegs verändert wurde.

Der Schlüssel liegt unter einem Selektor — einem frei gewählten Namen:

selector1._domainkey.firma.de

Deshalb kann ein Prüfwerkzeug DKIM nie mit Sicherheit ausschließen: Es müsste den Namen erraten. Unser DMARC-Check probiert zwölf verbreitete Selektoren von Microsoft 365, Google Workspace, IONOS und anderen durch. Findet er keinen, heißt das nur: nicht unter einem der üblichen Namen.

DMARC: die Entscheidung

DMARC ist der Eintrag, der aus den beiden anderen Schutz macht:

v=DMARC1; p=none; rua=mailto:dmarc@firma.de

Zwei Angaben zählen.

p= ist die Richtlinie. Sie sagt dem Empfänger, was er mit einer Mail tun soll, die weder SPF noch DKIM besteht:

rua= ist die Berichtsadresse. Dorthin schicken Google, Microsoft und die anderen großen Empfänger täglich eine Zusammenfassung: Wer hat in eurem Namen gesendet, und hat es die Prüfung bestanden? Ohne rua fliegt man blind.

Warum p=none kein Schutz ist

Bei p=none wird nur beobachtet. Gefälschte Mails werden trotzdem zugestellt.

Als Startpunkt ist das genau richtig — man braucht die Berichte, bevor man verschärft. Als Dauerzustand ist es eine Attrappe: Der Eintrag ist da, das Prüfwerkzeug zeigt grün, und schützen tut er nichts.

Wir sehen p=none bei der Mehrheit der Domains, die wir prüfen. Meistens, weil jemand vor zwei Jahren den ersten Schritt gemacht und den zweiten nie nachgeholt hat.

Die Falle mit der Subdomain

Ein DMARC-Eintrag auf mail.firma.de schützt firma.de nicht.

Das ist uns selbst passiert. Ein Aggregatbericht meldete 20 von 20 bestandenen Prüfungen — für unsere Versand-Subdomain. Unter der Hauptdomain, unter der uns die Kunden kennen und unter der sie Rechnungen von uns erwarten, gab es gar keinen DMARC-Eintrag.

DMARC wird von der Organisationsdomain aus vererbt, nicht umgekehrt. Wer eine Subdomain absichert, hat die Hauptdomain nicht abgesichert. Für Subdomains gibt es dafür sp= — die eigene Richtlinie für alles unterhalb.

Die Reihenfolge, die niemand abkürzen sollte

1. SPF vervollständigen. Alle sendenden Systeme aufnehmen, danach die Lookups zählen.
2. DKIM einschalten — bei jedem sendenden System einzeln.
3. DMARC mit p=none und rua= anlegen. Ab hier laufen Berichte ein.
4. Zwei bis vier Wochen Berichte auswerten. Sie zeigen Systeme, an die sich niemand mehr erinnert: das alte Ticketsystem, den Drucker, den Dienstleister von 2019.
5. Auf p=quarantine, beobachten.
6. Auf p=reject — erst wenn über mehrere Wochen nichts Eigenes mehr durchfällt.

Wer Schritt 4 überspringt und direkt auf p=reject geht, verliert echte Mail. Nicht theoretisch: Rechnungen, Bestellbestätigungen, Newsletter. Und man merkt es erst, wenn sich jemand beschwert.

Wie es bei euch aussieht

Der kostenlose DMARC-Check liest eure öffentlichen DNS-Einträge und zeigt in zehn Sekunden, wo ihr steht — SPF samt Lookup-Zählung, DMARC-Richtlinie, DKIM-Selektoren, dazu MTA-STS und TLS-RPT. Ohne Anmeldung, ohne E-Mail-Adresse.

Wenn dabei etwas herauskommt, das jemand geradeziehen soll: Wir machen das seit über 25 Jahren und stellen schrittweise scharf, ohne dass unterwegs Mail verloren geht.