DKIM, SPF und DMARC: E-Mail-Authentifizierung richtig einrichten

E-Mail ist das Rückgrat der Kommunikation im eigenen Homelab — aber ohne Authentifizierung landen Ihre Nachrichten schnell im Spam-Filter oder werden ganz blockiert. DKIM, SPF und DMARC sind die drei Säulen, auf denen eine vertrauenswürdige Absenderidentität ruht. Dieser Artikel zeigt, wie Sie sie Schritt für Schritt einrichten und worauf Sie bei der Konfiguration achten müssen.

Warum E-Mail-Authentifizierung notwendig ist

Die E-Mail-Technik entstand, als das Internet noch klein war und niemand dachte, dass Absenderadressen vorgefälscht werden könnten. Das Ergebnis: Jeder kann im From-Feld beliebige E-Mails vortäuschen. Speisen Sie Ihre Nachrichten ohne Authentifizierung in die Welt, dann behandeln viele Provider (Gmail, Outlook, GMX) Ihre Mails als verdächtig — oder lehnen sie gar nicht erst an.

Drei Mechanismen lösen dieses Problem gemeinsam:

• SPF (Sender Policy Framework) definiert, welche Server für Ihre Domain E-Mails versenden dürfen.
• DKIM (DomainKeys Identified Mail) signiert jede ausgehende Nachricht mit einem privaten Schlüssel, den der Empfänger über den öffentlichen DNS-Eintrag verifizieren kann.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) sagt den Empfängern, was sie mit Nachrichten tun sollen, die SPF oder DKIM nicht bestehen — und liefert Berichte zurück an Sie.

Ohne diese drei Mechanismen sehen große Postfachanbieter Ihre Domain als riskant an. Die Folge: gelieferte Nachrichten landen im Spam-Ordner, schlechtere Zuverlässigkeit und im schlimmsten Fall eine komplette Ablehnung durch empfangende Server.

SPF-Record: Praktische Einrichtung mit Mailcow und Postfix

Ein SPF-Record ist ein TXT-Eintrag in Ihrer DNS-Zone. Er listet alle autorisierten Mailserver auf und definiert, wie streng der Empfänger bei Verstößen vorgehen soll.

Syntax und Grundstruktur

v=spf1 include:_spf.mailcow.email -all

Hier sind die wichtigsten Elemente:

• v=spf1 kennzeichnet den Record.
• include: bindet externe SPF-Definitionen ein (beispielsweise die Mailserver Ihres Providers oder von Mailcow).
• -all bedeutet "hard fail": E-Mails von nicht aufgelisteten Servern werden abgelehnt.
• Alternativ ~all (SoftFail) für die Testphase, wenn Sie noch nicht sicher sind.

Beispiele für häufige Konfigurationen

Nur eigener Server (Postfix direkt):

v=spf1 mx ~all

Das autorisiert den Host, der auch für MX-Empfang zuständig ist. Gut für einfache Homelab-Setups, bei denen kein Drittanbieter mitsendet.

Mailcow mit externen Versanddiensten:

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

Mailcow setzt eigene SPF-Templates bereit. Prüfen Sie unter Site-Admin → Mail-Settings → MX/SMTP, ob Ihr DNS bereits korrekt konfiguriert ist.

Typische Fehler bei SPF

1. Zu viele DNS-Lookups: SPF erlaubt maximal 10 DNS-Abfragen (Mechaniken wie include, a, mx, ptr). Überschreiten Sie diese Grenze, gilt der Record als permerror und wird nicht ausgewertet.

Vermeiden Sie verschachtelte include:-Ketten. Prüfen Sie die Lookup-Anzahl mit einem Tool wie dig oder online mit einem SPF-Checker.

2. Falsche oder doppelte include-Einträge: Ein lbs. include: verweist auf einen externen SPF-Record, der selbst wieder include:-Mechanismen haben kann. Jede Stufe kostet einen Lookup.

3. Widersprüchliche Qualifier: Wenn Sie sowohl ~all als auch -all in verschiedenen Records definieren, ist das Ergebnis unspezifisch. Nutzen Sie einen einzigen konsistenten Eintrag.

DKIM: Schlüssel erzeugen, veröffentlichen und rotieren

DKIM funktioniert über ein Public/Private-Key-Verfahren. Der Private Key signiert E-Mails beim Versand; der Public Key widerholt im DNS und ermöglicht dem Empfänger die Verifikation.

Schlüssel mit OpenDKIM generieren

Die gebräuchlichste Methode ist opendkim-genkey:

mkdir -p /etc/opendkim/keys/brillianze.de
opendkim-genkey -b 2048 -d brillianze.de -s mail -D /etc/opendkim/keys/brillianze.de
chmod 600 /etc/opendkim/keys/brillianze.de/mail.private
chown opendkim:opendkim /etc/opendkim/keys/brillianze.de/mail.*

• -b 2048 erzeugt einen 2048-Bit-RSA-Schlüssel (empfohlen; 1024 Bit gilt als zu schwach).
• -s mail definiert den Selektor (bestimmt den DNS-Subdomänen-Namen).

