E-Mail-Authentifizierung in Microsoft 365

Als Microsoft 365-organization mit Postfächern in Exchange Online oder als eigenständiges Exchange Online Protection (EOP) organization ohne Exchange Online Postfächer, schützen Sie die Integrität von E-Mail-Nachrichten von Absendern in Ihrer -Domänen sind wichtig. Empfänger sollten sicher sein, dass Nachrichten von Absendern in Ihrer Domäne wirklich von Absendern in Ihrer Domäne stammen.

Email-Authentifizierung (auch als E-Mail-Überprüfung bezeichnet) ist eine Gruppe von Standards, um die Zustellung von E-Mail-Nachrichten von gefälschten Absendern (auch als Spoofing bezeichnet) zu identifizieren und zu verhindern. Spoofed Sender werden häufig bei Bec (Business Email Compromise), Phishing und anderen E-Mail-Angriffen verwendet. Diese Standards umfassen:

• Sender Policy Framework (SPF):Gibt die E-Mail-Quellserver an, die zum Senden von E-Mails für die Domäne autorisiert sind.
• DomainKeys Identified Mail (DKIM): Verwendet eine Domäne, um wichtige Elemente der Nachricht digital zu signieren, um sicherzustellen, dass die Nachricht während der Übertragung nicht geändert wurde.
• Domänenbasierte Nachrichtenauthentifizierung, Berichterstellung und Konformität (DMARC): Gibt die Aktion für Nachrichten an, bei denen SPF- oder DKIM-Überprüfungen für Absender in der Domäne fehlschlagen, und gibt an, wohin die DMARC-Ergebnisse gesendet werden sollen (Berichterstellung).
• Authentifizierte empfangene Kette (Authenticated Received Chain, ARC): Behält die ursprünglichen E-Mail-Authentifizierungsinformationen bekannter Dienste bei, die Nachrichten während der Übertragung ändern. Der Ziel-E-Mail-Server kann diese Informationen verwenden, um Nachrichten zu authentifizieren, die andernfalls dmarc fehlschlagen würden.

Es ist wichtig zu wissen, dass diese Standards voneinander abhängige Bausteine sind, die zusammenarbeiten , um den bestmöglichen E-Mail-Schutz vor Spoofing- und Phishingangriffen zu bieten. Alles, was kleiner als alle E-Mail-Authentifizierungsmethoden ist, führt zu einem minderwertigen Schutz.

Informationen zum Konfigurieren der E-Mail-Authentifizierung für E-Mails, die von Microsoft 365-Organisationen mit Postfächern in Exchange Online oder eigenständigen Exchange Online Protection EOP-Organisationen ohne Exchange Online Postfächer gesendet werden, finden Sie in den folgenden Artikeln:

• Einrichten von SPF zum Verhindern von Spoofing
• Verwenden von DKIM zum Überprüfen ausgehender E-Mails, die von Ihrer benutzerdefinierten Domäne gesendet werden
• Verwenden von DMARC zum Überprüfen von E-Mails

Informationen zum Verhindern von E-Mail-Authentifizierungsfehlern aufgrund von Diensten, die eingehende E-Mails ändern, die an Ihre Microsoft 365-organization gesendet werden, finden Sie unter Konfigurieren vertrauenswürdiger ARC-Versiegelungen.

Im weiteren Verlauf dieses Artikels wird Folgendes erläutert:

• Warum Internet-E-Mails eine Authentifizierung benötigen
• Zusammenarbeit von SPF, DKIM und DMARC zum Authentifizieren von Absendern von E-Mail-Nachrichten
• Wie Microsoft die E-Mail-Authentifizierung verwendet, um eingehende E-Mails zu überprüfen, die an Microsoft 365 gesendet wurden
• Vermeiden von E-Mail-Authentifizierungsfehlern beim Senden von E-Mails an Microsoft 365

Warum Internet-E-Mails eine Authentifizierung benötigen

