E‑Mail‑Security praktisch: DMARC, DKIM und SPF einführen mit Postfix und Testing‑Workflow

Wenn Sie DMARC DKIM SPF einführen, ist das mehr als DNS‑Änderungen: Es ist ein Betriebsprojekt, das Inventar, MTA‑Design, Signaturstrategie, Report‑Handling und sichere Rollbacks erfordert. Dieses Runbook richtet sich an Administratoren, System Engineers und Betreiber: pragmatische Abläufe, Prüfbefehle, typische Stolperfallen und eine klare Rückfallstrategie.

DMARC DKIM SPF einführen: Kurze Begriffsklärung: SPF, DKIM, DMARC in der Praxis

SPF (Sender Policy Framework) ist ein DNS‑TXT‑Record, der angibt, welche Server für die Envelope‑From‑Domain senden dürfen; er schützt primär gegen direkten Spoofing des Return‑Path. DKIM (DomainKeys Identified Mail) signiert Nachrichten kryptografisch; der Empfänger verifiziert die Signatur gegen einen öffentlichen Schlüssel im DNS. DMARC (Domain‑based Message Authentication, Reporting & Conformance) verknüpft SPF und DKIM und prüft zusätzlich Alignment, also ob die geprüften Domains zur sichtbaren From:-Domain passen. Ohne Alignment ist die Schutzwirkung gegen Anzeige‑Täuschung begrenzt.

Voraussetzungen und organisatorische Vorbereitung

Bevor Sie Records ändern, legen Sie ein vollständiges Inventar aller Mail‑Sender an: zentrale Postfix‑Relays, Applikationen (z. B. Zammad‑Instanzen), Cloud‑Services (M365, Google, Marketing‑Tools), Monitoring, Backup‑Alerts und externe Anbieter. Klären Sie DNS‑Schreibrechte, TTL‑Policy (vor Änderungen TTL temporär senken) sowie mögliche Split‑Horizon‑DNS‑Setups, die unterschiedliche Antworten intern/extern liefern können.

Empfohlene Reihenfolge beim Rollout

1. DMARC mit p=none und RUA aktivieren, um reale Sender sichtbar zu machen.
2. SPF konsolidieren: einen sauberen Record pro Domain, Lookup‑Limit beachten.
3. DKIM flächig aktivieren, idealerweise zentral am Relay signieren (OpenDKIM).
4. Monitoren und dann DMARC stufenweise härten: quarantine (ggf. mit pct) → reject.

SPF: Praxisregeln und typische Fehler

SPF ist technisch simpel, in großen Umgebungen aber schnell komplex. Wichtige Regeln:

• Nur ein SPF‑TXT‑Record pro Domain (mehrere führen zu PermError).
• Begrenzen Sie DNS‑Lookups (Maximal 10); vermeiden Sie tiefe include‑Ketten.
• Dokumentieren Sie jeden Include und prüfen Sie Drittanbieter‑Sender (Newsletter, Scanner).

SPF‑Beispiel

; SPF für example.tld
example.tld. 3600 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.mailerprovider.net ~all"

SPF prüfen

dig +short TXT example.tld
# oder für vollständige Ausgabe
dig TXT example.tld +noall +answer

Wenn Sie viele Includes haben, ziehen Sie SPF‑Flattening nur mit Vorsicht in Betracht oder legen Sie Versand‑Subdomains an (z. B. mailer.example.tld) mit eigenen SPF‑Records.

DKIM mit Postfix: OpenDKIM als Milter

In Postfix wird DKIM typischerweise per Milter realisiert. OpenDKIM ist ein verbreitetes, stabil laufendes Werkzeug. Entscheiden Sie: zentrale Signatur am Relay (vereinheitlicht Keys/Rotation) oder dezentral pro Host (bessere Verantwortungszuordnung).

Schlüsselstrategie

Empfehlung: RSA 2048 als Minimum; 1024 gilt als veraltet. Nutzen Sie ein Selector‑Schema mit Zeitkomponente (z. B. s2026q3) zur Rotation. Lagern Sie private Schlüssel sicher (Dateirechte, Zugriffsbeschränkungen) und legen Sie regelmäßige Rotationstermine fest.

OpenDKIM: Installation und Basiskonfiguration

sudo apt-get update
sudo apt-get install -y opendkim opendkim-tools

