DMARC für Office 365: Schritt-für-Schritt-Einrichtung & Best Practices

Microsoft unterstützt und empfiehlt Nutzern von Microsoft 365 (auch als Office 365 oder M365 bezeichnet) die Einrichtung von DMARC, wodurch diese E-Mail-Authentifizierungsprotokolle einheitlich für alle ihre registrierten Domains anwenden können. In diesem Blogbeitrag erläutern wir die Schritte zur Konfiguration von DMARC für Office 365, um alle Office 365-E-Mails zu validieren, die folgende Merkmale aufweisen:

• Online-E-Mail-Routing-Adressen mit Microsoft haben
• Benutzerdefinierte Domains im Verwaltungszentrum hinzugefügt haben
• Geparkte oder inaktive, aber registrierte Domains haben

Was ist DMARC und warum ist es für Microsoft 365 wichtig?

DMARC ist ein E-Mail-Authentifizierungsprotokoll, das Domains vor Spoofing und Phishing schützt. (Domain-based Message Authentication, Reporting, and Conformance) baut auf SPF und DKIM auf, gleicht die Authentifizierungsergebnisse mit den Domain-Richtlinien ab und teilt den empfangenden Servern mit, wie sie mit Nachrichten umgehen sollen, die diese Prüfungen nicht bestehen.

In einer Microsoft 365-Umgebung erfüllt DMARC eine doppelte Funktion. Es schützt Ihre Domain davor, von Angreifern missbraucht zu werden, und trägt dazu bei, dass Ihre legitimen E-Mails von externen Empfängern als vertrauenswürdig eingestuft werden.

Übernimmt Microsoft 365 die DMARC-Verwaltung für Sie?

Eines der häufigsten Missverständnisse unter Administratoren ist, dass Microsoft 365 die DMARC-Verwaltung für Sie übernimmt.

Microsoft 365 führt zwar eine DMARC-Überprüfung durch, jedoch nur für eingehende E-Mails. Exchange Online Protection (EOP) überprüft automatisch die SPF-, DKIM- und DMARC-Validierung bei Nachrichten, die Ihre Organisation erhält. Das bedeutet, dass Ihre Benutzer bis zu einem gewissen Grad vor gefälschten E-Mails geschützt sind.

Bei ausgehenden E-Mails unternimmt Microsoft jedoch nichts, solange Sie dies nicht konfigurieren. Wenn Sie Ihre Domain schützen und moderne Compliance-Anforderungen erfüllen möchten, müssen Sie einen DMARC-Eintrag in Ihrem DNS veröffentlichen.

Dieser Unterschied ist entscheidend. Microsoft schützt Ihren Posteingang, DMARC hingegen schützt den Ruf Ihrer Domain. Deshalb benötigt Microsoft 365 DMARC auch dann, wenn EOP bereits eingerichtet ist. Die Konfiguration, die Sie nun vornehmen werden, dient dem Schutz ausgehender E-Mails.

Voraussetzungen: SPF und DKIM für Microsoft 365 einrichten

Bevor Sie einen DMARC-Eintrag veröffentlichen, müssen Sie sicherstellen, dass sowohl SPF als auch DKIM für Ihre Domain korrekt konfiguriert sind. DMARC authentifiziert E-Mails nicht selbst, sondern stützt sich vollständig auf die Ergebnisse von SPF und/oder DKIM. Fehlen diese oder sind sie nicht aufeinander abgestimmt, schlägt DMARC fehl, und legitime E-Mails können beeinträchtigt werden, sobald die Durchsetzung aktiviert ist.

Schritt 1: SPF für Microsoft 365 konfigurieren

SPF (Sender Policy Framework) legt fest, welche Mailserver berechtigt sind, E-Mails im Namen Ihrer Domain zu versenden. In einer Microsoft 365-Umgebung umfasst dies in der Regel die eigenen Mailserver von Microsoft sowie alle von Ihnen genutzten Dienste von Drittanbietern.

Manuelle SPF-Einrichtung (DNS-Methode)

So konfigurieren Sie SPF manuell:

1. Rufen Sie die Seite Ihres DNS-Hosting-Anbieters auf (z. B. GoDaddy, Cloudflare usw.)
2. Erstellen oder aktualisieren Sie einen TXT-Eintrag für Ihre Root-Domain

Verwenden Sie den folgenden Standard-SPF-Eintrag für Microsoft 365:

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

Wenn Sie weitere Dienste (wie Mailchimp oder Salesforce) nutzen, müssen Sie diese ebenfalls angeben. Zum Beispiel:

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