Standardmäßig macht SMTP-E-Mails (Simple Mail Transfer Protocol) im Internet keine Anstrengungen, um zu überprüfen, ob der Absender der Nachricht ist, der er vorgibt zu sein.

Eine standardmäßige SMTP-E-Mail-Nachricht besteht aus einem Nachrichtenumschlag und Nachrichteninhalt:

• Der Nachrichtenumschlag enthält Informationen zum Senden und Empfangen der Nachricht zwischen SMTP-Servern. Der Nachrichtenumschlag wird in RFC 5321 beschrieben. Empfängern wird der Nachrichtenumschlag nie angezeigt, da er während des Nachrichtenübertragungsprozesses generiert wird.
• Der Nachrichteninhalt enthält Nachrichtenkopffelder (zusammenfassend als Nachrichtenkopf bezeichnet) sowie den Nachrichtentext. Der Nachrichtenheader wird in RFC 5322 beschrieben.

Aufgrund dieses Entwurfs verfügt eine Nachricht über mehrere Absenderwerte:

• Die MAIL FROM-Adresse (auch als 5321.MailFrom Adresse, P1-Absender oder Umschlagsender bezeichnet) ist die E-Mail-Adresse, die bei der Übertragung der Nachricht zwischen SMTP-E-Mail-Servern verwendet wird. Diese Adresse wird in der Regel im Feld Return-Path-Header im Nachrichtenkopf aufgezeichnet (obwohl der Quell-E-Mail-Server eine andere Return-Path-E-Mail-Adresse festlegen kann). Diese E-Mail-Adresse wird in Unzustellbarkeitsberichten (auch als NDRs oder Unzustellbarkeitsnachrichten bezeichnet) verwendet.
• Die Von-Adresse (auch als 5322.From Adresse oder P2-Absender bezeichnet) ist die E-Mail-Adresse im Kopfzeilenfeld Von und ist die E-Mail-Adresse des Absenders, die in E-Mail-Clients angezeigt wird.

Das folgende Beispiel zeigt das vereinfachte Transkript einer gültigen Nachrichtenübertragung zwischen zwei SMTP-E-Mail-Servern:

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

In diesem Beispiel:

• Der Quell-E-Mail-Server identifiziert sich als woodgrovebank.com mit dem Ziel-E-Mail-Server tailspintoys.com im HELO-Befehl.
• Der Nachrichtenempfänger ist astobes@tailspintoys.com.
• Die MAIL FROM-Adresse im Nachrichtenumschlag (wird zum Übertragen der Nachricht zwischen SMTP-E-Mail-Servern verwendet) ist dubious@proseware.com.
• Die Im E-Mail-Client des Empfängers angezeigte From-Adresse ist security@woodgrovebank.com.

Obwohl diese Nachricht gemäß SMTP gültig ist, stimmt die Domäne der MAIL FROM-Adresse (proseware.com) nicht mit der Domäne in der Von-Adresse (woodgrovebank.com) überein. Diese Nachricht ist ein klassisches Beispiel für Spoofing, bei dem die Absicht wahrscheinlich den Empfänger täuscht, indem die wahre Quelle der Nachricht maskiert wird, die bei einem Phishingangriff verwendet werden soll.

Es ist klar, dass SMTP-E-Mails Hilfe benötigen, um zu überprüfen, ob Absender der Nachricht sind, der sie zu sein behaupten!

Zusammenarbeit von SPF, DKIM und DMARC zum Authentifizieren von Absendern von E-Mail-Nachrichten

In diesem Abschnitt wird beschrieben, warum Sie SPF, DKIM und DMARC für Domänen im Internet benötigen.

