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 Massenversender bei allen großen Postfachanbietern verpflichtend. Los geht’s!

Nutzen Sie diese Liste, um die wichtigsten Punkte abzuhaken. Gehen Sie Schritt für Schritt vor – jeder Schritt baut auf dem vorherigen auf.

1. Veröffentlichen Sie einen einzelnen SPF-TXT-Eintrag auf Ihrer Return-Path-Domain
2. Stellen Sie sicher, dass jede berechtigte Versand-IP im Eintrag enthalten ist
3. Überprüfen Sie, dass Sie nicht das DNS-Lookup-Limit von 10 überschreiten (nutzen Sie dafür den Red Sift SPF Checker)
4. Verwenden Sie ~all (Softfail), nicht -all, so dass DMARC die Durchsetzung übernimmt
5. Stellen Sie sicher, dass die Return-Path-Domain mit Ihrer sichtbaren From:-Domain übereinstimmt

1. Vergewissern Sie sich, dass alle versendenden Dienste DKIM unterstützen und aktiv signieren
2. Nutzen Sie eine Schlüssellänge von mindestens 2048 Bit
3. Prüfen Sie, dass die Signaturdomain (d=) mit Ihrer From:-Domain übereinstimmt
4. Bennenen Sie Selektoren eindeutig, sodass Sie jeden Dienst identifizieren können
5. Drehen Sie Schlüssel regelmäßig und widerrufen Sie kompromittierte Schlüssel

1. Veröffentlichen Sie einen DMARC-TXT-Eintrag – starten Sie mit p=none, um Berichte zu sammeln
2. Verweisen Sie rua= auf einen Berichtsempfänger (z.B. Red Sift OnDMARC), um aggregierte Daten nutzbar zu machen
3. Prüfen Sie die Berichte wöchentlich, um unbekannte oder fehlkonfigurierte Absender zu identifizieren
4. Gehen Sie auf p=quarantine, sobald alle legitimen Quellen SPF oder DKIM mit Alignment bestehen
5. Erhöhen Sie auf p=reject, um gefälschte E-Mails vollständig zu blocken – planen Sie mit 6–8 Wochen mit den richtigen Tools

Bonus: Transportsicherheit

1. Setzen Sie MTA-STS zuerst im Testmodus ein, danach auf Enforcement umstellen, nachdem Sie TLS-Berichte geprüft haben
2. Fügen Sie TLS-RPT hinzu, um Einblicke in durch TLS verursachte Zustellprobleme zu erhalten

SPF (Sender Policy Framework) ist ein E-Mail-Authentifizierungsstandard, der entwickelt wurde, um das Fälschen von Absenderadressen zu bekämpfen. Während der Übertragung prüft SPF die Authentizität der MAIL FROM- oder HELO/EHLO-Identität, indem die IP-Adresse des sendenden Servers mit einer Liste autorisierter Versender verglichen wird, die in einem TXT-Eintrag im DNS der Domain veröffentlicht ist. Stimmt die Absender-IP mit der gesetzten Liste überein, ist die SPF-Authentifizierung erfolgreich. 

SPF prüft die "Domain" in der E-Mail-Headerzeile, die verschiedene Namen wie Return-Path, MAIL-FROM, Bounce Address oder Envelope from haben kann. Fehlt dieser Header, verwendet SPF stattdessen den „HELO/EHLO“-Hostnamen und prüft, ob dort ein SPF-Eintrag vorhanden ist.

Der Return-Path-Header ist ein technischer Header, der für Endnutzer nicht sichtbar ist – es sei denn, sie wissen, wie E-Mail-Header in ihrem Mailclient angezeigt werden. Ansonsten bleibt er verborgen. 

DKIM (DomainKeys Identified Mail) dient dazu, verschiedene Headerfelder und die Nachricht zu signieren, um die Absenderdomain zu authentifizieren und Manipulationen während der Übertragung zu verhindern.

Dies geschieht durch asymmetrische Kryptographie, bestehend aus privaten und öffentlichen Schlüsseln. Der private Schlüssel bleibt beim Absender und wird zum Signieren der E-Mails genutzt. Der öffentliche Schlüssel wird im DNS der Absenderdomain veröffentlicht, sodass ihn jeder Empfänger abrufen kann.

Beim Versenden wird der E-Mail-Header und der Text mit dem privaten Schlüssel digital signiert und als DKIM-Signatur im Header mitgeschickt. Der empfangende Server (wenn DKIM aktiviert ist) ruft den öffentlichen Schlüssel ab und prüft, ob die Signatur gültig ist. Ist die Signatur erfolgreich geprüft, ist sichergestellt, dass die Domain tatsächlich die E-Mail gesendet hat und dass Header und Inhalt während der Übertragung nicht verändert wurden.

DKIM prüft den „DKIM-Signature“-Header.

