Einrichten von DMARC zum Überprüfen der Von-Adressdomäne für Cloud-Absender

Tipp

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

Domänenbasierte Nachrichtenauthentifizierung, Berichterstellung und Konformität (DMARC) ist eine Methode der E-Mail-Authentifizierung, um E-Mails zu überprüfen, die von Ihrem Microsoft 365-organization gesendet wurden. Diese Überprüfung trägt dazu bei, gefälschte Absender zu verhindern, die bei geschäftlichen E-Mail-Kompromittierungen (Business Email Compromise, BEC), Ransomware und anderen Phishingangriffen verwendet werden.

Sie aktivieren DMARC für eine Domäne, indem Sie einen TXT-Eintrag in DNS erstellen. Die DMARC-Überprüfung einer E-Mail-Nachricht umfasst die folgenden Elemente:

• Vergewissern Sie sich, dass die Domänen in der MAIL FROM- und der FROM-Adresse ausgerichtet sind: SPF und DKIM erfordern nicht, dass die Domänen in den folgenden E-Mail-Adressen "ausgerichtet" (übereinstimmen) müssen:

  • Die MAIL FROM-Adresse: Die E-Mail-Adresse, die bei der Übertragung der Nachricht zwischen SMTP-E-Mail-Servern verwendet wird. Diese Adresse wird auch als 5321.MailFrom Adresse, P1-Absender oder Umschlagsender bezeichnet.
  • Die Von-Adresse: Die E-Mail-Adresse im Feld Von-Kopfzeile , die in E-Mail-Clients als Absender der Nachricht angezeigt wird. Diese Adresse wird auch als 5322.From Adresse oder P2-Absender bezeichnet.

  Weitere Informationen dazu, wie sich diese E-Mail-Adressen in verschiedenen Domänen befinden und für Spoofing verwendet werden können, finden Sie unter Warum Internet-E-Mails eine Authentifizierung benötigen.

  • DMARC verwendet das Ergebnis aus SPF, um die beiden folgenden Bedingungen zu überprüfen:

    • Die Nachricht stammt aus einer autorisierten Quelle für die Domäne, die in der MAIL FROM-Adresse verwendet wird (die Grundanforderung von SPF).
    • Die Domänen in den Adressen MAIL FROM und From in der Nachricht sind ausgerichtet. Dieses Ergebnis erfordert effektiv, dass sich gültige Quellen für die Nachricht in der Adressdomäne Von befinden müssen.

  • DMARC verwendet das Ergebnis von DKIM, um zu überprüfen, ob die Domäne, die die Nachricht signiert hat (d = -Wert in einem DKIM-Signature-Headerfeld , wie durch den s= -Selektorwert überprüft), mit der Domäne in der From-Adresse übereinstimmt.

  Eine Nachricht übergibt DMARC, wenn eine oder beide der beschriebenen SPF- oder DKIM-Überprüfungen erfolgreich sind. Eine Nachricht schlägt DMARC fehl, wenn beide beschriebenen SPF- und DKIM-Überprüfungen fehlschlagen.

• DMARC-Richtlinie: Gibt an, was mit Nachrichten zu tun ist, bei denen DMARC fehlschlägt (Ablehnen, Quarantäne oder keine Anweisung).

• DMARC-Berichte: Gibt an, wohin Berichte gesendet werden sollen:

  • Aggregierte Berichte (eine regelmäßige Zusammenfassung positiver und negativer DMARC-Ergebnisse).
  • Forensische Berichte (auch als Fehlerberichte bezeichnet; nahezu sofortige DMARC-Fehlerergebnisse ähnlich wie ein Unzustellbarkeitsbericht oder eine Unzustellbarkeitsnachricht).

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

• Wenn Sie nur die MoERA-Domäne (Microsoft Online Email Routing Address) für E-Mails verwenden (z. B. contoso.onmicrosoft.com): Obwohl SPF und DKIM bereits für Ihre *.onmicrosoft.com-Domäne konfiguriert sind, müssen Sie den DMARC TXT-Eintrag für die Domäne *.onmicrosoft.com im Microsoft 365 Admin Center erstellen. Anweisungen finden Sie in diesem Abschnitt weiter unten in diesem Artikel. 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-Mail verwenden (z. B. contoso.com): Falls noch nicht geschehen, müssen Sie SPF für alle benutzerdefinierten Domänen und Unterdomänen konfigurieren, die Sie für E-Mails verwenden. Außerdem müssen Sie die DKIM-Signatur mithilfe der benutzerdefinierten Domäne oder Unterdomäne konfigurieren, damit die Domäne, die zum Signieren der Nachricht verwendet wird, mit der Domäne in der Von-Adresse übereinstimmt. Anweisungen finden Sie in den folgenden Artikeln:

  • Einrichten von SPF zum Identifizieren gültiger E-Mail-Quellen für Ihre benutzerdefinierten Clouddomänen
  • Einrichten von DKIM zum Signieren von E-Mails aus Ihrer Clouddomäne

  Danach müssen Sie auch die DMARC TXT-Einträge für Ihre benutzerdefinierten Domänen konfigurieren, wie in diesem Artikel beschrieben. Sie haben auch die folgenden Überlegungen:

  • Unterdomänen:

    • Verwenden Sie für E-Mail-Dienste, die nicht ihrer direkten Kontrolle unterliegen (z. B. Massen-E-Mail-Dienste), eine Unterdomäne (z. B. marketing.contoso.com) anstelle Ihrer Haupt-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 Benutzern in Ihrer Haupt-E-Mail-Domäne gesendet wurden. 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?.
    • Im Gegensatz zu SPF und DKIM deckt der DMARC TXT-Eintrag für eine Domäne automatisch alle Unterdomänen (einschließlich nicht vorhandener Unterdomänen) ab, die keinen eigenen DMARC TXT-Eintrag haben. Anders ausgedrückt: Sie können die Vererbung von DMARC in einer Unterdomäne unterbrechen, indem Sie einen DMARC TXT-Eintrag in dieser Unterdomäne erstellen. Jede Unterdomäne erfordert jedoch einen SPF- und DKIM-Eintrag für DMARC.

  • Wenn Sie registrierte, aber nicht verwendete Domänen besitzen: Wenn Sie registrierte Domänen besitzen, die nicht für E-Mails oder überhaupt etwas verwendet werden (auch als geparkte Domänen bezeichnet), konfigurieren Sie die DMARC TXT-Einträge in diesen Domänen, um anzugeben, dass keine E-Mails von diesen Domänen stammen dürfen. Diese Direktive umfasst die Domäne *.onmicrosoft.com , wenn Sie sie nicht für E-Mails verwenden.