• SPF: Wie unter Einrichten von SPF zum Identifizieren gültiger E-Mail-Quellen für Ihre Microsoft 365-Domäne erläutert, verwendet SPF einen TXT-Eintrag in DNS, um gültige E-Mail-Quellen aus der MAIL FROM-Domäne zu identifizieren und was zu tun ist, wenn der Ziel-E-Mail-Server E-Mails von einer nicht definierten Quelle empfängt ("Hard Fail", um die Nachricht abzulehnen; 'soft fail' to accept and mark the message).

  SPF-Probleme:

  • SPF überprüft nur Quellen für Absender in der MAIL FROM-Domäne. SPF berücksichtigt nicht die Domäne in der Von-Adresse oder die Ausrichtung zwischen den Domänen MAIL FROM und From:

    • Ein Angreifer kann eine E-Mail senden, die die SPF-Authentifizierung (falsch negativ) übergibt, indem er die folgenden Schritte ausführt:
      • Registrieren Sie eine Domäne (z. B. proseware.com), und konfigurieren Sie SPF für die Domäne.
      • Senden Sie E-Mails aus einer gültigen Quelle für die registrierte Domäne mit den Von-E-Mail-Adressen in einer anderen Domäne (z. B. woodgrovebank.com).
    • Ein legitimer E-Mail-Dienst, der E-Mails im Namen anderer Domänen sendet, kann die MAIL FROM-Adresse steuern. Die anderen Domänen und die MAIL FROM-Domäne stimmen nicht überein, sodass die Nachrichten die SPF-Authentifizierung nicht bestehen können (falsch positiv).

  • SPF-Unterbrechungen, nachdem Nachrichten auf eine serverbasierte E-Mail-Weiterleitung stoßen, die Nachrichten umleitet oder weiterleitet .

    • Bei der serverbasierten E-Mail-Weiterleitung wird die Nachrichtenquelle vom ursprünglichen Server in den Weiterleitungsserver geändert.
    • Der Weiterleitungsserver ist nicht zum Senden von E-Mails aus der ursprünglichen MAIL FROM-Domäne autorisiert, sodass die Nachricht die SPF-Authentifizierung nicht bestehen kann (falsch positiv).

  • Jede Domäne und alle Unterdomänen erfordern ihre eigenen individuellen SPF-Einträge. Unterdomänen erben nicht den SPF-Eintrag der übergeordneten Domäne. Dieses Verhalten wird problematisch, wenn Sie E-Mails von definierten und verwendeten Unterdomänen zulassen möchten, aber verhindern möchten, dass E-Mails nicht definierte und nicht verwendete Unterdomänen enthalten.

• DKIM: Wie unter Einrichten von DKIM zum Signieren von E-Mails aus Ihrer Microsoft 365-Domäne erläutert, verwendet DKIM eine Domäne, um wichtige Elemente der Nachricht (einschließlich der Von-Adresse) digital zu signieren, und speichert die Signatur im Nachrichtenkopf. Der Zielserver überprüft, ob die signierten Elemente der Nachricht nicht geändert wurden.

  Wie DKIM SPF unterstützt: DKIM kann Nachrichten überprüfen, bei denen SPF fehlschlägt. Zum Beispiel:

  • Nachrichten von einem E-Mail-Hostingdienst, bei dem dieselbe MAIL FROM-Adresse für E-Mails aus anderen Domänen verwendet wird.
  • Nachrichten, bei denen eine serverbasierte E-Mail-Weiterleitung auftritt.

  Da die DKIM-Signatur im Nachrichtenheader in diesen Szenarien nicht betroffen oder geändert wird, können diese Nachrichten DKIM übergeben.

  DKIM-Probleme: Die Domäne, die DKIM zum Signieren einer Nachricht verwendet, muss nicht mit der Domäne in der Von-Adresse übereinstimmen, die in E-Mail-Clients angezeigt wird.

  Wie SPF kann ein Angreifer eine E-Mail senden, die die DKIM-Authentifizierung (falsch negativ) besteht, indem er die folgenden Schritte ausführt:

  • Registrieren Sie eine Domäne (z. B. proseware.com), und konfigurieren Sie DKIM für die Domäne.
  • Senden Sie E-Mails mit den Von-E-Mail-Adressen in einer anderen Domäne (z. B. woodgrovebank.com).

