Beste Anbieter für DKIM- und SPF-Management

Kurzfassung: Dieser Leitfaden behandelt die nun verpflichtenden Anforderungen für SPF- und DKIM-E-Mail-Authentifizierung, die nach den Durchsetzungsmaßnahmen von Google, Yahoo und Microsoft in den Jahren 2024-2025 gelten. Er erklärt, wie diese Protokolle gemeinsam mit DMARC Domains vor Spoofing schützen und die Zustellbarkeit von E-Mails sichern, und weist auf typische Fallstricke wie das SPF-10-Lookup-Limit im DNS und fehlende DKIM-Schlüsselrotation hin.

Der Leitfaden positioniert Red Sift OnDMARC als umfassende Lösung, die das Management durch dynamisches SPF und integriertes DKIM-Tracking vereinfacht – in der Regel wird innerhalb von 6-8 Wochen eine vollständige DMARC-Durchsetzung erreicht.

Wesentliche Erkenntnisse:

• E-Mail-Authentifizierung ist nicht mehr optional: Google, Yahoo und Microsoft lehnen E-Mails von Massenversendern ab oder stellen sie unter Quarantäne, wenn sie nicht mit SPF, DKIM und DMARC authentifiziert sind. Nichteinhaltung wirkt sich direkt auf Zustellbarkeit und Umsatz aus.
• Das SPF-10-Lookup-Limit erwischt die meisten Unternehmen unerwartet: Bereits bei der Nutzung von 3-5 Drittanbieter-E-Mail-Services kann dieses Limit überschritten werden, was zu willkürlichen Authentifizierungsfehlern führt. Dynamische SPF-Lösungen beseitigen dieses Problem, ohne die Risiken manueller Vereinfachungen.
• DKIM-Schlüssel brauchen aktives Management: 2048-Bit-Schlüssel sind nun Mindeststandard, und M3AAWG empfiehlt die Rotation alle sechs Monate. Viele Unternehmen verwenden immer noch veraltete 1024-Bit-Schlüssel und schaffen so Sicherheitslücken.
• Alignment ist das fehlende Puzzleteil: SPF und DKIM können beide erfolgreich sein, aber DMARC scheitert trotzdem, wenn keiner mit der sichtbaren „From“-Domain abgeglichen ist. DKIM-Alignment ist besonders für Massenversender wichtig, da es das Weiterleiten besser übersteht als SPF.

SPF und DKIM korrekt umzusetzen ist keine Option mehr. Da Google, Yahoo und Microsoft jetzt strenge Anforderungen an die E-Mail-Authentifizierung für Massenversender durchsetzen, riskieren Organisationen ohne ordnungsgemäßes Management dieser Protokolle Zustellprobleme, Sicherheitslücken und möglichen Imageschaden.

Schätzungsweise 3,4 Milliarden Phishing-E-Mails werden täglich verschickt [1]. E-Mail bleibt die Angriffsfläche der Wahl für Cyberkriminelle, 94 % aller Malware wird über E-Mail-Anhänge zugestellt [2]. Aus diesem Grund ziehen große Anbieter für Posteingangsfächer klare Grenzen.

Seit Februar 2024 verlangen Google und Yahoo von Massenversendern (ab 5.000 E-Mails pro Tag), dass sie ihre E-Mails mit SPF und DKIM authentifizieren – mindestens eines davon muss für DMARC-Compliance ausgerichtet sein [3]. Microsoft folgt im Mai 2025 und lehnt nicht-konforme E-Mails sofort ab [4]. Dies sind keine Empfehlungen. Es sind Anforderungen.

In diesem Leitfaden erfahren Sie:

• Wie SPF und DKIM gemeinsam Ihre E-Mails authentifizieren
• Die häufigsten Fehlerquellen bei SPF und DKIM (und wie man sie behebt)
• Worauf man bei einem Anbieter für E-Mail-Authentifizierung achten sollte
• Warum DMARC alles zusammenhält
• Wie Red Sift OnDMARC den gesamten Prozess vereinfacht

Sender Policy Framework (SPF) ist die Gästeliste Ihrer Domain für E-Mail-Versand. Es ist ein DNS-Record, der empfangenden Servern mitteilt, welche IP-Adressen zum Versand von E-Mails unter Ihrem Domainnamen berechtigt sind [5].

