SPF, DKIM und DMARC im Unternehmensbetrieb: Zustellbarkeit sichern und Spoofing verhindern

E-Mail ist der Kanal, über den Rechnungen, Angebote und Passwort-Resets laufen. Gleichzeitig ist der Absender einer E-Mail technisch frei wählbar, solange niemand das Gegenteil prüft. SPF, DKIM und DMARC sind die drei Verfahren, mit denen eine Domain festlegt, wer in ihrem Namen senden darf und was empfangende Systeme mit allem anderen tun sollen. Wer diese Einträge nicht pflegt, riskiert beides gleichzeitig: Nachrichten im Spam-Ordner und Phishing unter der eigenen Adresse.

Warum Authentifizierung heute Pflicht ist

Große Mailanbieter behandeln unauthentifizierte Absender zunehmend restriktiv. Eine Nachricht ohne gültige Signatur und ohne passenden SPF-Eintrag landet im besten Fall in der Quarantäne, im schlechteren wird sie stillschweigend verworfen. Für ein Unternehmen ist das schwer zu bemerken, weil der Absender in der Regel keine Rückmeldung bekommt.

Der zweite Grund ist der Missbrauch. Ohne veröffentlichte Regeln kann jeder eine Mail mit Ihrer Absenderdomain verschicken. Typisch sind gefälschte Rechnungen an Ihre Kunden oder Anweisungen an Ihre Buchhaltung, die scheinbar aus der Geschäftsführung stammen. Technisch lässt sich das nicht vollständig verhindern, aber eine durchgesetzte DMARC-Policy sorgt dafür, dass solche Nachrichten bei den meisten Empfängern nicht mehr zugestellt werden.

SPF: Wer darf senden

SPF ist ein DNS-TXT-Eintrag, der die IP-Adressen und Systeme auflistet, die für Ihre Domain senden dürfen. Geprüft wird dabei nicht die Adresse, die der Empfänger im Mailprogramm sieht, sondern der Envelope-Absender, also der Return-Path. Dieser Unterschied ist der häufigste Grund für Verwirrung bei Drittanbietern.

Ein SPF-Eintrag sieht etwa so aus:

v=spf1 include:_spf.beispielprovider.de ip4:203.0.113.10 -all

Zwei Details entscheiden über die Wirkung. Erstens das Ende: -all bedeutet hard fail, ~all nur soft fail. Zweitens das DNS-Lookup-Limit. SPF erlaubt maximal zehn DNS-Abfragen bei der Auswertung. Jeder include zählt mit, und Provider verschachteln ihre Einträge gern weiter. Wird das Limit überschritten, ist das Ergebnis permerror und die Prüfung gilt als gescheitert. Sammeln Sie deshalb nicht jeden jemals genutzten Dienst im Eintrag, sondern räumen Sie auf, wenn ein Werkzeug abgelöst wird.

SPF hat eine bekannte Schwäche: Bei Weiterleitungen bleibt die Absenderdomain gleich, die sendende IP ändert sich aber. Die Prüfung schlägt fehl, obwohl die Mail legitim ist. Genau deshalb reicht SPF allein nicht aus.

DKIM: Die kryptografische Signatur

DKIM signiert ausgehende Nachrichten mit einem privaten Schlüssel. Der zugehörige öffentliche Schlüssel liegt im DNS unter einem frei wählbaren Selector, etwa mail._domainkey.ihre-domain.de. Empfangende Server holen den Schlüssel dort ab und prüfen, ob Header und Inhalt unterwegs unverändert geblieben sind.

Der Vorteil gegenüber SPF: Die Signatur überlebt einfache Weiterleitungen, weil sie nicht an die sendende IP gebunden ist. Verwenden Sie Schlüssel mit 2048 Bit und getrennte Selectors je System. Ein eigener Selector für das Newsletter-Tool, einer für den Mailserver, einer für das CRM. So lässt sich ein Dienst abschalten oder ein Schlüssel tauschen, ohne alles andere anzufassen.

Planen Sie eine Schlüsselrotation ein. Praktisch funktioniert das über zwei parallele Selectors: Der neue Schlüssel wird veröffentlicht, das Sendesystem stellt um, der alte Eintrag bleibt noch einige Tage stehen und wird danach entfernt.

DMARC: Die Klammer über beiden