• DMARC: Wie in Einrichten von DMARC zum Überprüfen der Absenderdomäne für Absender in Microsoft 365 erläutert, verwendet DMARC SPF und DKIM, um die Ausrichtung zwischen den Domänen in den Adressen MAIL FROM und From zu überprüfen. DMARC gibt auch die Aktion an, die das Ziel-E-Mail-System für Nachrichten ausführen soll, bei denen DMARC fehlschlägt, und identifiziert, wohin DMARC-Ergebnisse gesendet werden sollen (sowohl pass als auch fail).

  Wie DMARC SPF und DKIM unterstützt: Wie zuvor beschrieben, versucht SPF nicht, mit der Domäne in der MAIL FROM-Domäne und den Von-Adressen übereinzugleichen. DKIM ist es egal, ob die Domäne, die die Nachricht signiert hat, mit der Domäne in der Von-Adresse übereinstimmt.

  DMARC behebt diese Mängel mithilfe von SPF und DKIM, um zu bestätigen, dass die Domänen in den MAIL FROM- und From-Adressen übereinstimmen.

  DMARC-Probleme: Legitime Dienste, die Nachrichten während der Übertragung vor der Zustellung ändern, unterbrechen SPF-, DKIM- und damit DMARC-Überprüfungen.

• ARC: Wie unter Konfigurieren von vertrauenswürdigen ARC-Siegeln erläutert, können legitime Dienste, die Nachrichten während der Übertragung ändern, ARC verwenden, um die ursprünglichen E-Mail-Authentifizierungsinformationen geänderter Nachrichten beizubehalten.

  Wie ARC DMARC hilft: Das Ziel-E-Mail-System kann den Dienst als vertrauenswürdigen ARC-Versiegeler identifizieren. ARC kann dann die beibehaltenen E-Mail-Authentifizierungsinformationen verwenden, um die Nachricht zu überprüfen.

Authentifizierung eingehender E-Mails für an Microsoft 365 gesendete E-Mails

Aufgrund von Phishing-Bedenken und der weniger vollständigen Einführung strenger E-Mail-Authentifizierungsrichtlinien durch E-Mail-Absender im Internet verwendet Microsoft 365 die implizite E-Mail-Authentifizierung , um eingehende E-Mails zu überprüfen. Die implizite E-Mail-Authentifizierung erweitert die regulären SPF-, DKIM- und DMARC-Überprüfungen, indem Signale aus anderen Quellen verwendet werden, um eingehende E-Mails auszuwerten. Zu diesen Quellen gehören:

• Absenderreputation.
• Absenderverlauf.
• Empfängerverlauf.
• Verhaltensanalyse.
• Andere fortgeschrittene Techniken.

Die ursprüngliche Ankündigung von Microsoft zur impliziten Authentifizierung finden Sie unter A Sea of Phish Part 2 – Enhanced Anti-Spoofing in Microsoft 365.

Durch die Verwendung dieser anderen Signale können Nachrichten, die andernfalls bei herkömmlichen E-Mail-Authentifizierungsprüfungen fehlschlagen würden, die implizite Authentifizierung bestehen und in Microsoft 365 zugelassen werden.

Zusammengesetzte Authentifizierung

Die Ergebnisse der impliziten Authentifizierungsprüfungen von Microsoft 365 werden kombiniert und in einem einzelnen Wert namens zusammengesetzter Authentifizierung oder compauth kurz zusammengefasst gespeichert. Der compauth-Wert wird im Header der Authentifizierungsergebnisse im Nachrichtenheader vermerkt. Der Header Authentication-Results verwendet die folgende Syntax:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Diese Werte werden in der Nachrichtenkopfzeile „Authentication-results“ erklärt.

Administratoren und Benutzer können die Nachrichtenkopfzeilen untersuchen, um zu ermitteln, wie Microsoft 365 den Absender als verdächtigen gefälschten oder legitimen Absender identifiziert hat.

