Red Sift Leitfaden zur E-Mail-Protokollkonfiguration
SPF-Fehler: Hard Fail vs. Soft Fail
Was ist ein SPF-Fehler?
Ein SPF-Fehler tritt auf, wenn die IP-Adresse des Absenders nicht im veröffentlichten SPF-Eintrag aufgeführt ist. Fehler wirken sich erheblich auf die Zustellbarkeit Ihrer E-Mails aus, da sie dazu führen, dass die E-Mail im Spam landet oder komplett verworfen wird. Das kann für Unternehmen, die auf E-Mail-Kommunikation mit ihren Kunden angewiesen sind, katastrophal sein. Da große Postfachanbieter ab 2026 Authentifizierungsanforderungen durchsetzen, haben SPF-Fehler direkte Folgen für die Zustellbarkeit.
Es gibt zwei Arten von SPF-Fehlern – SPF-Softfail und SPF-Hardfail. Ein Hardfail zeigt an, dass eine E-Mail nicht autorisiert ist, während ein Softfail bedeutet, dass eine E-Mail wahrscheinlich nicht autorisiert wurde. Für den Empfänger bestimmt dies, wie mit der E-Mail umgegangen wird: Ein Hardfail signalisiert dem Empfänger, die E-Mail abzulehnen, während ein Softfail vorschlägt, sie zum Spam zu verschieben.
Wir zeigen anhand von zwei Beispielen den visuellen Unterschied zwischen beiden Varianten.
Beispiel für SPF-Hardfail
v=spf1 ip4:192.168.0.1 -all
Im obigen Beispiel bedeutet das Minuszeichen (vor all am Ende des Eintrags), dass alle Absender, die nicht in diesem SPF-Eintrag gelistet sind, als Hardfail behandelt werden sollen – das heißt, sie sind nicht autorisiert und ihre E-Mails sollten verworfen werden. In diesem Fall ist nur die IP-Adresse 192.168.0.1 zum Versenden von E-Mails berechtigt, alle anderen nicht.
Beispiel für SPF-Softfail
v=spf1 include:spf.protection.outlook.com ~all
Im obigen Beispiel bedeutet das Tilde-Symbol (vor all am Ende des Eintrags), dass alle Absender, die nicht im SPF-Eintrag aufgelistet sind, als Softfail betrachtet werden, also die Nachricht zugelassen werden kann, aber als Spam oder verdächtig markiert werden sollte. In diesem Fall berechtigt der Mechanismus include:spf.protection.outook.com Microsoft 365 zum Versenden von E-Mails. Alle E-Mails, die von anderen Servern stammen, sollten vom Empfänger als Spam markiert werden.
Unsicher bei Ihrer SPF-Konfiguration? Nutzen Sie unseren kostenlosen Checker, um loszulegen.
Welchen SPF-Fehlermodus sollten Sie verwenden?
Da Hardfail („-all“) signalisiert, dass alle nicht im SPF-Eintrag aufgeführten, nicht autorisierten Absender abgewiesen werden, erscheint dies als die naheliegende Wahl. Die Entscheidung ist allerdings komplexer.
Vor der Einführung von DMARC nutzten SPF-Einträge häufig das „-all“-Mechanismus, um die Absenderregeln streng durchzusetzen, ohne die zusätzliche Schicht von DKIM und DMARC zur Legitimierung von E-Mails.
Die aktuelle Branchenempfehlung im Jahr 2026 bevorzugt jedoch „~all“, um Sicherheit und Zustellbarkeit auszubalancieren und unnötige Ablehnung legitimer E-Mails zu vermeiden, die eventuell bei SPF durchfallen, aber DKIM und DMARC bestehen.
Die Branche betont, dass beim Umgang mit SPF-Modi Vorsicht geboten ist; die DMARC-Spezifikation (RFC 7489) besagt dazu:
„Manche Empfängerarchitekturen können SPF vor jeglicher Verarbeitung durch DMARC anwenden. Das bedeutet, ein „-“ Präfix bei SPF-Mechanismen wie „-all“ könnte dazu führen, dass eine Ablehnung schon früh erfolgt und die Nachricht vor jeglicher DMARC-Verarbeitung abgewiesen wird. Betreiber, die „-all“ verwenden, sollten sich dessen bewusst sein.“
Deshalb empfehlen wir Folgendes:
- Verwenden Sie „-all“ für inaktive Domains ohne E-Mail-Versand: Setzen Sie „-all“ nur ein, wenn von der Domain überhaupt keine E-Mails versendet werden. Diese Einstellung blockiert strikt unautorisierte E-Mails, birgt aber das Risiko, legitime E-Mails abzulehnen, wenn der SPF-Eintrag nicht aktuell ist.
- Verwenden Sie „~all“ für aktive, E-Mails versendende Domains: Nutzen Sie „~all“, wenn Sie SPF mit DKIM und DMARC kombinieren, um Phishing und Spoofing zu bekämpfen. Denn „~all“ in Verbindung mit DMARC (bei p=reject) führt ebenfalls dazu, dass unautorisierte E-Mails abgewiesen werden, wenn SPF und DKIM fehlschlagen. Diese Einstellung blockiert keine legitimen E-Mails und verbessert daher die Zustellbarkeit.
Zusammengefasst: Softfail stellt eine Balance zwischen strikter Sicherheit (was legitime E-Mails blockieren könnte) und Flexibilität in der E-Mail-Zustellung dar, sodass E-Mails auch bei gelegentlichen Unstimmigkeiten im SPF-Eintrag zugestellt werden können.
Wie bewerten Cybersecurity-Ratingunternehmen SPF-Softfail?
Es ist möglich, dass manche Rating-Anbieter Abzüge vergeben, wenn Ihre Domains auf SPF-Softfail eingestellt sind. Wir sind jedoch der Meinung, dass eine Abwertung des Sicherheitswerts aufgrund eines Softfail das tatsächliche Risikoprofil der Domain falsch darstellen und Organisationen bestrafen kann, die branchenübliche Empfehlungen für verantwortungsvolles E-Mail-Management und -Sicherheit einhalten. Im Jahr 2026 bietet eine korrekte DMARC-Implementierung bei p=reject die notwendige Durchsetzungsebene gegen Bedenken beim SPF-Softfail.
Andererseits erkennen Bewertungssysteme wie Security Scorecard DMARC (bei einer Policy von Quarantäne oder Reject) als „kompensierende“ Maßnahme für SPF-Softfail an.
Werden Sie für die Umsetzung von SPF-Softfail im Cybersicherheitsaudit abgewertet, treten Sie direkt mit dem Bewertungsteam in Kontakt, um Ihre E-Mail-Authentifizierungsstrategie und deren Konformität mit den Branchenstandards zu erläutern. Setzen Sie sich für eine differenzierte Betrachtung Ihrer Sicherheitsmaßnahmen ein, die den Kontext aller Schutzmechanismen berücksichtigt, anstatt einzelne Einstellungen isoliert zu bewerten.
Warum SPF alleine nicht ausreicht und Sie dennoch DMARC benötigen
Unabhängig davon, welchen Fehlermodus Sie im SPF-Datensatz festlegen, ist es unwahrscheinlich, dass empfangende Server Ihre angeforderte Policy tatsächlich umsetzen. Deshalb ist DMARC ab 2026 bei großen Postfachanbietern verpflichtend. SPF ist nämlich aus folgenden Gründen begrenzt:
- Es ist keine Übereinstimmung zwischen der Domain im
From-Feld und der imReturn-Pathgeprüften Adresse erforderlich. Sie müssen aus SPF-Sicht nicht übereinstimmen. - SPF bietet keine Reporting-Funktion, also sendet der Empfänger keine Berichte mit Authentifizierungsergebnissen an den Absender zurück.
- SPF funktioniert nicht bei automatischer Weiterleitung und bei indirekten Mail-Flows, was zu Authentifizierungsproblemen führen kann.
Aufgrund dieser Einschränkungen wurde DMARC (Domain-based Message Authentication, Reporting, and Conformance) als zusätzlicher Standard zur E-Mail-Authentifizierung eingeführt. DMARC behebt die Schwächen von SPF und bietet folgende Verbesserungen:
- DMARC konzentriert sich auf den sichtbaren
From-Header, den der Endnutzer sieht. - DMARC fordert eine Übereinstimmung zwischen der von SPF verwendeten Domain und der sichtbaren
From-Adresse der E-Mail. - DMARC ignoriert die Feinheiten von Softfail und Hardfail in der SPF-Konfiguration und behandelt beide als SPF-Fehler.
- DMARC bietet Reporting, sodass Authentifizierungsergebnisse an den Inhaber der
From-Domain zurückgesendet werden können. Dies hilft, Missbrauch zu erkennen und Konfigurationsfehler bei legitimen Absendern zu beheben. - DMARC enthält eine Policy, die Empfängern vorschreibt, wie mit nicht authentifizierten E-Mails umzugehen ist. Empfänger setzen diese Policy durch. Im Gegensatz dazu gibt es bei SPF keine Durchsetzungsmechanismen.
DMARC hat sich als Authentifizierungspflicht etabliert, weil es die Schwächen von SPF und DKIM behebt, exakte E-Mail-Imitationen blockiert und die Zustellbarkeit verbessert. Ab 2026 ist DMARC für Massenversender bei Google, Yahoo und Microsoft verpflichtend und gilt damit als Standard für E-Mail-Authentifizierung.
Häufig gestellte Fragen: Leitfaden zur E-Mail-Protokollkonfiguration
In der Zeit vor DMARC wurde in SPF-Einträgen häufig der Mechanismus „-all“ verwendet, um Absender-Policies strikt durchzusetzen. Die aktuellen Branchenempfehlungen für das Jahr 2026 bevorzugen jedoch „~all“, um Sicherheit und Zustellbarkeit ausgewogen zu gestalten und das unnötige Ablehnen legitimer E-Mails, die bei SPF durchfallen, aber DKIM und DMARC bestehen, zu vermeiden.
Der Grund dafür ist, dass „~all“ in Kombination mit DMARC (bei p=reject) weiterhin die Nichtzustellung von nicht-authentifizierten E-Mails ermöglicht, wenn SPF und DKIM fehlschlagen, ohne legitime E-Mails zu blockieren – dadurch wird die Gesamtzustellbarkeit verbessert.
Die DMARC-Spezifikation (RFC 7489) gibt an, dass ein Präfix „-“ beim SPF-Mechanismus des Absenders – wie „-all“ – dazu führen kann, dass eine E-Mail vorab abgelehnt wird, d.h. noch bevor DMARC greift. Verwenden Sie „-all“ nur für inaktive Domains, die nie E-Mails versenden. DMARC unterscheidet nicht zwischen Soft Fail und Hard Fail im SPF – beide werden schlicht als SPF-Fehler gewertet.
DMARC verlangt nicht nur, dass SPF oder DKIM besteht, sondern auch, dass mindestens eine der mit SPF oder DKIM genutzten Domains mit der Domain im From-Header übereinstimmt. Eine korrekte Übereinstimmung ist 2026 entscheidend für die E-Mail-Zustellung, denn die wichtigsten E-Mail-Anbieter setzen nun diese Anforderungen voraus.
Für SPF bedeutet Identifikationsabgleich, dass die Überprüfung von MAIL FROM/Return-PATH erfolgreich ist und dass der Domain-Teil von MAIL FROM/Return-PATH mit der Domain der From-Adresse übereinstimmt. Im Strict-Alignment-Modus müssen die Domains identisch sein, während im Relaxed-Alignment-Modus auch Subdomains akzeptiert werden, sofern sie zur gleichen Organisationsdomain gehören.
Beispiel: Ist der MAIL-FROM/RETURN-PATH @ondmarc.com und der From-Header @knowledge.ondmarc.com, sind sie im Strict-Mode nicht aligned. Im Relaxed-Mode würde DMARC die E-Mail jedoch validieren.
Ein DMARC-Aggregatbericht enthält Informationen zum Authentifizierungsstatus von Nachrichten, die im Namen einer Domain gesendet wurden. Es handelt sich um einen XML-Bounce-Report, der einen Überblick darüber gibt, welche E-Mails SPF und DKIM bestanden oder nicht bestanden haben. So erhalten Domaininhaber genaue Einblicke, von welchen Quellen E-Mails im Namen ihrer Domain versendet werden und was mit diesen E-Mails geschieht (Policy des Empfängers).
Empfänger schauen hierzu auf den 'rua'-Tag Ihres DMARC-Eintrags, um die Berichte zu senden. Sie können das Aggregatbericht-Intervall mit dem Tag ri im DMARC-Eintrag festlegen (Standardwert: 86400 Sekunden, also 24h). Forensik-Berichte liefern deutlich detailliertere Informationen zu jedem Authentifizierungsfehler. Personenbezogene Daten werden entfernt, aber alle für die DMARC-Problembehebung nützlichen Informationen wie Header-Fehler für SPF/DKIM, vollständige Absenderadresse und Betreff werden übermittelt.
Die Empfangsadresse für DMARC-Forensik-Berichte wird per 'ruf'-Tag angegeben. Nicht alle Empfängersysteme unterstützen Forensik-Berichte. Red Sift OnDMARC ist eine der wenigen DMARC-Lösungen, die Forensik-Berichte empfangen kann – dank Partnerschaft mit Yahoo.
Ein SPF-Makro ist ein Mechanismus in SPF-Einträgen, mit dem wiederverwendbare Mengen von IP-Adressen festgelegt werden können. SPF-Makros bieten größere Flexibilität und Wartbarkeit, da Sie komplexe IP-Sets in einem Mechanismus definieren und in mehreren SPF-Einträgen referenzieren können. Beispiel: Statt jede zugelassene IP einzeln aufzulisten, können Sie ein Makro wie „%{i}“ verwenden, das auf die ausgehende IP des E-Mails verweist. So behalten Sie leichter die Kontrolle über große IP-Listen, ohne das SPF-Lookup-Limit zu überschreiten, und verschleiern beim DNS-Lookup autorisierte IPs.
Je nach Aufbau des SPF-Makro-Eintrags kann fehlende Makro-Entwicklung jedoch zu SPF-Fehlern oder zu einem neutralen Ergebnis (?all) führen. Falls SPF-Makros für die Erlaubnis legitimer Sende-Server entscheidend sind, können E-Mails leichter an SPF-Kontrollen scheitern oder von SPF-basierten Systemen als suspekt eingestuft werden.
Mail Transfer Agent Strict Transport Security (MTA-STS) ist ein Standard zur Verschlüsselung von Nachrichten zwischen zwei Mailservern. Er teilt sendenden Mailservern mit, dass E-Mails nur über eine sichere Verbindung mittels Transport Layer Security (TLS) übertragen werden dürfen und schützt so vor Abfangen durch Cyberkriminelle.
Die Einführung von MTA-STS hat deutlich zugenommen; Organisationen werden 2026 Transportsicherheit als unerlässlich für den Schutz von E-Mails im Transit betrachten. Zur Aktivierung von MTA-STS auf einer Empfängerdomain müssen Sie die Unterstützung per DNS bekannt machen und eine Policy-Datei auf Ihrer Website bereitstellen.
MTA-STS sollte vorsichtig aktiviert werden, um nicht unbeabsichtigt die E-Mail-Zustellung zu blockieren. Es empfiehlt sich, den Modus Test zuerst zu verwenden, damit Sie mit Hilfe von TLS-Berichten Fehler aufdecken und beheben können, bevor Sie den strikten Modus aktivieren. Dieses schrittweise Vorgehen wird 2026 voraussichtlich zum Standard für sichere E-Mail-Transportsicherheit.
SMTP TLS Reporting (TLS-RPT) dient laut RFC8460 dazu, TLS-Konnektivitätsprobleme von sendenden MTAs zu melden. Wie bei DMARC werden auch hier Berichte per E-Mail an den Domaininhaber gesendet, wenn TLS-Probleme die Zustellung verhindern. Die Berichte enthalten erkannte MTA-STS-Policies, Traffic-Statistiken, fehlgeschlagene Verbindungen und Fehlerursachen.
Mit der MTA-STS-Funktion in Red Sift OnDMARC müssen Sie sich nicht um komplexe Bereitstellungen kümmern. Sie fügen die von OnDMARC bereitgestellten MTA-STS Smart Records zu Ihrem DNS hinzu und Red Sift übernimmt das Hosting der MTA-STS-Policy-Datei, das SSL-Zertifikatmanagement und meldet gefundene Verstöße automatisiert per TLS-Bericht. 2026 gehört gehostetes MTA-STS bei modernen DMARC-Plattformen immer öfter zum Standard, was die Einführung der Transportverschlüsselung deutlich vereinfacht.
Gemäß RFC 7671 ist DANE (DNS-based Authentication of Named Entities) ein neuer Internetstandard zur Etablierung von TLS-Kommunikation zwischen Client und Server ohne Abhängigkeit von klassischen Certificate Authorities (CAs).
Im traditionellen Modell kann jede CA für jede Domain ein Zertifikat ausstellen. DANE verfolgt einen anderen Ansatz und nutzt die DNSSEC-Infrastruktur (Domain Name System Security Extensions), um einen Domainnamen kryptografisch mit einem Zertifikat zu verbinden. DANE nutzt das bestehende DNSSEC-Protokoll, um Empfangs-Authentizität und Integrität zu gewährleisten.
DANE führt außerdem einen neuen DNS Resource Record Typ TLSA ein, der dem Client signalisiert, dass der Server TLS unterstützt. Es wird empfohlen, sowohl MTA-STS als auch DANE einzurichten. DANE ist für zahlreiche Behörden verpflichtend, insbesondere in der EU für öffentliche Einrichtungen.
DANE und MTA-STS sind nur dann sinnvoll, wenn auch der Versandserver die Mechanismen unterstützt – viele implementieren jedoch nur einen der beiden Ansätze. Beide Standards zu aktivieren, erhöht daher die Gesamtsicherheit. 2026 setzen Organisationen häufig zuerst MTA-STS zur maximalen Kompatibilität ein und ergänzen anschließend DANE, wenn ein höheres Sicherheitsniveau gefordert wird.
Die Subdomain-Policy ermöglicht es Administratoren, verschiedene Domains und Subdomains je nach Stand der DMARC-Einführung individuell zu schützen. Wenn beispielsweise alle Ihre Versanddienste für die Hauptdomain richtig mit SPF und DKIM abgesichert sind, können Sie Ihre Hauptdomain mit einer DMARC-Policy p=reject schützen, für Subdomains aber p=none einsetzen – oder umgekehrt.
Wenn ein Versanddienst kein DMARC unterstützt (also kein SPF oder DKIM implementiert), können Sie diesem Dienst eine eigene Subdomain mit separater DMARC-Policy zuweisen, ohne den Schutz der übrigen Domains zu beeinträchtigen. Dadurch können Sie den Traffic auf verschiedene Subdomains verteilen und jede je nach Bedarf absichern.