Wenn eine E-Mail ankommt, prüft der empfangende Server den SPF-Record der Domain in der Return-Path-Adresse. Stimmt die sendende IP mit einer aus der Liste überein, ist SPF erfolgreich. Ansonsten schlägt es fehl.

SPF hat eine entscheidende Einschränkung, die den meisten Organisationen Probleme bereitet: das Limit von 10 DNS-Lookups [6]. Jeder include-, a-, mx-, ptr- und redirect-Mechanismus in Ihrem SPF-Record zählt zu diesem Limit. Wird es überschritten, geben Empfängerserver einen „permerror“ zurück und Ihre E-Mails scheitern zufällig an der Authentifizierung.

So summiert sich das schnell:

• Google Workspace: 4 DNS-Lookups
• Microsoft 365: 2-3 DNS-Lookups
• Marketing-Automation-Plattformen: jeweils 3-7 DNS-Lookups
• CRM-E-Mail-Versand: 2-4 DNS-Lookups

Die meisten mittelständischen Unternehmen nutzen mindestens 3-5 Tools, die im Namen der Organisation E-Mails versenden. Addiert man alles zusammen, überschreitet man schnell 10 Lookups, ehe man es bemerkt.

• SPF-Flattening wandelt Hostnamen in IP-Adressen um, die nicht gegen das Lookup-Limit zählen. Problematisch ist: E-Mail-Provider aktualisieren häufig ihre IP-Adressen. Passiert das, ist Ihr geflatteter Record veraltet und Authentifizierung schlägt fehl [7].
• SPF-Makros bieten eine dynamischere Lösung, indem sie Lookups zur Abfragezeit auflösen. Manche ältere Empfänger-Infrastrukturen unterstützen jedoch Makros nicht vollständig, was zu Inkonsistenzen führt [8].
• Subdomain-Delegation erstellt eigene SPF-Records für verschiedene Versender, indem diese auf Subdomains verschoben werden. Dann zeigt aber die „From“-Adresse die Subdomain und nicht mehr Ihre Hauptdomain.
• Dynamische SPF-Lösungen wie Red Sift's Dynamic SPF bündeln alle berechtigten Versender in einem einzigen Include, das zur Abfragezeit aufgelöst wird. Keine manuellen DNS-Updates, keine Kompatibilitätsprobleme mit Makros, keine Subdomain-Komplexität.

Neben den E-Mail-Authentifizierungsempfehlungen der M3AAWG [9]:

• SPF-Records für alle sendenden Domains veröffentlichen (auch für geparkte Domains)
• „~all“ (softfail) statt „-all“ (hardfail) verwenden, damit DMARC eine Bewertung machen kann
• SPF-Records vierteljährlich prüfen und ungenutzte Mechanismen entfernen
• Alle Drittanbieter erfassen, die in Ihrem Namen E-Mails versenden
• Änderungen zuerst im Überwachungsmodus testen, bevor man sie erzwingt

DomainKeys Identified Mail (DKIM) fügt Ihren ausgehenden E-Mails eine kryptographische Signatur hinzu [10]. Diese Signatur beweist: Die E-Mail stammt wirklich von Ihrer Domain – und ihr Inhalt blieb auf dem Weg unverändert.

Wenn Sie eine E-Mail senden, erstellt der Mailserver eine einzigartige Signatur mit einem privaten Schlüssel. Diese Signatur wird im E-Mail-Header eingefügt. Der empfangende Server ruft Ihren öffentlichen Schlüssel aus dem DNS ab und prüft, ob die Signatur passt.

Schlüssellänge ist entscheidend. 1024-Bit-Schlüssel galten lange als Standard, sind inzwischen aber nicht mehr sicher. 2048-Bit-RSA-Schlüssel sind nun Mindestempfehlung [11]. Manche Organisationen nutzen bereits 4096-Bit-Schlüssel.

Schlüsselrotation ist unerlässlich. DKIM-Schlüssel sollten laut M3AAWG mindestens alle sechs Monate rotiert werden [12]. Risikoreiche Versender wie Banken sollten monatlich rotieren. Dennoch lassen viele DKIM-Konfigurationen über Jahre unangetastet. Forscher finden sogar noch 1024-Bit-Schlüssel aus 2015 [13].

Selector-Namenskonventionen helfen, aktive Schlüssel nachzuvollziehen. Aussagekräftige Selector wie „jan2026“ erleichtern die Dokumentation von Schlüsselrotationen und zeigen, welche Dienste mit welchem Schlüssel signieren [14].