Die folgenden Beispiele konzentrieren sich nur auf die Ergebnisse der E-Mail-Authentifizierung (Wert compauth und Grund). Andere Microsoft 365-Schutztechnologien können Nachrichten identifizieren, die die E-Mail-Authentifizierung als gefälscht übergeben, oder Nachrichten, die die E-Mail-Authentifizierung als legitim fehlschlagen.

• Szenario: Die Domäne im SPF-Eintrag oder die DKIM-Signatur stimmt nicht mit der Domäne in der Von-Adresse überein.

• Ergebnis: Die Nachricht kann bei der zusammengesetzten Authentifizierung fehlschlagen. Trotz des Fehlers der zusammengesetzten Authentifizierung ist die Nachricht möglicherweise weiterhin zulässig, wenn andere Bewertungen nicht auf verdächtige Art hinweisen:

  Authentication-Results: spf=none (sender IP is 192.168.1.8)
    smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
    (signature was verified) header.d=maliciousdomain.com;
    contoso.com; dmarc=none action=none header.from=contoso.com;
    compauth=fail reason=001
  From: chris@contoso.com
  To: michelle@fabrikam.com
  

• Szenario: Die fabrikam.com Domäne verfügt über keine SPF-, DKIM- oder DMARC-Einträge.

• Ergebnis: Nachrichten von Absendern in der fabrikam.com Domäne können bei der zusammengesetzten Authentifizierung fehlschlagen:

  Authentication-Results: spf=none (sender IP is 10.2.3.4)
    smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
    (message not signed) header.d=none; contoso.com; dmarc=none
    action=none header.from=fabrikam.com; compauth=fail reason=001
  From: chris@fabrikam.com
  To: michelle@contoso.com
  

• Szenario: Die fabrikam.com Domäne verfügt über einen SPF-Eintrag und keinen DKIM-Eintrag. Die Domänen in den ADRESSEN MAIL FROM und From stimmen überein.