• DMARC-Überprüfungen auf eingehende E-Mails benötigen möglicherweise Hilfe: Wenn Sie einen E-Mail-Dienst verwenden, der Nachrichten während der Übertragung vor der Übermittlung an Microsoft 365 ändert, können Sie den Dienst möglicherweise als vertrauenswürdigen ARC-Versiegeler identifizieren. Vertrauenswürdige ARC-Versiegelungen verhindern, dass geänderte Nachrichten automatisch dmarc-Überprüfungen fehlschlagen. Weitere Informationen finden Sie im Abschnitt Nächste Schritte am Ende dieses Artikels.

Der Rest dieses Artikels behandelt die Erstellung von DMARC TXT-Einträgen, das schrittweise Rollout für benutzerdefinierte Domänen und die eingehende DMARC-Behandlung in Microsoft 365.

Tipp

Informationen zum Erstellen des DMARC TXT-Eintrags für Ihre *.onmicrosoft.com-Domäne im Microsoft 365 Admin Center finden Sie in diesem Abschnitt weiter unten in diesem Artikel.

Es gibt keine Verwaltungsportale oder PowerShell-Cmdlets in Microsoft 365, mit denen Sie DMARC TXT-Einträge in Ihren benutzerdefinierten Domänen verwalten können. Stattdessen erstellen Sie den DMARC TXT-Eintrag bei Ihrer Domänenregistrierungsstelle oder ihrem DNS-Hostingdienst (oft dasselbe Unternehmen).

Es werden Anweisungen zum Erstellen des TXT-Eintrags zum Nachweis des Domänenbesitzes für Microsoft 365 bei vielen Domänenregistrierungsstellen bereitgestellt. Sie können diese Anweisungen als Ausgangspunkt verwenden, um DMARC TXT-Einträge 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 DMARC TXT-Einträge

DMARC TXT-Einträge werden vollständig in RFC 7489 beschrieben.

Die grundlegende Syntax des DMARC TXT-Eintrags für eine Domäne in Microsoft 365 lautet:

Hostname: _dmarc
TXT-Wert: v=DMARC1; <DMARC policy>; <Percentage of DMARC failed mail subject to DMARC policy>; <DMARC reports>

oder

Hostname: _dmarc
TXT-Wert: v=DMARC1; p=<reject | quarantine | none>; pct=<0-100>; rua=mailto:<DMARCAggregateReportURI>; ruf=mailto:<DMARCForensicReportURI>

Zum Beispiel:

Hostname: _dmarc
TXT-Wert: v=DMARC1; p=reject; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com

• Der Hostnamenwert _dmarc ist erforderlich.

• v=DMARC1; identifiziert den TXT-Eintrag als DMARC TXT-Eintrag.

• DMARC-Richtlinie: Teilt dem Ziel-E-Mail-System mit, was mit Nachrichten zu tun ist, bei denen DMARC fehlschlägt, wie weiter oben in diesem Artikel beschrieben:

  • p=reject: Die Nachrichten sollten abgelehnt werden. Was mit der Nachricht tatsächlich geschieht, hängt vom Ziel-E-Mail-System ab, aber die Nachrichten werden in der Regel verworfen.
  • p=quarantine: Die Nachrichten sollten 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.
  • p=none: Keine vorgeschlagene Aktion für Nachrichten, bei denen DMARC fehlschlägt. Was mit der Nachricht geschieht, hängt von den E-Mail-Schutzfunktionen im Ziel-E-Mail-System ab. Sie verwenden diesen Wert zum Testen und Optimieren der DMARC-Richtlinie , wie weiter unten in diesem Artikel beschrieben.

  Tipp

  Ausgehende E-Mails von Domänen in Microsoft 365, bei denen DMARC-Überprüfungen durch den E-Mail-Zieldienst fehlschlagen, werden über den Übermittlungspool mit hohem Risiko für ausgehende Nachrichten weitergeleitet, wenn die DMARC-Richtlinie für die Domäne oder p=quarantinelautetp=reject. Es gibt keine Außerkraftsetzung für dieses Verhalten.

• Prozentsatz der fehlgeschlagenen DMARC-E-Mails, die der DMARC-Richtlinie unterliegen: Teilt dem Ziel-E-Mail-System mit, wie viele Nachrichten, bei denen DMARC fehlschlägt (Prozent), die DMARC-Richtlinie auf sie angewendet werden. Beispielsweise bedeutet, dass alle Nachrichten, pct=100 bei denen DMARC fehlschlägt, die DMARC-Richtlinie erhalten, die auf sie angewendet wird. Sie verwenden Werte unter 100 zum Testen und Optimieren der DMARC-Richtlinie , wie weiter unten in diesem Artikel beschrieben. Wenn Sie nicht verwenden pct=, ist pct=100der Standardwert .

• DMARC-Berichte:

  • DMARC-Aggregatberichts-URI: Der rua=mailto: Wert gibt an, wohin der DMARC-Aggregatbericht gesendet werden soll. Der Aggregatbericht verfügt über die folgenden Eigenschaften:

    • Die E-Mail-Nachrichten, die den Aggregatbericht enthalten, werden in der Regel einmal pro Tag gesendet (der Bericht enthält die DMARC-Ergebnisse vom Vortag). Die Betreffzeile enthält die Zieldomäne, die den Bericht gesendet hat (Submitter) und die Quelldomäne für die DMARC-Ergebnisse (Berichtsdomäne).
    • Die DMARC-Daten sind in einer XML-E-Mail-Anlage enthalten, die wahrscheinlich GZIP komprimiert ist. Das XML-Schema ist in Anhang C von RFC 7489 definiert. Der Bericht enthält die folgenden Informationen:
      • Die IP-Adressen von Servern oder Diensten, die E-Mails über Ihre Domäne senden.
      • Gibt an, ob die Server oder Dienste die DMARC-Authentifizierung bestehen oder fehlschlagen.
      • Die Aktionen, die DMARC für E-Mails ausführt, bei denen die DMARC-Authentifizierung fehlschlägt (basierend auf der DMARC-Richtlinie).

    Tipp

    Die Informationen im Aggregatbericht können umfangreich und schwer zu analysieren sein. Um die Daten besser zu verstehen, können Sie die folgenden Optionen für die DMARC-Berichterstellung verwenden:

    • Erstellen einer Automatisierung mithilfe von PowerShell oder Microsoft Power BI.
    • Verwenden Sie einen externen Dienst. Eine Liste der Dienste finden Sie im Microsoft Intelligent Security Association(MISA)-Katalog unter https://www.microsoft.com/misapartnercatalognach DMARC. Die DMARC Reporting Services beschreiben alle benutzerdefinierten Werte, die im DMARC TXT-Eintrag erforderlich sind.

  • URI des forensischen DMARC-Berichts: Der ruf=mailto: Wert gibt an, wohin der forensische DMARC-Bericht (auch als DMARC-Fehlerbericht bezeichnet) gesendet werden soll. Der Bericht wird generiert und sofort nach einem DMARC-Fehler wie einem Nichtzustellbarkeitsbericht (auch als NDR- oder Unzustellbarkeitsnachricht bezeichnet) gesendet.

  Tipp

  Sie sollten die DMARC-Aggregatberichte regelmäßig überprüfen, um zu überwachen, woher E-Mails von Ihren Domänen stammen, und um auf unbeabsichtigte DMARC-Fehler (falsch positive Ergebnisse) zu überprüfen.

  Einzelne Ziel-E-Mail-Systeme sind dafür verantwortlich, DMARC-Berichte an Sie zurückzusenden. Die Menge und Vielfalt der DMARC-Berichte variiert auf die gleiche Weise, wie die Menge und Vielfalt der von Ihrem organization gesendeten E-Mails variieren. Erwarten Sie beispielsweise ein geringeres E-Mail-Volumen an Feiertagen und ein höheres E-Mail-Volumen bei Organisationsereignissen. Es empfiehlt sich, bestimmte Personen für die Überwachung von DMARC-Berichten festzulegen und ein bestimmtes Postfach oder eine bestimmte Microsoft 365-Gruppe zu verwenden, um die DMARC-Berichte zu empfangen (übermitteln Sie die Berichte nicht an das Postfach eines Benutzers).

