Freigeben über

Einrichten von SPF zum Identifizieren gültiger E-Mail-Quellen für Ihre Microsoft 365-Domäne

Tipp

Wussten Sie, dass Sie die Features in Microsoft Defender XDR für Office 365 Plan 2 kostenlos testen können? Verwenden Sie die 90-tägige Defender for Office 365 Testversion auf dem Microsoft Defender Portal-Testversionshub. Informationen dazu, wer sich registrieren und testen kann, finden Sie unter Try Microsoft Defender for Office 365.

Sender Policy Framework (SPF) ist eine Methode der E-Mail-Authentifizierung, mit der E-Mails überprüft werden können, die von Ihrem Microsoft 365-organization gesendet wurden, um gefälschte Absender zu verhindern, die bei der Kompromittierung von Geschäfts-E-Mails (BEC), Ransomware und anderen Phishingangriffen verwendet werden.

Der Hauptzweck von SPF besteht darin, E-Mail-Quellen für eine Domäne zu überprüfen. SPF verwendet insbesondere einen TXT-Eintrag im DNS, um gültige E-Mail-Quellen für die Domäne zu identifizieren. Empfangende E-Mail-Systeme verwenden den SPF TXT-Eintrag, um zu überprüfen, ob die E-Mail von der Absenderadresse, die während der SMTP-Übertragung der Nachricht verwendet wurde (als MAIL FROM-Adresse, 5321.MailFrom Adresse, P1-Absender oder Umschlagsender bezeichnet) von einer bekannten, angegebenen E-Mail-Quelle für diese Domäne stammt.

Wenn Ihre E-Mail-Domäne in Microsoft 365 beispielsweise contoso.com ist, erstellen Sie einen SPF TXT-Eintrag in DNS für die contoso.com Domäne, um Microsoft 365 als autorisierte E-Mail-Quelle aus contoso.com zu identifizieren. Ziel-E-Mail-Systeme überprüfen den SPF TXT-Eintrag in contoso.com, um festzustellen, ob die Nachricht von einer autorisierten Quelle für contoso.com E-Mail stammt.

