Einrichten von DMARC zum Überprüfen der Domäne der Absenderadresse für Cloudabsender

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 den MAIL-FROM- und FROM-Adressen übereinstimmen: SPF und DKIM erfordern nicht, dass die Domänen in den folgenden E-Mail-Adressen „übereinstimmen“:

  • 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 der Nachricht stimmen überein. Dieses Ergebnis bedeutet praktisch, dass gültige Quellen für die Nachricht aus der Domäne der From-Adresse stammen 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 unter Verwenden des Microsoft 365 Admin Center zum Hinzufügen von DMARC TXT-Einträgen für *.onmicrosoft.com-Domänen in Microsoft 365. 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 in den nächsten Schritten.

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 Domäne *.onmicrosoft.com in der Microsoft 365 Admin Center finden Sie unter Verwenden des Microsoft 365 Admin Center, um DMARC TXT-Einträge für *.onmicrosoft.com-Domänen in Microsoft 365 hinzuzufügen.

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, die DMARC nicht bestehen (Ablehnen, Quarantäne oder keine Aktion):

  • 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 angenommen, 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.

  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=rejectlautetp=quarantine. 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 pct=100, dass auf alle Nachrichten, bei denen DMARC fehlschlägt, die DMARC-Richtlinie angewendet wird. Sie verwenden Werte unter 100 zum Testen und Optimieren der DMARC-Richtlinie. 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 nicht.
      • 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 von Diensten finden Sie, indem Sie im Katalog der Microsoft Intelligent Security Association (MISA) unter https://www.microsoft.com/misapartnercatalog nach DMARC suchen. 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 unmittelbar nach einem DMARC-Fehler generiert und gesendet, ähnlich wie bei einem Nichtzustellbarkeitsbericht (auch als NDR oder Bounce-Nachricht bezeichnet).

  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.

Führen Sie die folgenden Schritte aus, um einen DMARC TXT-Eintrag für Ihre *.onmicrosoft.com-Domäne im Microsoft 365 Admin Center 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 , um direkt auf die Seite https://admin.microsoft.com/Adminportal/Home#/Domains zu gelangen.

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

Bevor Sie DMARC für benutzerdefinierte Domänen oder Unterdomänen konfigurieren, 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.

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. Unterdomänen erben 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 Features und Verhaltensweisen beeinflussen, wie Microsoft 365 DMARC für eingehende Nachrichten auswertet und ob DMARC-Berichte gesendet werden.