• Verwenden Sie mindestens 2048-Bit-Schlüssel (unverzüglich von 1024-Bit migrieren)
• Schlüssel mindestens alle sechs Monate rotieren
• Während der Rotation zwei aktive Schlüssel parallel betreiben, um Authentifizierungslücken zu vermeiden
• Alle ausgehenden E-Mails, auch Transaktionsnachrichten, signieren
• Signing-Domain beim DKIM auf die „From“-Domain ausrichten (DMARC)
• Verschiedene Selector für verschiedene Versender verwenden
• Rotationstermine und Selector-Konventionen dokumentieren

SPF und DKIM sind essentielle Protokolle, wurden aber ursprünglich nicht aufeinander abgestimmt. Hier kommt DMARC (Domain-based Message Authentication, Reporting, and Conformance) ins Spiel.

DMARC verlangt, dass mindestens eines der Protokolle SPF oder DKIM bestehen UND zur Domain im „From“-Header passen muss [15]. Das ist der kritische Unterschied: SPF und DKIM können jeweils separat erfolgreich sein, aber wenn keine Ausrichtung zur sichtbaren „From“-Domain besteht, fällt DMARC durch.

SPF Alignment meint, dass die Domain im Return-Path (Envelope Sender) zur „From“-Domain passt. Viele Drittanbieterdienste verwenden für Bounce-Handling ihre eigene Return-Path-Domain und verhindern damit das SPF-Alignment.

DKIM Alignment bedeutet, dass die Domain in der DKIM-Signatur (d= Wert) mit der „From“-Domain identisch ist. DKIM-Alignment ist oft robuster, da es Weiterleitungen überlebt, wohingegen SPF hier häufig scheitert.

Deshalb verlangen Google, Yahoo und Microsoft für Massenversender explizit DKIM. SPF allein genügt den neuen Anforderungen nicht.

In einem DMARC-Record können Sie unterschiedliche Prüfstrenge für SPF (aspf) und DKIM (adkim) festlegen. Die meisten Organisationen setzen SPF auf „relaxed“, DKIM aber auf „strict“, weil SPF bei Third-Party-Return-Path-Domains und durch Weiterleitungen oft bricht, während DKIM mit der Nachricht mitwandert und auch bei strengen Regeln bestehen bleibt [22].

Haben Sie das noch nicht gesetzt, starten Sie mit beiden auf „relaxed“. Beobachten Sie einige Wochen die DMARC-Reports, identifizieren Sie, welche Versender den Strict-Modus überstehen, und verschärfen Sie dann gezielt, wo Sie direkten Einfluss auf den Versender haben.

Ein Hinweis zur aktuellen Spezifikation: RFC 9989 (DMARCbis) ersetzt RFC 7489. Alignment-Mechaniken sind unverändert, aber die Bestimmung der „organisational domain“ verläuft nun anhand des DNS-Baums statt der Public Suffix List [23].

DMARC-Policies sind in drei Stufen gegliedert:

• p=none: Nur überwachen. Berichte erhalten, aber keine Zustellauswirkung.
• p=quarantine: Fehlende E-Mails landen im Spam-/Junk-Ordner.
• p=reject: Fehlende E-Mails werden komplett abgelehnt.

Der Umstieg von Monitoring zu Durchsetzung dauert typischerweise 4-8 Wochen [16]. Unternehmen brauchen diese Zeit, um alle legitimen Versender zu identifizieren, SPF und DKIM korrekt zu konfigurieren und Alignment-Probleme vor der Umstellung zu beheben.

Ihr Anbieter sollte das 10-DNS-Lookup-Limit lösen, ohne neue Probleme zu verursachen. Lösungen mit manuellem Flattening scheitern bei IP-Adressänderungen. Makro-basierte Lösungen funktionieren nicht überall.

Red Sift OnDMARC's Dynamic SPF verwendet ein einziges dynamisches Include, das alle freigegebenen Absender in Echtzeit authentifiziert. Keine manuellen DNS-Updates, keine Makro-Probleme, keine zufälligen Authentifizierungsfehler.

Achten Sie auf Anbieter, die:

• 2048-Bit-Schlüssel unterstützen (idealerweise auch 4096-Bit)
• Schlüsselrotation automatisch und nach Zeitplan durchführen
• Während Wechselphasen mehrere aktive Schlüssel parallel halten
• Selector-Nutzung über alle Versender hinweg nachverfolgen
• Sie bei schwachen oder ablaufenden Schlüsseln warnen

SPF und DKIM dienen der Durchsetzung von DMARC. Ihr Anbieter sollte bieten:

• Aggregierte Berichte zu Authentifizierungserfolgen/-fehlern
• Forensische Reports mit detaillierten Fehlerdaten
• Klare Sichtbarkeit, welche Services korrekt authentifizieren – und welche nicht
• Konkrete Handlungsempfehlungen zur Fehlerbehebung

Das Management von SPF-, DKIM- und DMARC-Records erfordert häufige DNS-Änderungen. Anbieter, bei denen Sie alle Records zentral verwalten, sparen separate DNS-Zugänge und vermeiden Fehler.

Mit OnDMARC können Unternehmen SPF-, DKIM-, DMARC-, BIMI- und MTA-STS-Records über eine einzige Oberfläche verwalten. Eine DNS-Änderung genügt für den Einstieg, der Rest wird in der Plattform erledigt.

E-Mail-Authentifizierung ist kein technischer Haken im System. Sie hat direkte Auswirkungen auf Ertrag und Risikomanagement Ihres Unternehmens.

Wenn SPF oder DKIM fehlschlagen, erreichen Ihre E-Mails ihre Empfänger nicht. Marketingkampagnen schlagen fehl, Vertriebskontakte bleiben unbeantwortet, Kundenkommunikation landet im Spam. Die finanziellen Folgen summieren sich rasch.

Eine Beispielrechnung: Sendet Ihr Unternehmen monatlich 50.000 E-Mails und schlechte Authentifizierung verursacht 10 % Verlust bei der Zustellbarkeit, erreichen 5.000 E-Mails ihr Ziel nicht. Bei Marketing oder Vertrieb sind das direkte Umsatzverluste.

Wise, das internationale Geldtransferunternehmen, steigerte nach der Einführung von OnDMARC seine E-Mail-Zustellrate auf 99 % [20] – durch die richtige Konfiguration aller SPF- und DKIM-Dienste.

Phishing-Attacken mit gefälschter Domain ruinieren nicht nur Ihren Ruf. Sie zerstören Vertrauen, öffnen rechtliche Risiken und ermöglichen BEC-Attacken mit hohem Schaden.

Das FBI Internet Crime Complaint Center verzeichnete 2024 insgesamt 21.442 BEC-Fälle mit einem Gesamtschaden von 2,77 Mrd. $ [21]. Viele Angriffe beginnen mit Domain-Spoofing, das durch konsequente E-Mail-Authentifizierung verhindert worden wäre.

Ist Ihre Domain durch SPF, DKIM und DMARC auf Enforcement-Level geschützt, können Angreifer keine Mails versenden, die von Ihrer Organisation zu stammen scheinen. Gefälschte Nachrichten werden bereits bei der Zustellung geblockt.

Behörden und Aufsichtsstellen schreiben E-Mail-Authentifizierung zunehmend vor. Das NIST empfiehlt DMARC als Teil der US-Bundes-IT-Richtlinien. Das National Cyber Security Centre (NCSC) UK befürwortet DMARC ebenfalls. Die EU-Kommission gibt entsprechende Empfehlungen für Mitgliedsorganisationen.

Für regulierte Branchen wie Gesundheitswesen oder Finanzwesen ist ordentliche E-Mail-Authentifizierung Pflichtteil des Nachweises über Sorgfalt in der Kommunikationssicherung.

OnDMARC verfolgt einen integrierten Ansatz für E-Mail-Authentifizierung: SPF, DKIM und DMARC werden als gemeinsames System statt als Einzelprotokolle behandelt.

