Red Sift Leitfaden zur E-Mail-Protokollkonfiguration
SPF-Fehler: Hardfail vs. Softfail
Was ist ein SPF-Fehler?
Ein SPF-Fehler tritt auf, wenn die IP-Adresse des Absenders nicht im veröffentlichten SPF-Eintrag gefunden wird. Fehler beeinträchtigen die Zustellbarkeit Ihrer E-Mails erheblich, 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 Kunden angewiesen sind, katastrophal sein. Da große Posteingangsanbieter ab 2026 Authentifizierungsanforderungen durchsetzen, haben SPF-Fehler direkte Auswirkungen auf 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 E-Mail-Empfänger bestimmt das die Behandlung der E-Mail: Ein Hardfail signalisiert, die E-Mail abzulehnen, während ein Softfail darauf hinweist, dass sie als Spam behandelt werden sollte.
Wir zeigen anhand von zwei Beispielen den optischen Unterschied zwischen beiden.
Beispiel für einen SPF-Hardfail
v=spf1 ip4:192.168.0.1 -all
Im obigen Beispiel steht das Minuszeichen (vor all am Ende des Eintrags) dafür, dass alle nicht im SPF-Eintrag aufgeführten Absender als Hardfail behandelt werden sollen. Das heißt: Sie sind nicht autorisiert, und E-Mails von ihnen werden verworfen. In diesem Fall ist nur die IP-Adresse 192.168.0.1 zum Senden von E-Mails zugelassen, sonst keine weitere.
Beispiel für einen SPF-Softfail
v=spf1 include:spf.protection.outlook.com ~all
Im obigen Beispiel steht das Tilde-Symbol (vor all am Ende des Eintrags) dafür, dass nicht im SPF-Eintrag gelistete Absender als Softfail behandelt werden, d.h. die E-Mail kann zwar durchgelassen, sollte aber als Spam oder verdächtig markiert werden. In diesem Fall autorisiert der include:spf.protection.outook.com-Mechanismus Microsoft 365 zum Senden von E-Mails. E-Mails von anderen Servern sollten von Empfängern als Spam markiert werden.
Unsicher bei Ihrem SPF-Setup? Nutzen Sie unseren kostenlosen Checker, um loszulegen.
Welchen SPF-Fehlermodus sollten Sie verwenden?
Da Hardfail ("-all") signalisiert, dass alle nicht autorisierten Absender, die nicht im SPF-Eintrag stehen, abgelehnt werden, scheint dies die bevorzugte Option zu sein. Allerdings ist die Entscheidung komplexer.
In der Zeit vor DMARC verwendeten SPF-Einträge häufig den Mechanismus „-all“, um die Senderichtlinien strikt durchzusetzen, ohne zusätzliche Schicht durch DKIM und DMARC zur Authentifizierung legitimer E-Mails.
Nach aktuellen Branchenempfehlungen im Jahr 2026 wird jedoch „~all“ bevorzugt, um Sicherheit und Zustellbarkeit auszubalancieren und nicht versehentlich legitime E-Mails abzulehnen, die zwar bei SPF durchfallen, aber DKIM und DMARC bestehen könnten.
Die Branche weist generell darauf hin, dass bei SPF-Modi Vorsicht geboten ist; die DMARC-Spezifikation (RFC 7489) führt aus:
„Manche Empfänger-Architekturen könnten SPF auswerten, bevor DMARC-Operationen greifen. Das bedeutet, ein „-“ Präfix bei einem SPF-Mechanismus wie „-all“ kann dazu führen, dass eine Ablehnung frühzeitig greift und Nachrichten zurückgewiesen werden, noch bevor DMARC greift. Betreiber, die „-all“ einsetzen, sollten sich dessen bewusst sein.“
Deshalb empfehlen wir Folgendes:
- „-all“ für inaktive Domains ohne E-Mail-Versand: Setzen Sie „-all“ ausschließlich dann ein, wenn die Domain überhaupt keine E-Mails sendet. Diese Einstellung blockiert strikt nicht autorisierte E-Mails, kann aber legitime blockieren, falls der SPF-Eintrag nicht aktuell ist.
- „~all“ für aktive E-Mail-Domains: Verwenden Sie „~all“, wenn Sie SPF gemeinsam mit DKIM und DMARC einsetzen, um Phishing und Spoofing zu bekämpfen. Denn „~all“ – kombiniert mit DMARC (p=reject) – führt trotzdem zur Ablehnung nicht authentifizierter Nachrichten, sofern SPF und DKIM fehlschlagen. Diese Einstellung blockiert keine legitimen E-Mails und verbessert daher die Zustellbarkeit insgesamt.
Zusammengefasst: Softfail bietet einen Mittelweg zwischen strikter Sicherheit (die auch legitime E-Mails blockieren kann) und Flexibilität, damit E-Mails trotz gelegentlicher SPF-Abweichungen noch zugestellt werden können.
Wie bewerten Unternehmen für Cybersecurity-Ratings SPF-Softfail?
Manche Bewertungsunternehmen könnten Ihre Domains schlechter einstufen, wenn diese mit SPF-Softfail konfiguriert sind. Wir sind jedoch der Ansicht, dass eine Abwertung des Sicherheitswerts einer Domain aufgrund eines Softfail das tatsächliche Risikoprofil verfälschen und Organisationen bestrafen kann, die empfohlene Branchenstandards für verantwortungsbewusstes E-Mail-Management und Sicherheit umsetzen. Im Jahr 2026 stellt eine korrekte DMARC-Implementierung mit p=reject die Durchsetzung sicher, auch wenn SPF auf Softfail steht.
Andererseits erkennen Ratingdienste wie Security Scorecard an, dass DMARC (bei Richtlinie Quarantäne oder Reject) einen „kompensierenden“ Kontrollmechanismus für SPF-Softfail darstellt.
Wenn Ihnen bei einem Cybersecurity-Audit für SPF-Softfail Punkte abgezogen werden, treten Sie direkt mit der Bewertungsstelle in Kontakt, um Ihre Authentifizierungsstrategie für E-Mails und die Ausrichtung an Branchenstandards darzulegen. Machen Sie sich für einen differenzierteren Bewertungsansatz stark, der den Gesamtkontext Ihrer Sicherheitsmaßnahmen betrachtet und nicht nur einzelne Konfigurationen isoliert bewertet.
Warum SPF alleine nicht ausreicht und Sie trotzdem DMARC brauchen
Unabhängig davon, welchen Fehlermodus Sie im SPF-Eintrag angeben – empfangende Server folgen selten Ihrer Wunschrichtlinie. Deshalb ist DMARC ab 2026 bei großen Posteingangsanbietern Pflicht geworden. Das liegt daran, dass SPF folgende Einschränkungen hat:
- Es ist keine Übereinstimmung zwischen der Domain im From-Feld und der Return-Path-Adresse im SPF-Prüfmechanismus erforderlich. Aus SPF-Sicht müssen diese nicht identisch sein.
- SPF liefert keine Berichtsfunktion – der Empfänger versendet keine Rückmeldungen mit den Ergebnissen der E-Mail-Authentifizierung an den Absender.
- SPF besteht nicht bei automatischer Weiterleitung und indirekten Zustellpfaden, was zu Authentifizierungsproblemen führen kann.
Aufgrund dieser Einschränkungen wurde DMARC (Domain-based Message Authentication, Reporting, and Conformance) als zusätzlicher Authentifizierungsstandard eingeführt. DMARC behebt die Schwächen von SPF und erweitert um folgende Funktionen:
- DMARC prüft den sichtbaren From-Header, der für Endnutzer sichtbar ist.
- DMARC verlangt Übereinstimmung zwischen der von SPF genutzten Domain und der im sichtbaren From-Absender der E-Mail.
- DMARC ignoriert die Unterschiede zwischen Softfail und Hardfail bei der SPF-Konfiguration und behandelt beide als SPF-Fehler.
- DMARC liefert Berichtsfunktion, sodass Authentifizierungsergebnisse an den Besitzer der From-Domain geschickt werden. Das hilft, Missbrauch der Domain zu erkennen und Konfigurationsfehler mit legitimen Absendern zu beheben.
- DMARC gibt eine Richtlinie vor, wie nicht authentifizierte E-Mails zu behandeln sind und setzt diese Richtlinie durch. SPF hat alleine keine Durchsetzungsmechanismen.
DMARC hat sich als Authentifizierungsstandard durchgesetzt, da er die Schwächen von SPF und DKIM behebt, E-Mail-Spoofing effektiv verhindert und die Zustellbarkeit verbessert. Ab 2026 ist DMARC für Massen-Versender bei Google, Yahoo und Microsoft Pflicht und damit zum E-Mail-Authentifizierungsstandard geworden.
Prüfen Sie Ihren SPF-Eintrag kostenlos – keine Registrierung erforderlich.
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.