Verwenden Sie die folgenden Ressourcen, um weitere Informationen zu DMARC zu erfahren:

• Die DMARC-Trainingsreihe von M³AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group).
• Informationen unter DMARC.org.

Verwenden Sie die Microsoft 365 Admin Center, um DMARC TXT-Einträge für *.onmicrosoft.com-Domänen in Microsoft 365 hinzuzufügen.

1. Wählen Sie im Microsoft 365 Admin Center unter https://admin.microsoft.comdie Option Alle>Einstellungsdomänen> anzeigen aus. Oder verwenden Sie https://admin.microsoft.com/Adminportal/Home#/Domains, um direkt zur Seite Domänen zu wechseln.

2. Wählen Sie auf der Seite Domänen die Domäne *.onmicrosoft.com aus der Liste aus, indem Sie an einer beliebigen Stelle in der Zeile neben dem Domänennamen auf das Kontrollkästchen klicken.

3. Wählen Sie auf der daraufhin geöffneten Seite mit den Domänendetails die Registerkarte DNS-Einträge aus .

4. Wählen Sie auf der Registerkarte DNS-Einträgedie Option Eintrag hinzufügen aus.

5. Konfigurieren Sie im flyout Add a custom DNS record (Benutzerdefinierten DNS-Eintrag hinzufügen ), das geöffnet wird, die folgenden Einstellungen:

   • Typ: Vergewissern Sie sich, dass TXT (Text) ausgewählt ist.

   • TXT-Name: Geben Sie ein _dmarc.

   • TXT-Wert: Geben Sie ein v=DMARC1; p=reject.

     Tipp

     Verwenden Sie die Syntax v=DMARC1; p=reject; rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>, um Ziele für die BERICHTE DMARC-Aggregat und DMARC-Forensik anzugeben. Beispiel: v=DMARC1; p=reject; rua=mailto:rua@contoso.onmicrosoft.com; ruf=mailto:ruf@contoso.onmicrosoft.com.

     DMARC-Berichtsanbieter im MISA-Katalog unter https://www.microsoft.com/misapartnercatalog erleichtern das Anzeigen und Interpretieren von DMARC-Ergebnissen.

   • Gültigkeitsdauer: Vergewissern Sie sich, dass 1 Stunde ausgewählt ist.

   Wenn Sie mit dem Flyout Benutzerdefinierten DNS-Eintrag hinzufügen fertig sind, wählen Sie Speichern aus.

Einrichten von DMARC für aktive benutzerdefinierte Domänen in Microsoft 365

Tipp

Wie bereits in diesem Artikel erwähnt, müssen Sie SPF TXT-Einträge erstellen und die DKIM-Signatur für alle benutzerdefinierten Domänen und Unterdomänen konfigurieren, die Sie zum Senden von E-Mails in Microsoft 365 verwenden, bevor Sie DMARC für benutzerdefinierte Domänen oder Unterdomänen konfigurieren.

Ein schrittweiser Ansatz zum Einrichten von DMARC für Ihre Microsoft 365-Domänen wird empfohlen. Das Ziel besteht darin, eine p=reject DMARC-Richtlinie für alle Ihre benutzerdefinierten Domänen und Unterdomänen zu erhalten, aber Sie müssen auf dem Weg testen und überprüfen, um zu verhindern, dass Ziel-E-Mail-Systeme gute E-Mails aufgrund unbeabsichtigter DMARC-Fehler ablehnen.

Ihr DMARC-Rolloutplan sollte die folgenden Schritte ausführen. Beginnen Sie mit einer Domäne oder Unterdomäne mit geringem E-Mail-Volumen und/oder weniger potenziellen E-Mail-Quellen (weniger Wahrscheinlichkeit, dass legitime E-Mails aus unbekannten Quellen blockiert werden):

1. Beginnen Sie mit einer DMARC-Richtlinie von p=none , und überwachen Sie die Ergebnisse für die Domäne. Zum Beispiel:

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

   Hostname: _dmarc
   TXT-Wert: v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   Die Berichte DMARC-Aggregat und DMARC-Forensik geben die Anzahl und Quellen von Nachrichten an, die DMARC-Überprüfungen bestanden und fehlschlagen. Sie können sehen, wie viel von Ihrem legitimen E-Mail-Datenverkehr von DMARC abgedeckt wird oder nicht, und probleme beheben. Sie können auch sehen, wie viele betrügerische Nachrichten gesendet werden und woher sie gesendet werden.

2. Erhöhen Sie die DMARC-Richtlinie auf , p=quarantine und überwachen Sie die Ergebnisse für die Domäne.

   Nachdem Sie genügend Zeit haben, die Auswirkungen von p=nonezu überwachen, können Sie die DMARC-Richtlinie für die Domäne auf p=quarantine erhöhen. Zum Beispiel:

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

   Hostname: _dmarc
   TXT-Wert: v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   Sie können den pct= -Wert auch verwenden, um schrittweise mehr Nachrichten zu beeinflussen und die Ergebnisse zu überprüfen. Sie können z. B. in den folgenden Schritten verschieben:

   • pct=10
   • pct=25
   • pct=50
   • pct=75
   • pct=100

