Red Sift Leitfaden zur E-Mail-Protokollkonfiguration

In diesem Kapitel beantworten wir einige der am häufigsten gestellten Fragen, die unsere Customer Success Engineers zu SPF, DKIM und DMARC erhalten — den drei Säulen der modernen E-Mail-Authentifizierung. Ab 2026 sind diese Protokolle für Versender von Massen-E-Mails bei den wichtigsten Posteingangsanbietern verpflichtend. Los geht's!

SPF (Sender Policy Framework) ist ein Standard zur E-Mail-Authentifizierung, der entwickelt wurde, um gefälschte Absenderadressen zu bekämpfen. Durch die Überprüfung der Authentizität der MAIL FROM- oder HELO/EHLO-Identitäten während der Übertragung vergleicht SPF die IP-Adresse des absendenden Servers mit einer Liste autorisierter Absender, die in einem TXT-Eintrag innerhalb der DNS des Domaininhabers angegeben ist. Wenn die absendende IP-Adresse mit der autorisierten Liste übereinstimmt, ist die SPF-Authentifizierung erfolgreich. 

SPF konzentriert sich auf die „Domain“, die im E-Mail-Header zu finden ist, bekannt unter verschiedenen Namen wie Return-Path, MAIL-FROM, Bounce-Adresse oder Envelope from. Falls dieser Header fehlt, greift SPF auf den “HELO/EHLO”-Hostnamen zurück und prüft dort auf einen SPF-Eintrag.

Der Return-Path-Header ist ein technischer Header, der für den Endnutzer nicht sichtbar ist – es sei denn, sie wissen, wie sie sich in ihrem Mail-Client die Header einer E-Mail anzeigen lassen können, werden sie ihn nicht sehen. 

DKIM (DomainKeys Identified Mail) wird genutzt, um verschiedene Header-Felder und die Nachricht selbst zu signieren, um die absendende Domain zu authentifizieren und die Manipulation der Nachricht während der Übertragung zu verhindern.

Dies wird durch den Einsatz asymmetrischer Kryptografie erreicht, bestehend aus einer Kombination von öffentlichem und privatem Schlüssel. Der private Schlüssel bleibt auf der Seite der absendenden Domain und wird zum Signieren der E-Mails verwendet. Der öffentliche Schlüssel wird im DNS der absendenden Domain veröffentlicht, sodass ihn jeder Empfänger von Nachrichten dieser Domain abrufen kann.

Beim Erstellen einer E-Mail werden Header und Nachrichtentext mit dem privaten Schlüssel des Absenders signiert – daraus entsteht eine digitale Signatur, die als zusätzliches Header-Feld zusammen mit der E-Mail verschickt wird. Auf der Empfängerseite (wenn DKIM aktiviert ist) ruft der Server den öffentlichen Schlüssel ab und prüft, ob die E-Mail tatsächlich von der absendenden Domain signiert wurde. Wenn die Signatur erfolgreich validiert wird, beweist dies, dass die absendende Domain die Nachricht verschickt hat und dass Header und Inhalt der Nachricht während der Übertragung nicht verändert wurden.

DKIM konzentriert sich auf den „DKIM-Signature“-Header.

Wie auch bei SPF ist dieser Header für den Endnutzer nicht sichtbar, es sei denn, sie wissen, wie sie die Header der erhaltenen E-Mail anzeigen.