• SPF-Management: Dynamisches SPF hebt das Lookup-Limit von 10 durch ein einziges dynamisches Include auf. Alle legitimierten Absender authentifizieren über einen Mechanismus, der sich automatisch aktualisiert. Es werden keine Makros benötigt – dadurch bestehen bessere Kompatibilität mit alter Empfängerinfrastruktur [17].
• DKIM-Management: OnDMARC überwacht alle DKIM-Schlüssel, meldet schwache oder fehlende Signaturen und gibt konkrete Hinweise zur Konfiguration. Die Plattform integriert sich mit großen E-Mail-Providern für eine vereinfachte DKIM-Einrichtung.
• DMARC-Durchsetzung: Unternehmen, die OnDMARC nutzen, erreichen im Durchschnitt nach 6-8 Wochen die vollständige DMARC-Durchsetzung (p=reject oder p=quarantine) [18]. Die Plattform analysiert laufend DMARC-Reports und liefert konkrete Umsetzungsvorschläge.
• Mehr als nur E-Mail-Authentifizierung: OnDMARC bietet mit DNS Guardian Schutz vor Subdomain-Übernahmen und SubdoMailing-Attacken, zudem integrierte BIMI-Unterstützung mit VMC-Bereitstellung für verifizierte Markenlogos.

E-Mail-Service-Provider wie SendGrid und Amazon SES übernehmen DKIM-Signierung für die von ihnen zugestellten Mails, verwalten aber keine SPF-Records und liefern keine DMARC-Berichte. Die übergreifende Authentifizierung aller Versender müssen Sie selbst steuern.

SPF-Flattening-Services wie AutoSPF und SafeSPF lösen das Lookup-Limit, setzen jedoch voraus, dass Sie Ihre SPF-Infrastruktur einem Dritten anvertrauen. Kommt es dort zu Ausfällen, sind Sie direkt betroffen.

DMARC-Only-Plattformen bieten Reporting, adressieren aber nicht zwingend die zugrundeliegende SPF- und DKIM-Konfig. Sie sehen die Probleme, werden aber nicht bei deren Behebung unterstützt.

Kostenlose Tools wie MxToolbox, URIports u.a. validieren Konfigurationen, liefern aber keine laufende Verwaltung, Automatisierung oder Enforcement-Support.

Identifizieren Sie alle Dienste, die E-Mails über Ihre Domain versenden, darunter:

• Unternehmens-E-Mail (Microsoft 365, Google Workspace)
• Marketing-Automation-Plattformen
• CRM-Systeme
• Transaktionsmaildienste
• HR- und Recruiting-Plattformen
• Kundensupport-Systeme
• Finanz- und Buchhaltungssoftware

Überprüfen Sie Ihren SPF-Record auf ungenutzte Includes und die Lookup-Anzahl. Prüfen Sie, ob DKIM für jeden Dienst konfiguriert ist.

Erstellen Sie ein Verzeichnis (Inventory) aller Versender mit:

• Name & Anbieter des Service
• E-Mail-Volumen & -Typ (Marketing, Transaktional, Intern)
• Aktueller SPF-Include-Mechanismus
• DKIM-Selector und Schlüssellänge
• Alignment-Status (Abgleich mit der From-Domain oder nicht)

Dieses Verzeichnis ist Ihre Referenzbasis für die Konfigurationsarbeit.

Fügen Sie DKIM-Schlüssel für jeden Service hinzu oder aktualisieren Sie diese. Bevorzugen Sie 2048-Bit-Schlüssel und dokumentierte Selector-Namen.

DKIM-Konfiguration bei den großen Plattformen:

• Microsoft 365: CNAME-Records für DKIM-Infrastruktur von Microsoft. Automatische Schlüsselrotation zwischen zwei Selectors ist möglich.
• Google Workspace: Schlüssel über das Admin-Panel generieren und als TXT-Records im DNS veröffentlichen. Spezielle Selector vereinfachen das Management.
• Marketing-Plattformen: Meist sind CNAME- oder TXT-Records einzutragen. Prüfen Sie, ob Alignment mit Ihrer From-Domain möglich ist.

Optimieren Sie Ihren SPF-Record, ggf. durch Dynamic SPF, damit Sie das Lookup-Limit nicht reißen, während alle legitimierten Sender autorisiert sind.

Veröffentlichen Sie einen DMARC-Record mit p=none, um aggregierte Reports zu erhalten, ohne die Zustellung zu beeinflussen. Setzen Sie rua auf eine kontrollierte Mailadresse (oder die Reporting-Adresse Ihres DMARC-Dienstes).

Überprüfen Sie DMARC-Berichte auf:

• Legitime Sender ohne korrekte Authentifizierung
• Alignment-Fehler (SPF/DKIM besteht, ist aber nicht ausgerichtet)
• Unbekannte oder unautorisierten Absender
• Mengenmuster, die auf Spoofing deuten

