Verwenden von DMARC zum Überprüfen von E-Mails

  • Artikel

Tipp

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

Gilt für

Die domänenbasierte Nachrichtenauthentifizierung, Berichterstellung und Konformität (DMARC) funktioniert zusammen mit Sender Policy Framework (SPF) und DomainKeys Identified Mail (DKIM) bei der E-Mail-Absender-Authentifizierung.

DMARC stellt sicher, dass die Ziel-E-Mail-Systeme Nachrichten vertrauen, die von Ihrer Domäne gesendet werden. Die Verwendung von DMARC mit SPF und DKIM bietet Organisationen mehr Schutz vor Spoofing und Phishing-E-Mails. DMARC hilft beim Empfangen von E-Mail-Systemen bei der Entscheidung, was mit Nachrichten aus Ihrer Domäne geschieht, bei denen SPF- oder DKIM-Überprüfungen fehlschlagen.

Tipp

Besuchen Sie den Microsoft Intelligent Security Association (MISA)-Katalog, um zu sehen, welche Drittanbieter DMARC-Berichterstellung für Microsoft 365 bieten.

Tipp

Haben Sie unsere Schritt-für-Schritt-Anleitungen gesehen? Konfiguration 1-2-3s und ohne Schnickschnack, für Administratoren, die es eilig haben. Besuchen Sie die Schritte zum Aktivieren der DMARC-Berichterstellung für Microsoft Online Email Routingadressen (MOERA) und geparkte Domänen.

Wie arbeiten SPF und DMARC zusammen, um E-Mails in Microsoft 365 zu schützen?

Eine E-Mail kann mehrere Ersteller- oder Absenderadressen enthalten. Diese Adressen können für verschiedene Zwecke verwendet werden. Sehen Sie sich beispielsweise die folgenden Adressen an:

  • "E-Mail von"-Adresse: Identifiziert den Absender und gibt an, wohin Rücksendebenachrichtigungen gesendet werden sollen, wenn Probleme mit der Zustellung der Nachricht auftreten (z. B. Unzustellbarkeitsbenachrichtigungen). Mail "Von"-Adresse erscheint im Umschlagteil einer E-Mail-Nachricht und wird von Ihrer E-Mail-Anwendung nicht angezeigt, und wird manchmal als 5321.MailFrom-Adresse oder umgekehrte Pfadadresse bezeichnet.

  • „Von"-Adresse: die Adresse, die von der E-Mail-Anwendung als Absenderadresse angezeigt wird. "Von"-Adresse identifiziert den Autor der E-Mail. Das heißt, das Postfach der Person oder des Systems, das sich für das Schreiben der Nachricht verantwortlich zeichnet. Die "Von"-Adresse wird manchmal als 5322.From-Adresse bezeichnet.

SPF verwendet einen DNS TXT-Eintrag, um autorisierte sendende IP-Adressen für eine bestimmte Domäne aufzulisten. In der Regel werden SPF-Prüfungen nur für die „5321.MailFrom"-Adresse durchgeführt. Die 5322.From-Adresse wird nicht authentifiziert, wenn Sie SPF allein verwenden. Dies ermöglicht ein Szenario, in dem ein Benutzer eine Nachricht erhält, die SPF-Überprüfungen bestanden hat, aber über eine gefälschte Absenderadresse "5322.From" verfügt. Betrachten Sie beispielsweise das folgende SMTP-Transkript:

S: Helo woodgrovebank.com
S: Mail from: phish@phishing.contoso.com
S: Rcpt to: astobes@tailspintoys.com
S: data
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings User,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that Microsoft has the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

In diesem Transkript lauten die Absenderadressen wie folgt:

  • E-Mail von Adresse (5321.MailFrom): phish@phishing.contoso.com

  • Von Adresse (5322.From): security@woodgrovebank.com

Wenn Sie SPF konfiguriert haben, überprüft der empfangende Server die E-Mail von der Adresse phish@phishing.contoso.com. Wenn die Nachricht aus einer gültigen Quelle der Domäne „phishing.contoso.com“ stammt, dann besteht sie die SPF-Prüfung. Da der E-Mail-Client nur die Von-Adresse anzeigt, sieht der Benutzer, dass diese Nachricht von security@woodgrovebank.comstammt. Wenn nur SPF verwendet wird, wird die Gültigkeit von „woodgrovebank.com" nicht authentifiziert.