1. Die meisten Probleme bei der E-Mail-Authentifizierung lassen sich auf dieselben Ursachen zurückführen. Wenn Sie diese drei Dinge richtig machen, lösen Sie 90 % aller Probleme mit Zustellbarkeit und Sicherheit.
2. Veröffentlichen Sie einen DMARC-Eintrag mit p=reject Starten Sie mit p=none, um Berichte zu sammeln, aber bleiben Sie nicht dabei stehen. Eine reine Monitoring-Richtlinie schützt Sie nicht. Wechseln Sie zu p=reject, sobald Sie alle legitimen Absender identifiziert und konfiguriert haben. Das signalisiert empfangenden Servern, E-Mails zu blockieren, die die Authentifizierung nicht bestehen.
3. Stellen Sie sicher, dass SPF und DKIM mit Ihrer From:-Domain übereinstimmen SPF und DKIM können beide bestehen – und dennoch fällt DMARC durch, wenn die Domains nicht übereinstimmen. Prüfen Sie, ob Ihre Return-Path-Domain (bei SPF) und Ihre DKIM-Signing-Domain (d=) mit der sichtbaren From:-Adresse übereinstimmen beziehungsweise deren Subdomains sind. Hier bleiben die meisten Organisationen hängen.
4. Überwachen Sie Ihre DMARC-Berichte wöchentlich DMARC-Berichte zeigen Ihnen genau, wer in Ihrem Namen E-Mails verschickt und ob diese die Authentifizierung bestehen. Verwenden Sie eine Plattform wie Red Sift OnDMARC, um rohes XML in verwertbare Daten umzuwandeln. Entdecken Sie Fehlkonfigurationen, bevor sie zu Zustellproblemen werden.

Warum SPF & DKIM nicht ausreichen: Während DKIM verifizieren kann, dass eine E-Mail tatsächlich die gesendete E-Mail ist, und SPF einem empfangenden Server empfehlen kann, eine E-Mail basierend auf der IP abzulehnen, sind beide nicht effektiv, um Spoofing zu verhindern. Genau deshalb ist DMARC für Organisationen, die 2026 Massen-E-Mails versenden, verpflichtend geworden.

Der Hauptgrund hierfür ist der überprüfte Header bei jedem Protokoll.

SPF prüft den Eintrag der Domain im Return-Path-Header und DKIM prüft den Schlüssel der d=-Domain (im DKIM-Header).

Beide der oben genannten Protokolle können für beliebige Domains konfiguriert werden.

In einer E-Mail ist die Hauptdomain des Absenders die Domain im From:-Header; dieser Header bestimmt den großen Namen oben in der E-Mail – die Adresse, die der Endnutzer sieht, wenn er prüft, von wem die E-Mail stammt.

Nach dem oben genannten könnte Ihre E-Mail-Domain von Angreifern imitiert werden: sie könnten das From: auf yourdomain.com setzen und Return-Path sowie d= auf theirdomain.com. Solange die SPF- und DKIM-Einträge für theirdomain.com korrekt konfiguriert sind, würde die E-Mail sowohl SPF als auch DKIM bestehen und Ihre Domain erfolgreich imitiert werden.

SPF und DKIM erfüllen beide ihren Zweck, aber keiner allein verhindert Nachahmung.

DMARC steht für Domain-based Message Authentication, Reporting and Conformance und baut auf SPF und DKIM auf, indem es eine zusätzliche Ebene der E-Mail-Authentifizierung und Richtliniendurchsetzung bietet. DMARC ist nun bei den wichtigsten Posteingangsanbietern vorgeschrieben und gilt 2026 als Branchenstandard für E-Mail-Authentifizierung.

DMARC bewirkt Folgendes:

1. Es berücksichtigt die Ergebnisse von SPF und DKIM 
2. Damit DMARC erfolgreich ist, muss SPF oder DKIM bestehen und die von einem der beiden verwendete Domain muss auch mit der im From:-Feld aufgeführten Domain übereinstimmen. Wenn Sie mehr über Identifier Alignment erfahren möchten, klicken Sie hier.
3. Es meldet SPF-, DKIM- und DMARC-Ergebnisse an die im From:-Feld gefundene Domain (d. h. den Absender) zurück.
4. Abschließend teilt es Empfängern mit, wie mit E-Mails umzugehen ist, die die DMARC-Validierung nicht bestehen, indem eine Richtlinie im DNS angegeben wird.