3. Erhöhen Sie die DMARC-Richtlinie auf , p=reject und überwachen Sie die Ergebnisse für die Domäne.

   Nachdem Sie genügend Zeit haben, die Auswirkungen von p=quarantinezu überwachen, können Sie die DMARC-Richtlinie für die Domäne auf p=reject erhöhen. Zum Beispiel:

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

   Hostname: _dmarc
   TXT-Wert: v=DMARC1; p=reject; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   Sie können den pct= -Wert auch verwenden, um schrittweise mehr Nachrichten zu beeinflussen und die Ergebnisse zu überprüfen.

4. Wiederholen Sie die vorherigen drei Schritte für die verbleibenden Unterdomänen mit zunehmender Volumen- und/oder Komplexitätssteigerung, und speichern Sie die übergeordnete Domäne für die letzte.

   Tipp

   Das Blockieren legitimer E-Mails in einem erheblichen Umfang ist für Benutzer inakzeptabel, aber es ist fast unvermeidlich, dass Sie einige falsch positive Ergebnisse erhalten. Gehen Sie langsam und methodisch mit Problemen um, die in der DMARC-Berichterstellung aufgedeckt werden. DMARC-Berichtsanbieter im MISA-Katalog unter https://www.microsoft.com/misapartnercatalog erleichtern das Anzeigen und Interpretieren der DMARC-Ergebnisse.

5. Wie weiter oben beschrieben, erben Unterdomänen die DMARC TXT-Eintragseinstellungen der übergeordneten Domäne, die Sie mit einem separaten DMARC TXT-Eintrag in der Unterdomäne überschreiben können. Wenn Sie die Einrichtung von DMARC in einer Domäne und allen Unterdomänen abgeschlossen haben und die DMARC-Einstellungen für die übergeordnete Domäne und alle Unterdomänen praktisch identisch sind, können Sie die DMARC TXT-Einträge in den Unterdomänen entfernen und sich auf den einzelnen DMARC TXT-Eintrag in der übergeordneten Domäne verlassen.

DMARC TXT-Einträge für geparkte Domänen in Microsoft 365

Tipp

Der empfohlene SPF TXT-Eintrag für geparkte Domänen, die keine E-Mails senden, wird unter SPF TXT-Einträge für benutzerdefinierte Clouddomänen beschrieben. Wie unter Einrichten von DKIM zum Signieren von E-Mails aus Ihrer Clouddomäne beschrieben, werden DKIM-CNAME-Einträge für geparkte Domänen nicht empfohlen.

1. Wenn Sie Domänen registriert haben, von denen niemand im Internet E-Mails erwarten sollte, erstellen Sie den folgenden DMARC TXT-Eintrag bei der Domänenregistrierungsstelle für die Domäne:

   Hostname: _dmarc
   TXT-Wert: v=DMARC1; p=reject;

   • Der pct= Wert ist nicht enthalten, da der Standardwert ist pct=100.
   • Die rua=mailto: Werte und ruf=mailto: werden in diesem Szenario wohl nicht benötigt, da keine gültigen E-Mails von Absendern in der Domäne stammen sollten.

2. Wenn Sie die Domäne *.onmicrosoft.com nicht zum Senden von E-Mails verwenden, müssen Sie auch den DMARC TXT-Eintrag für Ihre *.onmicrosoft.com-Domäne hinzufügen.

DMARC für eingehende E-Mails in Microsoft 365

• Die folgenden integrierten Sicherheitsfeatures für alle Cloudpostfächer wirken sich auf DMARC-Überprüfungen eingehender E-Mails aus:

  • Gibt an, ob Spoofintelligenz in der Antiphishingrichtlinie, die die Nachricht überprüft hat, aktiviert oder deaktiviert ist. Durch das Deaktivieren der Spoofintelligenz wird der implizite Spoofingschutz nur vor zusammengesetzten Authentifizierungsprüfungen deaktiviert.
  • Gibt an, ob die Einstellung Honor DMARC record policy when the message is detected as spoof in the anti-phishing policy that check the message, and the specified actions based on the DMARC policy of the source domain (or in the DMARC TXT record) enabled or disabled is enabled or disabled in the anti-phishing policy that the message check, and the specified actions based on the DMARC policy of the source domain (p=quarantineor p=reject in the DMARC TXT record).

  Vollständige Informationen finden Sie unter Spoofschutz und Absender-DMARC-Richtlinien.

  Um die Standardwerte für diese Einstellungen in Antiphishingrichtlinien anzuzeigen, überprüfen Sie die Einstellungswerte in der Tabelle unter Antiphishing-Richtlinieneinstellungen für alle Cloudpostfächer.

• Microsoft 365 sendet keine forensischen DMARC-Berichte (auch als DMARC-Fehlerberichte bezeichnet), auch wenn im DMARC TXT-Eintrag der Quelldomäne eine gültige ruf=mailto: Adresse vorhanden ist.

• Microsoft 365 sendet DMARC Aggregate-Berichte an alle Domänen mit einer gültigen rua=mailto: Adresse in den DMARC TXT-Einträgen, solange der MX-Eintrag für die Microsoft 365-Domäne direkt auf Microsoft 365 verweist.

  Wenn Sie Internet-E-Mails vor der Übermittlung an Microsoft 365 (der MX-Eintrag verweist auf einen anderen Ort als Microsoft 365) weiterleiten, werden DMARC Aggregate-Berichte nicht gesendet. Diese Einschränkung umfasst Hybridszenarien, in denen E-Mails an die lokale Umgebung übermittelt werden, bevor sie mithilfe eines Connectors an Microsoft 365 weitergeleitet werden.

  Tipp

  Wenn ein nicht von Microsoft stammender Dienst oder Gerät vor E-Mails sitzt, die an Microsoft 365 gesendet werden, identifiziert die erweiterte Filterung für Connectors (auch als Überspringen der Auflistung bezeichnet) die Quelle der Internetnachrichten für SPF, DKIM (wenn der Dienst Nachrichten ändert) und DMARC-Überprüfung ordnungsgemäß.

DMARC-Problembehandlung

Eine Kurzübersichtstabelle mit DMARC-Fehlern, -Ursachen und -Korrekturen finden Sie unter Problembehandlung bei der E-Mail-Authentifizierung in Microsoft 365.

In diesem Abschnitt können Sie häufige DMARC-Fehler diagnostizieren und beheben, verstehen, wie Microsoft 365 auf verschiedene DMARC-Richtlinien reagiert, und dmarc-Aggregat- und forensische Berichte interpretieren.

Diagnose von Ausrichtungsfehlern