Automatisierte SPF-Einrichtung (mit PowerDMARC)

Das manuelle Erstellen von SPF-Einträgen kann komplex werden, insbesondere wenn mehrere Dienste beteiligt sind. Fehler wie das Überschreiten von DNS-Abfrage-Limits oder Fehlkonfigurationen kommen häufig vor.

Die Verwendung der SPF-Tools von PowerDMARC vereinfacht diesen Vorgang. Der SPF-Generator erstellt automatisch einen gültigen Eintrag auf der Grundlage Ihrer Absenderadressen.

Schritt 2: DKIM für Microsoft 365 aktivieren

DKIM (DomainKeys Identified Mail) versieht Ihre E-Mails mit einer kryptografischen Signatur. Dadurch können empfangende Server überprüfen, ob die Nachricht nicht verändert wurde und tatsächlich von Ihrer Domain stammt.

Im Gegensatz zu SPF erfordert DKIM in Microsoft 365 sowohl eine DNS-Konfiguration als auch eine Aktivierung im Admin Center.

Manuelle DKIM-Einrichtung (DNS + Admin Center)

So aktivieren Sie DKIM manuell:

1. Zum Microsoft 365 Defender-Portal wechseln
2. Navigieren Sie zu „E-Mail & Zusammenarbeit“ → „Richtlinien & Regeln“ → „Bedrohungsrichtlinien“ → „DKIM“
3. Wählen Sie Ihre Domain aus

Bildquelle

Bevor Sie DKIM aktivieren können, werden Sie von Microsoft aufgefordert, zwei CNAME-Einträge zu Ihrem DNS hinzuzufügen.

Diese sehen in der Regel so aus:

selector1._domainkey.yourdomain.com → selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

selector2._domainkey.yourdomain.com → selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

Nachdem Sie diese Einträge veröffentlicht haben, kehren Sie zum Admin-Portal zurück und klicken Sie bei DKIM auf „Aktivieren“. Sobald die Funktion aktiviert ist, beginnt Microsoft damit, alle ausgehenden E-Mails mit DKIM zu signieren.

Automatische DKIM-Einrichtung (mit PowerDMARC)

Die Einrichtung von DKIM kann verwirrend sein, insbesondere für Administratoren, die mit CNAME-Einträgen und Selektorformaten nicht vertraut sind.

PowerDMARC vereinfacht diesen Vorgang, indem es automatisch die richtigen DKIM-Einträge für Ihre Domain generiert, eine automatische DNS-Veröffentlichung anbietet, um Fehler bei der manuellen Eingabe zu vermeiden, und einen DKIM-Checker bereitstellt, mit dem Sie überprüfen können, ob DKIM korrekt aktiviert ist

Wie richte ich DMARC für Office 365 ein?

Sobald SPF und DKIM ordnungsgemäß konfiguriert sind, können Sie mit der Einrichtung von DMARC fortfahren. In Microsoft 365 erfolgt dieser Vorgang auf DNS-Ebene, doch um ihn korrekt durchzuführen, müssen Sie Ihr E-Mail-Umfeld kennen, die richtige Richtlinie auswählen und die Ergebnisse vor der Durchsetzung überwachen.

Schritt 1: Alle E-Mail-Absender ermitteln

Bevor Sie einen DMARC-Eintrag veröffentlichen, müssen Sie einen vollständigen Überblick darüber haben, wer E-Mails im Namen Ihrer Domain versendet. Dies ist einer der wichtigsten Schritte, da das Übersehen eines legitimen Absenders später zu Zustellungsfehlern führen kann.

Zu Ihren Absendern gehören in der Regel:

• Microsoft 365 (Exchange Online)
• Marketingplattformen (Mailchimp, HubSpot usw.)
• CRM-Systeme (Salesforce)
• Support-Tools (Zendesk, Freshdesk)
• Interne Anwendungen oder Server

Sollten einige dieser E-Mails nicht ordnungsgemäß über SPF oder DKIM authentifiziert sein, werden sie nach Aktivierung der Durchsetzung die DMARC-Prüfung nicht bestehen.

Schritt 2: Erstellen Sie Ihren DMARC-Eintrag

Ein DMARC-Eintrag ist ein TXT-Eintrag, der in Ihrem DNS veröffentlicht wird. Er definiert Ihre Richtlinien und teilt den empfangenden Servern mit, wie sie mit E-Mails umgehen sollen, die die Authentifizierung nicht bestehen. Mit dem Tool zum sofortigen Erstellen von DMARC-Einträgen von PowerDMARC können Sie einen individuellen Office 365-DMARC-Eintrag für Ihre Domain erstellen.

