DKIM mit Rspamd und Postfix unter Debian 13

SPF, DKIM und DMARC gehören inzwischen zur Grundausstattung eines öffentlich betriebenen Mailservers. Gerade DKIM wird dabei häufig noch mit einem zusätzlichen OpenDKIM-Dienst umgesetzt. Wer Postfix ohnehin zusammen mit Rspamd betreibt, benötigt diesen zusätzlichen Baustein normalerweise nicht: Rspamd kann eingehende DKIM-Signaturen prüfen und ausgehende Nachrichten selbst signieren.

In diesem Artikel geht es deshalb nicht nur darum, einen DKIM-Schlüssel zu erzeugen. Entscheidend ist das Zusammenspiel zwischen Postfix, Rspamd, DNS und DMARC – und die Frage, an welcher Stelle im Mailfluss die DKIM-Signatur eigentlich entsteht.

Die Beispiele basieren auf Debian 13 „Trixie“ mit Postfix und Rspamd.

Was DKIM eigentlich macht

DKIM steht für DomainKeys Identified Mail.

Der sendende Mailserver berechnet aus definierten Bestandteilen einer Nachricht einen kryptografischen Hash und signiert diesen mit einem privaten Schlüssel. Die Signatur wird anschließend als zusätzlicher Header in die Nachricht eingefügt:

DKIM-Signature: ...

Der dazugehörige öffentliche Schlüssel befindet sich nicht auf dem empfangenden Mailserver, sondern im DNS der Absenderdomain.

Eine typische DNS-Abfrage sieht beispielsweise so aus:

2026a._domainkey.example.com

Der empfangende Server liest Domain und Selector aus der DKIM-Signatur, ruft den entsprechenden öffentlichen Schlüssel im DNS ab und überprüft damit die Signatur.

Damit lässt sich feststellen, ob die Nachricht von einem System signiert wurde, das Zugriff auf den privaten DKIM-Schlüssel der Domain hatte, und ob die signierten Bestandteile nach der Signierung verändert wurden.

DKIM verschlüsselt eine E-Mail dabei nicht. Auch der Inhalt der Nachricht bleibt vollständig lesbar.

Ebenso beweist eine gültige DKIM-Signatur nicht automatisch, dass ein beliebiger sichtbarer Absender legitim ist. Die Verbindung zwischen der DKIM-Domain und der sichtbaren Absenderdomain entsteht erst durch DMARC.

DKIM, SPF und DMARC erfüllen unterschiedliche Aufgaben

SPF, DKIM und DMARC werden häufig gemeinsam genannt, erfüllen aber unterschiedliche Aufgaben.

SPF beantwortet vereinfacht die Frage:

Darf dieser sendende Mailserver für die Domain des SMTP-Envelope-Senders Nachrichten verschicken?

DKIM beantwortet:

Ist die kryptografische Signatur dieser Nachricht gültig und gehört sie zur angegebenen Domain?

DMARC verbindet anschließend SPF und DKIM mit der Domain im sichtbaren From:-Header.

Diese Unterscheidung wird besonders bei Mailweiterleitungen wichtig.

SPF kann bei einer klassischen Weiterleitung fehlschlagen, weil der weiterleitende Server nicht im SPF-Record der ursprünglichen Absenderdomain enthalten ist. Eine DKIM-Signatur kann dagegen weiterhin gültig bleiben, solange die signierten Bestandteile der Nachricht nicht verändert werden.

Umgekehrt können Mailinglisten, Gateways, Disclaimer-Systeme oder andere Mailfilter eine DKIM-Signatur ungültig machen, wenn sie beispielsweise Betreff oder Nachrichtentext nachträglich verändern.

DKIM sollte deshalb nicht isoliert betrachtet werden, sondern immer als Teil eines Gesamtkonzepts aus SPF, DKIM und DMARC.

Warum DKIM direkt mit Rspamd?

Rspamd übernimmt auf einem modernen Mailserver bereits zahlreiche Aufgaben rund um Mailfilterung und Authentifizierung.