Indem die DMARC-Richtlinie auf p=reject gesetzt wird, kann eine Organisation den Empfangsservern empfehlen, Mails, die die Übereinstimmungsprüfung nicht bestehen, abzulehnen. Dies stoppt alle Nachahmungsversuche, sofern der Empfänger-Server DMARC korrekt implementiert.

DMARC konzentriert sich auf die Domain, die im From:- oder Header From-Header zu finden ist und für den Endnutzer sichtbar ist. 

SPF prüft, ob eine E-Mail von einem autorisierten Absender stammt, indem es eine Liste autorisierter IP-Adressen auswertet, die Sie im DNS veröffentlichen. Der Empfangsserver nimmt die im Return-Path-Header gefundene Domain und prüft, ob ein SPF-Eintrag existiert. Dabei wird geprüft, ob die absendende IP-Adresse in diesem SPF-Eintrag enthalten ist. Ist die IP-Adresse vorhanden, bedeutet das, sie ist zum Senden berechtigt: SPF BESTANDEN. Ist die IP-Adresse nicht enthalten, dann: SPF FEHLGESCHLAGEN.

Die Logik dahinter:

• Wenn die absendende IP im SPF-Eintrag enthalten ist = SPF BESTANDEN
• Wenn die absendende IP nicht enthalten ist = SPF FEHLGESCHLAGEN

Der Empfangsserver prüft den DKIM-Signature-Header, der den Selector (s=) und die Signing-Domain (d=) enthält – das sind Tags zum Abrufen des öffentlichen Schlüssels. Nach dem Abruf prüft der Server mithilfe des öffentlichen Schlüssels die E-Mailsignatur. Ist die Prüfung erfolgreich, gilt: DKIM BESTANDEN, andernfalls: DKIM FEHLGESCHLAGEN.

Die Logik dahinter:

• Wenn die Prüfung erfolgreich ist = DKIM BESTANDEN
• Wenn die Prüfung fehlschlägt = DKIM FEHLGESCHLAGEN

Der empfangende Server überprüft, ob entweder SPF oder DKIM BESTANDEN haben, dann prüft er, ob die Return-Path-Domain (von SPF) und/oder die d=-Domain (von DKIM) mit der From:-Domain übereinstimmen, und schlussendlich entnimmt er die im DNS der „From“-Adresse veröffentlichte DMARC-Richtlinie und befolgt sie.

Die Logik dahinter:

• Wenn SPF BESTANDEN und abgestimmt (ALIGNED) mit der „From“-Domain = DMARC BESTANDEN, oder
• Wenn DKIM BESTANDEN und abgestimmt (ALIGNED) mit der „From“-Domain = DMARC BESTANDEN
• Wenn sowohl SPF als auch DKIM FEHLGESCHLAGEN = DMARC FEHLGESCHLAGEN

DMARC verlangt nicht nur, dass SPF oder DKIM BESTANDEN haben, sondern auch, dass die Domains, die durch diese Protokolle genutzt werden, mit der Domain der From:-Adresse ABGESTIMMT (ALIGNED) sind.

Nur dann gilt: DMARC BESTANDEN.

Strict Alignment bedeutet, dass die Return-Path-Domain oder die Signing-Domain „d=“ genau mit der „From“-Domain übereinstimmen muss.

Relaxed Alignment bedeutet, dass die Return-Path-Domain oder die Signing-Domain „d=“ eine Subdomain der „From“-Domain (oder umgekehrt) sein kann.

Wenn Sie mehr über Identifier Alignment erfahren möchten, klicken Sie hier.

Falls DMARC fehlschlägt, befolgt der Empfangsserver in der Regel die Richtlinie, die Sie im DMARC-Eintrag festgelegt haben.

• Im Report-only-Modus (p=none) wird die E-Mail vom Empfangsserver akzeptiert und durch andere Filter weiter geprüft.
• Im Quarantäne-Modus (p=quarantine) wird die E-Mail in Quarantäne verschoben und normalerweise in den Spam-Ordner des Empfängers gelegt.
• Im Reject-Modus (p=reject) bricht der Empfangsserver die Verbindung mit dem absendenden Mailserver ab und die E-Mail erreicht den Endnutzer nicht.