Ein einfacher DMARC-Eintrag sieht wie folgt aus: v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Schauen wir uns das einmal genauer an:

v=DMARC1 – Gibt die DMARC-Version an
p=none – Überwachungsmodus (keine Durchsetzung)
rua=mailto:[email protected] – Wohin die Sammelberichte gesendet werden
fo=1 – Aktiviert die Fehlermeldung

Dies ist der empfohlene Ausgangspunkt, da Sie so Daten erfassen können, ohne die E-Mail-Zustellung zu beeinträchtigen.

Schritt 3: Veröffentlichen Sie den DMARC-Eintrag im DNS

Sobald Ihr Eintrag fertig ist, müssen Sie ihn in Ihr DNS eintragen.

Verwenden Sie die folgenden Einstellungen:

Datensatztyp: TXT
Host/Name: _dmarc
Wert: Ihr DMARC-Datensatz
TTL: 1 Stunde (oder Standardwert)

Schritt 4: DMARC-Berichte überwachen

Nachdem Sie DMARC mit der Richtlinie „p=none“ aktiviert haben, erhalten Sie Berichte von den empfangenden Servern. Diese Berichte geben Aufschluss darüber, wer E-Mails unter Verwendung Ihrer Domain versendet, welche Nachrichten die Authentifizierung bestehen oder nicht bestehen, sowie über den Übereinstimmungsstatus für SPF und DKIM.

DMARC-Berichte werden in der Regel im XML-Format versendet und lassen sich manuell nur schwer auswerten. Ohne eine gründliche Analyse können Fehlkonfigurationen oder nicht autorisierte Absender leicht übersehen werden.

Schritt 5: Gehen Sie schrittweise zur Durchsetzung über

Sobald Sie Ihre Berichte geprüft und sichergestellt haben, dass alle legitimen Absender ordnungsgemäß authentifiziert sind, können Sie damit beginnen, Ihre DMARC-Richtlinie zu verschärfen.

Ein typischer Ablauf sieht folgendermaßen aus:

Beginnen Sie mit der Überwachung: v=DMARC1; p=none; rua=mailto:[email protected]

↓

In Quarantäne verschieben (verdächtige E-Mails werden in den Spam-Ordner verschoben): v=DMARC1; p=quarantine; rua=mailto:[email protected];

↓

Schließlich die Ablehnung erzwingen: v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

Schritt 6: DMARC für verschiedene Domain-Typen konfigurieren

Die Vorgehensweise kann je nach der Domain, die Sie konfigurieren, variieren.

Schritt 7: Überprüfen und verwalten Sie Ihre Microsoft 365-DMARC-Konfiguration

DMARC ist keine einmalige Einrichtung. Wenn sich Ihr E-Mail-Umfeld verändert, muss sich auch Ihre Konfiguration anpassen. Selbst wenn der Wert „p=reject“ erreicht ist, ist eine kontinuierliche Überwachung unerlässlich, um die Zustellbarkeit und Sicherheit aufrechtzuerhalten.

Sie sollten regelmäßig:

• DMARC-Berichte überprüfen
• SPF-Einträge bei Hinzufügen neuer Absender aktualisieren
• Stellen Sie sicher, dass DKIM aktiviert und korrekt konfiguriert bleibt
• Auf unbefugte Aktivitäten achten

Einführung der DMARC-Richtlinie: Warum eine schrittweise Umsetzung wichtig ist

Der direkte Übergang zu einer Ablehnungsrichtlinie ist einer der häufigsten Fehler bei der DMARC-Implementierung. Ohne Einblick in Ihre E-Mail-Abläufe kann die Durchsetzung dieser Richtlinie die legitime Kommunikation beeinträchtigen.

Eine schrittweise Einführung ermöglicht es Ihnen, Probleme zu überwachen und zu beheben, bevor Sie strenge Richtlinien anwenden. Die meisten Unternehmen verfolgen einen schrittweisen Ansatz, der von der Überwachung über die Quarantäne bis hin zur Ablehnung reicht. Die Dauer jeder Phase hängt von der Komplexität Ihrer E-Mail-Umgebung ab, doch das Überspringen von Schritten erhöht das Risiko unbeabsichtigter Zustellungsfehler.

Wie Exchange Online eingehende DMARC-Nachrichten verarbeitet