Dazu gehören unter anderem:

• Spam-Scoring
• SPF-Prüfung
• DKIM-Prüfung
• DMARC-Prüfung
• Bayes-Klassifikation
• Greylisting
• Reputationsbewertung
• Policy-Regeln

Zusätzlich besitzt Rspamd ein eigenes DKIM-Signing-Modul.

Damit ergibt sich eine vergleichsweise einfache Architektur:

Mailclient
    │
    │ SMTP Submission / Port 587
    ▼
Postfix
    │
    │ Milter
    ▼
Rspamd
    │
    ├── Spamprüfung
    ├── SPF / DKIM / DMARC
    ├── Policy
    └── DKIM-Signierung
    │
    ▼
Postfix
    │
    ▼
Internet

Ein zusätzlicher OpenDKIM-Prozess mit eigener Socket-, Benutzer- und Schlüsselverwaltung entfällt.

Das reduziert nicht nur die Zahl der beteiligten Dienste, sondern erleichtert auch die Fehlersuche, weil Filterung und DKIM-Signierung an einer zentralen Stelle zusammenlaufen.

Postfix mit Rspamd verbinden

Rspamd wird in Postfix als Milter eingebunden.

In /etc/postfix/main.cf:

smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = inet:127.0.0.1:11332

milter_protocol = 6
milter_default_action = tempfail
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}

Dabei gibt es einen wichtigen Unterschied zwischen smtpd_milters und non_smtpd_milters.

smtpd_milters verarbeitet Nachrichten, die über den Postfix-SMTP-Dienst eingehen. Dazu gehören auch Nachrichten, die ein Benutzer authentifiziert über den Submission-Dienst auf Port 587 einliefert.

non_smtpd_milters greift dagegen bei lokal über Postfix eingelieferten Nachrichten, beispielsweise über den lokalen sendmail-Mechanismus.

Gerade im Zusammenhang mit DKIM ist das relevant, wenn auch lokale Systemnachrichten signiert werden sollen.

Mit

milter_default_action = tempfail

wird eine Nachricht bei einem Ausfall von Rspamd zunächst temporär zurückgestellt.

Alternativ kann auch:

milter_default_action = accept

verwendet werden. In diesem Fall läuft der Mailverkehr bei einem Rspamd-Ausfall weiter, gegebenenfalls allerdings ohne Spamfilterung und ohne DKIM-Signierung.

Auf einem sicherheitsorientierten Mailserver ist tempfail eine sinnvolle Entscheidung. Eine Nachricht wird dann lieber später erneut zugestellt, statt die zentrale Filter- und Policy-Schicht unbemerkt zu umgehen.

DKIM-Schlüssel erzeugen

Zunächst wird ein geschütztes Verzeichnis für die privaten DKIM-Schlüssel angelegt:

sudo install -d \
  -o _rspamd \
  -g _rspamd \
  -m 0750 \
  /etc/rspamd/dkim

Anschließend wird das Schlüsselpaar erzeugt:

cd /etc/rspamd/dkim

sudo rspamadm dkim_keygen \
  -b 2048 \
  -s 2026a \
  -d example.com \
  -k 2026a.key

Danach werden die Zugriffsrechte gesetzt:

sudo chown _rspamd:_rspamd 2026a.key 2026a.txt
sudo chmod 0600 2026a.key
sudo chmod 0644 2026a.txt

Als Schlüssellänge werden 2048 Bit verwendet.

1024-Bit-Schlüssel sollten für neue Installationen nicht mehr verwendet werden. RSA mit 2048 Bit ist für klassische DKIM-Installationen weiterhin ein gut interoperabler Standard.

Rspamd unterstützt zusätzlich modernere Algorithmen wie Ed25519. Für einen öffentlich betriebenen Mailserver mit maximaler Kompatibilität gegenüber unterschiedlichen Empfängersystemen ist RSA-2048 jedoch weiterhin ein pragmatischer Ausgangspunkt.