Wie in der Einführung in die DMARC-Überprüfung beschrieben, übergibt eine Nachricht DMARC, wenn mindestens eine Ausrichtungsprüfung erfolgreich ist (SPF oder DKIM). Eine Nachricht schlägt DMARC nur fehl, wenn beide Ausrichtungsprüfungen fehlschlagen.

Ausrichtungsmodi

Die aspf Tags (SPF) und adkim (DKIM) im DMARC TXT-Eintrag steuern, wie genau die From-Domäne mit der authentifizierten Domäne übereinstimmen muss. Beide sind optional und standardmäßig ( r gelockert), aber s (streng) ist auch verfügbar. Zum Beispiel:

Hostname: _dmarc
TXT value: v=DMARC1; p=reject; aspf=s; adkim=r; pct=100; rua=mailto:dmarc@contoso.com

• Gelockert (rStandard): Organisationsdomänen (Stammdomänen) müssen übereinstimmen. Unterdomänen sind zulässig.
• Streng (s): FQDNs müssen genau übereinstimmen. Kein Unterdomänenabgleich.

Hinweis

Die aspf Tags und adkim sind unabhängig. Sie können jeweils unterschiedliche Modi verwenden, wie im Beispiel gezeigt. Eine Nachricht übergibt DMARC, wenn eine der Ausrichtungsüberprüfungen erfolgreich ist, sodass ein strikter Fehler bei einer Überprüfung keine Rolle spielt, wenn die andere Überprüfung mit gelockerten Ausrichtung bestanden wird.

Beispiele:

Von Adresse	MAIL FROM / DKIM-Signature d= adresse	Entspannt (r)	Streng (s)
user@contoso.com	contoso.com	✅ Bestehen	✅ Bestehen
user@contoso.com	bounces.contoso.com	✅ Bestehen	❌ Fehler
user@marketing.contoso.com	contoso.com	✅ Bestehen	❌ Fehler
user@contoso.com	contoso.onmicrosoft.com	❌ Fehler	❌ Fehler
user@contoso.com	adatum.net	❌ Fehler	❌ Fehler

Häufige Fehlerszenarien bei der Ausrichtung

Szenario	Problembeschreibung	Ursache	Lösung
Nicht-Microsoft-Dienst sendet in Ihrem Namen	SPF übergibt adatum.com aber DMARC schlägt fehl.	MAIL FROM verwendet die Domäne des Diensts (z. B bounce.adatum.com. ) und keine DKIM-Signierung mit Ihrer Domäne.	Konfigurieren sie die DKIM-Signierung mit Ihrer Domäne im Dienst, oder ändern Sie MAIL FROM in Ihre Domäne/Unterdomäne.
Automatische Weiterleitung in Microsoft 365	DMARC schlägt am Ziel fehl	Weiterleitung von Umschlagssendern; DKIM-Signatur kann unterbrochen werden	Verwenden Sie vertrauenswürdige ARC-Versiegelungen am Ziel, oder verwenden Sie DKIM (die Weiterleitung bleibt erhalten, wenn der Text nicht geändert wird)
Unterdomäne sendet mit strenger Ausrichtung	aspf=s verursacht Fehler bei Unterdomänen-Absendern	MAIL FROM ist sub.contoso.com , aber From ist contoso.com	Ändern Sie in aspf=r (gelockert), oder stellen Sie sicher, dass die From-Adresse mit der Unterdomäne übereinstimmt.
DKIM-Signaturdomänenkonflikt	DKIM besteht, aber DMARC schlägt weiterhin fehl	DER DKIM-Wert d= (z. B adatum.com. ) entspricht nicht der Von-Domäne (contoso.com)	Konfigurieren der benutzerdefinierten DKIM-Signatur beim Dienst mithilfe Ihrer Domäne
Freigegebenes Postfach oder freigegebene Verteilergruppe	DMARC schlägt zeitweilig fehl	Antworten von oder Umleitung von Umschlagadressen	Überprüfen Sie, ob DKIM intakt ist. Erwägen von ARC für zwischengeschaltete Dienste

Diagnostizieren von Ausrichtungsfehlern von Nachrichtenheadern

Schritt 1: Öffnen Sie die Nachrichtenheader, und suchen Sie den Header Authentication-Results von Microsoft 365:

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

Schritt 2: Identifizieren des Ausrichtungsfehlers:

Prüfen	Kopfzeilenfeld	Wert im Beispiel	Wird mit Von (contoso.com) ausgerichtet?
SPF-Ausrichtung	smtp.mailfrom=	bounces.adatum.com	❌ Nein (andere Organisationsdomäne)
DKIM-Ausrichtung	header.d=	adatum.com	❌ Nein (andere Organisationsdomäne)
DMARC-Ergebnis	dmarc=	fail	Fehler bei beiden Überprüfungen

Schritt 3: Bestimmen Sie den Fix, indem Sie die folgenden Fragen beantworten:

1. Können Sie die MAIL FROM-Adresse in Ihre Domäne ändern (z. B. bounces.contoso.com anstelle von bounces.adatum.com)?
   • Ja: Konfigurieren Sie die MAIL FROM-Änderung beim Dienst, um die SPF-Ausrichtung zu korrigieren.
   • Nein: Verwenden Sie stattdessen die DKIM-Ausrichtung (fahren Sie mit Schritt 2 fort).
2. Kann der Dienst mit Ihrer Domäne (d=contoso.com) signieren?
   • Ja: Konfigurieren Sie die benutzerdefinierte DKIM-Signatur im Dienst.
   • Nein: Erwägen Sie eine Unterdomänenstrategie:
     • Senden aus einer Unterdomäne (z. B. sub.contoso.com).
     • Veröffentlichen Sie einen separaten DMARC-Eintrag für diese Unterdomäne.
     • Lassen Sie den Dienst DKIM mit d=sub.contoso.com signieren.

Überprüfen der Ausrichtung auf zuletzt verwendete Nachrichten in PowerShell

Stellen Sie eine Verbindung mit Exchange Online PowerShell her, und führen Sie die folgenden Befehle aus:

# Get recent messages and check authentication results
$messages = Get-MessageTrace -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -PageSize 100

foreach ($msg in $messages) {
    $details = Get-MessageTraceDetail -MessageTraceId $msg.MessageTraceId -RecipientAddress $msg.RecipientAddress
    $authEvent = $details | Where-Object { $_.Event -eq "Receive" }
    if ($authEvent.Detail -match "dmarc=fail") {
        Write-Output "DMARC FAIL: From=$($msg.SenderAddress), Subject=$($msg.Subject)"
    }
}

Auswirkung der DMARC-Richtlinie auf das Microsoft 365-Verhalten