Exchange Online Protection überprüft automatisch alle eingehenden Nachrichten auf DMARC-Konformität, und seit Juli 2023 befolgt Microsoft standardmäßig die vom Absender veröffentlichte Richtlinie. Wenn der MX-Eintrag der Empfängerdomäne direkt auf Microsoft 365 verweist, werden Nachrichten, die bei einer p=reject-Richtlinie die DMARC-Prüfung nicht bestehen, am Gateway abgelehnt. Ebenso werden Fehler mit p=quarantine in die Quarantäne verschoben. Dies wird durch die Einstellung„DMARC-Eintrag-Richtlinie beachten, wenn die Nachricht als gefälscht erkannt wird“in der Anti-Phishing-Richtlinie gesteuert, die standardmäßig aktiviert ist.

Bildquelle

Das „oreject“-Verhalten erklärt

Vor Juli 2023 wandte Microsoft bei eingehenden Nachrichten, die die p=reject-Richtlinie des Absenders nicht erfüllten, eine interne Übersteuerung namens „action=oreject“ (Origin Reject) an. Anstatt die E-Mail direkt am Gateway zurückzuweisen, leitete EOP sie in den Junk-Ordner des Empfängers weiter und versah den Header mit der Aktion „oreject“.

Microsoft hat dies bewusst so gestaltet, da weitergeleitete E-Mails und der Verkehr über Mailinglisten während der Übertragung häufig gegen SPF und DKIM verstoßen. Das bedeutet, dass eine legitime Nachricht, die beim ursprünglichen Absender die Authentifizierung besteht, diese möglicherweise nicht mehr besteht, wenn sie bei einem sekundären Empfänger eintrifft. Eine strikte Ablehnung mit „p=reject“ hätte dazu geführt, dass neben den gefälschten Nachrichten auch eine beträchtliche Menge legitimer E-Mails verworfen worden wäre. Der Spam-Ordner stellte einen Kompromiss dar: Die Empfänger konnten die E-Mails bei Bedarf weiterhin abrufen, und die Richtlinie des Absenders wurde technisch gesehen eingehalten.

Der Nachteil war, dass gefälschte Nachrichten, die eigentlich hätten zurückgewiesen werden müssen, dennoch in den Posteingängen der Nutzer landeten (im Spam-Ordner), wo ein unaufmerksamer Empfänger sie möglicherweise öffnete. Für die Sicherheitsteams bedeutete dies, dass die Durchsetzung von DMARC nie so streng wirkte, wie es die Richtlinie vorgab.

Wann Sie heute noch „oreject“ sehen werden

Da sich die Standardeinstellung geändert hat, behandelt EOP „p=reject“ nun als echte Ablehnung für Direct-MX-Flows. Das frühere Verhalten ist jedoch nicht vollständig verschwunden. In drei Fällen wird weiterhin „oreject“ angezeigt:

1. „Honor DMARC“ ist in Ihrer Anti-Phishing-Richtlinie deaktiviert.

So beheben Sie das Problem: Überprüfen Sie die Einstellung unter „Microsoft 365 Defender“ → „E-Mail und Zusammenarbeit“ → „Bedrohungsrichtlinien“ → „Anti-Phishing“ → „Spoof-Einstellungen“. Die Option ist standardmäßig aktiviert, kann jedoch bei Mandanten, die von älteren Konfigurationen migriert wurden, deaktiviert sein.

2. E-Mails werden über ein Gateway eines Drittanbieters geleitet, bevor sie Microsoft 365 erreichen.

Wenn Ihr MX-Eintrag auf eine Sicherheitslösung (Proofpoint, Mimecast usw.) verweist, die die E-Mails anschließend an EOP weiterleitet, kann Microsoft DMARC nicht erneut bewerten, es sei denn, Sie aktivieren im Defender-Portal die erweiterte Filterung für Konnektoren. Ohne diese Funktion vertraut EOP dem Urteil des vorgelagerten Gateways und lehnt fehlgeschlagene E-Mails standardmäßig ab.

3. Eine Zulassungsregel auf Mandantenebene umgeht die Filterung.

Absender auf der Whitelist, vertrauenswürdige eingehende Verbindungen oder Transportregeln, die den Spam Confidence Level (SCL -1) zuweisen, umgehen die DMARC-Durchsetzung vollständig, sodass die Nachricht unabhängig von den Richtlinien im Posteingang landet.

