Red Sift Leitfaden zur E-Mail-Protokollkonfiguration

In diesem Kapitel beantworten wir einige der häufigsten Fragen, die unsere Customer Success Engineers zu SPF, DKIM und DMARC gestellt bekommen – die drei Grundpfeiler der modernen E-Mail-Authentifizierung. Ab 2026 ist für Versender von Massenaussendungen bei den großen Postfachanbietern die Verwendung dieser Protokolle Pflicht. Tauchen wir ein!

Nutzen Sie diese Checkliste, um sicherzustellen, dass Sie die wichtigsten Punkte abgedeckt haben. Arbeiten Sie die Liste in der angegebenen Reihenfolge ab – jeder Schritt baut auf dem vorherigen auf.

1. Veröffentlichen Sie einen einzigen SPF-TXT-Record auf Ihrer Return-Path-Domain
2. Stellen Sie sicher, dass jede legitime Absender-IP im Record enthalten ist
3. Prüfen Sie, dass Sie das DNS-Lookup-Limit von 10 nicht überschritten haben (verwenden Sie hierfür Red Sift's SPF Checker)
4. Verwenden Sie ~all (Softfail), nicht -all, damit DMARC die Durchsetzung übernehmen kann
5. Stellen Sie sicher, dass die Return-Path-Domain mit Ihrer sichtbaren From:-Domain übereinstimmt

1. Stellen Sie sicher, dass alle Absenderdienste DKIM unterstützen und aktiv damit signieren
2. Verwenden Sie eine Schlüssellänge von mindestens 2048 Bit
3. Überprüfen Sie, dass die signierende Domain (d=) mit Ihrer From:-Domain übereinstimmt
4. Bennen Sie die Selektoren so, dass jede Versandquelle eindeutig identifizierbar ist
5. Rotieren Sie regelmäßig die Schlüssel und widerrufen Sie kompromittierte Schlüssel

1. Veröffentlichen Sie einen DMARC-TXT-Record – starten Sie mit p=none, um Berichte zu sammeln
2. Tragen Sie bei rua= einen Berichtsempfänger ein (z. B. Red Sift OnDMARC), um die gesammelten Daten nutzbar zu machen
3. Überprüfen Sie Berichte wöchentlich, um unbekannte oder falsch konfigurierte Absender zu identifizieren
4. Wenn alle legitimen Quellen SPF oder DKIM mit Alignment bestehen, stellen Sie auf p=quarantine um
5. Setzen Sie die Policy auf p=reject, um gefälschte E-Mails komplett zu blockieren – ein Zeitraum von 6–8 Wochen ist mit den richtigen Tools realistisch

Extra: Transportsicherheit

1. Setzen Sie MTA-STS zunächst im Testmodus ein und gehen Sie nach Auswertung der TLS-Berichte in den erzwungenen Modus
2. Ergänzen Sie TLS-RPT, um Transparenz über Zustellprobleme durch TLS-Probleme zu bekommen

Eine korrekt eingerichtete SPF- und DKIM-Konfiguration heißt nicht, dass jede Versandquelle immer authentifiziert ist. Es gibt einige Lücken, die dazu führen, dass legitime E-Mails unauffällig fehlschlagen, oft ohne sichtbare Fehlermeldung:

• Unzureichend geschützte Subdomains. Eine Subdomain ohne eigenen SPF- oder DKIM-Record kann gefälscht werden, selbst wenn die Hauptdomain geschützt ist.
• Drittanbieter als Versender. Marketingplattformen, CRM-Tools und Supportsysteme versenden oft in Ihrem Namen über ihre eigene Infrastruktur. Jede dieser Quellen benötigt eine eigene Authentifizierungsprüfung.
• DNS-Record-Drift. Infrastrukturänderungen wie neue E-Mail-Anbieter oder stillgelegte Tools hinterlassen veraltete SPF-Includes oder DKIM-Selektoren, wodurch echte Absender scheitern können.
• Fehlerhafte Weiterleitungen. DKIM-Signaturen werden ungültig, wenn eine Nachricht über einen Weiterleitungsservice läuft, der Header oder Body verändert.
• Inkonsistente Interpretation durch E-Mail-Clients. Nicht alle Mail-Clients auf Desktop und Mobil prüfen Authentifizierungsergebnisse identisch, so dass die Zustellung je nach Öffnungsumgebung unterschiedlich sein kann.
• Rufübertragung. Wiederholte Authentifizierungs-Fehler verschlechtern den Absender-Ruf. Eine Domain, die wiederholt Prüfungen nicht besteht, rutscht im Ranking der Mailserver ab – das verschlechtert die Zustellbarkeit, auch für korrekte E-Mails.

Vermeiden Sie, dass diese Fehler auffallen, indem Sie regelmäßig alle Domains und Subdomains überprüfen, die E-Mails in Ihrem Namen versenden, und für jede die SPF-, DKIM- und DMARC-Konfiguration kontrollieren.

SPF (Sender Policy Framework) ist ein E-Mail-Authentifizierungsstandard, der entwickelt wurde, um das Fälschen von Absenderadressen zu erschweren. Dabei wird während der Übertragung die MAIL FROM- oder HELO/EHLO-Identität überprüft. SPF vergleicht die IP-Adresse des sendenden Servers mit einer Liste autorisierter Absender, die als TXT-Record im DNS der Domain veröffentlicht ist. Stimmt die Absender-IP mit der Liste überein, gilt die SPF-Authentifizierung als bestanden. 

SPF konzentriert sich auf die „Domain“ im E-Mail-Header, auch bekannt als Return-Path, MAIL-FROM, Bounce-Adresse oder Envelope-From. Falls dieser Header nicht vorhanden ist, greift SPF auf den „HELO/EHLO“-Hostnamen zurück und sucht dort nach einem SPF-Record.

Der Return-Path-Header ist ein technischer Header, der für Endnutzer nicht sichtbar ist – nur wer gezielt in seinem E-Mail-Programm die Header einblendet, sieht ihn. 

DKIM (DomainKeys Identified Mail) dient dazu, verschiedene Headerfelder und den E-Mail-Body zu signieren, um die sendende Domain zu authentifizieren und nachträgliche Manipulationen auszuschließen.

Dies wird durch asymmetrische Kryptographie erreicht, bei der ein Schlüssel-Paar verwendet wird; der private Schlüssel verbleibt beim Absender und signiert die E-Mails. Der öffentliche Schlüssel wird im DNS veröffentlicht und kann von jedem Empfangssystem abgerufen werden.

Beim Versand einer E-Mail werden Header und Body mit dem privaten Schlüssel des Absenders signiert. Diese digitale Signatur wird als zusätzliches Headerfeld mit versandt. Das empfangende System (sofern DKIM aktiviert ist) verwendet den öffentlichen Schlüssel, um zu prüfen, ob die E-Mail wirklich von der sendenden Domain stammt. Gelingt diese Validierung, beweist das sowohl die Herkunft als auch die Unversehrtheit der E-Mail während des Transports.

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

Wie bei SPF ist auch dieser Header für den Endnutzer unsichtbar, sofern er nicht explizit im E-Mail-Client die Header anzeigt.

1. Die meisten Probleme mit der E-Mail-Authentifizierung lassen sich auf dieselben Ursachen zurückführen. Machen Sie diese drei Dinge richtig und Sie beseitigen 90% aller Probleme bei Zustellbarkeit und Sicherheit.
2. Veröffentlichen Sie einen DMARC-Record mit p=reject. Starten Sie mit p=none, um Berichte zu sammeln – aber bleiben Sie nicht in diesem Überwachungsmodus. Nur eine Monitoring-Policy schützt Sie nicht. Wechseln Sie auf p=reject, sobald Sie alle legitimen Absender identifiziert und konfiguriert haben. So signalisieren Sie den empfangenden Servern, dass E-Mails ohne Authentifizierung geblockt werden sollen.
3. Stellen Sie sicher, dass SPF und DKIM mit Ihrer From:-Domain übereinstimmen. SPF und DKIM können bestehen, und trotzdem schlägt DMARC fehl, wenn die Domains nicht übereinstimmen. Überprüfen Sie, dass Ihre Return-Path-Domain (für SPF) und Ihre DKIM-Signierende Domain (d=) mit Ihrer sichtbaren From:-Adresse übereinstimmen oder Subdomains davon 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 diese authentifiziert werden. Verwenden Sie eine Plattform wie Red Sift OnDMARC, um rohe XML-Daten in verwertbare Infos umzuwandeln. Erkennen Sie Misskonfigurationen, bevor sie zu Zustellproblemen werden.

Warum SPF & DKIM nicht ausreichen: DKIM kann zwar nachweisen, dass eine E-Mail im Original unverändert versendet wurde, und SPF kann dem empfangenden Server empfehlen, E-Mails auf Basis der IP zurückzuweisen – doch keines der beiden Protokolle schützt wirksam vor Spoofing. Genau deshalb ist DMARC für Unternehmen, die ab 2026 Massenmails versenden, Pflicht.

Der Hauptgrund dafür liegt im überprüften Header-Feld jedes Protokolls.

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

Beide Protokolle lassen sich für beliebige Domains konfigurieren.

Für die Empfänger ist die wichtigste Domain die im From:-Feld angezeigte, denn sie steht als großer Name oben in der E-Mail – das sieht der Nutzer, wenn er den Absender prüft.

Dadurch könnte Ihre E-Mail-Domain gefälscht werden: Angreifer könnten als From: Ihre-domain.com eintragen, aber Return-Path und d= auf ihre-domain.com setzen. Sind die SPF- und DKIM-Records bei deren Domain korrekt, passieren beide Prüfungen – Ihre Domain wurde erfolgreich imitiert.

SPF und DKIM erfüllen beide ihren Zweck, sind jedoch allein kein wirksamer Schutz gegen Nachahmung.

DMARC steht für Domain-based Message Authentication, Reporting and Conformance und baut auf SPF und DKIM auf. DMARC bietet eine zusätzliche Schicht E-Mail-Authentifizierung und Policy-Enforcement. DMARC ist inzwischen bei allen großen Postfachanbietern vorgeschrieben und stellt ab 2026 den Branchenstandard für E-Mail-Authentifizierung dar.

DMARC leistet Folgendes:

1. Es bezieht die Ergebnisse von SPF und DKIM mit ein
2. Für einen DMARC-„Pass“ muss SPF oder DKIM bestehen und die jeweils verwendete Domain mit der im From:-Header übereinstimmen. Mehr zur Identifier Alignment finden Sie hier.
3. Es übermittelt SPF-, DKIM- und DMARC-Ergebnisse an die im From:-Header angegebene Domain (also den Absender).
4. Schließlich gibt es an, wie E-Mails, die DMARC nicht bestehen, vom empfangenden Server gehandhabt werden müssen – indem eine Policy im DNS hinterlegt wird.

Setzt ein Unternehmen die DMARC-Policy auf p=reject, empfiehlt es empfangenden Servern ausdrücklich, jede E-Mail zurückzuweisen, die nicht den Alignment-Check besteht. Damit werden alle Imitationsversuche unterbunden, sofern der empfangende Server DMARC korrekt implementiert.

DMARC prüft die Domain im From:- oder Header-From-Header, der für den Nutzer sichtbar ist. 

SPF prüft, ob eine E-Mail von einem autorisierten Absender stammt, indem es die Liste autorisierter IP-Adressen in Ihrem DNS abgleicht. Der Empfangsserver nimmt die Domain aus dem Return-Path-Header und fordert dort den SPF-Record an. Er überprüft, ob die Absender-IP der E-Mail im Record aufgeführt ist. Ist das der Fall, ist SPF BESTANDEN. Steht die IP nicht im Record, schlägt SPF fehl.

Das Grundprinzip lautet:

• Ist die Absender-IP im SPF-Record = SPF BESTANDEN
• Ist die Absender-IP nicht im SPF-Record = SPF NICHT BESTANDEN

Der Empfangsserver prüft den DKIM-Signature-Header. Dieser enthält den Selector (s=) und die signierende Domain (d=), mit denen der öffentliche Schlüssel abgerufen wird. Nach Abruf validiert der Server damit die E-Mail. Ist die Validierung erfolgreich, ist DKIM BESTANDEN, andernfalls schlägt DKIM fehl.

Das Grundprinzip lautet:

• Validierung erfolgreich = DKIM BESTANDEN
• Validierung nicht erfolgreich = DKIM NICHT BESTANDEN

Der Empfangsserver prüft, ob entweder SPF oder DKIM Bestandnen sind, anschließend ob die Return-Path-Domain beim SPF und/oder die d=-Domain bei DKIM mit der From:-Domain übereinstimmt, und beachtet schließlich die DMARC-Policy der From:-Domain.

Das Grundprinzip lautet:

• Wenn SPF BESTANDEN und mit From:-Domain ALIGNED = DMARC BESTANDEN, oder
• Wenn DKIM BESTANDEN und mit From:-Domain ALIGNED = DMARC BESTANDEN
• Wenn sowohl SPF als auch DKIM FEHLGESCHLAGEN = DMARC NICHT BESTANDEN

DMARC verlangt also nicht nur, dass SPF oder DKIM bestanden wurden, sondern auch, dass die verwendete Domain jeweils mit der im

From:-Header steht. Nur so gilt DMARC als BESTANDEN.

Strict Alignment bedeutet: Die Return-Path-Domain oder signierende Domain „d=“ muss exakt mit der From:-Domain übereinstimmen.

Relaxed Alignment bedeutet: Die Return-Path-Domain oder die signierende Domain „d=“ darf eine Subdomain der From:-Domain sein und umgekehrt.

Mehr über Identifier Alignment lesen Sie hier.

Schlägt DMARC fehl, befolgt der empfangende Server im Normalfall die von Ihnen festgelegte Policy im DMARC-Record.

• Im Report-only-Modus (p=none) wird die E-Mail angenommen und wie gehabt gefiltert.
• Im Quarantäne-Modus (p=quarantine) wird die E-Mail in Quarantäne verschoben, häufig landet sie im Spam-Ordner.
• Im Reject-Modus (p=reject) bricht der empfangende Server die Zustellung ab und die E-Mail erreicht den Empfänger nie.

Unabhängig von der Policy werden die Metadaten der E-Mail zusammen mit den Authentifizierungsergebnissen protokolliert und an Ihren DMARC-Report-Processor weitergeleitet. Mehr zu DMARC-Berichten erfahren Sie hier.

Eine theoretisch korrekte SPF- und DKIM-Konfiguration garantiert nicht, dass sie in der Praxis bei jeder Domain, Subdomain und jedem Versender korrekt funktioniert. Bevor Sie einzelne Fehler suchen, verschaffen Sie sich einen Gesamtüberblick über Ihre aktuelle Authentifizierungs-Situation.

Listen Sie sämtliche Domains und Subdomains auf, die in Ihrem Namen E-Mails versenden – inkl. Marketingplattformen, CRM-Tools und Supportsysteme. Notieren Sie für jede deren SPF-, DKIM- und DMARC-Status.

Erfassen Sie Bounceraten, Spam-Beschwerden und Fehlzustellungen aller Hauptanbieter. Vergleichen Sie die Werte mit Domain-Ruf-Tools wie Google Postmaster Tools, um Authentifizierungs-Lücken mit Auswirkungen auf die Zustellung zu finden.

Ordnen Sie für jede Domain den Geschäftsschaden bei erfolgreichem Spoofing ein: Eine nur intern genutzte Domain hat ein anderes Risiko als die für die Rechnungsstellung beim Kundenkontakt. Priorisieren Sie die Korrekturen nach Risiko, nicht nach Einfachheit der Behebung.

Machen Sie diese Bestandsaufnahme vierteljährlich, denn neue Absender und Infrastrukturänderungen sind häufig Ursache für plötzlich auftretende Probleme in einer ehemals sauberen Umgebung.

Manche Unternehmen meinen, für vollständige E-Mail-Authentifizierung seien Enterprise-Ausgaben nötig. In der Praxis steigen die Kosten mit der Komplexität, nicht mit dem Umfang des Schutzes.

Fünf Faktoren beeinflussen die Kosten: Versandvolumen, Infrastrukturkomplexität (wie viele Domains, Subdomains, Dienste), internes Know-how, branchenspezifische Compliance-Anforderungen und der Grad individuell angepasster Systemintegration.

In einigen Situationen übersteigt der Schaden durch fehlende Authentifizierung die Lösungskosten bei weitem:

• Fusionen & Übernahmen. Zusammenschlüsse von E-Mail-Infrastruktur über mehrere Domains und Altsysteme schaffen Lücken, die Angreifer gezielt während Übergangsphasen nutzen.
• Regulierte Branchen. Gesundheitswesen und Finanzsektor unterliegen Compliance-Vorgaben bei Mail-Sicherheit. Fehlende Authentifizierung bei Patientenkontakt kann HIPAA-Verstöße mit Millionenschäden auslösen.
• Wertvolle Angriffsziele. Unternehmen, die mit sensiblen Daten oder Finanztransaktionen zu tun haben, sind klassische Ziele für Business E-Mail Compromise. Ein Hersteller verlor so durch Domain-Spoofing 2,3 Millionen Dollar bei einer Überweisung.
• Weltweite Organisationen. Unterschiedliche Regionen, Sprachen und Vorschriften erhöhen die Anzahl zu authentifizierender Absender massiv.

Laut FBI lagen die Schäden durch erfolgreiche Spoofing-Angriffe 2023 bei über 18 Millionen Dollar.

1. Stellen Sie sicher, dass Sie einen SPF-Record in Ihrer Return-Path-Domain haben.
2. Hinterlegen Sie für den Fall von Bounces ohne Return-Path-Header auch einen SPF-Record in Ihrer HELO/EHLO-Domain.
3. Stellen Sie sicher, dass es pro Domain nur einen SPF-Record gibt.
4. Überprüfen Sie die korrekte Syntax Ihres SPF-Records.
5. Stellen Sie sicher, dass Ihre Return-Path-Domain mit der From-Domain übereinstimmt.
6. Stellen Sie sicher, dass alle autorisierten Absender im SPF-Record enthalten sind.
7. Stellen Sie sicher, dass keine unautorisierten Absender in Ihrem SPF-Record stehen.
8. Behalten Sie das DNS-Limit von 10 Lookups im Auge. Falls Sie mehr als 10 Lookups benötigen, nutzen Sie beispielsweise Dynamic SPF von Red Sift OnDMARC.
9. Vermeiden Sie veraltete SPF-Mechanismen wie „ptr“.
10. Vereinfachen Sie die Pflege mit einem DMARC-Partner wie Red Sift

1. Stellen Sie sicher, dass Ihre Versand-Systeme DKIM unterstützen.
2. Stellen Sie sicher, dass alle E-Mails DKIM-signiert sind.
3. Überprüfen Sie die Übereinstimmung der signierenden Domain mit der „From“-Domain.
4. Wählen Sie eine DKIM-Schlüssellänge über 1024 Bit (empfohlen: 2048 Bit)
5. Benennen Sie Selektoren möglichst so, dass Versanddienste leicht unterscheidbar sind.
6. Widerrufen Sie kompromittierte Schlüssel.
7. Drehen Sie DKIM-Schlüssel regelmäßig.
8. Achten Sie auf korrekte DKIM-Key-Syntax.
9. Stellen Sie sicher, dass für jeden privaten DKIM-Schlüssel auch ein öffentlicher Schlüssel existiert.

1. Da DMARC auf SPF und DKIM und deren verwendete Domains basiert, muss die Return-Path-Domain für SPF exakt oder als Subdomain mit der „From“-Domain übereinstimmen. Gleiches gilt für die signierende Domain bei DKIM. Richtige Alignment-Konfiguration ist 2026 entscheidend für die Zustellbarkeit.
2. Überprüfen Sie die Syntax Ihres DMARC-Records.
3. Konfigurieren Sie alle Systeme vor dem Wechsel zu einer Reject-Policy mit SPF & DKIM, sonst gehen E-Mails verloren.
4. Nutzen Sie Systeme oder Drittanbieter wie Red Sift OnDMARC, um DMARC-Berichte auszuwerten, Konfigurationsfehler sichtbar zu machen und fehlerhafte Systeme zu entdecken. Moderne DMARC-Lösungen wie OnDMARC ermöglichen die Policy-Durchsetzung in 6-8 Wochen dank automatisiertem Troubleshooting und Echtzeit-Tests.
5. Überwachen Sie alle Versandquellen und jede Änderung an SPF & DKIM. Red Sift OnDMARC bietet diese Kontrolle als Kernfunktion.