Beheben Sie für jeden Dienst die Authentifizierungsfehler. Dies kann die Zusammenarbeit mit Drittanbietern für spezielle DKIM-Signaturen oder Anpassung des Return-Path bedeuten.

Typische Fehlerquellen:

• Drittanbieter signieren DKIM nicht mit Ihrer Domain
• Marketing-Plattformen mit Return-Path gehen beim Alignment verloren
• Altsysteme ohne DKIM-Unterstützung
• Shadow IT/unerkanntes Mailing über externe Dienste

Stellen Sie von p=none auf p=quarantine um, um Enforcement zu testen, ohne alle fehlerhaften Mails sofort zu blockieren. Überwachen Sie die Spamrate.

Starten Sie mit einem geringen pct-Wert (z.B. pct=10), um die Policy zuerst nur auf einen Teil der Mails anzuwenden. Erhöhen Sie die Quote allmählich.

Wenn alle legitimen E-Mails korrekt authentifizieren, wechseln Sie zu p=reject.

Selbst bei Enforcement: Bleiben Sie wachsam. Neue Dienste, Konfigurationsänderungen und Updates von Drittplattformen können Authentifizierung brechen. Laufende Überwachung beugt bösen Überraschungen bei der Zustellbarkeit vor.

• Symptome: SPF besteht für einige Empfänger, schlägt aber bei anderen fehl. DMARC-Reports zeigen inkonsistente SPF-Resultate.
• Wahrscheinliche Ursache: Sie haben das 10-DNS-Lookup-Limit überschritten. Empfangende Server, die den gesamten SPF prüfen, bevor das Limit greift, sehen ein PASS. Server, die als erstes das Limit erreichen, geben permerror zurück.
• Lösung: Überprüfen Sie Ihr SPF-Record auf unnötige Includes. Entfernen Sie Mechanismen für Dienste, die Sie nicht mehr verwenden. Setzen Sie Dynamic SPF oder Subdomain-Delegation ein, um unter dem Limit zu bleiben.

• Symptome: Nach dem Wechsel der E-Mail-Plattform (z. B. von einem Marketing-Automatisierungstool zu einem anderen) schlägt DKIM fehl.
• Wahrscheinliche Ursache: Die alten DKIM-Schlüssel sind noch im DNS vorhanden, aber die neue Plattform verwendet andere Selector. Oder die neue Plattform ist überhaupt nicht so konfiguriert, dass mit Ihrer Domain signiert wird.
• Lösung: Generieren Sie neue DKIM-Schlüssel für die neue Plattform. Veröffentlichen Sie sie im DNS mit dem vom Anbieter angegebenen Selector. Überprüfen Sie, dass die Plattform mit dem d=-Wert Ihrer Domain signiert, nicht mit ihrem eigenen. Entfernen Sie alte Schlüssel, nachdem die neue Konfiguration funktioniert.

• Symptome: DMARC-Berichte zeigen, dass SPF und DKIM bestehen, aber DMARC schlägt dennoch fehl.
• Wahrscheinliche Ursache: Weder SPF noch DKIM sind mit Ihrer From-Domain ausgerichtet. Der Dienst authentifiziert, aber nicht auf eine Weise, die DMARC hilft.
• Lösung: Überprüfen Sie die Return-Path-Domain (für SPF-Alignment) und den d=-Wert in den DKIM-Signaturen (für DKIM-Alignment). Arbeiten Sie mit dem versendenden Dienst zusammen, um benutzerdefinierte Domains einzurichten, die mit Ihrer Absenderadresse übereinstimmen.

• Symptome: DKIM-Überprüfung schlägt mit „ungültige Signatur“-Fehlern fehl. Der Schlüssel ist korrekt im DNS veröffentlicht.
• Wahrscheinliche Ursache: Der E-Mail-Inhalt wurde unterwegs verändert. Mailinglisten, die Fußzeilen hinzufügen, E-Mail-Sicherheitsgateways, die URLs umschreiben, oder Weiterleitungsdienste können DKIM-Signaturen zerstören.
• Lösung: Dies liegt oft außerhalb Ihres Einflussbereichs. Stellen Sie sicher, dass Sie ein SPF-Alignment als Rückfalloption haben. Erwägen Sie die Implementierung von ARC (Authenticated Received Chain), wenn Sie die Organisation sind, die E-Mails auf dem Weg verändert.