Für eine strengere Handhabung aktivieren Sie im Defender-Portal neben „Honor DMARC“ auch „Spoof Intelligence“. Spoof Intelligence bewertet die Absenderreputation unabhängig von DMARC und stellt Nachrichten unter Quarantäne, die wie Identitätsbetrugsversuche aussehen, selbst wenn die Authentifizierung technisch gesehen erfolgreich ist.

Verschärfung der Kontrollen im Wareneingang durch Transportvorschriften

Für Organisationen, die eine garantierte Ablehnung von E-Mails wünschen, die die DMARC-Prüfung nicht bestehen, ist eine Exchange Online-Transportregel der zuverlässigste Mechanismus.

So erstellen Sie die Regel:

1. Gehen Sie zu „Exchange-Verwaltungscenter“ → „E-Mail-Fluss“ → „Regeln“ und erstellen Sie eine neue Regel.
2. Bedingung festlegen: Ein Nachrichten-Header enthält eines der folgenden Wörter. Header-Name: Authentication-Results. Header-Wert: dmarc=fail action=oreject.
3. Legen Sie die Aktion fest: Lehnen Sie die Nachricht mit folgender Begründung ab: Geben Sie etwa Folgendes ein: „Die Nachricht hat die DMARC-Authentifizierung nicht bestanden und wurde gemäß den Unternehmensrichtlinien abgelehnt.“
4. (Optional) Fügen Sie eine Ausnahme für vertrauenswürdige interne Absender oder bekannte legitime Weiterleiter hinzu, um Fehlalarme zu vermeiden.
5. Stellen Sie den Regelmodus in der ersten Woche auf „Testen mit Richtlinienhinweisen“ ein. Überprüfen Sie die erfassten Nachrichten im Nachrichtenverlauf, bevor Sie auf „Durchsetzen“ umschalten.

Weitere Informationen finden Sie in der ausführlichen Dokumentation von Microsoft zu Mail-Flow-Regeln.

Wann dieser Ansatz anzuwenden ist:

Transportregeln sind sinnvoll, wenn gesetzliche Vorschriften oder interne Richtlinien eine konsequente Ablehnung fehlerhafter E-Mails vorschreiben, wenn Ihr Unternehmen ein besonders attraktives Ziel für Spoofing-Angriffe ist (Finanzwesen, Rechtsabteilung, Kommunikation der Geschäftsleitung) oder wenn Sie ein einheitliches Verhalten sowohl bei direkten MX- als auch bei Gateway-Verbindungen von Drittanbietern wünschen.

Microsofts DMARC-Durchsetzung ab Mai 2025: Was hat sich geändert?

Im Mai 2025 führte Microsoft eine wesentliche Änderung im Umgang mit nicht authentifizierten E-Mails von externen Absendern ein. Diese Änderung betrifft in erster Linie Absender mit hohem E-Mail-Aufkommen, hat jedoch weitreichende Auswirkungen auf alle Organisationen.

Im Großen und Ganzen stehen die Anforderungen von Microsoft an E-Mail-Absender im Einklang mit dem allgemeinen Trend in der Branche hin zu einer strengeren Authentifizierung und einer stärkeren Rechenschaftspflicht der Absender. Mit der Aktualisierung werden klare Schwellenwerte, Durchsetzungsmaßnahmen und Erwartungen eingeführt, die zuvor eher locker gehandhabt wurden.

Wichtige Änderungen, die von Microsoft eingeführt wurden

• DMARC-Pflicht für Massenversender: Domains, die täglich mehr als 5.000 E-Mails an Microsoft-Kundendienste senden, müssen nun über einen gültigen DMARC-Eintrag verfügen.
• Gilt für Outlook.com, Hotmail.com und Live.com: Die Durchsetzung zielt speziell auf das Postfach-Ökosystem für Privatkunden von Microsoft ab, nicht nur auf Unternehmensmandanten.
• Mindestanforderung: DMARC mit p=none: Selbst eine Überwachungsrichtlinie ist akzeptabel, doch das Fehlen eines DMARC-Eintrags wird im großen Maßstab nicht mehr toleriert.
• Stärkere Betonung der Domain-Übereinstimmung: Eine Authentifizierung allein reicht nicht aus; SPF und DKIM müssen mit der sichtbaren „Von“-Domain übereinstimmen, damit DMARC den Test besteht.
• Kategorische Ablehnung wegen Nichteinhaltung der Anforderungen: E-Mails, die die Anforderungen nicht erfüllen, können mit folgender Meldung blockiert werden: 550 5.7.515 Zugriff verweigert, die sendende Domain [SendingDomain] erfüllt nicht das erforderliche Authentifizierungsniveau.

