SPF-Prüfung in Exchange: So überprüfen, veröffentlichen und korrigieren Sie SPF-Einträge in Exchange

Im Mai 2025 begann Microsoft damit, E-Mails von Absendern mit hohem Versandvolumen zurück, denen gültige SPF-, DKIM- und DMARC-Einstellungen fehlten. Wenn Ihre Domain täglich mehr als 5.000 Nachrichten ohne ordnungsgemäße Authentifizierung an Outlook.com oder Hotmail.com sendet, erreichen diese Nachrichten den Posteingang nicht.

Google und Yahoo führten im Februar 2024 ähnliche Anforderungen ein. im Februar 2024. Diese frühere Durchsetzungsrunde reduzierte laut Googles E-Mail-Sicherheitsteam die Anzahl nicht authentifizierter Nachrichten, die Gmail-Nutzer erhielten, um etwa 75 %.

„Business Email Compromise“, bei dem Schwachstellen in der E-Mail-Authentifizierung direkt ausgenutzt werden, verursachte laut FBI IC3 Internet Crime Report, 2023. 

Das Problem in Exchange-Umgebungen ist, dass SPF-Fehler unbemerkt bleiben. Exchange Online benachrichtigt Sie nicht, wenn Ihr Eintrag fehlerhaft ist. Es gibt kein integriertes Dashboard, das die Erfolgsquote anzeigt. Die meisten Teams bemerken dies erst Wochen später, wenn sich Nutzer darüber beschweren, dass E-Mails zurückkommen, oder wenn die Marketingabteilung meldet, dass die Öffnungsraten eingebrochen sind.

In diesem Leitfaden erfahren Sie, wie Sie Ihren Exchange-SPF-Eintrag mit vier verschiedenen Methoden überprüfen, wie Sie den richtigen Eintrag für Exchange Online, lokale und hybride Konfigurationen veröffentlichen und wie Sie die häufigsten SPF-Fehler (einschließlich der 10-Lookup-Obergrenze, die SPF in den meisten mittelständischen Unternehmen beeinträchtigt) beheben können, wie Exchange Online SPF intern tatsächlich auswertet und wie Sie SPF kontinuierlich überwachen können, anstatt ihn nur einmal zu überprüfen und dann zu vergessen.

So überprüfen Sie Ihren Exchange-SPF-Eintrag (Schritt für Schritt)

Es gibt vier zuverlässige Methoden, um Ihren SPF-Eintragzu überprüfen, von der schnellsten bis zur umfassendsten. Verwenden Sie Methode 1 für eine schnelle Überprüfung und Methode 4 für eine kontinuierliche operative Transparenz.

Methode 1: Verwenden Sie ein SPF-Lookup-Tool (am schnellsten)