Wie bei SPF ist auch dieser Header für den Endnutzer in der Regel nicht sichtbar, es sei denn, die E-Mail-Header werden manuell angezeigt.

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 bei Zustellung 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. Eine reine Überwachungs-Policy schützt nicht. Wechseln Sie auf p=reject, sobald Sie alle legitimen Versender erkannt und konfiguriert haben. So signalisieren Sie 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 jeweils erfolgreich sein, DMARC schlägt dennoch fehl, wenn die Domains nicht übereinstimmen. Prüfen Sie, dass Ihre Return-Path-Domain (für SPF) und Ihre DKIM-Signaturdomain (d=) übereinstimmen oder Subdomains Ihrer sichtbaren From:-Adresse sind. Hier hakt es bei den meisten Organisationen.
4. Überwachen Sie Ihre DMARC-Berichte wöchentlich DMARC-Berichte zeigen Ihnen genau, wer in Ihrem Namen E-Mails versendet und ob sie die Authentifizierung bestehen. Nutzen Sie eine Plattform wie Red Sift OnDMARC, um Rohdaten (XML) in umsetzbare Informationen zu verwandeln. Entdecken Sie Fehlkonfigurationen, bevor sie zu Zustellproblemen führen.

Warum SPF & DKIM nicht ausreichen: DKIM kann zwar prüfen, ob eine E-Mail exakt so gesendet wurde, und SPF kann empfehlen, eine E-Mail über die IP-Adresse abzulehnen, aber keine von beiden Methoden verhindert effektiv Spoofing. Genau deshalb wird DMARC ab 2026 für Organisationen, die Massen-E-Mails versenden, verpflichtend.

Der Hauptgrund liegt im jeweils geprüften Header.

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

Beide Protokolle können auf beliebige Domains angewandt werden.

Die aus Nutzersicht maßgebliche Domain ist die in der From:-Adresse. Dies ist die Adresse, die oben in der E-Mail angezeigt wird – die der Nutzer beim Absender sieht.

Basierend darauf könnte Ihre E-Mail-Domain imitiert werden, indem ein Angreifer From: yourdomain.com setzt, aber Return-Path und d= auf theirdomain.com. Sind bei theirdomain.com die richtigen SPF- und DKIM-Einträge konfiguriert, würden beide Prüfungen bestehen – die E-Mail würde erfolgreich Ihre Domain nachahmen..

SPF und DKIM erfüllen beide wichtige Aufgaben, doch keine allein verhindert Imitation.

DMARC steht für Domain-based Message Authentication, Reporting and Conformance und baut auf SPF und DKIM auf, indem es eine zusätzliche Schicht E-Mail-Authentifizierung und Policy-Durchsetzung ermöglicht. DMARC wird inzwischen von allen großen Postfachanbietern verlangt und gilt 2026 als Branchenstandard.

DMARC leistet Folgendes:

1. Bezieht die Ergebnisse aus SPF und DKIM ein 
2. Für einen DMARC-PASS muss SPF oder DKIM bestehen und die für eines davon verwendete Domain mit der in der From:-Adresse übereinstimmen. Erfahren Sie hier mehr über Identifier Alignment.
3. Berichtet SPF-, DKIM- und DMARC-Ergebnisse an die in der From:-Adresse angegebene Domain (also den Absender).
4. Legt schließlich per Policy im DNS fest, wie Server mit E-Mails umgehen, die DMARC nicht bestehen.

Mit einer DMARC-Policy auf p=reject kann eine Organisation Empfangsserver anweisen, sämtliche E-Mails abzulehnen, die den Alignment-Check nicht bestehen. Dies stoppt alle Imitationsversuche bei korrekter DMARC-Implementierung am empfangenden Server.

DMARC prüft die Domain in der From:- bzw. Header-from-Zeile, die für den Endnutzer sichtbar ist. 

SPF prüft, ob eine E-Mail von einem autorisierten Absender versendet wurde, indem es eine Liste autorisierter Versand-IP-Adressen in Ihrem DNS abgleicht. Der empfangende Server entnimmt die Domain aus dem Return-Path-Header und sucht dort einen SPF-Eintrag. Die SPF-Prüfung besteht, wenn die sendende IP-Adresse in diesem Eintrag zu finden ist, ansonsten schlägt sie fehl.

Die Grundlogik lautet:

• Ist die Versand-IP im SPF-Eintrag enthalten = SPF BESTANDEN
• Ist die Versand-IP nicht im SPF-Eintrag enthalten = SPF FEHLER

Der empfangende Server prüft den DKIM-Signature-Header, der den Selector (s=) und die Signaturdomain (d=) enthält, um den öffentlichen Schlüssel zu ermitteln. Mit diesem Schlüssel wird die Signaturvalidierung vorgenommen. Läuft diese erfolgreich, ist DKIM BESTANDEN – bei fehlgeschlagener Validierung ist DKIM FEHLER.

Die Grundlogik lautet:

• Gültige Signatur = DKIM BESTANDEN
• Ungültige Signatur = DKIM FEHLER

Der empfangende Server prüft, ob entweder SPF oder DKIM BESTANDEN ist, dann ob die mittels SPF (Return-Path) oder DKIM (d=) geprüften Domains mit der From:-Domain übereinstimmen und wendet schließlich die im DNS per DMARC-Policy veröffentlichte Anweisung für die in der “From”-Adresse enthaltene Domain an.