Wenn Sie DMARC verwenden, führt der empfangende Server auch eine Prüfung der Absenderadresse durch. Wenn im obigen Beispiel ein DMARC TXT-Eintrag für woodgrovebank.com vorhanden ist, schlägt die Überprüfung der Absenderadresse fehl.

Was ist ein DMARC-TXT-Eintrag?

Wie die DNS-Einträge für SPF ist der Eintrag für DMARC ein DNS-Texteintrag (TXT), der vor Spoofing- und Phishing-E-Mails schützt. Sie veröffentlichen DMARC-TXT-Einträge in DNS. DMARC-TXT-Einträge prüfen den Ursprung von E-Mail-Nachrichten, indem sie die IP-Adresse des Absenders mit dem vorgeblichen Besitzer der Absenderdomäne vergleichen. Durch den DMARC-TXT-Eintrag werden autorisierte Server für ausgehende E-Mails gekennzeichnet. Die Ziel-E-Mail-Systeme können dann überprüfen, ob die empfangenen Nachrichten von autorisierten Servern für ausgehende E-Mails stammen.

Der DMARC-TXT-Eintrag von Microsoft sieht in etwa wie folgt aus:

_dmarc.microsoft.com.   3600    IN      TXT     "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com; fo=1"

Weitere Drittanbieter, welche die DMARC-Berichterstellung für Microsoft 365 anbieten, finden Sie im MISA-Katalog.

DMARC für eingehende E-Mail-Nachrichten einrichten

Sie müssen nichts weiter tun, um DMARC für E-Mails einzurichten, die Sie in Microsoft 365 erhalten. Es wird alles erledigt. Wenn Sie mehr darüber erfahren möchten, was mit E-Mail-Nachrichten geschieht, die unsere DMARC-Prüfungen nicht bestehen, finden Sie weitere Informationen unter So behandelt Microsoft 365 eingehende E-Mail-Nachrichten, die DMARC-Prüfungen nicht bestehen.

DMARC für ausgehende E-Mail-Nachrichten von Microsoft 365 einrichten