Warum ein zeitbezogener Selector sinnvoll ist

Häufig findet man DKIM-Konfigurationen mit einem statischen Selector wie:

mail

Technisch funktioniert das problemlos.

Für eine spätere Schlüsselrotation ist ein zeitbezogener Selector allerdings praktischer, beispielsweise:

2026a

Der DNS-Eintrag lautet dann:

2026a._domainkey.example.com

Bei einer späteren Schlüsselrotation kann beispielsweise ein neuer Selector angelegt werden:

2027a

Der alte Schlüssel kann während einer Übergangsphase weiterhin im DNS verbleiben.

Damit lässt sich der Schlüssel wechseln, ohne den laufenden Mailbetrieb zu unterbrechen.

Rspamd für DKIM konfigurieren

Die DKIM-Signierung wird in:

/etc/rspamd/local.d/dkim_signing.conf

konfiguriert.

Eine einfache Konfiguration für eine einzelne Domain sieht so aus:

enabled = true;

domain {
  example.com {
    selector = "2026a";
    path = "/etc/rspamd/dkim/2026a.key";
  }
}

sign_authenticated = true;
sign_local = true;
sign_inbound = false;

use_domain = "header";
use_esld = true;

check_pubkey = true;
allow_pubkey_mismatch = false;

Die einzelnen Optionen sind dabei wichtiger, als es auf den ersten Blick wirkt.

Authentifizierte Benutzer signieren

sign_authenticated = true;

Damit werden Nachrichten signiert, die von authentifizierten Benutzern über den Mailserver eingeliefert werden.

Das ist der normale Weg für Mailclients, die Nachrichten über den Submission-Port 587 versenden.

Lokale Nachrichten signieren

sign_local = true;

Damit können auch vertrauenswürdige lokal eingelieferte Nachrichten signiert werden.

Das ist beispielsweise für Systemmeldungen, Cronjobs oder lokale Anwendungen interessant, die Nachrichten über Postfix erzeugen.

Wer ausschließlich authentifizierte SMTP-Submission signieren möchte, kann:

sign_local = false;

verwenden.

Auf einem klassischen Mailserver ist sign_local = true jedoch häufig sinnvoll, weil sonst lokal generierte Nachrichten unerwartet ohne DKIM-Signatur versendet werden können.

Eingehende Nachrichten nicht neu signieren

sign_inbound = false;

Fremde eingehende Nachrichten dürfen selbstverständlich nicht mit dem eigenen DKIM-Schlüssel neu signiert werden.

Rspamd prüft die vorhandene Signatur eingehender Nachrichten, verwendet aber den eigenen Schlüssel ausschließlich für dafür vorgesehene ausgehende Nachrichten.

Domain aus dem From-Header verwenden

use_domain = "header";

Damit verwendet Rspamd die Domain aus dem sichtbaren From:-Header als DKIM-Signing-Domain.

Das spielt insbesondere im Zusammenspiel mit DMARC eine wichtige Rolle.

Beispielsweise:

From: alice@example.com

Die DKIM-Signatur sollte dazu passen:

d=example.com;

Nur dann kann DKIM entsprechend der verwendeten DMARC-Policy als aligned gewertet werden.

Öffentlichen Schlüssel kontrollieren

Zusätzlich werden folgende Optionen gesetzt:

check_pubkey = true;
allow_pubkey_mismatch = false;

Rspamd kontrolliert damit, ob der zum privaten Schlüssel gehörende öffentliche Schlüssel tatsächlich im DNS veröffentlicht wurde.

Mit:

allow_pubkey_mismatch = false;

wird verhindert, dass Rspamd trotz eines nicht passenden DNS-Schlüssels einfach weiter signiert.

Das reduziert die Gefahr, versehentlich über längere Zeit Nachrichten mit einem Schlüssel zu signieren, den externe Mailserver nicht validieren können.

Öffentlichen Schlüssel im DNS veröffentlichen

Bei der Schlüsselerzeugung wurde neben dem privaten Schlüssel:

2026a.key