Bevor wir beginnen, müssen Sie folgendes über SPF in Microsoft 365 wissen, basierend auf Ihrer E-Mail-Domäne:

  • Wenn Sie nur die MoERA-Domäne (Microsoft Online Email Routing Address) für E-Mails (z. B. contoso.onmicrosoft.com) verwenden: Sie müssen nichts tun. Der SPF TXT-Eintrag ist bereits für Sie konfiguriert. Microsoft besitzt die onmicrosoft.com Domäne. Daher sind wir für das Erstellen und Verwalten der DNS-Einträge in dieser Domäne und Unterdomänen verantwortlich. Weitere Informationen zu *.onmicrosoft.com Domänen finden Sie unter Warum habe ich eine "onmicrosoft.com"-Domäne?.

  • Wenn Sie eine oder mehrere benutzerdefinierte Domänen für E-Mails verwenden (z. B. contoso.com): Für den Microsoft 365-Registrierungsprozess mussten Sie bereits den SPF TXT-Eintrag in DNS für Ihre benutzerdefinierte Domäne erstellen oder ändern, um Microsoft 365 als autorisierte E-Mail-Quelle zu identifizieren. Für den maximalen E-Mail-Schutz müssen Sie jedoch noch mehr Arbeit erledigen:

    • Überlegungen zu Unterdomänen:

      • Für E-Mail-Dienste, die sich nicht unter Ihrer direkten Kontrolle befinden (z. B. Massen-E-Mail-Dienste), empfehlen wir die Verwendung einer Unterdomäne (z. B. marketing.contoso.com) anstelle Ihrer Standard E-Mail-Domäne (z. B. contoso.com). Sie möchten nicht, dass Probleme mit E-Mails, die von diesen E-Mail-Diensten gesendet werden, die Reputation von E-Mails beeinträchtigen, die von Mitarbeitern in Ihrer Standard E-Mail-Domäne gesendet werden. Weitere Informationen zum Hinzufügen von Unterdomänen finden Sie unter Kann ich Benutzerdefinierte Unterdomänen oder mehrere Domänen zu Microsoft 365 hinzufügen?.

      • Jede Unterdomäne, die Sie zum Senden von E-Mails von Microsoft 365 verwenden, erfordert einen eigenen SPF TXT-Eintrag. Beispielsweise deckt der SPF TXT-Eintrag für contoso.com nicht marketing.contoso.com ab. marketing.contoso.com benötigt einen eigenen SPF TXT-Eintrag.

        Tipp

        Email Authentifizierungsschutz für nicht definierte Unterdomänen wird durch DMARC abgedeckt. Alle Unterdomänen (definiert oder nicht) erben die DMARC-Einstellungen der übergeordneten Domäne (die pro Unterdomäne überschrieben werden kann). Weitere Informationen finden Sie unter Einrichten von DMARC zum Überprüfen der Absenderdomäne für Absender in Microsoft 365.

    • Wenn Sie registrierte, aber nicht verwendete Domänen besitzen: Wenn Sie registrierte Domänen besitzen, die nicht für E-Mails oder überhaupt verwendet werden (auch als geparkte Domänen bezeichnet), konfigurieren Sie SPF TXT-Einträge, um anzugeben, dass keine E-Mail von diesen Domänen stammen darf, wie weiter unten in diesem Artikel beschrieben.

  • SPF allein reicht nicht aus. Um den besten E-Mail-Schutz für Ihre benutzerdefinierten Domänen zu erzielen, müssen Sie auch DKIM und DMARC als Teil Ihrer allgemeinen E-Mail-Authentifizierungsstrategie konfigurieren. Weitere Informationen finden Sie im Abschnitt Nächste Schritte am Ende dieses Artikels.

    Wichtig

    In komplexen Organisationen, in denen es schwierig ist, alle gültigen E-Mail-Quellen für die Domäne zu identifizieren, ist es wichtig, dass Sie dkim signieren und DMARC (im Modus "Keine Aktion ausführen") schnell für die Domäne konfigurieren. Ein DMARC-Berichtsdienst ist sehr hilfreich, um E-Mail-Quellen und SPF-Fehler für die Domäne zu identifizieren.

Im weiteren Verlauf dieses Artikels werden die SPF TXT-Einträge beschrieben, die Sie für benutzerdefinierte Domänen in Microsoft 365 erstellen müssen.

Tipp

Es gibt keine Verwaltungsportale oder PowerShell-Cmdlets in Microsoft 365, über die Sie SPF-Einträge in Ihrer Domäne verwalten können. Stattdessen erstellen Sie den SPF TXT-Eintrag bei Ihrer Domänenregistrierungsstelle oder ihrem DNS-Hostingdienst (oft dasselbe Unternehmen).

Wir bieten Anweisungen zum Erstellen des TXT-Eintrags für den Nachweis des Domänenbesitzes für Microsoft 365 bei vielen Domänenregistrierungsstellen. Sie können diese Anweisungen als Ausgangspunkt verwenden, um den SPF TXT-Eintragswert zu erstellen. Weitere Informationen finden Sie unter Hinzufügen von DNS-Einträgen zum Herstellen einer Verbindung mit Ihrer Domäne.

Wenn Sie mit der DNS-Konfiguration nicht vertraut sind, wenden Sie sich an Ihre Domänenregistrierungsstelle, und bitten Sie um Hilfe.

Syntax für SPF TXT-Einträge

SPF TXT-Einträge werden in RFC 7208 vollständig beschrieben.

Die grundlegende Syntax des SPF TX-Eintrags für eine benutzerdefinierte Domäne in Microsoft 365 lautet:

v=spf1 <valid mail sources> <enforcement rule>

oder -

v=spf1 [<ip4>|<ip6>:<PublicIPAddress1> <ip4>|<ip6>:<PublicIPAddress2>... <ip4>|<ip6>:<PublicIPAddressN>] [include:<DomainName1> include:<DomainName1>... include:<DomainNameN>] <-all | ~all>

Zum Beispiel:

v=spf1 ip4:192.168.0.10 ip4:192.168.0.12 include:spf.protection.outlook.com -all

  • v=spf1 identifiziert den TXT-Eintrag als SPF TXT-Eintrag.

  • Gültige E-Mail-Quellen: Gültige E-Mail-Quellen für die Domäne angegeben. Verwendet Domänen, IP-Adressen oder beides:

    • Domänen: include: Werte geben andere Dienste oder Domänen als gültige E-Mail-Quellen aus der ursprünglichen Domäne an. Diese Werte führen letztendlich mithilfe von DNS-Lookups zu einer IP-Adresse.

      Die meisten Microsoft 365-Organisationen benötigen include:spf.protection.outlook.com im SPF TXT-Eintrag für die Domäne. Andere E-Mail-Dienste von Drittanbietern erfordern häufig einen zusätzlichen include: Wert, um den Dienst als gültige E-Mail-Quelle aus der ursprünglichen Domäne zu identifizieren.

    • IP-Adressen: Ein IP-Adresswert enthält die beiden folgenden Elemente:

      • Der Wert ip4: oder ip6: , um den Typ der IP-Adresse zu identifizieren.
      • Die öffentlich auflösbare IP-Adresse des Quell-E-Mail-Systems. Zum Beispiel:
        • Eine einzelne IP-Adresse (z. B. 192.168.0.10).
        • Ein IP-Adressbereich mit CIDR-Notation (Classless Inter-Domain Routing) (z. B. 192.168.0.1/26). Stellen Sie sicher, dass der Bereich nicht zu groß oder zu klein ist.

      In Microsoft 365 verwenden Sie ip-Adressen in der Regel nur dann im SPF TXT-Eintrag, wenn Sie über lokale E-Mail-Server verfügen, die E-Mails aus der Microsoft 365-Domäne senden (z. B. Exchange Server Hybridbereitstellungen). Einige E-Mail-Dienste von Drittanbietern verwenden möglicherweise auch einen IP-Adressbereich anstelle eines include: Werts im SPF TXT-Eintrag.

  • Erzwingungsregel: Teilt Ziel-E-Mail-Systemen mit, was mit Nachrichten aus Quellen zu tun ist, die nicht im SPF TXT-Eintrag für die Domäne angegeben sind. Gültige Werte sind:

    • -all (Harter Fehler): Quellen, die nicht im SPF TXT-Eintrag angegeben sind, sind nicht zum Senden von E-Mails für die Domäne autorisiert, sodass die Nachrichten abgelehnt werden sollten. Was mit der Nachricht tatsächlich geschieht, hängt vom Ziel-E-Mail-System ab, aber die Nachrichten werden in der Regel verworfen.

      Für Microsoft 365-Domänen empfehlen -all wir (hard fail), da wir auch DKIM und DMARC für die Domäne empfehlen. Die DMARC-Richtlinie gibt an, was mit Nachrichten zu tun ist, bei denen SPF oder DKIM fehlschlägt, und DMARC-Berichte ermöglichen es Ihnen, die Ergebnisse zu überprüfen.

      Tipp

      Wie bereits erwähnt, hilft DMARC, die mit einem DMARC-Berichtsdienst konfiguriert wurde, erheblich bei der Identifizierung von E-Mail-Quellen und SPF-Fehlern für die Domäne.

    • ~all (weicher Fehler): Quellen, die nicht im SPF TXT-Eintrag angegeben sind, sind wahrscheinlich nicht zum Senden von E-Mails für die Domäne autorisiert, daher sollten die Nachrichten akzeptiert, aber markiert werden. Was mit der Nachricht tatsächlich geschieht, hängt vom Ziel-E-Mail-System ab. Beispielsweise kann die Nachricht als Spam unter Quarantäne gestellt, an den Ordner Junk Email übermittelt oder an den Posteingang übermittelt werden, wobei dem Betreff oder nachrichtentext ein Bezeichner hinzugefügt wurde.

      Da wir auch DKIM und DMARC für Microsoft 365-Domänen empfehlen, werden die Unterschiede zwischen -all (hard fail) und ~all (soft fail) effektiv beseitigt (DMARC behandelt beide Ergebnisse als SPF-Fehler). DMARC verwendet SPF, um zu bestätigen, dass die Domänen in den ADRESSEN MAIL FROM und From ausgerichtet sind und die Nachricht von einer gültigen Quelle für die From-Domäne stammt.

    Tipp

    ?all (neutral) ist auch verfügbar, um keine spezifische Aktion für Nachrichten aus nicht identifizierten Quellen vorzuschlagen. Dieser Wert wird für Tests verwendet, und dieser Wert wird in Produktionsumgebungen nicht empfohlen.