Mit dieser Änderung schließt sich Microsoft Google und Yahoo an, die im Februar 2024 ähnliche Anforderungen eingeführt haben, sodass nun alle drei größten E-Mail-Anbieter eine Authentifizierung für Massenversender vorschreiben.

Plattformen wie PowerDMARC schließen diese Lücke, indem sie spezielle Compliance-Programme anbieten, die auf die Anforderungen der E-Mail-Anbieter für alle Ihre Absenderquellen abgestimmt sind.

Warum Microsoft 365 allein nicht ausreicht

Microsoft 365 bietet zwar einen starken Schutz für eingehende E-Mails, verfügt jedoch nur über begrenzte Funktionen für die Verwaltung und Überwachung von DMARC in großem Maßstab – Funktionen, die spezielle E-Mail-Authentifizierungsplattformen bieten.

Fehlen von für Menschen lesbaren Berichten

Zwar versendet Microsoft mittlerweile DMARC-Berichte für Unternehmenskunden, doch gibt es kein integriertes System, um diese Berichte sinnvoll zusammenzufassen und auszuwerten. Diese Berichte werden im XML-Format übermittelt und lassen sich ohne spezielle Tools nur schwer analysieren. Infolgedessen fehlt es Unternehmen oft an Transparenz darüber, wer in ihrem Namen E-Mails versendet und ob diese Absender ordnungsgemäß authentifiziert sind.

Keine Leitlinien zur Durchsetzung

Microsoft bietet keine automatisierte Anleitung für den Übergang von der Überwachung zur Durchsetzung. Daher müssen Administratoren die Daten manuell auswerten und Entscheidungen treffen, die sich auf die E-Mail-Zustellung auswirken können.

Nicht für die laufende Verwaltung geeignet

Eine spezielle DMARC-Lösung wandelt Rohdaten aus Berichten in verwertbare Erkenntnisse um. Sie ermöglicht eine kontinuierliche Überwachung, vereinfacht die Richtlinienverwaltung und unterstützt Unternehmen dabei, sicher und schrittweise eine vollständige Durchsetzung zu erreichen – und zwar in einem Umfang, den Microsoft 365 von Haus aus nicht bietet.

Behebung häufiger DMARC-Probleme in Office 365

1. Es wurde kein DMARC-Eintrag veröffentlicht

Dies ist das häufigste Problem. „Kein DMARC-Eintrag veröffentlicht“ bedeutet im Grunde genommen, dass in Ihrem DNS-Eintrag für Ihre Domain kein DMARC-TXT-Eintrag vorhanden ist, sodass die Empfänger keine Richtlinie haben, nach der sie handeln können.

Um dieses Problem zu beheben, gehen Sie zunächst wie folgt vor:

• Überprüfen Sie dies mithilfe eines DMARC-Checkers.
• Wenn das Tool die Fehlermeldung „DMARC-Eintrag fehlt“ ausgibt, müssen Sie einen Eintrag mit dem Format „v=DMARC1; p=none; rua=mailto:[email protected]“ veröffentlichen, damit Sie mit der Erfassung von Berichten beginnen können, bevor Sie die Richtlinien verschärfen.
• Sobald Sie mit Ihrer Konfiguration vertraut sind, können Sie schrittweise zur Durchsetzung übergehen und dabei Ihre Berichte im Auge behalten.

2. Durch das Weiterleiten werden SPF und DKIM umgangen

Die E-Mail-Weiterleitung ist die mit Abstand häufigste Ursache für legitime, aber fehlgeschlagene E-Mails. Wenn ein Zwischenglied (Mailingliste, Weiterleitungsdienst oder Sicherheitsgerät) einen in der DKIM-Signatur enthaltenen Header verändert, lässt sich die Signatur nicht mehr verifizieren, und DKIM schlägt fehl. In der Regel bricht auch SPF gleichzeitig zusammen, da die IP-Adresse des Weiterleitungsservers nicht in Ihrem Eintrag enthalten ist.

Hier sind drei mögliche bewährte Vorgehensweisen zur Fehlerbehebung:

• Bevorzugen Sie eine DKIM-konforme Signatur an der Quelle, da DKIM Weiterleitungen besser übersteht als SPF, wenn die Header nicht umgeschrieben werden
• Vermeiden Sie „Sender Rewriting Scheme“ (SRS) als Lösung, da es zwar SPF korrigiert, aber die Übereinstimmung der Absenderdomain nicht wiederherstellt, sodass DMARC weiterhin fehlschlägt
• Konfigurieren Sie vertrauenswürdige ARC-Sealer (Authenticated Received Chain) in Microsoft Defender für jeden Weiterleitungsdienst, der Ihre E-Mails rechtmäßig verändert. Microsoft berücksichtigt das vorgelagerte Authentifizierungsergebnis über die ARC-Kette, anstatt die Nachricht sofort als ungültig zu markieren.

3. SPF-Permerror aufgrund zu vieler DNS-Abfragen

Wenn SPF plötzlich bei jeder legitimen Quelle fehlschlägt und einen permanenten Fehler zurückgibt, liegt die Ursache in der Regel eher auf struktureller Ebene als auf der Konfigurationsebene.

Dafür gibt es möglicherweise zwei Ursachen:

• Erstens haben Sie das von SPF festgelegte Limit von 10 Lookups für die Mechanismen „include“, „a“, „mx“, „redirect“, „exists“ und „ptr“ überschritten. Auch verschachtelte Lookups innerhalb von Vendor-Includes werden mitgezählt, sodass ein Eintrag, der auf den ersten Blick korrekt erscheint, unbemerkt bereits 12 oder 13 Lookups aufweisen kann. Sobald dieses Limit überschritten wird, gibt jeder Empfänger einen „permerror“ zurück, und die SPF-basierte DMARC-Übereinstimmung bricht für die gesamte Domain auf einmal zusammen.

Vorgehensweise: Überprüfen Sie zunächst Ihre Einträge mit einem SPF-Lookup-Tool und entfernen Sie Anbieter, die Sie nicht mehr nutzen. Dies ist jedoch nur eine vorübergehende Lösung. Eine langfristige Lösung ist der Einsatz einer gehosteten SPF-Lösung wie PowerSPF mit SPF-Makro-Optimierung für die dynamische Verwaltung von SPF-Lookups.

• Der zweite Grund für „Temperror“-Fehler, die speziell bei Microsoft-Zielen auftreten, könnten DNS-Timeouts sein. Wenn die Timeouts bei einem bestimmten Eintrag auftreten, sollte dieser Anbieter aus der Liste entfernt oder umgestellt werden.

4. Die „p=reject“-Richtlinien werden nicht eingehalten

Seit Juli 2023 wendet Microsoft standardmäßig „p=reject“ an, d. h., eine fehlerhafte Nachricht sollte sofort abgelehnt werden. Ist dies nicht der Fall, liegt einer der folgenden vier Gründe vor:

• Die DMARC-Einhaltung ist möglicherweise in Ihrer Anti-Phishing-Richtlinie deaktiviert: Stellen Sie sicher, dass die Option „DMARC-Eintrag-Richtlinie einhalten, wenn die Nachricht als gefälscht erkannt wird“ aktiviert ist und dass die Aktion für p=reject auf „Ablehnen“ (nicht „Quarantäne“) eingestellt ist.
• Vor Microsoft 365 ist ein Gateway eines Drittanbieters geschaltet: Wenn Ihr MX-Eintrag auf ein Sicherheitsgateway eines Drittanbieters verweist, setzt Microsoft DMARC nicht durch, es sei denn, Sie aktivieren die erweiterte Filterung für Konnektoren.
• Die zusammengesetzte Authentifizierung hat das Ergebnis außer Kraft gesetzt: Microsoft ergänzt DMARC um Reputationssignale. Eine Nachricht kann DMARC nicht bestehen und dennoch zugestellt werden, wenn compauth=pass gilt
  (Weitere Informationen hierzu finden Sie in der Microsoft-Lerngemeinschaft).
• Eine Zulassungsregel für einen Mandanten umgeht die Filterung: Ein auf der Zulassungsliste stehender Absender, ein vertrauenswürdiger eingehender Connector oder eine Regel, die den Spam-Vertrauensgrad SCL-1 zuweist, führt dazu, dass die DMARC-Durchsetzung vollständig übersprungen wird.

Weiterentwicklung von DMARC in Microsoft 365

DMARC in Microsoft 365 ist ein zweischneidiges Schwert. Exchange Online Protection übernimmt die Validierung eingehender E-Mails automatisch für Sie, doch der Schutz ausgehender E-Mails liegt vollständig in Ihrer Verantwortung. Die Änderungen bei der Durchsetzung ab Mai 2025 machen diese Verantwortung für alle, die große Mengen an E-Mails versenden, zu einer dringenden Angelegenheit.