; /etc/opendkim.conf (Auszug)
Syslog                  yes
SyslogSuccess           yes
Canonicalization        relaxed/simple
Mode                    sv
Socket                  local:/run/opendkim/opendkim.sock
KeyTable                /etc/opendkim/key.table
SigningTable            refile:/etc/opendkim/signing.table
InternalHosts           /etc/opendkim/trusted.hosts

sudo install -d -m 0750 -o opendkim -g opendkim /etc/opendkim/keys/example.tld
cd /etc/opendkim/keys/example.tld
sudo -u opendkim opendkim-genkey -b 2048 -s s2026q3 -d example.tld
sudo chown -R opendkim:opendkim /etc/opendkim/keys/example.tld
sudo chmod 0640 /etc/opendkim/keys/example.tld/s2026q3.private
# DNS prüfen
dig @1.1.1.1 +short TXT s2026q3._domainkey.example.tld

Postfix‑Anbindung

# /etc/postfix/main.cf (Ausschnitt)
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:/run/opendkim/opendkim.sock
non_smtpd_milters = unix:/run/opendkim/opendkim.sock

Wichtig: Während der Einführungsphase sollten Sie milter_default_action=accept setzen, damit Milter‑Ausfälle die Zustellung nicht blockieren.

DMARC: Reporting aktivieren, Policy später verschärfen

DMARC publizieren Sie als TXT unter _dmarc.example.tld. Starten Sie mit p=none und einem rua-Empfänger, um aggregierte Reports zu sammeln und Probleme sichtbar zu machen.

Startrecord

_dmarc.example.tld. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; fo=1; pct=100"

RUA‑Reports sind XML‑Dateien (oft in ZIP), die Informationen über SPF/DKIM‑Ergebnisse, IPs und Volumen enthalten. Verwenden Sie einen Parser (z. B. Open‑Source‑Tools wie pydmarc) oder einen externen Collector; achten Sie auf Storage, Retention und Datenschutz der enthaltenen IP‑Informationen.

Alignment verstehen

DMARC erfordert, dass entweder SPF oder DKIM zur sichtbaren From:-Domain aligned ist. Häufige Ursachen für DMARC‑Fails sind:

• Envelope‑From gehört einem Drittanbieter (Provider), From: trägt Unternehmensdomain.
• DKIM signiert mit anderer d=‑Domain als der sichtbaren From:-Domain.

Lösungen: Envelope‑From anpassen (z. B. über Relay), DKIM so signieren, dass d= die From‑Domain ist, oder Versand über Subdomains mit eigenem DMARC.

Testing‑Workflow: Messbar und kontrolliert

Ein iteratives Vorgehen schützt vor Abschaltungen legitimer Systeme. Empfohlenes Ablaufmodell:

1) Baseline: DMARC p=none, 48–72 Stunden Reports

Sammeln Sie RUA‑Daten, katalogisieren Sie Sender‑IPs und Dienste. Markieren Sie unklare Quellen und priorisieren Sie die Klärung nach Volumen und Kritikalität.

2) SPF bereinigen

Reduzieren Sie Includes, erstellen Sie falls nötig Versand‑Subdomains und testen Sie nach jeder Änderung mit öffentlichen Resolvern.

3) DKIM überall aktivieren

Sorgen Sie dafür, dass alle produktiven Pfade über den signierenden Hop laufen. Versenden Sie Testmails aus jeder Applikation und prüfen Sie die Header beim Empfänger.

4) Quarantine mit pct‑Steuerung

_dmarc.example.tld. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; pct=50"

Steigern Sie die Policy‑Strenge schrittweise und beobachten Sie Canary‑Postfächer (Gmail, M365) sowie das Support‑Backlog.

5) Reject

Setzen Sie p=reject erst, wenn alle legitimen Sender stabil aligned sind und Sie zeitnah auf Support‑Tickets reagieren können. Planen Sie klare SLAs für Analyse & Rollback.

Praktische Test‑ und Diagnosebefehle

Zum Versenden von Testmails ist swaks (Swiss Army Knife SMTP) nützlich; damit können Sie prüfen, ob Signaturen erzeugt werden:

# Beispiel: Testmail via lokalen Relay
swaks --to test@example.org --from zammad@example.tld --server localhost:25 --header "Subject: DKIM Test"

