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-Record gefunden wird. Fehler wirken sich erheblich auf die Zustellbarkeit Ihrer E-Mail aus, da sie dazu führen, dass die E-Mail im Spam landet oder ganz verworfen wird. Dies kann für Unternehmen, die auf E-Mail-Kommunikation mit Kunden angewiesen sind, katastrophal sein. Da große Postfachanbieter ab 2026 Authentifizierungsanforderungen durchsetzen, haben SPF-Fehler direkte Auswirkungen auf die Zustellung.
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 vermutlich nicht autorisiert wurde. Für den Empfänger der E-Mail bestimmt dies die Behandlung der E-Mail: Ein Hardfail weist den Empfänger an, die E-Mail abzulehnen, während ein Softfail nahelegt, sie in den Spam-Ordner umzuleiten.
Wir werden zwei Beispiele verwenden, um den visuellen Unterschied zwischen beiden Varianten zu demonstrieren.
Beispiel für SPF-Hardfail
v=spf1 ip4:192.168.0.1 -all
Im obigen Beispiel bedeutet das Minuszeichen (vor all am Ende des Records), dass alle Absender, die nicht in diesem SPF-Record aufgeführt sind, als Hardfail behandelt werden – d.h. sie sind nicht autorisiert und deren E-Mails sollten verworfen werden. In diesem Fall ist nur die IP-Adresse 192.168.0.1 zum Senden von E-Mails autorisiert – keine anderen.
Beispiel für SPF-Softfail
v=spf1 include:spf.protection.outlook.com ~all
Im obigen Beispiel bedeutet das Tilde-Zeichen (vor all am Ende des Records), dass alle Absender, die nicht in diesem SPF-Record aufgeführt sind, als Softfail behandelt werden sollen – das heißt, E-Mails dürfen prinzipiell zugelassen, sollten aber als Spam oder verdächtig markiert werden. In diesem Fall autorisiert der Mechanismus include:spf.protection.outook.com Microsoft 365 zum Versand von E-Mails. Jegliche E-Mails von anderen Servern sollten von den Empfängern als Spam markiert werden.
Unsicher beim SPF-Setup? Nutzen Sie unseren kostenlosen Checker, um loszulegen.
Welchen SPF-Fehlermodus sollten Sie verwenden?
Da Hardfail ("-all") signalisiert, dass unautorisierte Absender, die nicht im SPF-Record enthalten sind, abgelehnt werden sollen, scheint dies zunächst die bevorzugte Methode zu sein. Doch die Entscheidung ist differenzierter.
Vor DMARC wurden SPF-Records üblicherweise mit dem "-all"-Mechanismus geführt, um Absender strikt einzuschränken – ohne die zusätzliche Authentifizierungsschicht von DKIM und DMARC.
Die aktuelle Branchenempfehlung 2026 spricht sich jedoch für "~all" aus, um Sicherheit und Zustellbarkeit in Einklang zu bringen und unnötige Ablehnungen legitimer E-Mails zu vermeiden, die bei SPF durchfallen könnten, aber DKIM und DMARC bestehen.
Die Branche ist sich einig, dass bei SPF-Modi Sorgfalt geboten ist; die DMARC-Spezifikation (RFC 7489) gibt an:
„Manche Empfängerarchitekturen implementieren SPF bereits vor allen DMARC-Operationen. Das bedeutet, dass ein "-"-Präfix im SPF-Mechanismus des Absenders, wie etwa "-all", eine Ablehnung bereits früh im Mailflow auslösen kann – noch bevor DMARC verarbeitet wird. Betreiber, die "-all" einsetzen, sollten sich dessen bewusst sein.“
Aus diesen Gründen empfehlen wir Folgendes:
- Nutzen Sie "-all" für inaktive Domains ohne E-Mail-Versand: Wenden Sie "-all" nur an, wenn die Domain keinerlei E-Mails versendet. Damit blockieren Sie streng jegliche unautorisierten E-Mails, riskieren aber die Ablehnung legitimer Mails, falls der SPF-Record nicht aktuell ist.
- Nutzen Sie "~all" für aktive, E-Mail-verschickende Domains: Greifen Sie zu "~all", wenn Sie SPF gemeinsam mit DKIM und DMARC zur Abwehr von Phishing und Spoofing einsetzen. Denn "~all" – in Kombination mit DMARC (bei p=reject) – sorgt trotzdem dafür, dass unautorisierte Mails abgelehnt werden, falls SPF und DKIM fehlschlagen. Dieser Modus blockiert keine legitimen E-Mails und verbessert somit die Zustellbarkeit insgesamt.
Zusammengefasst: Softfail bildet einen Mittelweg zwischen strenger Sicherheit (die legitime E-Mails blockieren könnte) und Flexibilität in der E-Mail-Zustellung, sodass E-Mails auch bei gelegentlichen Fehlern im SPF-Record zustellbar bleiben.
Wie wird SPF-Softfail von Cybersecurity-Rating-Unternehmen bewertet?
Es ist möglich, dass einige Bewertungsunternehmen Abzüge vergeben, wenn Ihre Domains mit SPF-Softfail konfiguriert sind. Wir sind jedoch der Meinung, dass das Herabsetzen des Sicherheitsscores einer Domain basierend auf Softfail das tatsächliche Risikoprofil verzerren und Organisationen benachteiligen kann, die branchenüblichen Empfehlungen für verantwortungsvolles E-Mail-Management und Sicherheit folgen. Im Jahr 2026 liefert eine korrekte DMARC-Implementierung mit p=reject die nötige Durchsetzung zur Absicherung bei SPF-Softfail.
Andererseits erkennen Bewertungsdienste wie Security Scorecard an, dass DMARC (bei einer Quarantäne- oder Reject-Policy) ein „kompensierendes“ Kontrollinstrument für SPF-Softfail ist.
Werden Sie bei einer Cybersecurity-Prüfung für SPF-Softfail abgestraft, suchen Sie das Gespräch mit dem Bewertungsteam und erläutern Sie Ihre E-Mail-Authentifizierungsstrategie sowie die Ausrichtung an Best Practices der Branche. Plädieren Sie für einen differenzierten Ansatz bei der Beurteilung der Sicherheitslage, der alle E-Mail-Sicherheitsmaßnahmen im Kontext betrachtet und nicht einzelne Konfigurationen isoliert abwertet.
Warum SPF allein nicht ausreicht und DMARC trotzdem erforderlich ist
Unabhängig davon, welchen Fehlermodus Sie im SPF-Record wählen, beachten empfangende Server die gewünschte Policy meist nicht. Deshalb ist DMARC ab 2026 bei großen Postfachanbietern Pflicht. Denn SPF ist in folgenden Punkten limitiert:
- Es ist keine Übereinstimmung zwischen der Domain im
From-Feld und der geprüftenReturn-Path-Adresse gefordert. Aus SPF-Sicht müssen diese nicht übereinstimmen. - SPF bietet keine Reporting-Funktionalität – der Empfänger sendet dem Absender keine Berichte zu den Ergebnissen der E-Mail-Authentifizierung zurück.
- SPF übersteht weder automatisches Weiterleiten noch indirekte Mailflows, 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, der für Endnutzer sichtbar ist. - DMARC fordert eine Übereinstimmung zwischen der SPF-Domain und der im sichtbaren
From-Header verwendeten Domain. - DMARC ignoriert die Unterscheidung zwischen Softfail und Hardfail bei der SPF-Konfiguration und behandelt sie allgemein als SPF-Fehler.
- DMARC bietet Reporting-Funktionalität, sodass Authentifizierungsergebnisse an den Besitzer der
From-Domain gesendet werden. Dies hilft, Domainmissbrauch zu erkennen und Fehlkonfigurationen mit legitimen Versendern zu beheben. - DMARC enthält eine Policy, die Empfängern vorgibt, wie mit E-Mails umzugehen ist, die die Authentifizierung nicht bestehen – und diese Policy wird durchgesetzt. Im Gegensatz dazu fehlen SPF Enforcement-Mechanismen.
DMARC hat sich als Authentifizierungsstandard weitgehend durchgesetzt, da damit die Schwächen von SPF und DKIM beseitigt, exakte E-Mail-Imitationen gestoppt und die Zustellbarkeit verbessert werden können. Ab 2026 ist DMARC für Massenversender bei Google, Yahoo und Microsoft verpflichtend und gilt damit als neuer Goldstandard der E-Mail-Authentifizierung.
Prüfen Sie Ihren SPF-Record kostenlos – keine Anmeldung 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.