Unabhängig von der Richtlinie werden die Metadaten der E-Mail zusammen mit dem Authentifizierungsergebnis protokolliert und zur weiteren Auswertung an Ihren DMARC-Report-Processor weitergeleitet. Erfahren Sie hier mehr zu DMARC-Berichten.

1. Stellen Sie sicher, dass Sie einen SPF-Eintrag in Ihrer Return-Path-Domain haben.
2. Stellen Sie sicher, dass Sie einen SPF-Eintrag in Ihrer HELO/EHLO-Domain haben für den Fall, dass bei Bounces die Return-Path-Domain leer bleibt.
3. Stellen Sie sicher, dass pro Domain nur ein SPF-Eintrag existiert.
4. Stellen Sie sicher, dass die Syntax Ihres SPF-Eintrags korrekt ist.
5. Stellen Sie sicher, dass Ihre Return-Path-Domain mit der From-Domain übereinstimmt.
6. Stellen Sie sicher, dass Ihre autorisierten Absender im SPF-Eintrag enthalten sind.
7. Stellen Sie sicher, dass nicht autorisierte Absender NICHT im SPF-Eintrag stehen.
8. Achten Sie darauf, das 10-Lookup-Limit von SPF im DNS nicht zu überschreiten. Falls Sie diese Grenze überschritten haben, erwägen Sie z. B. Red Sift’s OnDMARC’s Dynamic SPF.
9. Achten Sie darauf, keine veralteten Mechanismen wie “ptr” im SPF-Eintrag zu nutzen.

1. Stellen Sie sicher, dass Ihre genutzten Versand-Systeme DKIM unterstützen.
2. Stellen Sie sicher, dass Ihre E-Mails DKIM-signiert werden.
3. Stellen Sie sicher, dass die Signing-Domain mit der „From“-Domain übereinstimmt.
4. Verwenden Sie eine DKIM-Schlüssellänge über 1024 Bit (empfohlen werden 2048 Bit).
5. Wählen Sie DKIM-Selector möglichst so, dass der Versanddienst identifizierbar ist.
6. Sperren Sie kompromittierte Schlüssel umgehend.
7. Drehen Sie DKIM-Schlüssel regelmäßig.
8. Stellen Sie sicher, dass die Syntax des DKIM-Schlüssels korrekt ist.
9. Stellen Sie sicher, dass es zu jedem privaten Signaturschlüssel einen öffentlichen Schlüssel im DNS gibt.

1. Da DMARC sowohl auf SPF als auch DKIM und deren genutzte Domains basiert, stellen Sie sicher, dass die Return-Path-Domain für SPF exakt oder als Subdomain zur „From“-Domain passt. Gleiches gilt für die Signing-Domain bei DKIM. Korrekte Alignment-Konfiguration ist entscheidend für die Zustellbarkeit in 2026.
2. Stellen Sie sicher, dass die DMARC-Eintrags-Syntax korrekt ist.
3. Stellen Sie sicher, dass Sie alle Systeme korrekt mit SPF und DKIM konfiguriert haben, bevor Sie auf „reject“ umstellen, da sonst E-Mails verloren gehen könnten.
4. Nutzen Sie eine Lösung wie Red Sift OnDMARC oder externe Services, um DMARC-Berichte zu empfangen und zu analysieren, um Fehlkonfigurationen Ihrer Systeme auszuschließen. Moderne DMARC-Plattformen wie OnDMARC ermöglichen 2026 Organisationen durch automatisiertes Troubleshooting und Echtzeittests eine Richtliniendurchsetzung in 6–8 Wochen.
5. Überwachen Sie alle Versandquellen und erkennen Sie jede Änderung an SPF und DKIM. Red Sift OnDMARC bietet dies als Kernfunktion.