KeyHelp: SPF, DKIM und DMARC für Kundendomains einrichten und prüfen

Mails Ihrer Kunden landen nur dann zuverlässig im Posteingang, wenn die Domain drei Dinge im DNS veröffentlicht: einen SPF-Eintrag, der die erlaubten Absender-Server nennt, einen DKIM-Schlüssel, mit dem der Empfänger die Signatur prüft, und eine DMARC-Richtlinie, die festlegt, was mit durchgefallenen Mails passiert. KeyHelp legt alle drei beim Anlegen einer Domain automatisch an. Diese Anleitung zeigt, wo Sie die Einträge finden, wie Sie sie für Kundendomains anpassen, was KeyHelp dabei im Hintergrund in BIND und Rspamd schreibt und wie Sie das Ergebnis auf dem Server prüfen. Sie richtet sich an Administratoren eines Servers wie in KeyHelp installieren und absichern. Getestet haben wir mit KeyHelp 26.1.1 auf Debian 12.

Voraussetzungen

• KeyHelp mit Admin-Zugang, getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12. Kunden nutzen den „DNS-Editor“, wenn in der Benutzerverwaltung bei ihrem Konto das Recht „DNS-Editor“ gesetzt ist (beim Testkunden ab Werk aktiv).
• Eine Domain mit aktivierter Option „Domain kann für E-Mail verwendet werden“. Wie Domains angelegt werden, zeigt KeyHelp: Domains und Subdomains anlegen.
• Zuständiges DNS: Entweder zeigen die Nameserver der Domain auf Ihren KeyHelp-Server, dann wirken die Einträge aus dem Panel direkt. Oder die Zone liegt bei einem anderen Anbieter, dann tragen Sie dort dieselben Werte ein.
• SSH-Zugang für die Prüfung mit dig und rspamc. dig steckt unter Debian im Paket dnsutils.

Schritt 1: Die Standardeinträge kennen

Öffnen Sie „DNS-Editor“ im Bereich „Domains“ und wählen Sie die Kundendomain. Die Tabelle zeigt neben SOA, A, MX und NS drei mailrelevante TXT-Einträge:

• SPF auf @: "v=spf1 a mx -all". Erlaubt sind die IP-Adresse des A-Eintrags und die der MX-Server, alles andere schlägt hart fehl (-all).
• DKIM mit den Platzhaltern <DKIM_RECORD_HOST> und <DKIM_RECORD_VALUE>. KeyHelp ersetzt sie beim Schreiben der Zone durch Selektor und öffentlichen Schlüssel.
• DMARC auf _dmarc: "v=DMARC1; p=none". Das ist reine Beobachtung, Empfänger ergreifen keine Maßnahme.

Der MX-Eintrag lautet 10 mail, gemeint ist mail.kunde1.example.de, das über den Wildcard-A-Eintrag auf die Server-IP zeigt. Damit deckt mx im SPF-Eintrag den eigenen Server bereits ab.

Verifizieren: Fragen Sie den lokalen BIND direkt ab:

dig +short @127.0.0.1 TXT kunde1.example.de
dig +short @127.0.0.1 TXT _dmarc.kunde1.example.de
dig +short @127.0.0.1 TXT default._domainkey.kunde1.example.de

Im Test kamen "v=spf1 a mx -all", "v=DMARC1; p=none" und "v=DKIM1; k=rsa; " "p=MIIBIjAN…" zurück. Die Zonendatei selbst liegt unter /etc/bind/keyhelp_domains/kunde1.example.de und trägt den Hinweis, dass Änderungen beim nächsten Update verloren gehen. Bearbeiten Sie sie deshalb nur über das Panel.

Schritt 2: Prüfen, wie KeyHelp DKIM signiert

KeyHelp nutzt für DKIM kein OpenDKIM, sondern das Signiermodul von Rspamd. Die Steuerdatei /etc/rspamd/local.d/dkim_signing.conf verweist auf zwei Tabellen, die KeyHelp pflegt:

cat /var/lib/rspamd/keyhelp/dkim/signing.table
cat /var/lib/rspamd/keyhelp/dkim/key.table

Die erste ordnet Absenderadressen wie *@kunde1.example.de einer Domain zu, die zweite der Domain Selektor und Schlüsseldatei, etwa kunde1.example.de:default:/var/lib/rspamd/keyhelp/dkim/keys/kunde1.example.de/default.private. Jede Domain hat einen eigenen Schlüssel, auch die Systemsubdomain und der Server-Hostname. Den Eintrag für den Hostnamen zeigt das „Dashboard“ unter „DKIM DNS-Eintrag“.

Verifizieren: Senden Sie eine Testmail über Port 587 mit Anmeldung, zum Beispiel mit swaks, und sehen Sie in den Kopfzeilen nach:

swaks --server 127.0.0.1 --port 587 --tls --auth LOGIN \
  --auth-user info@kunde1.example.de --from info@kunde1.example.de \
  --to info@kunde1.example.de --header "Subject: DKIM-Test"