DMARC verbindet SPF und DKIM mit zwei Ergänzungen. Erstens verlangt es Alignment: Die bei SPF oder DKIM geprüfte Domain muss zu der Domain passen, die der Empfänger im From-Feld sieht. Ein Dienstleister, der mit seiner eigenen Return-Path-Domain sendet, besteht zwar die SPF-Prüfung, scheitert aber am Alignment. Zweitens legt DMARC fest, was im Fehlerfall passieren soll.

v=DMARC1; p=none; rua=mailto:dmarc@ihre-domain.de; fo=1

Die Policy kennt drei Stufen: none beobachtet nur, quarantine verschiebt in den Spam-Ordner, reject weist ab. Eine DMARC-Policy entfaltet ihre Schutzwirkung erst bei quarantine oder reject, none ist ausschließlich eine Messphase.

Ein realistischer Einführungspfad

1. Bestandsaufnahme: Welche Systeme senden tatsächlich mit Ihrer Domain? Mailserver, ERP, Ticketsystem, Monitoring, Newsletter, Bewerbungsportal.
2. SPF und DKIM für jedes dieser Systeme einrichten und einzeln testen.
3. DMARC mit p=none und Report-Adresse veröffentlichen.
4. Zwei bis vier Wochen Reports auswerten, bis keine unbekannten legitimen Quellen mehr auftauchen.
5. Auf quarantine wechseln, zunächst mit einem Prozentsatz über pct.
6. Nach stabiler Beobachtung auf reject stellen.

Typische Stolperfallen

Die meisten Probleme entstehen nicht am Mailserver, sondern an den Randsystemen. Ein Ticketsystem versendet Benachrichtigungen mit der Unternehmensdomain, wurde aber nie in SPF aufgenommen. Eine Marketingabteilung bucht ein Versandwerkzeug, ohne die IT einzubinden. Beides fällt erst auf, wenn die Policy hart gestellt wird.

Weiterleitungen sind ein zweiter Klassiker. Mitarbeiter leiten Post an private Adressen weiter, Verteiler verändern den Betreff und brechen damit die DKIM-Signatur. Mailinglisten setzen dafür teilweise ARC ein, verlassen kann man sich darauf nicht überall.

Vergessen Sie Subdomains nicht. DMARC vererbt die Policy zwar an Subdomains, sofern kein sp-Tag etwas anderes sagt, aber Angreifer nutzen gern Domains, die gar keine Mail versenden. Für solche Domains gehört ein restriktiver SPF-Eintrag und eine DMARC-Policy mit reject hinterlegt.

Reports auswerten, ohne darin zu ertrinken

Aggregat-Reports kommen als XML von jedem prüfenden Anbieter, typischerweise täglich. Sie enthalten sendende IP-Adressen, die Anzahl der Nachrichten und das Prüfergebnis. Im Rohformat sind sie mühsam zu lesen, deshalb lohnt ein Auswertungswerkzeug oder eine kleine Verarbeitung in ein Dashboard.

Interessant sind drei Fragen: Welche Quellen senden mit meiner Domain? Welche davon kenne ich nicht? Und scheitern bei bekannten Quellen SPF und DKIM gleichzeitig oder nur eines von beidem? Scheitert nur SPF, während DKIM korrekt signiert, ist das oft eine Weiterleitung und unkritisch.

Forensische Reports über ruf enthalten Teile echter Nachrichten. Prüfen Sie vor der Aktivierung, ob das mit Ihren Datenschutzvorgaben vereinbar ist. Für die Einführung reichen Aggregat-Reports fast immer aus.

Was im laufenden Betrieb bleibt

E-Mail-Authentifizierung ist kein Projekt mit Enddatum. Die Einträge leben im DNS und veralten genauso wie jede andere Konfiguration. Drei Punkte gehören in den Regelbetrieb.

• Änderungsprozess: Jedes neue System, das Mail versendet, durchläuft vorher die Freigabe für SPF und DKIM. Wird ein Dienst abgelöst, verschwinden seine Einträge wieder.
• Monitoring der DMARC-Reports, mindestens als monatlicher Blick auf unbekannte Quellen.
• Dokumentation, welcher Selector zu welchem System gehört und wann der Schlüssel zuletzt getauscht wurde.

Der Aufwand ist überschaubar, sobald die Erstaufnahme steht. Der Nutzen ist doppelt: verlässliche Zustellung Ihrer Geschäftspost und eine Domain, die sich nicht ohne Weiteres für Phishing missbrauchen lässt.