Der sicherste Weg ist der langsame: Verwenden Sie zunächst „p=none“, beobachten Sie Ihre Berichte zwei bis vier Wochen lang, beheben Sie die Probleme bei den Absendern, die dabei auffallen, und wechseln Sie dann zu „p=quarantine“ und schließlich zu „p=reject“. Das Überspringen von Schritten ist der häufigste Grund dafür, dass legitime E-Mails während der Einführung nicht mehr zugestellt werden.

Sobald die Durchsetzung in Kraft ist, verlagert sich der Schwerpunkt von der Einrichtung auf die Überwachung. Es kommen neue Absender hinzu, und Drittanbieter ändern ihre Infrastruktur – all dies kann unbemerkt zu Abweichungen führen, wenn niemand die Berichte im Auge behält. Genau hier spielt eine dedizierte DMARC-Plattform ihre Stärken aus. Die Berichts- und Analysetools von PowerDMARC wandeln rohe XML-Daten in aussagekräftige Erkenntnisse um und erkennen Abweichungen, bevor sie zu einem Problem für die Zustellbarkeit werden.

Überprüfen Sie zunächst Ihren aktuellen DMARC-Eintrag, um zu sehen, wo Sie derzeit stehen.

Häufig gestellte Fragen

Richtet Microsoft 365 DMARC automatisch ein?

Microsoft überprüft DMARC für eingehende E-Mails, konfiguriert es jedoch nicht für Ihre benutzerdefinierte Domain. Sie müssen den ausgehenden DMARC-TXT-Eintrag selbst manuell veröffentlichen.

Verlangt Microsoft DMARC?

Ja, Microsoft schreibt DMARC für Absender mit hohem E-Mail-Aufkommen vor. Es wird außerdem allen Organisationen dringend empfohlen, DMARC zu nutzen, um die Zustellbarkeit und den Schutz ihrer E-Mails zu gewährleisten.

Was bedeutet der Fehler 550 5.7.515?

Dieser Fehler weist darauf hin, dass Ihre E-Mails aufgrund fehlender oder nicht konformer DMARC-Richtlinien gemäß den Durchsetzungsregeln von Microsoft zurückgewiesen werden.

Warum werden E-Mails immer noch mit dem Status „p=reject“ zugestellt?

Microsoft hat in der Vergangenheit eine interne Übersteuerung namens „oreject“ (Origin Reject) angewendet, die DMARC-konforme Nachrichten in den Junk-Ordner umleitet, anstatt sie direkt am Gateway zurückzuweisen. Dies diente dazu, legitime Absender vor versehentlichem Verlust zu schützen, hat jedoch zur Folge, dass gefälschte Nachrichten für die Empfänger sichtbar bleiben.

Zwei Dinge, die Sie wissen sollten:

1) Seit den Änderungen bei der Durchsetzung im Mai 2025 geht Microsoft bei Absendern mit hohem Versandvolumen zu einer strengeren, echten Ablehnung über.

2) Wenn Sie eine garantierte Ablehnung innerhalb Ihres eigenen Microsoft 365-Mandanten wünschen, erstellen Sie eine Exchange-Transportregel, die Nachrichten definitiv ablehnt.

Soll ich „Quarantäne“ oder „Ablehnen“ wählen?

Beginnen Sie mit der Überwachung (p=none), um Ihre Absenderquellen und E-Mail-Kanäle zu überwachen, gehen Sie dann zur Quarantäne über und wenden Sie die Ablehnung erst an, wenn Sie sicher sind, dass alle legitimen Quellen korrekt zugeordnet sind.

• Über
• Neueste Beiträge

Yunes Tarada

Experte für Domain- und E-Mail-Sicherheit bei PowerDMARC

Yunes ist Operations Team Lead bei PowerDMARC und verfügt über Expertenwissen im Bereich E-Mail-Authentifizierung und -Sicherheit. Yunes ist ein Microsoft-zertifizierter Azure Administrator Associate mit Zertifizierungen in CompTIA A+ und vielen mehr.

Neueste Beiträge von Yunes Tarada (alle anzeigen)

• DMARCbis erklärt – Was ändert sich und wie bereitet man sich vor - 16. April 2026
• Das SOA-Seriennummernformat ist ungültig: Ursachen und Lösungen – 13. April 2026
• So versenden Sie sichere E-Mails in Gmail: Eine Schritt-für-Schritt-Anleitung – 7. April 2026