• Ergebnis: Die Nachricht kann die zusammengesetzte Authentifizierung bestehen, da die Domäne, die SPF übergeben hat, mit der Domäne in der Von-Adresse übereinstimmt:

  Authentication-Results: spf=pass (sender IP is 10.2.3.4)
    smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
    (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
    action=none header.from=fabrikam.com; compauth=pass reason=109
  From: chris@fabrikam.com
  To: michelle@contoso.com
  

• Szenario: Die fabrikam.com Domäne verfügt über einen DKIM-Eintrag ohne SPF-Eintrag. Die Domäne, in der DKIM die Nachricht signiert hat, entspricht der Domäne in der Von-Adresse.

• Ergebnis: Die Nachricht kann die zusammengesetzte Authentifizierung bestehen, da die Domäne in der DKIM-Signatur mit der Domäne in der Von-Adresse übereinstimmt:

  Authentication-Results: spf=none (sender IP is 10.2.3.4)
    smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
    (signature was verified) header.d=outbound.fabrikam.com;
    contoso.com; dmarc=bestguesspass action=none
    header.from=fabrikam.com; compauth=pass reason=109
  From: chris@fabrikam.com
  To: michelle@contoso.com
  

• Szenario: Die Domäne im SPF-Eintrag oder die DKIM-Signatur stimmt nicht mit der Domäne in der Von-Adresse überein.

• Ergebnis: Die Meldung kann bei der zusammengesetzten Authentifizierung fehlschlagen:

  Authentication-Results: spf=none (sender IP is 192.168.1.8)
    smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
    (signature was verified) header.d=maliciousdomain.com;
    contoso.com; dmarc=none action=none header.from=contoso.com;
    compauth=fail reason=001
  From: chris@contoso.com
  To: michelle@fabrikam.com
  

Vermeiden von E-Mail-Authentifizierungsfehlern beim Senden von E-Mails an Microsoft 365

• Konfigurieren von SPF-, DKIM- und DMARC-Einträgen für Ihre Domänen: Verwenden Sie die Konfigurationsinformationen, die von Ihrer Domänenregistrierungsstelle oder dem DNS-Hostingdienst bereitgestellt werden. Es gibt auch Drittanbieter, die sich für die Einrichtung von E-Mail-Authentifizierungsdatensätzen engagieren.

  Viele Unternehmen veröffentlichen keine SPF-Einträge, da sie nicht alle E-Mail-Quellen für Nachrichten in ihrer Domäne kennen.

  1. Veröffentlichen Sie zunächst einen SPF-Eintrag, der alle E-Mail-Quellen enthält, die Sie kennen (insbesondere dort, wo sich Ihr Unternehmensdatenverkehr befindet), und verwenden Sie den Erzwingungsregelwert "soft fail" (~all). Zum Beispiel:

     fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"
     

     Wenn Sie diesen SPF-Eintrag erstellen, behandelt Microsoft 365 eingehende E-Mails aus Ihrer Unternehmensinfrastruktur als authentifiziert, aber E-Mails aus nicht identifizierten Quellen werden möglicherweise weiterhin als Spoof markiert, wenn die zusammengesetzte Authentifizierung fehlschlägt. Dieses Verhalten ist jedoch immer noch eine Verbesserung gegenüber allen E-Mails von Absendern in der Domäne, die von Microsoft 365 als Spoof gekennzeichnet wurden. In der Regel akzeptiert das Ziel-E-Mail-System Nachrichten von Absendern in der Domäne aus nicht identifizierten Quellen, wenn SPF mit einer Regel zur Erzwingung von vorläufigen Fehlern konfiguriert ist.

  2. Entdecken und einschließen Sie weitere E-Mail-Quellen für Ihre Nachrichten. Zum Beispiel:

     • Lokale E-Mail-Server.
     • E-Mail-Nachrichten von einem SaaS-Anbieter (Software-as-a-Service) versendet wurde.
     • E-Mail-Nachrichten, die von einem Cloud-Hostingdienst (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services usw.) versendet wurden

     Nachdem Sie alle E-Mail-Quellen für Ihre Domäne identifiziert haben, können Sie Ihren SPF-Eintrag aktualisieren, um den Erzwingungsregelwert "hard fail" (-all) zu verwenden.

  3. Richten Sie DKIM ein, um Nachrichten digital zu signieren.

  4. Richten Sie DMARC ein, um zu überprüfen, ob die Domänen in den ADRESSEN MAIL FROM und From übereinstimmen, um anzugeben, was mit Nachrichten geschehen soll, die dmarc-Überprüfungen nicht bestehen (ablehnen oder unter Quarantäne stellen), und um Reporting Services zur Überwachung der DMARC-Ergebnisse zu identifizieren.

  5. Wenn Sie Massensender verwenden, um E-Mails in Ihrem Namen zu senden, überprüfen Sie, ob die Domäne in der Von-Adresse mit der Domäne übereinstimmt, die SPF oder DMARC übergibt.

• Sie hosten die E-Mails einer Domäne oder stellen eine Hostinginfrastruktur bereit, die E-Mails senden kann:

  • Stellen Sie sicher, dass Ihre Kunden über eine Dokumentation verfügen, in der erläutert wird, wie SPF für ihre Domänen konfiguriert wird.
  • Erwägen Sie, DKIM ausgehende DKIM-E-Mails zu signieren, auch wenn der Kunde DKIM nicht explizit in seiner Domäne eingerichtet hat (Signieren mit einer Standarddomäne). Sie können die E-Mail sogar mit DKIM-Signaturen doppelt signieren (mit Ihrer Unternehmensdomäne und der Domäne des Kunden, wenn sie verfügbar ist).

  Die Übermittlung an Microsoft ist nicht garantiert, auch wenn Sie E-Mails authentifizieren, die von Ihrer Plattform stammen. Die E-Mail-Authentifizierung stellt jedoch sicher, dass Microsoft E-Mails von Ihren Kundendomänen nicht automatisch per Junk junkt, nur weil sie nicht authentifiziert sind.