Die zugestellte Mail trug DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kunde1.example.de; s=default. openssl rsa -noout -text auf die Schlüsseldatei meldete Private-Key: (2048 bit, 2 primes).

Schritt 3: SPF und DMARC im DNS-Editor anpassen

Verschickt der Kunde auch über einen anderen Dienst, etwa einen Newsletter-Anbieter oder einen zweiten Server, muss dessen Adresse in den SPF-Eintrag. Ändern Sie dazu den Wert der Zeile mit v=spf1, zum Beispiel auf "v=spf1 a mx ip4:192.0.2.25 -all", und klicken Sie auf „Speichern“. Für DMARC empfiehlt sich ein Stufenplan: Beginnen Sie mit p=none und einer Berichtsadresse, prüfen Sie einige Wochen die Berichte und stellen Sie dann auf quarantine und später reject um. Ein Beispielwert:

"v=DMARC1; p=quarantine; rua=mailto:dmarc@kunde1.example.de"

Wichtig sind die Anführungszeichen um den ganzen Wert. Ohne sie schreibt KeyHelp den Wert ungeprüft in die Zonendatei, und BIND macht aus jedem Wort eine eigene Zeichenkette. Was dann passiert, steht unter „Typische Fehler“.

Nach dem Speichern meldet KeyHelp „Die Einstellungen wurden aktualisiert. Die Änderungen werden in wenigen Augenblicken wirksam.“ Im Test dauerte es bis zu einer Minute, bis die neue Zone mit erhöhter Seriennummer geladen war. Über „Einstellungen zurücksetzen“ stellen Sie die Standardzone wieder her, im Test wurden SPF und DMARC dabei auf die Werkswerte zurückgesetzt.

Verifizieren: dig +short @127.0.0.1 TXT kunde1.example.de muss genau einen v=spf1-Eintrag als eine zusammenhängende Zeichenkette liefern. named-checkzone kunde1.example.de /etc/bind/keyhelp_domains/kunde1.example.de meldete im Test loaded serial 2026100102 und OK.

Schritt 4: Die Wirkung mit Rspamd nachweisen

Ohne echte Zustellung nach außen lässt sich die Prüfung beim Empfänger mit rspamc nachstellen: Sie übergeben eine gespeicherte Mail und geben vor, von welcher IP sie kam. Damit Rspamd die Zonen des eigenen BIND sieht, haben wir in der Test-VM /etc/rspamd/local.d/options.inc mit dns { nameserver = ["127.0.0.1:53"]; } angelegt. Auf einem Produktivserver mit öffentlichem DNS ist das nicht nötig.

rspamc --ip 192.0.2.25 --from info@kunde1.example.de \
  --helo mail.example.net symbols < testmail.eml | grep -E "SPF|DKIM|DMARC"

Die Ergebnisse im Test:

• Signierte Mail von der erlaubten IP 192.0.2.25: R_SPF_ALLOW, R_DKIM_ALLOW, DMARC_POLICY_ALLOW, Aktion no action.
• Signierte Mail von der fremden IP 198.51.100.10: R_SPF_FAIL, aber DMARC_POLICY_ALLOW, weil die DKIM-Signatur passt. Trotzdem Aktion reject durch FORCE_ACTION_REJECT_SPF_FAIL, weil auf KeyHelp-Empfängern die Option „Zurückweisen von E-Mails, die SPF-Prüfungen nicht bestehen“ ab Werk aktiv ist.
• Unsignierte Mail von der fremden IP: DMARC_POLICY_QUARANTINE mit „No valid SPF, No valid DKIM, quarantine“.

Die Lehre: DKIM allein rettet eine Mail nicht, wenn der Empfänger hart nach SPF filtert. Halten Sie den SPF-Eintrag vollständig. Wie Sie die Empfangsseite in Rspamd einstellen, zeigt KeyHelp: Rspamd-Spamfilter einrichten.

Verifizieren: Erlaubte IP ergibt R_SPF_ALLOW und DMARC_POLICY_ALLOW, eine Fälschung ohne Signatur ergibt DMARC_POLICY_QUARANTINE oder REJECT, je nach Ihrer Richtlinie.

Schritt 5: DKIM-Selektor wechseln und extern eintragen

Im Bearbeiten-Dialog der Domain finden Sie im Reiter „E-Mail“ das Feld „DKIM-Selektor“ mit dem Wert „default“. KeyHelp warnt dort: „Jedes Mal, wenn Sie den Selektor ändern, wird ein neuer DKIM-Schlüssel erstellt.“ Ein eigener Selektor ist sinnvoll, wenn die Domain schon bei einem anderen Dienst einen Schlüssel unter default hat, oder für einen planmäßigen Schlüsselwechsel.

Im Test haben wir den Selektor auf k2026 geändert. KeyHelp erzeugte k2026.private, löschte den alten Schlüssel, passte key.table an und ersetzte in der Zone default._domainkey durch k2026._domainkey. Neue Mails trugen sofort s=k2026. Der alte Eintrag verschwindet dabei sofort aus dem DNS. Eine kurz vorher signierte Mail fiel bei der erneuten Prüfung mit R_DKIM_PERMFAIL durch. Wechseln Sie den Selektor deshalb nicht während laufender Mailaktionen.