Wie in DMARC für eingehende E-Mails beschrieben, hängt das Verhalten von Microsoft 365 von der Richtlinieneinstellung HONOR DMARC-Datensatz ab. Ausführliche Informationen finden Sie unter Spoofschutz- und Absender-DMARC-Richtlinien.

Die folgende Zusammenfassung zeigt das allgemeine Verhalten für eingehende Nachrichten, bei denen DMARC fehlschlägt , wenn die Richtlinie für den HONOR-DMARC-Datensatzauf Ein (empfohlen) lautet:

DMARC-Richtlinie des Absenders	Nachrichtendisposition	Authentifizierungsergebnisse	CompAuth
p=none	Keine DMARC-spezifische Aktion. Andere Filter werden weiterhin angewendet.	dmarc=fail action=none	Basierend auf zusammengesetzter Authentifizierung (SPF, DKIM, Spoof Intelligence)
p=quarantine	Junk-Email Ordner (für Quarantäne konfigurierbar)	dmarc=fail action=quarantine	compauth=fail reason=100
p=reject	Während SMTP abgelehnt (550 5.7.1)	dmarc=fail action=oreject	compauth=fail reason=100

Achtung

Seien Sie vorsichtig, wenn Sie legitime Absender außer Kraft setzen p=reject . Wenn Ihr organization rechtmäßig E-Mails von einem Absender empfängt, dessen DMARC fehlschlägt (z. B. weitergeleitete E-Mails, Adressenlisten), verwenden Sie einen der folgenden Ansätze:

• Konfigurieren Sie den Absender als vertrauenswürdigen ARC-Sealer (bevorzugt).
• Erstellen Sie eine Nachrichtenflussregel mit bestimmten Bedingungen (Absender-IP + Absenderdomäne), um die Spamfilterung zu überspringen.
• Fügen Sie einen Zulassungseintrag in der Mandanten-Zulassungs-/Sperrliste hinzu (temporär, läuft in 30 Tagen ab).

DMARC-Aktionswerte in Authentication-Results

Im Header Authentication-Results werden möglicherweise die folgenden DMARC-Aktionswerte angezeigt:

Action-Wert	Bedeutung
action=none	Absender veröffentlicht p=none; keine Aktion ausgeführt
action=quarantine	Absender veröffentlicht p=quarantine; Nachricht unter Quarantäne oder Junk-E-Mail
action=oreject	Absender veröffentlicht p=reject; Nachricht abgelehnt ("o" = Ursprung)
action=pct.quarantine	Absender, der mit pct= weniger als 100 veröffentlicht p=quarantine wurde; diese Nachricht war im Stichprobenprozentsatz enthalten.
action=pct.reject	Absender, der mit pct= weniger als 100 veröffentlicht p=reject wurde; diese Nachricht war im Stichprobenprozentsatz enthalten.

DMARC-Berichtinterpretation

In diesem Abschnitt erfahren Sie, wie Sie die DMARC-Aggregat- und forensischen Berichte interpretieren, die Empfänger an Ihre rua Adressen und ruf senden.

Aggregieren von Berichten

Das folgende Beispiel zeigt die XML-Struktur eines Aggregatberichts:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>microsoft.com</org_name>           <!-- Reporting organization -->
    <email>dmarceng@microsoft.com</email>
    <report_id>unique-report-id</report_id>
    <date_range>
      <begin>1700000000</begin>                   <!-- Unix timestamp: start -->
      <end>1700086400</end>                       <!-- Unix timestamp: end -->
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>contoso.com</domain>                  <!-- Your domain -->
    <adkim>r</adkim>                              <!-- DKIM alignment mode -->
    <aspf>r</aspf>                                <!-- SPF alignment mode -->
    <p>reject</p>                                 <!-- Domain policy -->
    <sp>quarantine</sp>                           <!-- Subdomain policy -->
    <pct>100</pct>                                <!-- Percentage -->
  </policy_published>

  <record>
    <row>
      <source_ip>198.51.100.10</source_ip>        <!-- Sending IP -->
      <count>1523</count>                         <!-- Number of messages -->
      <policy_evaluated>
        <disposition>none</disposition>           <!-- What receiver did -->
        <dkim>pass</dkim>                         <!-- DKIM alignment result -->
        <spf>fail</spf>                           <!-- SPF alignment result -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>contoso.com</header_from>      <!-- From address domain -->
      <envelope_from>bounces.adatum.com</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>contoso.com</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>bounces.adatum.com</domain>
        <result>pass</result>                     <!-- SPF passed but... -->
      </spf>
    </auth_results>
  </record>
</feedback>

Lesen von aggregierten Berichten

XML-Element	Was es Ihnen sagt	Problembehandlungsaktion
<source_ip>	Die IP-Adresse, die die Nachrichten gesendet hat	Ermitteln, ob dies ein legitimer Absender oder nicht autorisiert ist
<count>	Anzahl der Nachrichten aus dieser Quelle	Hohe Anzahl von unbekannten IP-Adressen = potenzielles Spoofing
<disposition>	Aktion, die der Empfänger ausgeführt hat (none, quarantine, reject)	Überprüfen, ob der Empfänger Ihre Richtlinie berücksichtigt
<dkim> Unter <policy_evaluated>	Gibt an, ob DKIM ausgerichtet ist (nicht nur übergeben)	fail = DKIM-Domäne stimmt nicht mit Der Domäne überein
<spf> Unter <policy_evaluated>	Gibt an, ob SPF ausgerichtet ist (nicht nur übergeben)	fail = MAIL FROM-Domäne stimmt nicht mit Der Domäne überein
<domain> Unter <auth_results><spf>	Domäne, für die SPF überprüft wurde	If different from From domain = alignment issue
<domain> Unter <auth_results><dkim>	DKIM-Signaturdomäne	Muss mit der From-Domäne für die DMARC-Ausrichtung übereinstimmen
<result> Unter <auth_results>	Unformatierter SPF-/DKIM-Pass/-Fehler (vor der Ausrichtungsprüfung)	pass + Ausrichtung fail = klassisches Ausrichtungsproblem

Tipp

Die wichtigste Erkenntnis aus aggregierten Berichten besteht darin, die Lücke zwischen Authentifizierungsdurchlauf und Ausrichtungsdurchlauf zu identifizieren:

• <auth_results><spf><result>pass</result> + <policy_evaluated><spf>fail</spf> = SPF wurde übergeben, domänen werden jedoch nicht ausgerichtet.
• Diese Kombination bedeutet, dass der Absender autorisiert ist (SPF-Pass), aber nicht ordnungsgemäß für DMARC konfiguriert ist (Ausrichtungsfehler).