Die Grundlogik lautet:

• SPF BESTANDEN und AUSGERICHTET mit “From”-Domain = DMARC BESTANDEN, oder
• DKIM BESTANDEN und AUSGERICHTET mit “From”-Domain = DMARC BESTANDEN
• SPF & DKIM BEIDE FEHLER = DMARC FEHLER

DMARC verlangt nicht nur ein SPF- oder DKIM-PASS, sondern auch, dass die verwendeten Domains mit jener in der 

“From”-Adresse übereinstimmen. Nur dann ist DMARC bestanden.

Strict Alignment bedeutet, dass die Return-Path- oder Signaturdomain „d=“ exakt der in der „From“-Adresse entsprechen muss.

Relaxed Alignment bedeutet, dass die Return-Path- oder Signaturdomain „d=“ auch eine Subdomain der „From“-Adresse (oder umgekehrt) sein darf.

Erfahren Sie hier mehr über Identifier Alignment.

Bei DMARC-Fehlschlägen hält sich der empfangende Server typischerweise an die Policy, die Sie im DMARC-Eintrag vorgegeben haben.

• Im Reporting-Modus (p=none) wird die E-Mail vom empfangenden Server akzeptiert und ggf. durch weitere Filter geprüft.
• Im Quarantäne-Modus (p=quarantine) wird die E-Mail isoliert (Spam-Ordner des Empfängers).
• Im Reject-Modus (p=reject) wird die Verbindung zum sendenden Server abgebrochen und die E-Mail erreicht den Empfänger nicht.

Egal, welche Policy gilt: Die Metadaten der E-Mail mitsamt Authentifizierungsergebnis werden protokolliert und an Ihren DMARC-Berichterstattungsdienst weitergeleitet. Mehr zu DMARC-Berichten finden Sie hier.

1. Stellen Sie sicher, dass Sie einen SPF-Eintrag auf Ihrer Return-Path-Domain haben.
2. Legen Sie einen SPF-Eintrag auch für Ihre HELO/EHLO-Domain an, falls der Return-Path bei Bounces leer ist.
3. Pro Domain sollte es nur einen SPF-Eintrag geben.
4. Korrekte Syntax der SPF-Einträge beachten.
5. Return-Path-Domain und From-Domain müssen übereinstimmen.
6. Berechtigte Absender gehören in den SPF-Eintrag.
7. Unberechtigte Absender nicht in SPF aufnehmen.
8. Das Limit von 10 DNS-Lookups nicht überschreiten. Falls Sie dieses Limit überschreiten, sollten Sie ein Feature wie Red Sift’s OnDMARC’s Dynamic SPF nutzen.
9. Vermeiden Sie veraltete Mechanismen wie „ptr“ im SPF-Eintrag.
10. Arbeiten Sie möglichst einfach und mit einem DMARC-Anbieter wie Red Sift

1. Stellen Sie sicher, dass Ihre Versand-Systeme DKIM unterstützen.
2. Stellen Sie sicher, dass Ihre E-Mails mit DKIM signiert werden.
3. Die Signaturdomain muss mit der „From“-Domain übereinstimmen.
4. Verwenden Sie DKIM-Schlüssel mit mindestens 1024 Bit, empfohlen sind 2048 Bit.
5. Wählen Sie, wenn möglich, Selektoren, die den sendenden Dienst eindeutig kennzeichnen.
6. Kompromittierte Schlüssel müssen widerrufen werden.
7. Drehen Sie DKIM-Schlüssel regelmäßig durch.
8. Korrekte Syntax der DKIM-Schlüssel sicherstellen.
9. Für jeden privaten Signierschlüssel muss ein entsprechender öffentlicher Schlüssel existieren.

1. Da DMARC auf SPF und DKIM (und deren Domains) basiert, achten Sie darauf, dass die Return-Path-Domain von SPF exakt oder als Subdomain zur „From“-Domain passt. Dasselbe gilt für die DKIM-Signaturdomain. Richtiges Alignment ist entscheidend für die E-Mail-Zustellung 2026.
2. Stellen Sie sicher, dass der Syntax Ihres DMARC-Eintrags korrekt ist.
3. Konfigurieren Sie alle Systeme mit SPF und DKIM korrekt, bevor Sie auf p=reject gehen, sonst gehen E-Mails verloren.
4. Nutzen Sie eine Plattform oder einen Drittanbieter wie Red Sift OnDMARC, um DMARC-Berichte auszuwerten und Fehlkonfigurationen aufzudecken. Moderne DMARC-Plattformen wie OnDMARC ermöglichen 2026 eine Policy-Durchsetzung in 6–8 Wochen durch automatisierte Fehlerdiagnose und Live-Tests.
5. Überwachen Sie alle Versandquellen und achten Sie auf Änderungen bei SPF und DKIM. Red Sift OnDMARC bietet dies als Kernfunktionalität.