Wichtige Punkte, die Sie beachten sollten:

  • Jede definierte Domäne oder Unterdomäne in DNS erfordert einen SPF TXT-Eintrag, und pro Domäne oder Unterdomäne ist nur ein SPF-Eintrag zulässig. Email Authentifizierungsschutz für nicht definierte Unterdomänen wird am besten von DMARC behandelt.
  • Sie können den vorhandenen SPF TXT-Eintrag für die Domäne *.onmicrosoft.com nicht ändern.
  • Wenn das Ziel-E-Mail-System die gültigen E-Mail-Quellen im SPF-Eintrag überprüft, schlägt die SPF-Überprüfung fehl, wenn die Überprüfung zu viele DNS-Lookups erfordert. Weitere Informationen finden Sie weiter unten in diesem Artikel im Abschnitt Problembehandlung bei SPF TXT-Einträgen .

SPF TXT-Einträge für benutzerdefinierte Domänen in Microsoft 365

Tipp

Wie bereits in diesem Artikel erwähnt, erstellen Sie den SPF TXT-Eintrag für eine Domäne oder Unterdomäne bei der Domänenregistrierungsstelle für die Domäne. In Microsoft 365 ist keine SPF TXT-Eintragskonfiguration verfügbar.

  • Szenario: Sie verwenden contoso.com für E-Mails in Microsoft 365, und Microsoft 365 ist die einzige E-Mail-Quelle von contoso.com.

    SPF TXT-Eintrag für contoso.com in Microsoft 365 und Microsoft 365 Government Community Cloud (GCC):

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

    SPF TXT-Eintrag für contoso.com in Microsoft 365 Government Community Cloud High (GCC High) und Microsoft 365 Department of Defense (DoD):

    v=spf1 include:spf.protection.office365.us -all

    SPF TXT-Eintrag für contoso.com in Microsoft 365, betrieben von 21Vianet

    v=spf1 include:spf.protection.partner.outlook.cn -all

  • Szenario: Sie verwenden contoso.com für E-Mail in Microsoft 365 und haben den SPF TXT-Eintrag bereits in contoso.com mit allen E-Mail-Quellen aus der Domäne konfiguriert. Sie besitzen auch die Domänen contoso.net und contoso.org, verwenden sie jedoch nicht für E-Mails. Sie möchten angeben, dass niemand berechtigt ist, E-Mails von contoso.net oder contoso.org zu senden.

    SPF TXT-Eintrag für contoso.net:

    v=spf1 -all

    SPF TXT-Eintrag für contoso.org:

    v=spf1 -all

  • Szenario: Sie verwenden contoso.com für E-Mails in Microsoft 365. Sie planen das Senden von E-Mails aus den folgenden Quellen:

    • Ein lokaler E-Mail-Server mit der externen E-Mail-Adresse 192.168.0.10. Da Sie die direkte Kontrolle über diese E-Mail-Quelle haben, halten wir es für IN ORDNUNG, den Server für Absender in der contoso.com Domäne zu verwenden.
    • Der Adatum-Massenversanddienst. Da Sie keine direkte Kontrolle über diese E-Mail-Quelle haben, empfehlen wir die Verwendung einer Unterdomäne, damit Sie zu diesem Zweck marketing.contoso.com erstellen. Gemäß der Dokumentation des Adatum-Diensts müssen Sie dem SPF TXT-Eintrag für Ihre Domäne hinzufügen include:servers.adatum.com .

    SPF TXT-Eintrag für contoso.com:

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

    SPF TXT-Eintrag für marketing.contoso.com:

    v=spf1 include:servers.adatum.com include:spf.protection.outlook.com -all