• 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. Das Deaktivieren der Spoofing-Intelligenz deaktiviert den impliziten Spoofingschutz nur bei Prüfungen der Verbundauthentifizierung.
  • Gibt an, ob die Einstellung DMARC-Eintragsrichtlinie berücksichtigen, wenn die Nachricht als Spoofing erkannt wird in der Anti-Phishing-Richtlinie, die die Nachricht überprüft hat, aktiviert oder deaktiviert ist, sowie die angegebenen Aktionen basierend auf der DMARC-Richtlinie der Quelldomäne (p=quarantine oder p=reject im DMARC-TXT-Eintrag).

  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 Zustellung an Microsoft 365 über einen Nicht-Microsoft-Dienst oder ein Nicht-Microsoft-Gerät leiten (der MX-Eintrag zeigt auf etwas anderes als Microsoft 365), werden keine DMARC-Aggregatberichte 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-Microsoft-Dienst oder -Gerät dem in Microsoft 365 eingehenden E-Mail-Datenverkehr vorgeschaltet ist, identifiziert Erweiterte Filterung für Connectors (auch als Skip Listing bezeichnet) die Quelle aus dem Internet stammender Nachrichten für die SPF-, DKIM- (wenn der Dienst Nachrichten verändert) und DMARC-Validierung korrekt.

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 "Einrichten von DMARC" beschrieben, um die Absenderdomäne für Cloud-Absender zu überprüfen, ü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 auf r (relaxiert) gesetzt, aber s (streng) ist ebenfalls verfügbar. Das folgende Beispiel zeigt einen DMARC TXT-Eintrag, der strenge SPF-Ausrichtung (aspf=s) und eine entspannte DKIM-Ausrichtung verwendet (adkim=r):

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.
• Exakt (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:

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

Häufige Fehlerszenarien bei der Ausrichtung

In der folgenden Tabelle sind allgemeine DMARC-Ausrichtungsfehlerszenarien, ihre Symptome, Ursachen und empfohlene Korrekturen aufgeführt.

Szenario	Symptom	Ursache	Lösung
Nicht-Microsoft-Dienst sendet in Ihrem Namen	SPF ist für adatum.com erfolgreich, 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 bei dem Dienst oder ändern Sie MAIL FROM auf Ihre Domäne/Unterdomäne.
Automatische Weiterleitung in Microsoft 365	DMARC schlägt am Ziel fehl	Weiterleitung ändert den Envelope-Sender; DKIM-Signatur kann ungültig werden	Verwenden Sie vertrauenswürdige ARC-Versiegler am Ziel, oder verwenden Sie DKIM (übersteht die Weiterleitung, 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) stimmt nicht mit der Absenderdomäne (contoso.com) überein.	Konfigurieren der benutzerdefinierten DKIM-Signatur beim Dienst mithilfe Ihrer Domäne
Freigegebenes Postfach oder Verteilergruppe	DMARC schlägt zeitweilig fehl	Antworten von oder Umleiten ändert 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 Nachrichtenkopfzeilen, und suchen Sie den Header "Authentifizierungsergebnisse" aus Microsoft 365. Das folgende Beispiel zeigt einen Authentication-Results-Header, bei dem SPF und DKIM beide einzeln übergeben werden. DMARC schlägt jedoch fehl, da keine Domäne mit der Absenderadressendomäne übereinstimmt:

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 an der Absenderadresse (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: Legen Sie die Fehlerbehebung fest, 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.

Ausrichtung für aktuelle Nachrichten in PowerShell überprüfen

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 Schutz vor Spoofing und DMARC-Richtlinien für Absender.

Die folgende Zusammenfassung zeigt das allgemeine Verhalten für eingehende Nachrichten, bei denen DMARC fehlschlägt, wenn DMARC-Eintragsrichtlinie berücksichtigen auf Ein festgelegt ist (empfohlen):

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 der SMTP-Verarbeitung abgelehnt (550 5.7.1)	dmarc=fail action=oreject	compauth=fail reason=100

Achtung

Seien Sie vorsichtig, wenn Sie p=reject für legitime Absender außer Kraft setzen. 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-Versiegler (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:

Aktionswert	Bedeutung
action=none	Absender veröffentlicht p=none; keine Aktion ausgeführt
action=quarantine	Absender hat p=quarantine veröffentlicht; Nachricht wurde unter Quarantäne gestellt oder als Junk-E-Mail eingestuft
action=oreject	Absender angegeben p=reject; Nachricht zurückgewiesen („o“ = Herkunft)
action=pct.quarantine	Absender hat p=quarantine mit pct= kleiner als 100 veröffentlicht; diese Nachricht befand sich im Stichprobenprozentsatz
action=pct.reject	Absender hat p=reject mit pct= kleiner als 100 veröffentlicht; diese Nachricht befand sich im Stichprobenprozentsatz

DMARC-Berichtinterpretation

Dieser Abschnitt hilft Ihnen, die DMARC-Sammelberichte und forensischen Berichte zu interpretieren, die Empfänger an Ihre rua und ruf Adressen senden. Informationen zum Konfigurieren der Werte rua und ruf im DMARC-TXT-Eintrag finden Sie unter Syntax für DMARC-TXT-Einträge.

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

Verwenden Sie die folgende Tabelle, um die wichtigsten Felder in einem DMARC-Aggregatbericht zu interpretieren und zu bestimmen, welche Problembehandlungsmaßnahme ausgeführt werden soll.

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 bestanden)	fail = DKIM-Domäne stimmt nicht mit der From-Domäne überein
<spf> unter <policy_evaluated>	Gibt an, ob SPF ausgerichtet ist (nicht nur bestanden)	fail = MAIL FROM-Domäne stimmt nicht mit der From-Domäne überein
<domain> unter <auth_results><spf>	Domäne, für die SPF überprüft wurde	Wenn abweichend von der Absenderdomäne = Ausrichtungsproblem
<domain> unter <auth_results><dkim>	DKIM-Signaturdomäne	Muss für die DMARC-Ausrichtung mit der Absenderdomäne übereinstimmen
<result> unter <auth_results>	Rohes SPF/DKIM – bestanden/nicht bestanden (vor der Alignment-Prü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 hat bestanden, die Domains stimmen jedoch nicht überein.
• Diese Kombination bedeutet, dass der Absender autorisiert ist (SPF-Pass), aber nicht ordnungsgemäß für DMARC konfiguriert ist (Ausrichtungsfehler).

Allgemeine Aggregatberichtsmuster und -korrekturen

In der folgenden Tabelle sind allgemeine Muster aufgeführt, die Sie möglicherweise in aggregierten Berichten und den in der Regel erforderlichen Aktionen finden.

Muster im Bericht	Interpretation	Fehlerbehebung
Bekannte IP-Adresse, SPF-Authentifizierung=Bestanden, SPF-Ausrichtung=Fehlgeschlagen	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 Sie benutzerdefiniertes DKIM beim 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-Ausrichtung=Bestanden	Normaler Microsoft 365-Nachrichtenfluss	Gesund. Keine Aktion erforderlich.
Geringes Volumen von einem legitimen Dienst, SPF und DKIM schlagen fehl	Dienst nicht in SPF enthalten und ohne DKIM-Signierung	Hinzufügen eines Diensts zum SPF-Eintrag und/oder Konfigurieren von DKIM
Weitergeleitete E-Mails (Mailinglisten-IPs), alle schlagen fehl	E-Mail-Weiterleitung macht SPF ungültig; Änderungen am Nachrichtentext machen DKIM ungültig	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	Wird von Empfängern weitgehend unterstützt	Begrenzte 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.

Das folgende Beispiel zeigt die Struktur eines forensischen DMARC-Berichts (AFRF/RFC 6591-Format), den ein Empfänger an Ihre ruf Adresse sendet, wenn eine Nachricht DMARC fehlschlägt. Suchen Sie nach den Feedback-TypeFeldern und Source-IP, Authentication-Results um die Fehlerdetails zu identifizieren:

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

Verwenden Sie die folgenden bewährten Methoden, um die DMARC-Berichterstellung effektiv zu verwalten.

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 ruf bei Bedarf später hinzu. 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 Ihre DMARC-rua- oder ruf-Adresse in einer anderen Domäne als der überwachten 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

Um fabrikam.com zu autorisieren, DMARC-Berichte im Namen von contoso.com zu empfangen, muss der Administrator von fabrikam.com den folgenden DNS-TXT-Eintrag veröffentlichen:

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

Die folgende Tabelle enthält eine Kurzübersicht über häufige DMARC-Symptome, ihre wahrscheinlichen Ursachen, Diagnoseschritte und Auflösungen.

Symptom	Wahrscheinliche Ursache	Diagnoseschritt	Lösung
dmarc=fail SPF und DKIM werden jedoch einzeln übergeben.	Fehler beim Abgleich: Die Domänen stimmen nicht mit dem Feld „Von“ überein	smtp.mailfrom= und header.d= mit header.from= in Authentication-Results überprüfen	SPF/DKIM mit übereinstimmenden Domänen konfigurieren
dmarc=bestguesspass	Kein DMARC-Eintrag für die Domäne "From" veröffentlicht	Txt-Eintrag _dmarc.domain.com abfragen	Microsoft leitet ein Bestehen ab. Veröffentlichen Sie einen expliziten DMARC-Datensatz.
dmarc=fail action=oreject aber Nachricht zugestellt	DMARC berücksichtigen deaktiviert, oder Zulassungsliste/Außerkraftsetzung vorhanden	Überprüfen Sie die Einstellungen der Anti-Phishing-Richtlinie und die Mandanten-Zulassungs-/Sperrliste.	Aktivieren Sie DMARC-Eintragsrichtlinie berücksichtigen, wenn eine strenge Erzwingung gewünscht wird.
dmarc=fail für weitergeleitete Nachrichten	Weiterleitung unterbricht die SPF-Ausrichtung; Textänderungen unterbrechen DKIM	Überprüfen Sie, ob die Nachricht eine Zwischenstation durchlaufen hat (X-MS-Exchange-Header)	Konfigurieren Sie den vertrauenswürdigen ARC-Sealer 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 Sie die zusammengefassten Berichte für die IP-Adresse des Dienstes.	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	Explizites DMARC-Fehlschlagen bei Richtliniendurchsetzung	Die DMARC-Richtlinie des Absenders hat den Fehler verursacht.	Beheben Sie die Ausrichtung an der Quelle, oder konfigurieren Sie 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-Diagnoseablauf

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

1. Identifizieren Sie die Absenderdomäne: Suchen Sie den Wert header.from= 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 stimmt überein.
   • 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 (dieselbe Organisationsdomäne mit adkim=r): DKIM ist abgestimmt.
   • 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 Sie das SPF-Alignment: Ändern Sie die MAIL FROM-Adresse auf Ihre Domäne.
   • Korrektur der DKIM-Ausrichtung: Signieren mit d=contoso.com.
   • Verwenden Sie eine Subdomain: Senden Sie von sub.domain.com mit einem eigenen DMARC-Datensatz.
   • Wenn die Nachricht weitergeleitet wird: Konfigurieren Sie einen vertrauenswürdigen ARC-Versiegeler.

5. Überprüfen Sie die Richtlinienmaßnahme:

   • 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 DMARC-Richtlinie anwenden 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 verwenden Sie die folgenden Befehle, um Ihre DMARC-Einstellungen für Antiphishingrichtlinien zu überprüfen, DMARC- und DKIM-DNS-Einträge zu überprüfen, aktuelle DMARC-Fehler zu überprüfen und die ARC-Konfiguration zu überprüfen:

# 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. Gleichen Sie dies mit Ihren DMARC-Aggregatberichten ab, um das Volumen und die Quell-IP-Adressen zu sehen.
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.