auch eine Datei mit dem öffentlichen Schlüssel erzeugt:

2026a.txt

Der darin enthaltene Wert wird als TXT-Record im DNS veröffentlicht.

Prinzipiell sieht der Eintrag so aus:

2026a._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=..."

Der Selector lautet:

2026a

Die Domain lautet:

example.com

In einer ausgehenden Nachricht enthält die DKIM-Signatur deshalb beispielsweise:

d=example.com;
s=2026a;

Der empfangende Server kombiniert daraus:

2026a._domainkey.example.com

und ruft dort den öffentlichen Schlüssel ab.

DNS-Eintrag überprüfen

Bevor die DKIM-Signierung produktiv verwendet wird, sollte kontrolliert werden, ob der DNS-Eintrag korrekt erreichbar ist.

Beispielsweise mit:

dig TXT 2026a._domainkey.example.com

oder kompakter:

dig +short TXT 2026a._domainkey.example.com

Erst wenn der öffentliche Schlüssel korrekt im DNS zurückgeliefert wird, sollte die Konfiguration produktiv aktiviert werden.

Rspamd-Konfiguration testen

Rspamd besitzt einen eigenen Konfigurationstest:

sudo rspamadm configtest

Ist die Konfiguration fehlerfrei, kann Rspamd neu gestartet werden:

sudo systemctl restart rspamd

Anschließend:

sudo systemctl status rspamd

Auch die Postfix-Konfiguration sollte kontrolliert werden:

sudo postfix check
sudo postconf -n

Zusätzlich lässt sich prüfen, ob der Rspamd-Milter erreichbar ist:

ss -lntp | grep 11332

DKIM mit einer echten Nachricht testen

Der entscheidende Test besteht nicht darin, lediglich die Konfiguration auf dem Server zu prüfen.

Eine reale Nachricht sollte über SMTP Submission mit Authentifizierung an einen externen Mailanbieter verschickt werden.

Im Header der empfangenen Nachricht sollte anschließend ein Eintrag wie:

DKIM-Signature:

vorhanden sein.

Noch wichtiger ist jedoch der Header des empfangenden Mailservers:

Authentication-Results:

Dort sollte sich beispielsweise finden:

dkim=pass

Ein vorhandener DKIM-Signature-Header allein beweist noch nicht, dass die Signatur gültig ist.

Entscheidend ist, dass der empfangende Server die Signatur erfolgreich überprüfen kann.

DKIM und DMARC

Damit DKIM bei DMARC berücksichtigt werden kann, muss die Signing-Domain zur sichtbaren Absenderdomain passen.

Beispielsweise:

From: alice@example.com

und:

DKIM-Signature:
    d=example.com;

sind miteinander aligned.

Eine DMARC-Policy kann zunächst beispielsweise so angelegt werden:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

Mit:

p=none

werden zunächst nur Berichte gesammelt.

Dieser Beobachtungsmodus ist sinnvoll, bevor eine restriktive Policy aktiviert wird.

Erst wenn alle legitimen Absender bekannt sind und SPF beziehungsweise DKIM korrekt funktionieren, kann schrittweise auf:

p=quarantine

und später gegebenenfalls:

p=reject

umgestellt werden.

Wer direkt mit p=reject startet, riskiert, legitime Absender zu blockieren.

Dazu können beispielsweise Newsletterdienste, Monitoring-Systeme, Drucker, Scanner, Ticketsysteme oder externe SaaS-Dienste gehören.

Mehrere Domains mit Rspamd signieren

Viele Mailserver verwalten mehr als eine Domain.

Für wenige Domains kann die Konfiguration weiterhin explizit erfolgen:

domain {
  example.com {
    selector = "2026a";
    path = "/etc/rspamd/dkim/example.com.2026a.key";
  }

  example.net {
    selector = "2026a";
    path = "/etc/rspamd/dkim/example.net.2026a.key";
  }
}

Für größere Installationen unterstützt Rspamd zusätzlich Maps und dynamisch aufgebaute Schlüsselpfade.