1. Öffnen Sie einen beliebigen SPF-Checker (den PowerDMARC SPF Checker ist kostenlos und erfordert keine Anmeldung)
2. Geben Sie Ihre Domain ein (z. B. yourdomain.com, ohne das Präfix http://) und 
3. Überprüfen Sie die Ausgabe

Die Abfrage liefert mehrere Ergebnisse der SPF-Validierung. Hier erfahren Sie, was die einzelnen Ausgabefelder bedeuten und worauf Sie bei der Überprüfung achten sollten: 

Ein Eintrag kann zwar korrekt ausgewertet werden und die Anzahl der Treffer kann bei sechs liegen, dennoch kann eine legitime Absenderquelle fehlen. Der SPF-Checker überprüft die Angaben im DNS, weiß aber nicht, welche IP-Adressen autorisiert sein sollten.

Methode 2: Überprüfung über das Microsoft 365 Admin Center

Melden Sie sich beim Microsoft 365-Admincenter an. Navigieren Sie zu „Einstellungen“ → „Domänen“ → wählen Sie Ihre Domäne aus → „DNS-Einträge“. Überprüfen Sie im Abschnitt „Microsoft Exchange“, ob der Status des TXT-Eintrags „OK“ lautet.

Wenn der Status „Ungültiger Eintrag“ lautet, fehlt Ihr SPF-Eintrag entweder oder enthält nicht die erforderliche Anweisung „include:spf.protection.outlook.com“. Dies ist der schnellste Weg, um die SPF-Einträge zu überprüfen, ohne das Admin-Portal zu verlassen.

Methode 3: Überprüfung über die Befehlszeile (nslookup / dig)

Für die serverseitige Fehlerbehebung oder in Fällen, in denen Sie keinen Browserzugriff haben, können Sie den SPF-TXT-Eintrag Ihrer Domain direkt über die Befehlszeile abfragen.

Führen Sie einen der folgenden Befehle aus: 

# Windows

nslookup -type=txt yourdomain.com

# Linux 

/ macOSdig txt yourdomain.com +short

Die Ausgabe enthält den rohen TXT-Eintrag. Suchen Sie nach der Zeile, die mit „v=spf1“ beginnt. Wenn Sie zwei solche Zeilen sehen, liegen mehrere SPF-Einträge vor, was sofort zu einem PermError führt. Beheben Sie diesen Fehler, bevor Sie weitere Schritte unternehmen.

Methode 4: Überprüfung anhand von DMARC-Aggregatberichten (der Goldstandard)

Gesamtberichte von E-Mail-Anbietern wie Gmail, Yahoo, Microsoft, Mail.ru und regionalen Internetdienstanbietern zeigen die SPF-Erfolgs- und Fehlerquoten für alle E-Mails, die von Ihrer Domain versendet wurden, und nicht nur für eine einzelne Testnachricht. Nur so lässt sich ein kontinuierlicher und vollständiger Überblick über den SPF-Status gewinnen.

Wenn Sie DMARC mit einem „rua=“-Tag veröffentlichen, erfassen Sie diese Berichte bereits. Die meisten Unternehmen verfügen über diese Berichte, doch nur wenige lesen sie, da das Roh-XML ohne eine Plattform zu seiner Auswertung unlesbar ist.

PowerDMARC erfasst diese Berichte täglich und stellt SPF-spezifische Analysen in einem eigenen Dashboard bereit, das die Erfolgs- und Fehlerquoten pro Absenderquelle, die Nachverfolgung von DNS-Abfragen sowie Benachrichtigungen bei Auftreten eines neuen, nicht autorisierten Absenders enthält.

Methode 5: Überprüfung anhand der Exchange-Nachrichten-Header (Validierung in der Praxis)

So überprüfen Sie, wie SPF von einem tatsächlichen Empfänger ausgewertet wird:

• Senden Sie eine Testnachricht von Ihrer Domain an eine externe Adresse (ein persönliches Gmail-Konto reicht aus).
• Öffnen Sie die Nachricht und rufen Sie die vollständigen Kopfzeilen ab. In Outlook: Datei → Eigenschaften → Internet-Kopfzeilen. In OWA oder Gmail: Quelltext anzeigen / Original anzeigen.
• Suchen Sie den Header „Authentication-Results“ und suchen Sie das Feld „spf=“.

So sieht der entsprechende Header mit Anmerkungen aus:

Authentifizierungsergebnisse: 

spf=pass (Absender-IP lautet 40.107.22.83)  

smtp.mailfrom=deineDomain.com;  

dkim=pass (Signatur wurde überprüft)  

header.d=deinedomain.com;  

dmarc=pass action=none  

header.from=deine-domain.com;  

compauth=pass reason=100

„spf=pass“ bestätigt, dass die Absender-IP durch Ihren SPF-Eintrag autorisiert wurde. Wenn Sie „spf=fail“, „spf=softfail“ oder „spf=permerror“ sehen, gibt Ihnen das jeweilige Ergebnis Aufschluss darüber, wo das Problem liegt:

• spf=fail: Die Absender-IP ist in Ihrem SPF-Eintrag überhaupt nicht enthalten.
• spf=softfail: Die IP-Adresse ist nicht autorisiert, aber dein Eintrag verwendet „~all“ anstelle von „-all“.
• spf=permerror: Ihr SPF-Eintrag weist ein strukturelles Problem auf (>10 Lookups, mehrere Einträge, Syntaxfehler).

So sieht ein gültiger Exchange-SPF-Eintrag aus

So veröffentlichen Sie einen SPF-Eintrag für Exchange Online (M365)

Das Veröffentlichen eines SPF-Eintrags für Exchange Online ist ganz einfach. Die meisten Teams scheitern jedoch daran, die richtigen Angaben zu machen.

Schritt 1: Ermitteln Sie alle Ihre autorisierten Absenderquellen

Bevor Sie Änderungen an der DNS vornehmen, sollten Sie jedes System überprüfen, das E-Mails im Namen Ihrer Domain versendet. Die meisten Unternehmen unterschätzen diese Liste um 30–50 %.

• Microsoft 365 / Exchange Online → include:spf.protection.outlook.com
• Marketing-Automatisierung (HubSpot, Mailchimp, Marketo, Pardot) → jedes hat seinen eigenen Include
• CRM (Salesforce, Microsoft Dynamics) → siehe Dokumentation des Anbieters zu SPF
• Transaktions-E-Mails (SendGrid, Amazon SES, Postmark, Mailgun) → anbieterspezifische Einbindungen
• Helpdesk / Ticket-System (Zendesk, Freshdesk, ServiceNow) → anbieterspezifische Einbindungen
• Personalwesen / Lohnbuchhaltung (BambooHR, Gusto, Workday) → Überprüfen Sie, ob Benachrichtigungen über Ihre Domain versendet werden
• Ältere lokale Server → IPv4: mit öffentlich zugänglichen IP-Adressen

Der zuverlässigste Weg, um Absender zu identifizieren, die Ihnen bisher unbekannt waren, ist DMARC-Aggregatberichte. Dort werden alle legitimen (und illegitimen) Absender angezeigt, die unter Ihrer Domain versenden.

Schritt 2: Erstellen Sie den SPF-Eintrag

Beginnen Sie mit dem Versions-Tag, fügen Sie autorisierte Quellen hinzu und schließen Sie mit dem Qualifizierer ab.

Einfaches M365-Beispiel:

v=spf1 

include:spf.protection.outlook.com -all

Ein typisches mittelständisches Unternehmen, das HubSpot und SendGrid nutzt:

v=spf1 

einschließlich:spf.protection.outlook.com 

einschließlich:_spf.hubspot.com 

include:sendgrid.net -all

Zählen Sie Ihre DNS-Abfragen während der Erstellung. Jeder „include:“, „a:“, „mx:“, „ptr:“ und „exists:“-Mechanismus löst eine Abfrage aus. „ip4:“- und „ip6:“-Mechanismen werden nicht gezählt. Verschachtelte „include:“-Anweisungen werden ebenfalls gezählt, da „include:spf.protection.outlook.com“ selbst intern 2–4 zusätzliche Abfragen verursacht, da es durch die Infrastruktur von Microsoft weitergeleitet wird.

Schritt 3: Den Eintrag im DNS veröffentlichen

Der Veröffentlichungsprozess unterscheidet sich je nach DNS-Anbieter geringfügig, folgt jedoch dem gleichen Schema:

Einstellungen, die durchgehend verwendet werden sollten:

• Datensatztyp: TXT
• Host / Name: @ (oder leer, je nach Anbieter)
• TTL: 3600 (1 Stunde) während der Testphase, danach 86400 (24 Stunden) bei stabilem Betrieb

Wichtig: Nur ein SPF-Eintrag pro Domain. Ein zweiter v=spf1-TXT-Eintrag ist ein PermError, der nur darauf wartet, entdeckt zu werden. Wenn der Bereitstellungsprozess Ihres DNS-Anbieters beim Hinzufügen eines Dienstes automatisch einen Eintrag erstellt, überprüfen Sie sofort, ob Duplikate vorhanden sind.

Schritt 4: Überprüfen Sie den veröffentlichten Datensatz

• Warten Sie 5 bis 60 Minuten, bis die DNS-Änderungen übernommen wurden (abhängig von der TTL und dem Provider).
• Führen Sie die SPF-Abfrage aus Methode 1 erneut durch, um zu überprüfen, ob der Eintrag korrekt aufgelöst wird.
• Überprüfen Sie das M365-Admincenter (Methode 2). Der TXT-Status sollte nun „OK“ anzeigen.
• Senden Sie eine Testnachricht an eine externe Adresse und überprüfen Sie die Kopfzeilen auf „spf=pass“.
• Stellen Sie sicher, dass die Anzahl der DNS-Abfragen unter 10 liegt.

Wenn Sie den Datensatz lieber nicht manuell zusammenstellen möchten, bietet der PowerDMARC SPF Generator einen korrekt formatierten Datensatz, sobald Sie Ihre Absenderquellen angeben.

SPF für hybride Exchange-Umgebungen: On-Premise + Cloud

Hybride Exchange-Umgebungen machen die SPF-Konfiguration deutlich komplexer, da E-Mails gleichzeitig sowohl aus Microsoft 365 als auch aus der lokalen Infrastruktur stammen können. Insbesondere bei Migrationen überschneiden sich die E-Mail-Flusswege oft in einer Weise, die zu unbemerkten SPF-Fehlern führt, sofern nicht jede ausgehende Route korrekt berücksichtigt wird.

Die Hybrid-Herausforderung: Zwei E-Mail-Pfade, ein SPF-Eintrag

In einer Hybridumgebung kann ausgehende Post über drei verschiedene Wege versendet werden:

• Direkt über Exchange Online: für in M365 gehostete Postfächer
• Lokale Exchange- oder Edge-Transport-Server: für Postfächer, die sich noch vor Ort befinden
• Smart Hosts oder Relays von Drittanbietern: wenn E-Mails extern weitergeleitet werden, bevor sie das öffentliche Internet erreichen

Jeder Pfad zeigt dem empfangenden Server eine andere Absender-IP an. Für SPF spielt es keine Rolle, welcher Pfad beabsichtigt war, da es lediglich prüft, ob die tatsächlich erfasste IP autorisiert ist. Beide Pfade müssen in einem einzigen SPF-Eintrag abgedeckt sein, da pro Domain nur ein SPF-Eintrag zulässig ist.

So richten Sie SPF für Hybrid Exchange ein

Fügen Sie beide Autorisierungspfade ein:

v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 ip4:203.0.113.11 -all

Die lokalen IP-Adressen sind die nach außen gerichteten Adressen, die Ihr Mailserver beim Versenden von E-Mails ins Internet verwendet, nicht die internen RFC-1918-Adressen. Überprüfen Sie die Sendekonnektoren Ihres Edge-Transport-Servers sowie alle NAT- oder Firewall-Regeln, die die nach außen gerichtete IP-Adresse festlegen. Wenn Sie über geografische Redundanz oder mehrere ausgehende Pfade verfügen, muss jede öffentliche IP-Adresse, von der E-Mails versendet werden könnten, in dem Datensatz enthalten sein.

SPF während der Migration (Übergangsphase)

Bei einer schrittweisen oder vollständigen Migration gibt es einen Zeitraum, in dem die Postfächer an beiden Standorten vorhanden sind und E-Mails über beide Wege versendet werden können. SPF muss während des gesamten Zeitraums beide Standorte abdecken.

• Bevor die Migration beginnt: Stellen Sie sicher, dass Ihr SPF-Eintrag sowohl die lokalen IPv4-Einträge als auch „include:spf.protection.outlook.com“ abdeckt.
• Während der Migration: Behalten Sie beide Autorisierungen bei. Überwachen Sie die SPF-Erfolgsraten über die DMARC-Gesamtberichte. Wenn Routing-Änderungen dazu führen, dass E-Mails über unerwartete Pfade geleitet werden, zeigen die Berichte dies an, bevor es die Benutzer bemerken.
• Nach Abschluss der Migration: Entfernen Sie die lokalen IPv4-Einträge. Das Belassen veralteter IP-Adressen in der SPF-Eintragung stellt ein Sicherheitsrisiko dar. Wenn diese alten IP-Adressen von Ihrem Internetdienstanbieter oder Cloud-Anbieter neu zugewiesen werden, kann der neue Nutzer authentifizierte E-Mails unter Ihrer Domain versenden.

Ein häufiger Fehler ist es, während der Migration lokale IP-Adressen zu entfernen, weil die Umstellung „fast abgeschlossen“ ist. Es reicht schon ein einziges Postfach, das weiterhin über den alten Pfad geleitet wird, um die Authentifizierung für die E-Mails dieses Benutzers zu unterbrechen.

Subdomains in Exchange: SPF wird nicht vererbt

Ein kritischer Punkt, an dem viele hybride Organisationen scheitern: Subdomains erben den SPF-Eintrag der übergeordneten Domain nicht. Wenn marketing.yourdomain.com E-Mails über einen separaten E-Mail-Dienstleister versendet, benötigt sie einen eigenen SPF-TXT-Eintrag. Wildcard-SPF-Einträge werden vom Protokoll nicht unterstützt. Jede Subdomain, die E-Mails versendet, muss einen eigenen v=spf1-Eintrag in ihrer DNS-Root-Zone veröffentlichen.

Das bedeutet auch, dass die Verwendung von Subdomains eine wirksame Strategie zur Verteilung der SPF-Last darstellt. Leiten Sie Marketing-E-Mails über marketing.yourdomain.com und Transaktions-E-Mails über mail.yourdomain.com weiter, sodass jede Subdomain ihr eigenes Budget von 10 Lookups erhält. Dies entspricht den RFC-Vorgaben, wird von E-Mail-Dienstanbietern gut unterstützt und ist in Unternehmensumgebungen weit verbreitet.

Überprüft Exchange Online die SPF-Einstellungen bei E-Mails innerhalb eines Mandanten?

Nein. Exchange Online behandelt mandanteninterne Nachrichten als interne E-Mails und führt keine SPF-Prüfung durch. Nachrichten zwischen verschiedenen Mandanten, selbst wenn es sich um vertrauenswürdige Partnerorganisationen handelt, unterliegen SPF-Prüfungen, da diese E-Mails den öffentlichen E-Mail-Routingpfad durchlaufen.

Für Organisationen mit mehreren Domänen in einem einzigen M365-Mandanten benötigt jede Domäne einen eigenen SPF-Eintrag. Die gemeinsame Nutzung eines Eintrags für mehrere Domänen über einen CNAME-Eintrag ist keine gängige Praxis und funktioniert nicht zuverlässig.

Häufige SPF-Fehler in Exchange und wie man sie behebt

Jedes der folgenden Szenarien zur Fehlerbehebung folgt dem gleichen diagnostischen Schema: Symptom → Ursache → Lösung.

PermError: Zu viele DNS-Abfragen

• • Symptom: SPF gibt „PermError“ zurück. Empfänger könnten Ihre E-Mail als Spam einstufen oder ablehnen. Die DMARC-Abgleichung schlägt fehl.
  • Ursache: Mehr als 10 DNS-Lookups in Ihrem SPF-Eintrag, einschließlich verschachtelter Einbindungen. Dies ist der häufigste Grund für SPF-Fehler in Unternehmen, die mehrere SaaS-Dienste nutzen.

• Lösung (5-Schritte-Ablauf):

• • Schritt 1: Überprüfen Sie Ihre aktuelle Anzahl an Lookups mit einem SPF-Checker, der verschachtelte Includes rekursiv zählt.
  • Schritt 2: Entfernen Sie veraltete Includes für Dienste, die Sie nicht mehr verwenden.
  • Schritt 3: Ersetzen Sie „include:“ durch „ip4:“, sofern die IP-Adressen des Anbieters stabil und dokumentiert sind.
  • Schritt 4: Verlegen Sie Absender mit hohem Versandvolumen, die nicht zu Ihrem Unternehmen gehören (Marketing, Transaktions-E-Mails), auf Subdomains mit eigenen SPF-Einträgen.
  • Schritt 5: Wenn Sie immer noch über 10 liegen, implementieren Sie SPF-Flattening oder Makros mit einem Tool wie PowerSPF, um Includes automatisch in IPv4-Einträge aufzulösen und den Eintrag auf dem neuesten Stand zu halten, wenn Anbieter ihre IP-Adressen ändern.

Vorher-Nachher-Beispiel:

Vorher (14 Abfragen: PermError):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com include:zendesk.com include:spf.freshdesk.com a mx -all

Nach (7 Abfragen: unterhalb des Grenzwerts):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net ip4:198.2.128.0/24 ip4:192.254.113.0/24 -all# Salesforce und Zendesk wurden zu mail.yourdomain.com# Freshdesk durch vereinfachte IPv4-Einträge ersetzt# a- und MX-Einträge entfernt (überflüssig durch explizite Einbindungen)

Es wurden mehrere SPF-Einträge gefunden

• Symptom: Der SPF-Checker gibt den Fehler „mehrere SPF-Einträge“ zurück. Die gesamte SPF-Prüfung schlägt fehl.
• Ursache: Für dieselbe Domain existieren zwei oder mehr TXT-Einträge, die mit „v=spf1“ beginnen. Dies geschieht häufig, wenn der Bereitstellungsprozess eines SaaS-Anbieters einen zweiten Eintrag erstellt, ohne dass der Administrator dies bemerkt.
• Korrektur: Führen Sie die Einträge zu einem einzigen Datensatz zusammen. Sie können innerhalb eines Datensatzes mehrere „include:“ und „ip4:“ Mechanismen verwenden, jedoch nur einen einzigen „v=spf1“ TXT-Datensatz pro Domain. Löschen Sie den überflüssigen Eintrag.

SPF funktioniert nach dem Hinzufügen eines neuen SaaS-Tools nicht mehr

• Symptom: E-Mails des neu hinzugefügten Tools bestehen den SPF-Test nicht. Auch bei anderen Absendern kann es zu Problemen kommen, wenn die Gesamtzahl der Lookups durch das neue Include 10 überschreitet.
• Ursache: Der neue Dienst wurde nicht zu SPF hinzugefügt, oder das Hinzufügen hat das Suchlimit überschritten.
• Lösung: Fügen Sie das Include hinzu und führen Sie anschließend eine erneute Überprüfung der gesamten Lookups durch. Wenn der Wert nun über 10 liegt, ist die Anzahl der Lookups das Problem, nicht das Include selbst. Wenden Sie den oben beschriebenen 5-Schritte-Workflow an.

SPF-Fehler bei Hybrid Exchange (lokale IP-Adresse fehlt)

• Symptom: E-Mails, die von einem lokalen Exchange-Server gesendet werden, scheitern am SPF, während E-Mails aus M365 den Test bestehen.
• Ursache: Die öffentlich zugängliche IP-Adresse des lokalen Servers ist nicht im SPF-Eintrag enthalten. Dies tritt besonders häufig nach einer teilweisen Migration auf, bei der der Administrator den SPF-Eintrag für Exchange Online aktualisiert hat, aber vergessen hat, dass der lokale Pfad weiterhin E-Mails weiterleitet.
• Lösung: Fügen Sie für jede lokale ausgehende IP-Adresse „ip4:x.x.x.x“ hinzu. Wenn E-Mails über einen Edge-Transport-Server, einen Smart Host oder einen Relay-Server eines Drittanbieters geleitet werden, muss auch die öffentliche IP-Adresse dieses Relay-Servers angegeben werden.

SPF funktioniert nach der Migration zu Exchange Online nicht mehr

• Symptom: E-Mails nach der Migration scheitern durchweg bei der SPF-Prüfung.
• Ursache: Das DNS verweist weiterhin auf alte lokale IP-Adressen, u. a.: spf.protection.outlook.com wurde nicht hinzugefügt, oder E-Mails werden während der Umstellung über unerwartete Pfade weitergeleitet.
• Behebung: Stellen Sie sicher, dass der SPF-Eintrag während des Migrationszeitraums sowohl den alten (On-Prem) als auch den neuen (Exchange Online) Autorisierungspfad enthält. Entfernen Sie alte Einträge erst, nachdem die Migration von 100 % der Postfächer bestätigt wurde. Überwachen Sie den Vorgang durchgehend mit DMARC-Gesamtberichten. Diese zeigen Ihnen genau, welche Pfade Ihre E-Mails aus Sicht der Empfänger nehmen.

SPF-Prüfung bestanden, aber E-Mail landet im Spam-Ordner

• Symptom: Die Kopfzeilen zeigen „spf=pass“ an, aber die Nachricht landet im Junk-Ordner des Empfängers.
• Ursache: SPF ist nur eines von vielen Signalen. Die Reputation des Absenders, der Inhalt, DKIM oder DMARC können fehlerhaft sein. Jeder dieser Faktoren kann einen einwandfreien SPF-Check außer Kraft setzen.
• Behebung: Überprüfen Sie die DKIM-Übereinstimmung, die DMARC-Richtlinie, die Absender-Reputation (Blacklist-Status, Domain-Alter, aktuelle Volumenänderungen) sowie die Reputation von Inhalten und Links. Der Domain Analyzer von PowerDMARC liefert in einem einzigen Scan eine Bewertung für all diese Aspekte.

SPF-Fehler bei weitergeleiteten E-Mails

• Symptom: Automatisch weitergeleitete Nachrichten, E-Mails aus Mailinglisten oder durch Transportregeln weitergeleitete Nachrichten bestehen den SPF-Test nicht.
• Ursache: Die IP-Adresse des Weiterleitungsservers ist nicht im SPF-Eintrag des ursprünglichen Absenders enthalten. Dies ist eine architektonische Einschränkung von SPF und kein Konfigurationsfehler.
• Behebung: Behandeln Sie einen SPF-Fehler bei weitergeleiteten E-Mails als erwartetes Verhalten. Stellen Sie sicher, dass DKIM für Ihre Domäne ordnungsgemäß konfiguriert ist. DKIM-Signaturen bleiben bei der Weiterleitung erhalten, wodurch DMARC auch bei einem SPF-Fehler über die DKIM-Ausrichtung bestehen kann. ARC (Authenticated Received Chain) in Exchange Online bewahrt die Authentifizierungsergebnisse über vertrauenswürdige Weiterleitungsketten hinweg zusätzlich.

Wie Exchange Online SPF-Ergebnisse tatsächlich verarbeitet (Die Black Box erklärt)

Die meisten Exchange-Administratoren stehen vor derselben Frage: Wie geht Exchange Online Protection (EOP) eigentlich mit SPF-Fehlern um? Einige Quellen behaupten, dass ein „Hard Fail“ eine automatische Ablehnung zur Folge hat. Andere meinen, SPF sei nur ein untergeordnetes Spam-Signal. Hier erfahren Sie, wie es tatsächlich funktioniert.

Die Multi-Signal-Pipeline (SPF ist nur ein Eingang)

Exchange Online Protection trifft Entscheidungen über die Zustellung nicht allein auf der Grundlage von SPF. SPF ist nur einer von mehreren Faktoren bei einer umfassenden Authentifizierungsprüfung, die Folgendes umfasst:

• SPF-Ergebnis: bestanden, nicht bestanden, Soft-Fail, neutral, PermError oder TempError
• DKIM-Ergebnis: bestanden, nicht bestanden oder keine
• DMARC-Ergebnis: abgeleitet aus dem Abgleich von SPF oder DKIM mit der „From“-Domain im Header
• Absender-Reputation: IP-Reputation, Domain-Reputation, historische Versandmuster
• Spam Confidence Level (SCL)-Bewertung: Microsofts interne Bewertung von -1 (vertrauenswürdiger Absender) bis 9 (Spam mit hoher Wahrscheinlichkeit)
• Inhaltsfilterung: Schlüsselwörter, URL-Reputation, Analyse von Anhängen

EOP stützt sich bei der endgültigen Entscheidung über die Weiterverarbeitung einer Nachricht auf das Gesamtergebnis der Authentifizierung und nicht auf ein einzelnes Protokoll.

Wie EOP mit den einzelnen SPF-Ergebnissen umgeht

„PermError“ ist ein schwerwiegender Fehler, den EOP fast genauso behandelt wie einen direkten SPF-Fehler, und der sich auf DMARC auswirkt, wodurch die Authentifizierung vollständig unterbrochen wird. Aus diesem Grund stellt die Begrenzung auf 10 Abfragen einen strukturellen Schwachpunkt dar.

Wo man die SPF-Ergebnisse in Exchange einsehen kann

Drei Orte, in aufsteigender Reihenfolge nach Vollständigkeit:

• Nachrichten-Header (Authentication-Results): Jede von EOP verarbeitete Nachricht wird mit spf=pass/fail/softfail/permerror/temperror sowie der ausgewerteten Absenderdomain und IP-Adresse versehen.
• Exchange-Nachverfolgung: Zeigt den Zustellstatus, die Quell-IP, den Empfänger und den endgültigen Verbleib an, stellt die SPF-Bewertung jedoch nicht deutlich dar. Wenn Sie sich für die SPF-Transparenz allein auf die Nachrichtenverfolgung verlassen, agieren Sie im Blindflug.
• DMARC-Gesamtberichte (RUA): Die einzige Datenquelle, die zeigt, wie Empfänger weltweit Ihr SPF bewerten. RUA-Berichte zeigen die SPF-Erfolgs- und Fehlerquoten pro IP-Adresse und pro Quelle für jeden Empfangsserver an, der Ihre E-Mails verarbeitet.

Konfigurieren der Durchsetzung von „SPF Hard Fail“ in EOP

Standardmäßig berücksichtigt Exchange Online die SPF-Ergebnisse bei der Gesamtbewertung, lehnt E-Mails jedoch nicht allein aufgrund des SPF-Ergebnisses ab. Um EOP explizit so zu konfigurieren, dass SPF-Hard-Fail-Nachrichten als Spam zu kennzeichnen:

Gehen Sie im Exchange Online-Verwaltungscenter zu „Schutz“ → „Spamfilter“ → „Erweiterte Optionen“ und schalten Sie den Schalter „SPF-Eintrag: Hard Fail“ auf „Ein“. Alternativ können Sie das folgende PowerShell-Cmdlet ausführen:

Get-HostedContentFilterPolicy | Where-Object {$_.IsDefault -eq $true} | Set-HostedContentFilterPolicy -MarkAsSpamSpfRecordHardFail On

Bewährte Verfahren für SPF in Exchange-Umgebungen im Jahr 2026

• Verwenden Sie „-all“ (Hard Fail) als Standard-Qualifizierer. In Kombination mit DMARC ist „-all“ der Standard. Die einzige Ausnahme bildet die anfängliche Einführungsphase, bevor DMARC eingerichtet ist.
• Verwenden Sie niemals „+all“. Damit gestatten Sie dem gesamten Internet, E-Mails im Namen Ihrer Domain zu versenden. Sollten Sie „+all“ in Ihrem Eintrag finden, behandeln Sie dies als aktuellen Sicherheitsvorfall.
• Fügen Sie für M365 immer spf.protection.outlook.com hinzu, auch wenn ausgehende E-Mails über ein Gateway eines Drittanbieters geleitet werden. Exchange Online generiert Kalendereinladungen, automatische Antworten, NDRs und Lesebestätigungen, die direkt über die Infrastruktur von Microsoft versendet werden.
• Überprüfen Sie Ihren SPF-Eintrag mindestens vierteljährlich. SaaS-Anbieter ändern ihre IP-Bereiche. Marketingteams führen neue Tools ein, ohne die IT-Abteilung darüber zu informieren. Durch vierteljährliche Überprüfungen lassen sich Abweichungen erkennen, bevor sie zu einem PermError führen. Eine kontinuierliche Überwachung mittels DMARC-Berichten erkennt Abweichungen in Echtzeit.
• Setzen Sie SPF zusammen mit DKIM und DMARC ein. SPF allein verhindert kein „Header-From“-Spoofing. DKIM allein überprüft nicht die Echtheit des Absenders im Envelope-Header. Nur die Durchsetzung von DMARC, bei der die Übereinstimmung von SPF oder DKIM mit der „From“-Domain im Header überprüft wird, bietet umfassenden Schutz.
• Erfüllen Sie die Absendervorgaben aller großen E-Mail-Anbieter. Ab 2026 verlangen Google, Yahoo, Microsoft und Apple von Massenversendern die Verwendung von SPF, DKIM und DMARC. PCI DSS v4.0, das seit März 2025 verbindlich ist, schreibt alle drei Maßnahmen ausdrücklich als Anti-Phishing-Kontrollen vor.

So überwachen Sie den SPF kontinuierlich 

Der größte Unterschied zwischen Organisationen, bei denen „SPF eingerichtet“ ist, und solchen, die tatsächlich durch SPF geschützt sind, liegt in der Überwachung. Die einmalige Konfiguration ist der einfache Teil, doch erst die Erkennung stiller Fehler in den folgenden Monaten unterscheidet eine funktionierende E-Mail-Authentifizierung von einer rein theoretischen.

Warum einmalige SPF-Prüfungen ein falsches Gefühl der Sicherheit vermitteln

SPF-Einträge ändern sich ständig, da Anbieter ihre autorisierten IP-Bereiche ändern, Ihre „include“-Ketten auf unterschiedliche IP-Adressen verweisen und eine davon möglicherweise dazu führt, dass Sie das Suchlimit überschreiten. Teams fügen neue SaaS-Tools hinzu, ohne die SPF-Einträge zu aktualisieren. Bei Migrationen ändert sich das Routing ausgehender E-Mails auf eine Weise, die sich nicht in Ihrem DNS widerspiegelt. Alte Einträge für Dienste, die das Unternehmen schon vor Jahren nicht mehr nutzt, bleiben bestehen.

So sieht die kontinuierliche SPF-Überwachung aus

Vier Komponenten, von denen jede einen bestimmten Fehlerfall abdeckt:

• Täglich werden aggregierte DMARC-Berichte von Empfängern weltweit erfasst. Diese zeigen die SPF-Ergebnisse pro IP-Adresse und pro Quelle für jeden Empfangsserver, der Ihre E-Mails verarbeitet hat. PowerDMARC erfasst diese automatisch und stellt sie in einem speziellen SPF-Analyse-Dashboard dar, das Pass-/Fail-Raten nach Quelle, die Anzahl der DNS-Abfragen sowie historische Trendlinien enthält.
• Automatische Benachrichtigungen, sobald SPF-Fehler einen Schwellenwert überschreiten, eine neue, nicht autorisierte Absenderquelle auftritt oder eine DNS-Änderung sich auf Ihren Eintrag auswirkt. Die PowerAlerts von PowerDMARC leiten diese per E-Mail, Slack oder Discord weiter, damit das zuständige Team das Problem während der Geschäftszeiten erkennt.
• Automatische SPF-Flattening , das aktualisiert wird, wenn Drittanbieter ihre IP-Adressen ändern. PowerSPF löst „include:“-Ketten in IPv4-Einträge auf und hält Ihren Eintrag dauerhaft unter 10 Lookups, ohne dass manuelle DNS-Änderungen erforderlich sind.
• Überwachung von Blacklists und Reputation. Wenn Ihre Absender-IPs auf einer Sperrliste landen, wird SPF zwar möglicherweise bestanden, die Zustellbarkeit verschlechtert sich jedoch trotzdem. Die integrierte Reputationsüberwachung erkennt Fehlerfälle, die SPF allein nicht erkennt.

Speziell für MSPs: Wenn der Anbieter eines Kunden seinen IP-Bereich ändert, erfahren Sie davon, noch bevor die E-Mail-Funktionen des Kunden ausfallen. 

Das MSP-Dashboard von PowerDMARC ermöglicht die zentrale SPF-Überwachung aller Kundendomänen auf einem einzigen Bildschirm und bietet die Möglichkeit, die Daten nach Mandanten aufzuschlüsseln. Dadurch wird die SPF-Verwaltung von reaktivem „Feuerlöschen“ zu einem produktisierten Dienstleistungsangebot.

Starten Sie eine 15-tägige kostenlose Testphase, um es selbst auszuprobieren. 

Häufig gestellte Fragen

Wie überprüfe ich SPF-Einträge in Exchange Online?

Verwenden Sie ein SPF-Abfrage-Tool wie den PowerDMARC SPF Checker, geben Sie Ihre Domain ein und überprüfen Sie den Eintrag, die Syntax und die Anzahl der Abfragen. Sie können dies auch im Microsoft 365 Admin Center unter „Einstellungen“ → „Domains“ → „DNS-Einträge“ überprüfen. Zur Überprüfung auf Empfängerseite überprüfen Sie den Header „Authentication-Results“ in einer extern versendeten Testnachricht.

Welchen SPF-Eintrag benötige ich für Microsoft 365?

Mindestens: v=spf1 include:spf.protection.outlook.com -all. Wenn Sie weitere Versanddienste nutzen (HubSpot, SendGrid, Salesforce, Zendesk), fügen Sie deren Einträge vor -all hinzu. Stellen Sie sicher, dass die Gesamtzahl der DNS-Lookups unter 10 bleibt, einschließlich verschachtelter Lookups innerhalb jedes Eintrags.

Warum schlägt SPF fehl, obwohl mein Eintrag korrekt aussieht?

Häufige Ursachen: Überschreitung des Limits von 10 DNS-Abfragen (PermError), mehrere SPF-Einträge für dieselbe Domain, weitergeleitete E-Mails (SPF funktioniert bei Weiterleitung grundsätzlich nicht) oder ein Anbieter, der seine autorisierten IP-Bereiche ändert, ohne Sie darüber zu informieren. Überprüfen Sie den „Authentication-Results“-Header auf das konkrete „spf=“-Ergebnis.

Was ist der Unterschied zwischen -all und ~all?

-all (Hard Fail) weist Empfänger an, Nachrichten von nicht autorisierten IP-Adressen zurückzuweisen oder als Fehler zu behandeln. ~all (Soft Fail) ist weniger streng. Ab 2026, wenn DMARC eingeführt ist, regelt die DMARC-Richtlinie die Durchsetzung unabhängig vom Qualifizierer. Wenn Sie noch kein DMARC nutzen, bietet -all einen deutlich stärkeren Schutz.

Wie viele DNS-Abfragen führt die Domain „include:spf.protection.outlook.com“ durch?

Der Microsoft-Include zählt als ein Abruf, führt jedoch zu verschachtelten Includes, die etwa zwei bis vier zusätzliche Abrufe erfordern. Die genaue Anzahl variiert, da Microsoft seine Infrastruktur aktualisiert. Überprüfen Sie dies stets mit einem Tool, das verschachtelte Abrufe rekursiv zählt.

Reicht SPF aus, um E-Mail-Spoofing zu verhindern?

Nein. SPF allein verhindert keine Fälschung der sichtbaren Absenderadresse (Header „From“). Es überprüft lediglich den Absender des Umschlags (Return-Path). Ein umfassender Schutz erfordert DKIM zur Signierung auf Nachrichtenebene sowie DMARC zur Durchsetzung der Übereinstimmung. Das Zusammenspiel aller drei Protokolle und deren kontinuierliche Überwachung ist im Jahr 2026 der Standard.