Das Management von SPF und DKIM ist von einem Nice-to-have zu einer Notwendigkeit geworden. Google, Yahoo und Microsoft setzen jetzt strenge Authentifizierungsstandards durch und nicht-konforme E-Mails werden abgelehnt statt nur mit schlechten Zustellraten bestraft.

Die Herausforderungen sind real: Das 10-Lookup-Limit von SPF verursacht ständigen Pflegeaufwand, die Rotation von DKIM-Schlüsseln erfordert sorgfältige Abstimmung, und alles für DMARC auszurichten bringt eine weitere Komplexitätsebene.

Aber die Lösung muss nicht kompliziert sein. Plattformen wie Red Sift OnDMARC bündeln die Verwaltung von SPF, DKIM und DMARC in einer Oberfläche, automatisieren die mühsamen Aufgaben und bieten klare Anleitungen zur vollen Durchsetzung.

Die Organisationen, die das richtig angehen, schützen ihre Domains effektiv vor Spoofing, verbessern die E-Mail-Zustellbarkeit und erfüllen die zunehmend strengen Anforderungen der Postfachanbieter. Wer das nicht tut, wird seine E-Mails im Spam-Ordner finden – oder sie kommen gar nicht mehr an.

[1] SalesHive. „DKIM, DMARC, SPF: Best Practices for Email Security and Deliverability in 2025.“ https://saleshive.com/blog/dkim-dmarc-spf-best-practices-email-security-deliverability/ 

[2] Verizon. „2024 Data Breach Investigations Report.“ https://www.verizon.com/business/resources/reports/dbir/ 

[3] Yahoo. „Sender Best Practices.“ https://senders.yahooinc.com/best-practices/ 

[4] Microsoft. „Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders.“ https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook's-new-requirements-for-high‐volume-senders/4399730 

[5] IETF. „RFC 7208: Sender Policy Framework.“ https://datatracker.ietf.org/doc/html/rfc7208 

[6] Mailhardener. „The SPF Lookup Limit Explained.“ https://www.mailhardener.com/blog/spf-lookup-limit-explained 

[7] URIports. „SPF Macros: Overcoming the 10 DNS Lookup Limit.“ https://www.uriports.com/blog/spf-macros-max-10-dns-lookups/ 

[8] Mailhardener. „Do Not Flatten Your SPF Record.“ https://www.mailhardener.com/blog/do-not-flatten-spf 

[9] M3AAWG. „Email Authentication Recommended Best Practices.“ https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf 

[10] IETF. „RFC 6376: DomainKeys Identified Mail Signatures.“ https://datatracker.ietf.org/doc/html/rfc6376 

[11] Twilio SendGrid. „2048 Bit DKIM Keys: Length and Best Practices.“ https://www.twilio.com/en-us/blog/insights/2048-bit-dkim-keys 

[12] M3AAWG. „DKIM Key Rotation Best Common Practices.“ https://www.m3aawg.org/DKIMKeyRotation 

[13] Suped. „How Often Should You Rotate Your DKIM Keys and What Key Length is Best.“ https://www.suped.com/knowledge/email-authentication/dmarc/how-often-should-you-rotate-your-dkim-keys-and-what-key-length-is-best 

[14] Mailgun. „How Can I Rotate My DKIM Key?“ https://help.mailgun.com/hc/en-us/articles/16956951504539-How-can-I-rotate-my-DKIM-key 

[15] IETF. „RFC 7489: Domain-based Message Authentication, Reporting, and Conformance.“ https://datatracker.ietf.org/doc/html/rfc7489 

[16] Red Sift. „OnDMARC.“ https://redsift.com/pulse-platform/ondmarc 

[17] Red Sift. „SPF, DKIM & DMARC: Essential Email Protocols Explained.“ https://redsift.com/guides/email-protocol-configuration-guide/all-you-need-to-know-about-spf-dkim-and-dmarc 

[18] Cisco. „Cisco Secure Email + Red Sift Domain Protection.“ https://docs.ces.cisco.com/docs/red-sift-cisco-secure-email 

[19] URIports. „SPF, DKIM, and DMARC Best Practices.“ https://www.uriports.com/blog/spf-dkim-dmarc-best-practices/ 

[20] Red Sift. „OnDMARC Customer Success.“ https://redsift.com/customers/customer-success 

[21] Bright Defense. „200+ Phishing Statistics for 2026.“ https://www.brightdefense.com/resources/phishing-statistics/