Allgemeine Aggregatberichtsmuster und -korrekturen

Muster im Bericht	Interpretation	Behebung
Bekannte IP-Adresse, SPF auth=pass, SPF aligned=fail	Legitimer Dienst mit falscher MAIL FROM-Domäne	Konfigurieren des Diensts für die Verwendung Ihrer Domäne in MAIL FROM oder Einrichten der DKIM-Signierung mit Ihrer Domäne
Bekannte IP-Adresse, DKIM auth=pass, DKIM aligned=fail	Der Dienst signiert DKIM mit einer eigenen Domäne.	Konfigurieren von benutzerdefiniertem DKIM im Dienst mit d=contoso.com
Unbekannte IP-Adresse, hohes Volumen, alle fehler	Potenzielle Spoofing-/Phishing-Kampagne	Keine Aktion erforderlich. Ihre DMARC-Richtlinie schützt Empfänger.
Bekannte IP-Adresse (Microsoft 365), SPF aligned=pass	Normaler Microsoft 365-Nachrichtenfluss	Gesund. Keine Aktion erforderlich.
Geringes Volumen des legitimen Diensts, SPF+DKIM schlägt fehl	Dienst nicht in SPF enthalten und nicht DKIM-Signatur	Hinzufügen eines Diensts zum SPF-Eintrag und/oder Konfigurieren von DKIM
Weitergeleitete E-Mails (Adressenlisten-IP-Adressen), alle fehler	Die E-Mail-Weiterleitung unterbricht SPF; Body-Änderung bricht DKIM	Normal für weitergeleitete E-Mails. Verwenden Sie ARC, oder akzeptieren Sie einige Fehler.

Forensische Berichte

Wie im Abschnitt DMARC für eingehende E-Mails erwähnt, sendet Microsoft 365 keine forensischen Berichte. Möglicherweise erhalten Sie sie jedoch von anderen Anbietern. In der folgenden Tabelle werden die beiden Berichtstypen verglichen:

Aspekt	Aggregierte Berichte (rua)	Forensische Berichte (ruf)
Frequency	Täglich (in der Regel)	Nahezu in Echtzeit (pro Fehler)
Inhalt	Zusammenfassungsstatistiken nach Quell-IP	Details zu einzelnen Nachrichten
Volume	Ein Bericht pro Tag und Reporter	Ein Bericht pro Fehler (kann ein hohes Volumen aufweisen)
Datenschutz	Nur IP-Adressen und -Zählungen	Kann Nachrichtenkopfzeilen/-text enthalten (bearbeitet)
Support	Weit verbreitet von Empfängern unterstützt	Eingeschränkte Unterstützung (viele Empfänger senden ruf nicht)
Anwendungsfall	Trendanalyse, Identifizierung unbekannter Absender	Debuggen bestimmter Fehler, forensische Untersuchung

Hinweis

Wenn Sie Fehlerdetails pro Nachricht von Microsoft 365 benötigen, verwenden Sie die Nachrichtenablaufverfolgung und die Nachrichtenheaderanalyse anstelle von forensischen Berichten.

Struktur des forensischen Berichts (FORMAT AFRF/RFC 6591):

From: noreply-dmarc-support@fabrikam.com
To: ruf@contoso.com
Subject: Report Domain: contoso.com Submitter: fabrikam.com

Feedback-Type: auth-failure
User-Agent: fabrikam.com/dmarc-reporter
Version: 1
Original-Mail-From: bounces@adatum.com
Arrival-Date: Mon, 15 Jan 2024 10:30:00 -0000
Source-IP: 198.51.100.10
Authentication-Results: fabrikam.com; dmarc=fail (p=reject)
  header.from=contoso.com
Reported-Domain: contoso.com
Original-Envelope-Id: <abc123@mail.adatum.com>

Bewährte Methoden für DMARC-Berichte

Empfehlung	Details
Verwenden eines dedizierten Postfachs für rua	Erstellen Sie ein freigegebenes Postfach (z. B dmarc-reports@contoso.com. ). Verwenden Sie keine einzelnen Benutzerpostfächer.
Verwenden einer Microsoft 365-Gruppe	Gruppen bieten eine bessere Zusammenarbeit und gemeinsamen Zugriff für das Sicherheitsteam
Erwägen eines DMARC-Berichterstellungsdiensts	DMARC Reporting Services analysieren XML in Dashboards. Suchen Sie im MISA-Katalog nach DMARC.
Nur mit rua beginnen	Fügen Sie bei Bedarf später hinzu ruf . Forensische Berichte können ein hohes Volumen generieren.
Regelmäßige Überwachung	Aggregatberichte während der ersten Bereitstellung wöchentlich überprüfen; monatlich einmal stabil
Realistische Erwartungen festlegen	Nicht alle Empfänger senden Berichte. Abdeckung beträgt in der Regel 70-90 % des gesamten E-Mail-Volumens

Domänenübergreifende Berichterstellung

Wenn sich Ihr DMARC rua oder ruf Ihre Adresse in einer anderen Domäne als die zu überwachende Domäne befindet, muss die empfangende Domäne einen DNS TXT-Eintrag veröffentlichen, der die Übermittlung des Berichts autorisiert:

Beispiel: DMARC für contoso.com sendet Berichte an dmarc@fabrikam.com

Erforderlicher DNS-Eintrag unter fabrikam.com:

Hostname: contoso.com._report._dmarc
Type: TXT
Value: v=DMARC1;

Ohne diesen Datensatz übermitteln Empfänger keine DMARC-Berichte an die externe Adresse.

Kurzübersicht zur DMARC-Problembehandlung

