Red Sift Leitfaden zur E-Mail-Protokollkonfiguration
Mehr über SPF erfahren
Ich habe SPF, brauche ich DMARC, um meine Domain zu schützen? Was macht DMARC, das SPF nicht macht?
Ja. Ab 2026 ist DMARC für große Posteingangsanbieter bei Massenversendern Pflicht und unerlässlich für den vollständigen Schutz Ihrer Domain.
Was SPF macht
- SPF autorisiert die versendenden IPv4/IPv6-Adressen.
- SPF schützt den Header der E-Mail, der für den Endnutzer nicht sichtbar ist (bekannt als
Return-Path,MAIL FROM, "Envelope From" oder Bounce-Adresse). Ist dieser Header nicht vorhanden, erfolgt die SPF-Prüfung auf derEHLO/HELO-Adresse.
Was SPF nicht macht
- SPF erfordert keine Übereinstimmung zwischen der
From-Domain und der oben genanntenReturn-Path-Adresse, die überprüft wird. Das bedeutet, dass die beiden aus SPF-Sicht nicht übereinstimmen müssen. - SPF bietet keinerlei Reporting-Funktionalität. Der Empfänger der E-Mail sendet also keine Berichte mit den Ergebnissen der E-Mail-Authentifizierung an den Absender zurück.
- SPF funktioniert nicht bei automatischer Weiterleitung und indirekten E-Mail-Flows.
Diese Schwächen führten zur Einführung von DMARC, um Empfängern explizite Anweisungen zu geben und Authentifizierungsberichte bereitzustellen. Dadurch ist es für Absender möglich, erforderliche Maßnahmen zur Korrektur legitimer Mail-Flows einzuleiten. Bis 2026 ist DMARC zum Standard für E-Mail-Authentifizierung geworden und bei Google, Yahoo und Microsoft für Massenversender verpflichtend.
DMARC nutzt SPF als eine seiner Grundlagen, fügt aber auch weitere Funktionen hinzu:
- Konzentriert sich auf den
From-Header, der für den Nutzer sichtbar ist ("Header From"). - Erfordert, dass die von SPF genutzte Domain mit der im sichtbaren
From-Absender der E-Mail übereinstimmt (exakte Übereinstimmung oder Subdomain). - Ignoriert die Unterschiede zwischen Soft-Fail und Hard-Fail in Ihrer SPF-Konfiguration, d. h.
~allund-allwerden gleichermaßen als SPF-Fail behandelt. - Bietet die Reporting-Funktionalität, um Ergebnisse der E-Mail-Authentifizierung an den Inhaber des
Fromzurückzusenden, sodass Sie herausfinden können, ob Ihre Domain missbraucht wird. Dies unterstützt auch die Fehlersuche bei der Zustellbarkeit Ihrer legitimen Absender. - Stellt eine Policy bereit, die den Empfängern vorgibt, wie mit einer E-Mail zu verfahren ist, die die Authentifizierung nicht besteht. Diese Policy wird von den Empfängern durchgesetzt. Nutzt man SPF ohne DMARC, gibt es keine solche Durchsetzung.
Große Mailbox-Anbieter nutzen mittlerweile visuelle Hinweise in ihren E-Mail-Clients, um zu zeigen, ob eine E-Mail authentifiziert ist. Beispielsweise zeigt Gmail ein Fragezeichen (?) für nicht authentifizierte E-Mails an – siehe unten. Dieser visuelle Indikator ist 2026 branchenweit Standard im Posteingang.
Führen Sie einen kostenlosen SPF-Check mit Red Sift durch – keine Anmeldung erforderlich.
Was ist eine SPF-Include-Anweisung?
Ein include ist ein SPF-Mechanismus, der auf eine Domain verweist, die beim Überprüfen der Absender-IP abgefragt werden soll. Gehört die versendende IP zu dem include, ergibt sich eine Übereinstimmung und die SPF-Prüfung ist bestanden.
Beispielsweise, wenn Sie include:_spf.google.com als Teil Ihres SPF-Records haben und die Ursprungs-IP einer E-Mail eine Google-IP ist, kommt es zu einer Übereinstimmung, da Sie Google für den Versand in Ihrem Auftrag autorisiert haben, und die Absender-IP innerhalb des include-Mechanismus zu finden ist.
Was sind SPF-Makros?
Ein SPF-Makro bezieht sich auf einen Mechanismus in SPF-Records, mit dem wiederverwendbare IP-Adresssets definiert werden. Mit SPF-Makros lässt sich die Flexibilität und Wartbarkeit von SPF-Einträgen erhöhen, indem Sie komplexe Adress-Sets in einem einzigen Mechanismus zusammenfassen und so in mehreren SPF-Einträgen referenzieren können. Das erleichtert die Verwaltung großer Mengen autorisierter Server, ohne dieselben Informationen mehrfach angeben zu müssen.
Statt jede einzelne IP-Adresse für autorisierte Server aufzuführen, können Sie z. B. ein Makro so definieren:
@spf.salesforce.com IN TXT "v=spf1 exists:%{i}.spf.mta.salesforce.com -all"
In diesem Beispiel stellt das Makro den Mechanismus %{i} dar, der die Absender-IP der E-Mail abruft. Die Domain wird so zu etwas wie 233.124.65.65._spf.mta.salesforce.com.
Mit dieser Art von SPF-Management können Sie eine große IP-Liste kontrollieren, ohne das Lookup-Limit zu überschreiten, und zugleich bleibt verborgen, welche IPs Sie öffentlich autorisieren.
Das Problem mit SPF-Makros
Das Risiko bei SPF-Makros besteht darin, dass die meisten alten E-Mail-Infrastrukturen diese nicht unterstützen und es dadurch zu gravierenden Zustellbarkeitsproblemen kommen kann. Laut technischen Studien und unseren eigenen Erfahrungen funktioniert dies nur bei etwa 75 % der SMTP-Server zuverlässig. Deshalb setzen Unternehmen 2026 zunehmend auf dynamisches SPF-Management, statt auf Makros oder manuelles Flattening.
Unterstützt ein Mailserver SPF-Makros nicht, kann das wie folgt aussehen:
Keine Expansion
Unterstützt der empfangende Mailserver keine SPF-Makros, werden diese nicht aufgelöst oder verarbeitet, sondern bleiben ein unverarbeiteter String. Dadurch entfällt die eigentliche Funktionalität des SPF-Records, wodurch SPF-Prüfungen ggf. unvollständig oder falsch ausfallen. Zwar werden Makros nicht in produktiven SPF-Records eingesetzt, das No-Expansion-Verhalten kommt dennoch bei Mailservern wie iCloud vor.
Mögliche SPF-Fehlschläge
Je nach Aufbau des SPF-Records mit Makros kann das Fehlen der Expansion zu SPF-Fehlschlägen oder 'Neutral'-Ergebnissen führen (angezeigt durch den Mechanismus ?all). In beiden Fällen hat der Eintrag nicht die gewünschte Wirkung der ordnungsgemäßen Autorisierung legitimer Absender.
Zustellbarkeitsauswirkungen
Wenn SPF-Makros eine wesentliche Rolle bei der Autorisierung legitimer Absender spielen, sind E-Mails anfälliger dafür, SPF-Prüfungen nicht zu bestehen oder von Empfängern, die auf SPF setzen, als verdächtig markiert zu werden.
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.