Problembehandlung bei SPF TXT-Einträgen

  • Ein SPF-Eintrag pro Domäne oder Unterdomäne: Mehrere SPF TXT-Einträge für dieselbe Domäne oder Unterdomäne verursachen eine DNS-Lookupschleife, die SPF fehlschlägt. Verwenden Sie daher nur einen SPF-Eintrag pro Domäne oder Unterdomäne.

  • Weniger als 10 DNS-Lookups: Wenn Ziel-E-Mail-Systeme den SPF TXT-Eintrag nach gültigen Quellen für die MAIL FROM-Adressdomäne abfragen, durchsucht die Abfrage die IP-Adressen und include: Anweisungen im Datensatz, bis die Nachrichtenquelle (letztlich eine IP-Adresse) mit einer der angegebenen Quellen übereinstimmt. Wenn die Anzahl der DNS-Lookups (die sich von der Anzahl der DNS-Abfragen unterscheiden kann) größer als 10 ist, schlägt die Meldung SPF mit einem dauerhaften Fehler (auch bekannt als ) permerrorfehl. Das Ziel-E-Mail-System lehnt die Nachricht in einem Nichtzustellbarkeitsbericht (auch als NDR oder Unzustellbarkeitsnachricht bezeichnet) mit einem der folgenden Fehler ab:

    • Die Nachricht hat die Hop-Anzahl überschritten.
    • Die Nachricht hat zu viele Suchvorgänge benötigt.

    Im SPF TXT-Eintrag verursachen einzelne IP-Adressen oder IP-Adressbereiche keine DNS-Lookups. Jede include: Anweisung erfordert mindestens eine DNS-Suche, und es sind möglicherweise weitere Nachschlagevorgänge erforderlich, wenn der include: Wert auf geschachtelte Ressourcen verweist. Anders ausgedrückt: Weniger als 10 include: Anweisungen garantieren nicht weniger als 10 DNS-Lookups.

    Beachten Sie auch: Ziel-E-Mail-Systeme werten die Quellen im SPF TXT-Eintrag von links nach rechts aus. Die Auswertung wird beendet, wenn die Nachrichtenquelle überprüft wird, und es werden keine quellen mehr überprüft. Daher kann ein SPF TXT-Eintrag genügend Informationen enthalten, um mehr als 10 DNS-Lookups zu verursachen, aber die Überprüfung einiger E-Mail-Quellen durch einige Ziele geht nicht tief genug in den Datensatz ein, um zu einem Fehler zu führen.

    Zusätzlich zum Erhalt des Rufs Ihrer Standard E-Mail-Domäne ist die Nichtüberschreitung der Anzahl von DNS-Lookups ein weiterer Grund, Unterdomänen für andere E-Mail-Dienste zu verwenden, die Sie nicht kontrollieren.

Sie können kostenlose Onlinetools verwenden, um Ihren SPF TXT-Eintrag und andere DNS-Einträge für Ihre Domäne anzuzeigen. Einige Tools berechnen sogar die Anzahl der DNS-Eintragssuche, die Ihr SPF TXT-Eintrag erfordert.

Nächste Schritte

Wie unter Zusammenarbeit von SPF, DKIM und DMARC zur Authentifizierung von Absendern von E-Mail-Nachrichten beschrieben, reicht SPF allein nicht aus, um Spoofing Ihrer Microsoft 365-Domäne zu verhindern. Außerdem müssen Sie DKIM und DMARC konfigurieren, um den bestmöglichen Schutz zu gewährleisten. Weitere Anweisungen finden Sie in:

Für E-Mails, die an Microsoft 365 gesendet werden, müssen Sie möglicherweise auch vertrauenswürdige ARC-Versiegelungen konfigurieren, wenn Sie Dienste verwenden, die Nachrichten während der Übertragung ändern, bevor sie an Ihre organization übermittelt werden. Weitere Informationen finden Sie unter Konfigurieren vertrauenswürdiger ARC-Versiegelungen.