Bei zwei oder drei Domains ist eine explizite Konfiguration allerdings oft übersichtlicher. Fehler lassen sich leichter nachvollziehen und Schlüssel können eindeutig einzelnen Domains zugeordnet werden.

DKIM-Schlüssel rotieren

Auch ein DKIM-Schlüssel sollte nicht für alle Zeiten unverändert verwendet werden.

Eine Rotation erfolgt ohne Unterbrechung des Mailverkehrs.

Zunächst wird ein neuer Schlüssel erzeugt, beispielsweise mit dem Selector:

2027a

Danach wird der neue öffentliche Schlüssel unter:

2027a._domainkey.example.com

im DNS veröffentlicht.

Erst nachdem der neue DNS-Eintrag verfügbar ist, wird die Rspamd-Konfiguration auf den neuen Selector umgestellt:

selector = "2027a";

Der alte DNS-Eintrag sollte nicht unmittelbar entfernt werden.

Nachrichten, die kurz vor der Umstellung mit dem alten Schlüssel signiert wurden, können noch unterwegs sein oder verzögert zugestellt werden.

Der alte öffentliche Schlüssel bleibt deshalb zunächst für eine Übergangszeit bestehen.

Den privaten DKIM-Schlüssel sichern

Der private Schlüssel:

/etc/rspamd/dkim/2026a.key

darf niemals veröffentlicht werden.

Er sollte allerdings Bestandteil eines verschlüsselten und zugriffsgeschützten Backups sein.

Nach einem vollständigen Serververlust könnte ohne den privaten Schlüssel nicht mehr mit dem vorhandenen Selector signiert werden. In diesem Fall wäre eine sofortige Schlüsselrotation notwendig.

Die Dateirechte sollten kontrolliert werden:

ls -l /etc/rspamd/dkim

Für den privaten Schlüssel sollte ungefähr folgende Berechtigung sichtbar sein:

-rw------- _rspamd _rspamd 2026a.key

Damit kann ausschließlich der Rspamd-Benutzer den Schlüssel lesen.

Was DKIM nicht löst

Eine gültige DKIM-Signatur bedeutet nicht automatisch, dass eine Nachricht vertrauenswürdig ist.

Auch ein Spammer kann eine eigene Domain registrieren und dafür eine technisch vollkommen gültige DKIM-Konfiguration betreiben.

DKIM sagt zunächst lediglich:

Diese Nachricht wurde mit einem Schlüssel der angegebenen Domain signiert und die signierten Bestandteile wurden anschließend nicht verändert.

Ob die Domain seriös ist, ob eine Nachricht Spam oder Phishing enthält oder ob der sichtbare Absender tatsächlich legitim ist, sind separate Fragen.

Rspamd kombiniert DKIM deshalb mit vielen weiteren Merkmalen wie SPF, DMARC, Reputation, Inhaltsanalyse und statistischen Verfahren.

DKIM ist damit ein wichtiger Baustein – aber eben nur ein Baustein.

Fazit

Auf einem aktuellen Debian-Mailserver mit Postfix und Rspamd ist ein separater OpenDKIM-Dienst in der Regel nicht erforderlich.

Rspamd kann sowohl eingehende DKIM-Signaturen überprüfen als auch ausgehende Nachrichten signieren und ist über die Postfix-Milter-Schnittstelle ohnehin bereits an einer zentralen Stelle des Mailflusses eingebunden.

Der eigentliche DKIM-Schlüssel ist dabei nur ein kleiner Teil der Konfiguration. Ebenso wichtig sind die Auswahl der Nachrichten, die signiert werden dürfen, die Kontrolle des öffentlichen DNS-Schlüssels, ein sauberer Umgang mit privaten Schlüsseln und eine geplante Schlüsselrotation.

Vor allem sollte DKIM nie isoliert betrachtet werden.

Erst gemeinsam mit SPF und DMARC entsteht daraus eine belastbare Authentifizierungs- und Policy-Schicht für einen modernen Mailserver.