Wenn Sie Microsoft 365 jedoch keine benutzerdefinierte Domäne verwenden (Sie verwenden die Domäne „onmicrosoft.com"), ist SPF bereits eingerichtet, und Microsoft 365 generiert automatisch eine DKIM-Signatur für Ihre ausgehenden E-Mails (weitere Informationen zu dieser Signatur finden Sie unter Standardverhalten für DKIM und Microsoft 365). Um DMARC für Ihre organization einzurichten, müssen Sie den DMARC TXT-Eintrag für die onmicrosoft.com Domäne erstellen und ihn über Office 365 Admin Center-Einstellungen>> Domänen > auf onmicrosoft.com Domäne > Eintrag hinzufügen veröffentlichen.

Wenn Sie über eine benutzerdefinierte Domäne verfügen oder lokale Exchange-Server zusammen mit Microsoft 365 verwenden, müssen Sie DMARC für Ihre ausgehenden E-Mails manuell einrichten. Das Einrichten von DMARC für Ihre benutzerdefinierte Domäne umfasst die folgenden Schritte:

Schritt 1: Identifizieren gültiger E-Mail-Nachrichtenquellen für Ihre Domäne

Wenn Sie SPF bereits eingerichtet haben, haben Sie diese Übung bereits durchlaufen. Es gibt einige weitere Überlegungen zu DMARC. Beantworten Sie beim Identifizieren von E-Mail-Quellen für Ihre Domäne die folgenden beiden Fragen:

  • Welche IP-Adressen senden Nachrichten aus meiner Domäne?

  • Was E-Mail-Nachrichten betrifft, die von Drittanbietern in meinem Auftrag gesendet werden: Stimmen die Domänen für „5321.MailFrom“ und „5322.From“ überein?

Schritt 2: Einrichten von SPF für Ihre Domäne

Sie haben nun eine Liste aller gültigen Absender erstellt und können die Schritte unter Einrichten von SPF zum Verhindern von Spoofing befolgen.

Beispiel: Angenommen, „contoso.com" sendet E-Mail-Nachrichten von Exchange Online, einem lokalen Exchange-Server mit der IP-Adresse 192.168.0.1 und einer Webanwendung mit der IP-Adresse 192.168.100.100, dann sieht der SPF-TXT-Eintrag wie folgt aus:

contoso.com  IN  TXT  " v=spf1 ip4:192.168.0.1 ip4:192.168.100.100 include:spf.protection.outlook.com -all"

Es ist eine bewährte Methode sicherzustellen, dass Ihr SPF-TXT-Eintrag auch Absenderadressen von Drittanbietern berücksichtigt.

Schritt 3: Einrichten von DKIM für Ihre benutzerdefinierte Domäne

Nachdem Sie SPF eingerichtet haben, müssen Sie DKIM einrichten. Mit DKIM können Sie E-Mail-Nachrichten in der Kopfzeile der Nachricht eine digitale Signatur hinzufügen. Wenn Sie DKIM nicht einrichten und stattdessen zulassen, dass Microsoft 365 die DKIM-Standardkonfiguration für Ihre Domäne verwenden, schlägt DMARC möglicherweise fehl. Dieser Fehler kann auftreten, weil die DKIM-Standardkonfiguration Ihre ursprüngliche onmicrosoft.com -Domäne als 5321.MailFrom-Adresse verwendet, nicht Ihre benutzerdefinierte Domäne. Dies führt zu einem Konflikt zwischen den 5321.MailFrom und 5322.From-Adressen in allen E-Mails, die von Ihrer Domäne gesendet wurden.

Wenn Sie über Drittanbieter verfügen, die in Ihrem Auftrag E-Mail-Nachrichten senden, und die „5321.MailFrom“- und „5322.From“-Adressen einer von diesen Anbietern gesendeten E-Mail-Nachricht nicht übereinstimmen, dann besteht diese E-Mail-Nachricht die DMARC-Prüfung nicht. Um dies zu vermeiden, müssen Sie DKIM für Ihre Domäne speziell mit diesen Drittanbietern als Absendern einrichten. Dadurch kann Microsoft 365 E-Mail-Nachrichten dieses Drittanbieterdiensts authentifizieren. Allerdings können auch andere, wie beispielsweise Yahoo, Google Mail und Comcast, E-Mail-Nachrichten, die von Ihrem Drittanbieter an sie gesendet wurden, als von Ihnen gesendet authentifizieren. Dies ist nützlich, da es Ihren Kunden ermöglicht, eine Vertrauensstellung mit Ihrer Domäne unabhängig davon zu erstellen, wo sich das Postfach befindet. Gleichzeitig markiert Microsoft 365 eine Nachricht aufgrund von Spoofing nicht als Spam, da sie die Authentifizierungsprüfungen für Ihre Domäne besteht.

Anleitungen zum Einrichten von DKIM für Ihre Domäne, einschließlich der Einrichtung von DKIM für Drittanbieter als Absender, die Ihre Domäne verwenden, finden Sie unter Verwenden von DKIM zum Überprüfen ausgehender E-Mails, die von Ihrer benutzerdefinierten Domäne gesendet werden.

Schritt 4: Erstellen des DMARC-TXT-Eintrags für Ihre Domäne

Obwohl es andere Syntaxoptionen gibt, die hier nicht erwähnt werden, sind dies die am häufigsten verwendeten Optionen für Microsoft 365. Erstellen Sie den DMARC-TXT-Eintrag für Ihre Domäne im folgenden Format:

_dmarc.domain  TTL  IN  TXT  "v=DMARC1; p=policy; pct=100"

Dabei gilt:

  • domain ist die Domäne, die Sie schützen möchten. Standardmäßig schützt der Eintrag E-Mail-Nachrichten von dieser Domäne und allen Unterdomänen. Beispiel: Wenn Sie „_dmarc.contoso.com“ angeben, schützt DMARC E-Mail-Nachrichten der Domäne und aller Unterdomänen, wie z. B. „housewares.contoso.com“ oder „plumbing.contoso.com“.

  • TTL (Gültigkeitsdauer) muss immer einer Stunde entsprechen. Die für „TTL“ verwendete Einheit, entweder Stunden (1 Stunde), Minuten (60 Minuten) oder Sekunden (3600 Sekunden), unterscheidet sich je nach Registrierungsstelle Ihrer Domäne.

  • pct=100 gibt an, dass diese Regel für alle E-Mail-Nachrichten (100 %) verwendet werden soll.

  • policy gibt an, welche Richtlinien der empfangende Server befolgen soll, wenn die DMARC-Prüfung nicht bestanden wird. Sie können für die Richtlinie „none“ (keine), „quarantine“ (Quarantäne) oder „reject“ (ablehnen) festlegen.

Um mehr darüber zu erfahren, welche Optionen Sie verwenden sollten, machen Sie sich mit den Konzepten unter Bewährte Methoden zum Implementieren von DMARC in Microsoft 365 vertraut.

Beispiele:

  • Richtlinie auf „none“ festgelegt

    _dmarc.contoso.com 3600 IN  TXT  "v=DMARC1; p=none"

  • Richtlinien auf „quarantine“ festgelegt

    _dmarc.contoso.com 3600 IN  TXT  "v=DMARC1; p=quarantine"

  • Richtlinie auf „reject“ festgelegt

    _dmarc.contoso.com  3600 IN  TXT  "v=DMARC1; p=reject"

Nachdem Sie Ihren Datensatz erstellt haben, müssen Sie den Eintrag bei Ihrer Domänenregistrierungsstelle aktualisieren.

DMARC-E-Mail

Achtung

E-Mails dürfen nicht täglich versendet werden.

In diesem Beispiel dmarc txt record: dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.example.com; ruf=mailto:d@ruf.example.com; fo=1"sehen Sie die rua-Adresse . Diese Adresse wird verwendet, um "aggregiertes Feedback" für die Analyse zu senden, das zum Generieren eines Berichts verwendet wird.

Tipp

Besuchen Sie den MISA-Katalog, um weitere Drittanbieter anzuzeigen, welche DMARC-Berichterstellung für Microsoft 365 anbieten. Weitere Informationen zu DMARC-"Rua"-Adressen finden Sie in "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" von IETF.org.

Bewährte Methoden zum Implementieren von DMARC in Microsoft 365

Sie können DMARC allmählich implementieren, ohne den übrigen E-Mail-Nachrichtenfluss zu beeinträchtigen. Erstellen und implementieren Sie einen Rolloutplan, der die folgenden Schritte ausführt. Führen Sie die einzelnen Schritte zunächst für eine Unterdomäne, dann weitere Unterdomänen und schließlich für die Domäne der obersten Ebene in Ihrer Organisation aus, bevor Sie mit dem nächsten Schritt fortfahren.

  1. Überwachen der Auswirkungen, die die Implementierung von DMARC hat

    Beginnen Sie mit einem einfachen Überwachungsmoduseintrag für eine Unterdomäne oder eine Domäne, der erfordert, dass DMARC-Empfänger Ihnen Statistiken zu Nachrichten schicken, die sie bei der Verwendung der Domäne sehen. Ein Überwachungsmoduseintrag ist ein DMARC-TXT-Eintrag, für den als Richtlinie „none" (keine) festgelegt wurde (p=none). Viele Unternehmen veröffentlichen einen DMARC TXT-Eintrag mit p=none, da sie nicht sicher sind, wie viele E-Mails sie verlieren könnten, indem sie eine restriktivere DMARC-Richtlinie veröffentlichen.

    Sie können dies sogar durchführen, bevor Sie in Ihrer Messaginginfrastruktur SPF oder DKIM implementiert haben. Sie können E-Mail-Nachrichten jedoch erst dann effektiv mit DMARC in Quarantäne verschieben oder ablehnen, wenn Sie SPF und DKIM implementiert haben. Wenn Sie SPF und DKIM einführen, geben die über DMARC generierten Berichte die Anzahl und die Quellen von Nachrichten an, die diese Überprüfungen bestehen, und welche nicht. So können Sie problemlos erkennen, wie viel des autorisierten Nachrichtenverkehrs abgedeckt wird, und Sie können auftretende Probleme beheben. Außerdem sehen Sie, wie viele betrügerische Nachrichten gesendet werden und von wo aus sie gesendet werden.

  2. Anfordern, dass externe E-Mail-Systeme Nachrichten isolieren, die die DMARC-Prüfung nicht bestehen

    Wenn Sie denken, dass der gesamte oder der meiste autorisierte Nachrichtenverkehr durch SPF und DKIM geschützt ist und Ihnen die Auswirkungen der Implementierung von DMARC bewusst sind, können Sie eine Quarantänerichtlinie implementieren. Eine Quarantänerichtlinie ist ein DMARC-TXT-Eintrag, dessen Richtlinie auf „quarantine" festgelegt ist (p=quarantine). Auf diese Weise bitten Sie DMARC-Empfänger, Nachrichten aus Ihrer Domäne, die DMARC nicht bestehen, in das lokale Äquivalent eines Spamordners anstatt in die Posteingänge Ihrer Kunden zu verschieben.

  3. Anfordern, dass externe E-Mail-Systeme keine Nachrichten akzeptieren, die die DMARC-Prüfung nicht bestehen

    Der letzte Schritt ist das Implementieren einer Ablehnungsrichtlinie. Eine Ablehnungsrichtlinie ist ein DMARC-TXT-Eintrag, dessen Richtlinie auf „reject" festgelegt ist (p=reject). Wenn Sie dies festlegen, fordern Sie DMARC-Empfänger auf, keine Nachrichten zu akzeptieren, die die DMARC-Prüfungen nicht bestehen.

  4. Wie richte ich DMARC für Unterdomänen ein?

    DMARC wird durch die Veröffentlichung einer Richtlinie als TXT-Eintrag in DNS implementiert und ist hierarchisch (z. B. gilt eine richtlinie, die für contoso.com veröffentlicht wird, für sub.domain.contoso.com es sei denn, es ist explizit eine andere Richtlinie für die Unterdomäne definiert). Dies ist nützlich, da Organisationen eine kleinere Anzahl von DMARC-Einträgen auf hoher Ebene für eine breitere Abdeckung angeben können. Achten Sie darauf, explizite DMARC-Einträge für Unterdomänen zu konfigurieren, bei denen die Unterdomänen nicht den DMARC-Eintrag der Domäne der obersten Ebene erben sollen.

    Sie können auch eine Wildcard-Typ-Richtlinie für DMARC hinzufügen, wenn Subdomains keine E-Mails senden sollten, indem Sie den Wert sp=reject hinzufügen. Zum Beispiel:

    _dmarc.contoso.com. TXT "v=DMARC1; p=reject; sp=reject; ruf=mailto:authfail@contoso.com; rua=mailto:aggrep@contoso.com"

DMARC Reject

Hinweis

Die in diesem Abschnitt beschriebenen Features befinden sich derzeit in der Vorschauphase, sind nicht in allen Organisationen verfügbar und können sich ändern.

DMARC p = reject ist eine DMARC-Richtlinie, die von Domänenbesitzern in ihrem DNS festgelegt wird, um Dienstanbieter zu benachrichtigen, E-Mails abzulehnen .

Dies ist darauf zurückzuführen, dass mit OReject als Standardeinstellung für reject alle abgelehnten E-Mails in die Quarantäne in Enterprise und junk-Ordner in Consumer (aufgrund fehlender Quarantäne dort) gesendet wurden. Mit DMARC Reject werden die Mails jedoch einfach abgelehnt.

Die Konfiguration kann im Microsoft 365 Defender-Portal oder über die Cmdlets New-AntiPhishPolicy oder Set-AntiPhishPolicy in Exchange Online PowerShell erfolgen. Weitere Informationen finden Sie in den folgenden Artikeln:

So behandelt Microsoft 365 ausgehende E-Mail-Nachrichten, die DMARC-Prüfungen nicht bestehen

Wenn eine Nachricht von Microsoft 365 gesendet wird (ausgehende Nachricht), die DMARC-Prüfung nicht besteht und Sie die Richtlinie „p=quarantine" oder „p=reject“ festgelegt haben, wird die Nachricht über den Pool für besonders riskante Zustellungen für ausgehende Nachrichten weitergeleitet. Für ausgehende E-Mail-Nachrichten erfolgt keine Außerkraftsetzung.

Wenn Sie eine DMARC-Ablehnungsrichtlinie veröffentlichen (p=reject), kann kein anderer Kunde in Microsoft 365 Ihre Domäne spoofen, da Nachrichten SPF oder DKIM nicht für Ihre Domäne bestehen können, wenn sie eine ausgehende Nachricht über den Dienst weiterleiten. Wenn Sie jedoch eine DMARC-Ablehnungsrichtlinie veröffentlichen, aber nicht alle Ihre E-Mails über Microsoft 365 authentifiziert haben, werden einige davon möglicherweise als Spam für eingehende E-Mails markiert (wie oben beschrieben), oder sie wird abgelehnt, wenn Sie SPF nicht veröffentlichen und versuchen, sie ausgehend über den Dienst weiterzuleiten. Diese geschieht zum Beispiel dann, wenn Sie beim Erstellen des DMARC-TXT-Eintrags vergessen, einige IP-Adressen für Server und Apps einzubeziehen, die E-Mail-Nachrichten im Auftrag Ihrer Domäne senden.

So behandelt Microsoft 365 eingehende E-Mail-Nachrichten, die DMARC-Prüfungen nicht bestehen

Wenn die DMARC-Richtlinie des sendenden Servers p=rejectist, markiert Exchange Online Protection (EOP) die Nachricht als Spoofing, anstatt Sie abzulehnen. Anders ausgedrückt: Für eingehende E-Mails behandelt p=reject Microsoft 365 und p=quarantine auf die gleiche Weise, oder Sie können Antiphishing-Richtlinien konfigurieren, um und in Absender-DMARC-Richtlinien zu berücksichtigen p=quarantine und p=reject separate Aktionen für jede DMARC-Richtlinie anzugeben. Weitere Informationen finden Sie unter Spoofschutz und DMARC-Richtlinien für Absender.

Microsoft 365 ist so konfiguriert, da einige autorisierte E-Mail-Nachrichten die DMARC-Prüfung möglicherweise nicht bestehen. Beispielsweise kann eine Nachricht DMARC nicht bestehen, wenn sie an eine Adressenliste gesendet wird, die die Nachricht dann an alle Listenteilnehmer weiterleitet. Wenn Microsoft 365 diese Nachrichten ablehnen würde, könnten autorisierte E-Mail-Nachrichten für Benutzer verloren gehen, ohne dass die Benutzer sie auf andere Weise abrufen können. Stattdessen treten bei diesen Nachrichten weiterhin DMARC-Fehler auf, sie werden jedoch als Spam gekennzeichnet und nicht abgelehnt. Falls gewünscht, können Benutzer diese Nachrichten immer noch anhand einer der folgenden Methoden in ihrem Posteingang erhalten:

  • Die Benutzer fügen mithilfe des E-Mail-Clients sichere Absender einzeln hinzu.

  • Administratoren können den Einblick in die Spoofintelligenz oder die Mandantenzulassungsliste/-sperrliste verwenden, um Nachrichten von dem gefälschten Absender zuzulassen.

  • Administratoren erstellen eine Exchange-Nachrichtenflussregel (auch bekannt als Transportregel) für alle Benutzer, die Nachrichten dieser bestimmten Absender zulassen.

Weitere Informationen finden Sie unter Erstellen von Listen sicherer Absender.

So verwendet Microsoft 365 ARC (Authenticated Received Chain)

Alle gehosteten Postfächer in Microsoft 365 profitieren nun von ARC mit besserer Zustellbarkeit von Nachrichten und verbessertem Antispoofingschutz. ARC bewahrt die Ergebnisse der E-Mail-Authentifizierung aller teilnehmenden Mittler bzw. Hops, wenn eine E-Mail vom ursprünglichen Server an das Empfängerpostfach geleitet wird. Von Mittlern im E-Mail-Routing vorgenommene Änderungen, z. B. Weiterleitungsregeln oder automatische Signaturen, konnten vor der Verwendung von ARC zu DMARC-Fehlern führen, wenn die E-Mail das Empfängerpostfach erreichte. Mit ARC kann Microsoft 365 anhand der kryptografischen Aufbewahrung der Authentifizierungsergebnisse die Authentizität eines E-Mail-Absenders überprüfen.

Microsoft 365 verwendet ARC zurzeit zur Überprüfung der Authentifizierungsergebnissen, wenn Microsoft der ARC-Sealer ist, aber Sie sollten künftig Unterstützung für ARC-Sealer von Drittanbietern vorsehen.

Problembehandlung bei der DMARC-Implementierung

Wenn Sie die MX-Einträge Ihrer Domäne konfiguriert haben, bei denen EOP nicht der erste Eintrag ist, werden DMARC-Fehler für Ihre Domäne nicht erzwungen.

Wenn Sie Kunde sind und der primäre MX-Eintrag Ihrer Domäne nicht auf EOP verweist, profitieren Sie nicht von den Vorteilen von DMARC. DMARC funktioniert beispielsweise nicht, wenn Sie den MX-Eintrag auf Ihren lokalen E-Mail-Server verweisen und anschließend E-Mail-Nachrichten mithilfe eines Connectors an EOP weiterleiten. In diesem Szenario ist die empfangende Domäne eine Ihrer akzeptierten Domänen, aber EOP ist nicht die primäre MX-Domäne. Nehmen Sie zum Beispiel einmal an, dass „contoso.com“ seinen MX auf sich selbst verweist und EOP als sekundären MX-Eintrag verwendet. Der MX-Eintrag von „contoso.com“ sieht dann wie folgt aus:

contoso.com     3600   IN  MX  0  mail.contoso.com
contoso.com     3600   IN  MX  10 contoso-com.mail.protection.outlook.com

Alle bzw. die meisten E-Mail-Nachrichten werden zuerst an „mail.contoso.com“ weitergeleitet, da dies der primäre MX-Eintrag ist. Anschließend werden die E-Mail-Nachrichten an EOP weitergeleitet. In einigen Fällen führen Sie EOP möglicherweise gar nicht als MX-Eintrag auf, sondern verbinden einfach Connectors zum Weiterleiten von E-Mail-Nachrichten. EOP muss nicht der erste Eintrag für die DMARC-Überprüfung sein. Es stellt lediglich die Validierung sicher, um zu gewährleisten, dass alle lokalen bzw. Nicht-O365-Server DMARC-Prüfungen durchführen. DMARC kann für die Domäne eines Kunden (nicht für den Server) erzwungen werden, wenn Sie den DMARC TXT-Eintrag einrichten, aber es liegt an dem empfangenden Server, die Erzwingung tatsächlich auszuführen. Wenn Sie EOP als Empfangsserver einrichten, führt EOP die DMARC-Erzwingung durch.

Eine Grafik zur Problembehebung für DMARC

Weitere Informationen

Sie möchten mehr über DMARC erfahren? Die folgenden Ressourcen können nützlich sein.

  • Antispam-Nachrichtenkopfzeilen umfassen die Syntax- und Kopfzeilenfelder, die von Microsoft 365 für DMARC-Überprüfungen verwendet werden.

  • Sehen Sie sich die DMARC Training Series von M3AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group) an.

  • Verwenden Sie die Checkliste von dmarcian.

  • Schauen Sie direkt an der Quelle nach: DMARC.org.

Siehe auch

Verwenden des Sender Policy Framework (SPF) durch Microsoft 365 zum Verhindern von Spoofing

Einrichten von SPF in Microsoft 365 zur Verhinderung von Spoofing

Verwenden von DKIM zum Überprüfen ausgehender E-Mails, die von Ihrer benutzerdefinierten Domäne in Microsoft 365 gesendet werden

Verwenden vertrauenswürdiger ARC-Absender für legitime Nachrichtenflüsse