# DKIM/Header prüfen (auf Empfänger oder lokalen Mailbox-Store)
grep -i "DKIM-Signature|Authentication-Results" /var/mail/testuser | sed -n '1,80p'

DNS‑Checks:

dig @1.1.1.1 TXT s2026q3._domainkey.example.tld
dig @8.8.8.8 TXT _dmarc.example.tld +noall +answer
# Über TCP testen, falls große TXT-Records Probleme machen
dig @1.1.1.1 TXT s2026q3._domainkey.example.tld +noall +answer +tcp

RUA‑Report prüfen (ZIP entpacken und formatieren):

unzip -p report-12345.zip | xmllint --format - | sed -n '1,200p'

Zammad‑spezifische Betriebsregeln

Zammad‑Instanzen senden oft systemkritische Mails (Ticket‑Benachrichtigungen, SLA‑Alerts). Prüfen Sie folgende Punkte:

• Stellen Sie Zammad so ein, dass ausgehende Mails über das zentrale Postfix‑Relay laufen (Admin‑UI oder systemsendmail). Das sichert zentrale DKIM‑Signatur und DMARC‑Alignment.
• Prüfen Sie From: vs Envelope‑From: Zammad kann standardmäßig unterschiedliche Absender verwenden; konfigurieren Sie konsistente Absenderdomains oder nutzen Sie eine Mailer‑Subdomain.
• Führen Sie Test‑Ticket‑Sends durch und prüfen Sie die Headers am Empfänger vollständig (Received, DKIM‑Signature, Authentication‑Results).
• Automatisieren Sie stichprobenartige Prüfungen: Ein Monitoring‑Job, der regelmäßig testmails schickt und Signatur/Authentication‑Results prüft, reduziert Betriebsrisiken.

Problemfälle und Troubleshooting

DMARC fail obwohl SPF/DKIM pass

Oft liegt das an fehlendem Alignment. Prüfen Sie, ob DKIM d= mit der From‑Domain übereinstimmt oder ob der Return‑Path zur gleichen organisationalen Domain gehört.

DKIM pass bei einigen Providern, fail bei anderen

Hier ist oft die DNS‑Auslieferung die Ursache: Split‑Horizon, TXT‑Trunkierung oder Caching. Testen Sie mit verschiedenen öffentlichen Resolvern und über TCP, um Fragmentierungsprobleme zu finden.

Milter‑Ausfall

sudo systemctl status opendkim --no-pager
sudo ss -xlpn | grep opendkim
journalctl -u opendkim -n 200 --no-pager
journalctl -u postfix -n 200 --no-pager

Während der Einführungsphase sollten Milter‑Fehler die Zustellung nicht verhindern (milter_default_action=accept), in der Betriebsphase jedoch überwacht und behoben werden.

Forwarding, Mailinglisten und ARC

SPF schlägt bei einfachem Forwarding häufig fehl, weil der Forwarder nicht in Ihrem SPF steht. Zwei praktikable Optionen:

• DKIM einsetzen — Signaturen überdauern Forwarding meist besser.
• Authenticated Received Chain (ARC) unterstützen — ARC ist ein Header‑Mechanismus, der die Authentizität über Mailinglisten/Forwarder hinweg dokumentiert und Empfängern hilft, legitime Nachrichten trotz gebrochener SPF/DKIM‑Ergebnisse zu akzeptieren.

ARC ist besonders nützlich in Umgebungen mit vielen Mailinglisten oder internen Weiterleitungen.

Sicherheit, Schlüsselmanagement und Betriebshygiene

Private DKIM‑Schlüssel sind Betriebsgeheimnisse: sichern Sie Dateien, beschränken Sie Dateirechte und sichern Sie Backups. Dokumentieren Sie Rotationstermine und testen Sie Key‑Wechsel in einer Staging‑Zone. Implementieren Sie ein Change‑Control für DNS‑Änderungen (Git + CI für Zonendateien oder ein Ticket‑gesteuertes DNS‑Deployment).

Konkreter Rollback‑Plan (kurz und handlungsfähig)

1. Wenn kritische Zustellausfälle auftreten, setzen Sie DMARC schnell auf p=none:

# Beispiel: neuer DMARC-Record
_dmarc.example.tld. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; pct=100"