DNS-Eintrag veröffentlichen

Der generierte mail.txt-Inhalt enthält den Public-Key als TXT-Record. Diesen tragen Sie unter folgender Adresse ein:

mail._domainkey.brillianze.de. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Stellen Sie sicher, dass:

• Der Selektor (hier mail) im DNS-Eintrag und in der DKIM-Konfiguration übereinstimmt.
• Der Schlüssel intakt ist — kein Zeilenumbruch im p=-Wert, kein fehlendes " oder Leerzeichen.

Rotation des DKIM-Schlüssels

Schlüssel sollten regelmäßig (alle 6–12 Monate) ausgetauscht werden:

1. Neuen Schlüssel mit neuem Selektor generieren (z. B. mail2).

2. DNS-Record für mail2._domainkey hinzufügen.

3. OpenDKIM-Konfiguration auf neuen Selektor umstellen (Selector mail2).

4. Mailserver neustarten.

5. Alten Schlüssel nach einer Übergangsfrist (z. B. 2 Wochen) aus DNS und OpenDKIM entfernen.

Wichtig: Während der Übergangszeit müssen beide Selektoren aktiv sein, damit luktierende E-Mails noch verifiziert werden können.

DMARC: Richtlinien setzen und Auswertungsberichte nutzen

DMARC bündelt SPF- und DKIM-Ergebnisse und entscheidet anhand einer definierten Policy (p=), was bei einem Fehlschlag passiert. Zusätzlich können Berichte an eine bestimmte Adresse (rua=) gesendet werden.

DMARC-Policy-Verfahren im Überblick

| Policy | Bedeutung | Empfehlung |

|--------|-----------|------------|

| p=none | Keine Aktion; nur Berichterstattung | Ideal zum Starten — keine Risiken für legitime Nachrichten. |

| p=quarantine | Nachrichten in Spam/Quarantäne verschieben | Schrittweise Verschärfung nach erfolgreicher Überwachungsphase. |

| p=reject | Nachrichten komplett ablehnen | Abschlussziel — nur setzen, wenn SPF + DKIM zuverlässig funktionieren. |

Beispiel für einen DMARC-Record

_dmarc.brillianze.de. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@brillianze.de; ruf=mailto:dmarc-forensics@brillianze.de; fo=1; pct=100"

• rua: Adresse für aggregierte Berichte (XML), die täglich von empfänger-Servern gesendet werden.
• ruf: Adresse für Fehlerberichte (forensic), die bei einzelnen Fehlschlägen ausgelöst werden (optional).
• fo=1: Berichte auch dann, wenn SPF und DKIM gemeinsam fehlschlagen (nicht nur wenn eines versagt).
• pct=100: gilt für 100% der Nachrichten (kann reduziert werden, um eine schrittweise Einführung zu testen).

Auswertung der DMARC-Berichte

Die aggregierten Berichte (rua) sind XML-Dateien. Um sie lesbar zu machen, nutzen Sie:

• Selbst gehostete Tools: z. B. DMARC-Explorer, Postmark DMARC Analyzer oder eigenständige Parser wie parsedmarc.
• Cloud-basierte Dienste: Viele Anbieter bieten Dashboards zum Parsen und Visualisieren von Berichten an.

Achten Sie bei der Auswertung auf:

• Reject-Quoten: Wie viele Nachrichten wurden wegen DMARC-Fehlschlag abgelehnt?
• Quelle der Nachrichten: Welche IPs oder Domains senden als Ihre Domain und bestehen keine Authentifizierung?
• Aligner-Probleme: Manchmal bestehen SPF/DKIM technisch, aber die Domain im Header stimmt nicht mit der authentifizierten Domain überein (Alignment-Problem).

Häufige Fehler und wie Sie sie vermeiden

1. Nicht-Array-fähige DNS-Records

Manche Provider erlauben nur einen TXT-Record pro Name. DKIM und DMARC erfordern aber genuine TXT-Einträge — kein CNAME-Fallback, der den Record überschreibt. Prüfen Sie, ob Ihr DNS-Anbieter TXT-Records mehrfach erlaubt oder ob Sie einen Array-Eintrag nutzen müssen.

2. Subdomain-Authentifizierung vergessen

SPF gilt standardmäßig nur für die Hauptdomain. Wenn Sie auch E-Mails von newsletter.brillianze.de versenden, benötigen Sie einen eigenen SPF-Record für die Subdomain:

newsletter.brillianze.de. IN TXT "v=spf1 include:_spf.mailcow.email ~all"

3. DMARC-Alignment (ausrichtung) falsch verstanden

DMARC erwartet, dass der From-Header mit dem authentifizierten Domain übereinstimmt (relaxed oder strict).

• Relaxed Alignment (Standard): Die organisatorische Domain muss übereinstimmen, Subdomains sind akzeptiert.
• Strict Alignment: Exakte Übereinstimmung erforderlich.

Die meisten Konfigurationen nutzen relaxed alignment. Wenn Sie beispielsweise von info@mail.brillianze.de senden, aber SPF für brillianze.de bestanden hat, akzeptiert relaxed DMARC das. Strict würde es verwerfen.