Problembeschreibung	Wahrscheinliche Ursache	Diagnoseschritt	Lösung
dmarc=fail SPF und DKIM werden jedoch einzeln übergeben.	Fehler bei der Ausrichtung: Domänen stimmen nicht mit "Von" überein	Überprüfen smtp.mailfrom= und header.d= Authentication-Results header.from=	Konfigurieren von SPF/DKIM mit ausgerichteten Domänen
dmarc=bestguesspass	Kein DMARC-Eintrag für die Domäne "From" veröffentlicht	Txt-Eintrag _dmarc.domain.com abfragen	Microsoft leitet einen Pass ab. Veröffentlichen Sie einen expliziten DMARC-Datensatz.
dmarc=fail action=oreject aber Nachricht übermittelt	DMARC deaktiviert oder Liste/Außerkraftsetzung zulassen	Überprüfen sie die Einstellungen der Antiphishingrichtlinie und die Mandantenliste "Zulassen/Blockieren".	Aktivieren sie die Richtlinie zum Honor DMARC-Datensatz , wenn eine strikte Erzwingung gewünscht ist.
dmarc=fail für weitergeleitete Nachrichten	Die Weiterleitung unterbricht die SPF-Ausrichtung; Textänderungen brechen DKIM	Überprüfen Sie, ob die Nachricht zwischendurchläuft (X-MS-Exchange-Header)	Konfigurieren des vertrauenswürdigen ARC-Sealers für den Weiterleitungsdienst
dmarc=fail für Nicht-Microsoft SaaS-Absender	Der Dienst verwendet eine eigene Domäne in MAIL FROM und DKIM. d=	Überprüfen der aggregierten Berichte für die IP-Adresse des Diensts	Konfigurieren der benutzerdefinierten DKIM-Signatur beim Dienst und Ausrichten von MAIL FROM
dmarc=temperror oder dmarc=permerror	DNS-Probleme beim Abrufen des DMARC-Eintrags (Timeout, Syntaxfehler)	Überprüfen der DMARC-Datensatzsyntax mit nslookup -type=TXT _dmarc.domain.com	Beheben von DNS-Syntaxfehlern; Sicherstellen, dass nur ein _dmarc TXT-Eintrag vorhanden ist
compauth=fail reason=000	Fehler bei der zusammengesetzten Authentifizierung (expliziter Fehler)	Überprüfen aller Authentifizierungsergebnisse (SPF, DKIM, DMARC, ARC)	Beheben von zugrunde liegenden SPF/DKIM/DMARC-Problemen
compauth=fail reason=100	Expliziter DMARC-Fehler bei Richtlinienerzwingung	Die DMARC-Richtlinie des Absenders hat den Fehler verursacht.	Korrigieren der Ausrichtung an der Quelle oder Konfigurieren von ARC/Außerkraftsetzung, falls legitim
Aggregatberichte, die nicht empfangen werden	rua Adresse nicht erreichbar oder domänenübergreifende Authentifizierung fehlt	Überprüfen, ob das Postfach und der DNS-Autorisierungseintrag für externe Domänen vorhanden sind	Korrigieren des Postfachroutings; TXT-Eintrag hinzufügen domain._report._dmarc

DMARC-Diagnoseworkflow

Führen Sie die folgenden Schritte aus, um eine Nachricht mit dmarc=failzu diagnostizieren:

1. Identifizieren sie die Domäne Von: Suchen Sie den header.from= Wert im Header Authentication-Results .

2. Überprüfen der SPF-Ausrichtung: Stimmt die smtp.mailfrom= Domäne mit der header.from= Domäne überein?

   • Ja (gleiche Organisationsdomäne mit aspf=r): SPF ist ausgerichtet.
   • Nein: Die SPF-Ausrichtung schlägt fehl.
   • Hat SPF überhaupt bestanden (spf=pass vs spf=fail.)? Wenn spf=fail, korrigieren Sie zuerst SPF, indem Sie den Absender zum SPF-Eintrag hinzufügen.

3. Überprüfen der DKIM-Ausrichtung: Stimmt der header.d= Wert im DKIM-Signature mit der header.from= Domäne überein?

   • Ja (gleiche Organisationsdomäne mit adkim=r): DKIM ist ausgerichtet.
   • Nein: Die DKIM-Ausrichtung schlägt fehl.
   • Hat DKIM überhaupt bestanden (dkim=pass vs dkim=fail)? Wenn dkim=fail, beheben Sie DKIM, indem Sie den Schlüssel veröffentlichen und die Signatur überprüfen.

4. Wenn beide Ausrichtungen fehlschlagen, schlägt DMARC fehl. Lösungsoptionen:

   • Korrigieren der SPF-Ausrichtung: Ändern Sie die MAIL FROM-Adresse in Ihre Domäne.
   • Korrektur der DKIM-Ausrichtung: Signieren mit d=contoso.com.
   • Unterdomäne verwenden: Senden von sub.domain.com mit einem eigenen DMARC-Eintrag.
   • Wenn die Nachricht weitergeleitet wird: Konfigurieren Sie einen vertrauenswürdigen ARC-Versiegeler.

5. Überprüfen Sie die Richtlinienaktion:

   • p=none: Keine Auswirkung auf die Übermittlung (nur Monitor).
   • p=quarantine: Die Nachricht wird an Junk-Email gesendet (wenn die Richtlinie "DMARC honor" aktiviert ist).
   • p=reject: Die Nachricht wird abgelehnt (wenn die Richtlinie "DMARC honor " aktiviert ist). Wenn legitime E-Mails abgelehnt werden, verwenden Sie ARC, eine Zulassungsliste, oder korrigieren Sie die Authentifizierung an der Quelle.

Nützliche PowerShell-Befehle für die DMARC-Problembehandlung

Stellen Sie eine Verbindung mit Exchange Online PowerShell her, und führen Sie die folgenden Befehle aus:

# Check your organization's anti-phishing policy DMARC settings
Get-AntiPhishPolicy | Format-List Name, HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

# Verify DMARC record for a domain
Resolve-DnsName -Name "_dmarc.contoso.com" -Type TXT | Select-Object -ExpandProperty Strings

# Check DKIM configuration (alignment prerequisite)
Get-DkimSigningConfig | Format-List Domain, Enabled, Selector1CNAME, Selector2CNAME

# Review messages that failed DMARC in the last 24 hours
Get-MailDetailSpamReport -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) |
  Where-Object { $_.MessageTraceId } |
  Select-Object Date, SenderAddress, RecipientAddress, Subject, SpamScore

# Check ARC configuration (for forwarding scenarios)
Get-ArcConfig | Format-List ArcTrustedSealers

# View anti-phishing policy DMARC override actions
Get-AntiPhishPolicy -Identity "Office365 AntiPhish Default" |
  Select-Object HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

Tipp

Bei der Problembehandlung von DMARC-Fehlern für einen bestimmten Absender:

1. Beginnen Sie mit dem Header Authentication-Results , um den Fehlertyp zu identifizieren.
2. Querverweis mit Ihren DMARC-Aggregatberichten , um das Volume und die Quell-IP-Adressen anzuzeigen.
3. Verwenden Sie Get-MessageTrace , um bestimmte Nachrichten zu finden, und Get-MessageTraceDetail , um Übermittlungsereignisse zu untersuchen.
4. Wenn der Absender legitim ist, arbeiten Sie mit dem Absender zusammen, um die SPF/DKIM-Ausrichtung zu korrigieren, bevor Sie Außerkraftsetzungen erstellen.

Nächste Schritte

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.

Informationen zur Diagnose und Behebung von E-Mail-Authentifizierungsfehlern finden Sie unter Problembehandlung bei der E-Mail-Authentifizierung in Microsoft 365.