Liegt das DNS der Domain nicht auf Ihrem Server, öffnen Sie im DNS-Editor der Domain über „Anzeigen“ den Dialog „DKIM DNS-Eintrag“. Er bietet den vollständigen Eintrag, den Host und den Wert mit und ohne Anführungszeichen zum Kopieren. Welche Form Sie brauchen, hängt vom Eingabefeld Ihres DNS-Anbieters ab.

Verifizieren: dig +short @127.0.0.1 TXT k2026._domainkey.kunde1.example.de liefert den neuen Schlüssel, cat /var/lib/rspamd/keyhelp/dkim/key.table zeigt kunde1.example.de:k2026:…. Bei externem DNS prüfen Sie mit dig +short TXT k2026._domainkey.kunde1.example.de gegen einen öffentlichen Resolver.

Typische Fehler

SPF ohne Anführungszeichen eingetragen

Wir haben bewusst v=spf1 a mx ip4:192.0.2.25 -all ohne Anführungszeichen gespeichert. KeyHelp nahm den Wert ohne Meldung an, dig lieferte danach "v=spf1" "a" "mx" "ip4:192.0.2.25" "-all". Rspamd wertete das als R_SPF_PERMFAIL (0.00)[empty SPF record], die Domain hatte damit faktisch kein SPF. Setzen Sie den ganzen Wert in Anführungszeichen.

Zwei SPF-Einträge

Wer für einen weiteren Dienst eine zweite v=spf1-Zeile hinzufügt, statt die vorhandene zu erweitern, bekommt im Test R_SPF_PERMFAIL (0.00)[bad SPF record]. KeyHelp warnt dabei nicht. Es darf nur einen SPF-Eintrag je Name geben.

MX ohne Priorität

Ein MX-Eintrag nur mit Hostnamen wird abgelehnt: „Eintrag #9 | Die Eingabefelder enthalten ungültige Daten für einen MX-Eintrag.“ Tragen Sie Priorität und Host ein, etwa 20 mail2.

Änderung scheint nicht zu wirken

KeyHelp schreibt die Zone nicht sofort. Warten Sie etwa eine Minute und prüfen Sie die Seriennummer in der Zonendatei. Öffentliche Resolver halten alte Werte zusätzlich bis zum Ablauf der TTL von 86400 Sekunden fest.

Häufige Fragen

Muss ich DKIM erst einschalten?

Nein. Im Test signierte Rspamd Mails der neuen Domain ohne weiteres Zutun. Es gibt im Panel keinen eigenen Schalter dafür.

Kann der Kunde die Einträge selbst ändern?

Ja, wenn sein Konto in der Benutzerverwaltung das Recht „DNS-Editor“ hat. Im Test konnte der Testkunde die Zone seiner Domain im Kundenbereich unter „DNS-Editor“ öffnen.

Ist p=none sinnvoll?

Als Start ja, dauerhaft nicht. p=none schützt nicht vor Fälschungen. Gehen Sie auf quarantine, sobald alle legitimen Absender im SPF stehen oder signieren.

Werden die Einträge bei neuen Domains automatisch übernommen?

Ja, jede neue Domain bekommt die Standardeinträge aus Schritt 1. Eigene Anpassungen gelten nur für die bearbeitete Zone.

Testumfang

Wir haben auf KeyHelp 26.1.1 die Standardeinträge einer Kundendomain geprüft, SPF, DMARC und den DKIM-Selektor geändert und die Wirkung mit dig, swaks und rspamc nachgestellt. Auffällig: TXT-Werte ohne Anführungszeichen und doppelte SPF-Einträge nimmt KeyHelp ohne Warnung an. Echte Zustellung an Google oder Microsoft und DMARC-Berichte haben wir nicht geprüft. Kontrollieren Sie nach jeder Änderung die Ausgabe von dig.

Fazit

KeyHelp nimmt Ihnen das Grundgerüst ab: SPF, DKIM mit eigenem Schlüssel pro Domain und eine DMARC-Beobachtung stehen ab dem Anlegen der Domain. Ihre Aufgabe ist es, den SPF-Eintrag um weitere Versender zu ergänzen, DMARC schrittweise zu verschärfen und bei externem DNS die Werte sauber zu übertragen. Achten Sie im DNS-Editor auf Anführungszeichen und auf genau einen SPF-Eintrag, denn hier prüft KeyHelp nicht mit.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern: das kostenlose Hosting-Panel für eigene Server
• KeyHelp: Rspamd-Spamfilter einrichten, einstellen und mit Testmails prüfen
• KeyHelp: E-Mail-Weiterleitungen mit SRS zuverlässig zustellen
• KeyHelp Knowledge Base: DNS-Zone bearbeiten
• Keyweb: KeyHelp 19.0 mit DKIM-Unterstützung