4. 10-Lookup-Limit bei SPF

SPF definiert maximal 10 DNS-Lookups. Wenn Sie viele include:-Einträge haben, kann die Grenze schnell erreicht sein. Nutzen Sie Tools wie spfquery oder Online-Spfl-Checker, um die Lookup-Zahl zu messen. Vereinfachen Sie die Policy, wenn nötig — bündeln Sie includes oder nutzen Sie mechanisch weniger aufwendige Alternativen (z. B. direkte IP-Einträge statt includes, wenn möglich).

Checkliste: Korrekte Einrichtung von DKIM, SPF und DMARC

• [ ] SPF: TXT-Record in DNS mit v=spf1 vorhanden.
• [ ] SPF: Alle autorisierten Mailserver aufgelistet (eigener Server, Mailcow, ggf. Drittanbieter).
• [ ] SPF: Lookup-Anzahl ≤ 10 geprüft.
• [ ] SPF: Keine widersprüchlichen Policies (nur ein -all oder ~all).
• [ ] DKIM: Private Key auf Mailserver installiert.
• [ ] DKIM: Selektor und Public-Key im DNS unter selector._domainkey.domain.tld veröffentlicht.
• [ ] DKIM: DNS-Eintrag enthält kein Leerzeichen oder Zeilenumbruch im p=-Wert.
• [ ] DMARC: _dmarc.domain.tld TXT-Record mit v=DMARC1 definiert.
• [ ] DMARC: Policy initial auf p=none gesetzt (für Beobachtungsphase).
• [ ] DMARC: rua-Adresse für aggregierte Berichte konfiguriert.
• [ ] DMARC: Berichte regelmäßig ausgewertet — Spam-Quelle und Fehlschläge analysiert.
• [ ] Subdomains: Eigene SPF-/DKIM-/DMARC-Einträge für genutzte Subdomains angelegt, wenn E-Mails von dort verschickt werden.
• [ ] Test: Eigene Test-E-Mails an Gmail/Outlook gesendet und Header auf SPF/DKIM/DMARC-Status geprüft.

Troubleshooting-Tabelle

| Symptom | Mögliche Ursache | Gegenmaßnahme |

|---------|-----------------|----------------|

| E-Mail landet im Spam trotz DKIM/SPF | DMARC-Policy noch auf none, aber Reputation-Probleme | DMARC-Berichte prüfen, E-Mail-Reputation überprüfen, Content-Anpassungen erwägen. |

| SPF permerror im Header | DNS-Lookup > 10 oder fehlerhafter Record | SPF-Record vereinfachen, Lookups zählen, Record-Syntax prüfen. |

| DKIM none oder fail im DMARC-Bericht | Private Key nicht gefunden, Selektor falsch, DNS-Record fehlerhaft | DKIM-Logs prüfen, DNS-Record mit dig überprüfen, Selektor-Konsistenz prüfen. |

| DMARC fail obwohl SPF und DKIM pass zeigen | Alignment-Problem (Domain im From-Header != authentifizierte Domain) | Alignment-Modus prüfen (relaxed/stred), From-Header prüfen, DKIM-Signatur-Domain abgleichen. |

| Keine DMARC-Berichte erhalten | rua falsch, Port 25 geblockt, oder pct=0 | rua-Adresse prüfen, Firewall-Regeln für eingehende SMTP prüfen, pct-Wert korrigieren. |

| Nach Schlüsselrotation werden alte Mails nicht verifiziert | Alter Selektor aus DNS entfernt, zu schnelle Rotation | Übergangsfrist einhalten, beide Selektoren parallel aktiv halten, bis alle offenen Nachrichten verarbeitet sind. |

Fazit

Eine fundierte E-Mail-Authentifizierung basiert auf drei Bausteinen: SPF definiert die autorisierten Sender, DKIM signiert die Inhalte kryptografisch und DMARC steuert das Verhalten bei Fehlern sowie die Berichterstattung. Beginnen Sie mit p=none, sammeln Sie DMARC-Berichte, korrigieren Sie Auffälligkeiten und steigern Sie nach und nach zu quarantine und schließlich reject.

Vor jeder Änderung testen Sie Ihre Konfiguration mit Tools wie MXToolbox, einem DMARC-Berichts-Parser oder einem eigenen Test-Mail-Kreislauf. Dieser Aufwand zahlt sich aus: Ihre Nachrichten erreichen die Empfänger, und Ihre Domain bleibt vor unbefugtem Gebrauch geschützt.

Für weiterführende Informationen zu Mailservern im Homelab siehe auch C:\\00hermes\\unternehmen\\artikel-neu\\drafts\\mailserver-selbst-hosten.md, zur allgemeinen DNS-Konfiguration mit Caddy: C:\\00hermes\\unternehmen\\artikel-neu\\drafts\\caddy-reverse-proxy-https.md, und eine Übersicht zu Reverse-Proxies und Transport-Sicherheit: C:\\00hermes\\unternehmen\\artikel-neu\\drafts\\reverse-proxy-vergleich.md.

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.