# DNS-Änderung prüfen
dig @1.1.1.1 TXT _dmarc.example.tld +noall +answer
# Postfix/OpenDKIM Status prüfen
sudo systemctl status postfix opendkim --no-pager

Setzen Sie dann die Ursachenanalyse an: welche Sender fehlschlugen, welche Services waren betroffen, und dokumentieren Sie Learnings in Ihrem Change‑Log.

Langfristige Pflege und Monitoring

Planen Sie regelmäßige Reviews: RUA‑Reports analysieren (z. B. wöchentlich), DKIM‑Key‑Rotation halbjährlich, SPF‑Inventar vierteljährlich. Automatisieren Sie Alerts für plötzliche Volumen‑ oder Fehlerratenanstiege in DMARC‑Reports.

Fazit

DMARC, DKIM und SPF einzuführen ist ein operatives Projekt: Inventar, DNS‑Governance, zentrale Signaturstrategie, Testing‑Workflow und klare Rückfallpfade sind entscheidend. Beginnen Sie mit DMARC‑Reporting, bereinigen Sie SPF, aktivieren Sie DKIM am Relay, und härten Sie DMARC stufenweise. Dokumentation, Monitoring und regelmäßige Pflege machen die Maßnahme dauerhaft erfolgreich — besonders für Applikationen wie Zammad, die kritische Benachrichtigungen versenden.

DMARC, DKIM & SPF: Betrieb, Monitoring und Automatisierung

Nachdem die Basistechnik steht, entscheidet der laufende Betrieb über Erfolg. Drehen Sie die Perspektive vom Einmal‑Projekt zum dauerhaften Service: DNS‑Governance, Milter‑Hochverfügbarkeit, RUA‑Pipeline, Key‑Lifecycle und Rollback‑Automatisierung sind operative Baustellen, die Sie früh planen sollten.

DNS‑Provider und Änderungsbetrieb

• Achten Sie auf Provider‑Limits für API‑Calls und Rate‑Limiting bei Zonenuploads; automatisierte Deploys können sonst fehlschlagen oder zu TTL‑Inkonsistenzen führen.
• Nutzen Sie vor großen Änderungen kurze TTLs (z. B. 300s) und erhöhen Sie sie wieder nach Stabilität.
• Testen Sie TXT‑Auslieferung über mehrere öffentliche Resolver und über TCP, um Trunkierung zu erkennen.

Hochverfügbarkeit und Schlüsselmanagement

Betreiben Sie den DKIM‑Signer als hochverfügbare Komponente: entkoppeln Sie Postfix‑Hops per TCP/inet‑Milter oder zentralen Proxy. Private Schlüssel gehören in einen sicheren Key‑Store oder HSM; legen Sie ein dokumentiertes Emergency‑Rotation‑Playbook an (neuer Selector publishen, Signaturen umschalten, alten Schlüssel erst nach Testwindow entfernen).

RUA‑Pipeline & SIEM‑Integration

RUA‑Reports sind Rohdaten — bauen Sie eine automatisierte Pipeline: Collector (E‑Mail oder API) → Parser/Normalizer → Zeitreihendatenbank & SIEM. Regeln, die sofort alerten sollten: plötzlicher Anstieg von DMARC‑Fails, neue Sendende IPs mit hohem Volumen, oder wiederkehrende Fehlschläge für kritische Subdomains. Achten Sie auf Datenschutz: IPs in Reports sind personenbezogen relevant und benötigen passende Retention‑Policies.

Operational Safety Nets

• Canary‑Empfänger: Ein kleines Set verschiedener Provider (Gmail, M365) als Frühwarnsystem.
• Milter‑Circuit‑Breaker: automatisches Alerting bei wiederholten Milter‑Timeouts; solange milter_default_action=accept hilft eine sichere Fallback‑Phase.
• Infrastructure as Code: DNS‑Changes per GitOps (Pull‑Request, Review, CI) minimiert menschliche Fehler und ermöglicht schnelles Revert.

Diese Betriebsbausteine machen das Projekt resilient: Sie reduzieren Support‑Tickets, verhindern Betriebsstörungen für individuelle Unternehmenssoftware wie Zammad und schaffen eine klar auditierbare Änderungshistorie.

Für dieses Thema sind auch Postfix Dkim und Spf Record wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.