Microsoft 365 / E-Mail-DNS-Einträge: Überprüfen Sie MX, SPF, DKIM und DMARC

Für Microsoft 365-E-Mails leiten DNS (Domain Name System)-Einträge eingehende E-Mails und unterstützen die Authentifizierung ausgehender E-Mails. Ein Mail-Exchanger (MX)-Eintrag identifiziert den empfangenden Server; Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) und Domain-based Message Authentication, Reporting, and Conformance (DMARC) bieten verschiedene Authentifizierungsprüfungen und Richtlinieninformationen. Überprüfen Sie die Domain-Inhaberschaft und inventarisieren Sie Microsoft 365- sowie externe sendende Dienste, bevor Sie diese Einträge ändern.

Rollen der vier Einträge

Microsofts Bereitstellungsleitfaden für E-Mail-Authentifizierung empfiehlt SPF, DKIM und DMARC für benutzerdefinierte Domänen. DMARC besteht nicht schon deshalb, weil SPF oder DKIM erfolgreich ist: Auch der Abgleich mit der sichtbaren From-Domäne muss erfolgreich sein.

SPF gibt an, welche sendenden Quellen autorisiert sind. Mit DKIM verwendet der Absender einen privaten Schlüssel, um Teile der Nachricht zu signieren, und der Empfänger verwendet einen über DNS veröffentlichten öffentlichen Schlüssel, um die Signatur zu überprüfen. DMARC überprüft die Übereinstimmung mit der sichtbaren From-Domain und veröffentlicht die gewünschte Fehlerrichtlinie sowie das Berichts-Ziel. Diese Authentifizierungsfunktionen sind im integrierten Schutz für Cloud-Postfächer enthalten; andere Defender-Funktionen können zusätzliche Lizenzanforderungen haben.

SPF überprüft die Domain, die in MAIL FROM, der zwischen Mailservern verwendeten Absenderadresse, genutzt wird. Diese kann sich von der Absenderadresse unterscheiden, die dem Leser angezeigt wird. Eine DKIM-signierende Domain kann ebenfalls dem Dienstanbieter gehören. Ein Customer-Relationship-Management (CRM)-Service könnte daher SPF und DKIM mit der Domain seines Anbieters bestehen, aber dennoch DMARC für die in From angezeigte Unternehmensdomain nicht bestehen. Mindestens ein SPF- oder DKIM-Ergebnis muss erfolgreich sein und zur sichtbaren From-Domäne passen.

Die Ausrichtung kann gelockert (relaxed: gleiche Organisationsdomäne, Unterdomänen erlaubt) oder streng (strict: exakter Domänenname) sein. Die optionalen Tags aspf und adkim steuern die SPF- und DKIM-Ausrichtung unabhängig voneinander; beide verwenden standardmäßig relaxed (r). Prüfen Sie diese Einstellungen, wenn ein Versanddienst eine Unterdomäne verwendet.

Untersuchen Sie den Sendeweg vor der Konfiguration

• Von Mitarbeitern über Exchange Online gesendete E-Mails
• Von externen Systemen wie Website-Anfrageformularen, CRM-, Marketingdiensten und Multifunktionsgeräten gesendete E-Mails
• Versanddienste, die Subdomains separat nutzen
• Der Pfad über ein E-Mail-Sicherheits-Gateway oder Relay-Server

Wenn die sendende Quelle weggelassen wird, können legitime E-Mails nach der Verstärkung von SPF, DKIM und DMARC abgelehnt werden. Entfernen Sie nicht genutzte sendende Quellen und authentifizieren Sie erforderliche Dienste gemäß den offiziellen Anweisungen des jeweiligen Anbieters.

Reihenfolge der Überprüfung in Microsoft 365

1. Öffnen Sie im Microsoft 365 Admin Center die Zieldomain unter [Einstellungen] → [Domänen] und prüfen Sie den DNS-Konfigurationsstatus. Verwenden Sie die im Domain-Assistenten für diese Domain angezeigten MX-Werte.

2. Überprüfen Sie die aktuellen SPF-TXT-Einträge bei Ihrem DNS-Hosting-Anbieter. Wenn Sendequellen außerhalb von Microsoft 365 eingeschlossen werden müssen, integrieren Sie sie in die bestehenden Werte.
3. Überprüfen Sie in den Einstellungen zur E-Mail-Authentifizierung im Microsoft Defender-Portal den DKIM-Status der benutzerdefinierten Domain und die erforderlichen DNS-Einträge. Nachdem Sie die vorgeschlagenen Werte im DNS hinzugefügt haben, vergewissern Sie sich, dass die Signierung aktiviert ist.

4. Führen Sie DMARC schrittweise ein. Analysieren Sie die tatsächlichen Absender und Authentifizierungsfehler anhand von Berichten, und entscheiden Sie dann über die Verschärfung der Richtlinie. Wenn Sie die Richtlinienanweisung nur hinzufügen, ohne die Berichte zu lesen, ist es schwierig, Probleme zu erkennen.
5. Senden Sie eine Test-E-Mail an eine externe Adresse außerhalb der Organisation und überprüfen Sie die SPF-, DKIM- und DMARC-Ergebnisse sowie die Ausrichtung in den empfangenden Headern. Selbst wenn der DNS-Status normal ist, müssen Sie den tatsächlichen Sendeweg testen.

Bedingungen, unter denen das SPF-Beispiel unverändert verwendet werden kann

Für eine benutzerdefinierte Domain, deren öffentliche DNS Sie verwalten, ist der folgende TXT-Wert ein einfaches Beispiel, wenn Microsoft 365 der einzige Versanddienst ist. Dieses Beispiel gilt für den weltweiten kommerziellen Dienst von Microsoft; spezielle Regierungs- oder in China betriebene Clouds können unterschiedliche Include-Domains erfordern. Verwenden Sie die dienstspezifischen Werte in Ihrem Administrationscenter und in der Dokumentation. Wenn eine Website oder ein Marketingdienst ebenfalls direkt über dieselbe Domain sendet, ersetzen Sie nicht Ihre aktuelle Richtlinie nur durch dieses Beispiel. Vergleichen Sie den Domain-Assistenten und die offiziellen Konfigurationsanweisungen jedes Absenders.

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

include bezieht sich auf den Microsoft 365-Versandbereich und -all gibt an, dass Sendequellen, die nicht durch die SPF-Mechanismen autorisiert sind, als SPF-Fehler behandelt werden sollen. Zwei SPF-TXT-Einträge mit demselben Namen zu erstellen, um Microsoft 365 und externe Dienste separat einzuschließen, ist eine falsche Konfiguration. Fassen Sie die erforderlichen Sendequellen in einer einzigen SPF-Richtlinie zusammen und entfernen Sie unnötige Absender. TXT-Einträge zur Eigentumsüberprüfung, die nicht SPF betreffen, haben einen anderen Zweck und müssen nicht entfernt werden. Wählen Sie basierend auf den Versand-Szenarien im Microsoft SPF-Setup-Leitfaden aus.

Beim Kombinieren von Diensten prüfen Sie auch das SPF-Limit von 10 DNS-Abfragen während der Auswertung. Verschachtelte Include-Mechanismen zählen ebenfalls: Weniger als 10 Anbieter oder Include-Einträge garantieren nicht, dass die Auswertung innerhalb des Limits bleibt.

Werte, die bei der Einrichtung von DKIM und DMARC auszuwählen sind

Öffnen Sie im Defender-Portal die benutzerdefinierte Domain unter E-Mail & Zusammenarbeit → Richtlinien & Regeln → Bedrohungsrichtlinien → E-Mail-Authentifizierungseinstellungen → DKIM. Generieren Sie bei Bedarf Schlüssel und geben Sie dann die Namen und Ziele der beiden CNAME (kanonischen Namen)-Einträge ein, die in den Domaindetails bei Ihrem DNS-Anbieter angezeigt werden. Ein CNAME-Eintrag verweist einen DNS-Namen auf einen anderen; in dieser Einrichtung verbindet er das DKIM-Lookup mit den DNS-Einträgen für Microsofts DKIM-Schlüssel. Kopieren Sie die für Ihren Mandanten bereitgestellten Selektornamen und Ziele, anstatt diese aus einem alten Blog zu erstellen. Microsoft hat im Mai 2025 ein neues Zielformat für neue benutzerdefinierte Domains eingeführt, während vorhandene Domains das ältere Format beibehalten können.

Nach der DNS-Propagation aktivieren Sie den DKIM-Signaturschalter für die Domain und prüfen, ob sie signiert. Wenn der CNAME fehlt, überprüfen Sie den eingegebenen Namen, den tatsächlichen DNS-Anbieter und die Erkennungszeit erneut. Gehen Sie nicht davon aus, dass die Signatur aktiviert ist, nur weil beide Einträge gespeichert sind. Sie können das Verfahren zur Fortsetzung je nach aktuellem Status in der offiziellen DKIM-Einrichtungsanleitung nachprüfen.

Die anfängliche DMARC-Richtlinie kann als berichtsfokussierte Konfiguration festgelegt werden, die legitime Absender analysieren kann. Unten ist ein Beispiel unter Verwendung von example.com als Beispiel-Domain. Veröffentlichen Sie den TXT-Eintrag unter _dmarc für Ihre eigene Domain und ersetzen Sie dmarc@example.com im Wert von rua=mailto: durch ein echtes Berichtspostfach, das von Ihrer Organisation verwaltet wird. Die Beispieladresse ist kein Ziel, das unverändert verwendet werden sollte.

v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=none ist eine Anfangsrichtlinie, die für DMARC-Fehler selbst keine Quarantäne oder Ablehnung vorsieht, und sie deaktiviert auch keine anderen Spam- oder Sicherheitsfilter. rua ist die Adresse, um aggregierte Berichte zu erhalten. Sie müssen bereit sein, diese Berichte tatsächlich an dieser Adresse zu empfangen und zu analysieren, und wenn Sie eine externe Berichtsdienstadresse verwenden, müssen Sie auch zusätzliche DNS-Zulassungsbedingungen prüfen. Nach der Überprüfung der Übereinstimmung legitimer Absender und des Lieferpfads verstärken Sie die Richtlinie zu quarantine und reject Schritten. Detaillierte Bedingungen folgen den DMARC-Implementierungsrichtlinien.

Überprüfen Sie DNS-Einträge und Authentifizierung bei neu gesendeter Mail

Senden Sie neue E-Mails an eine Testadresse für jeden Versandweg, wie etwa Mitarbeiter-Mail, Web-Anfrageformulare, CRM usw. Auf der Empfängerseite öffnen Sie die Originalnachricht und die Internet-Header, um die SPF-, DKIM- und DMARC-Ergebnisse im Authentication-Results des empfangenden Systems zu überprüfen, und vergleichen zudem die DKIM-Signaturdomäne mit dem angezeigten From. Sie benötigen die Ergebnisse der neu gesendeten Nachrichten nach Änderungen und nicht "alte Mails waren in Ordnung".

Wenn DNS normal ist, aber ein bestimmtes CRM fehlschlägt, überprüfen Sie zunächst die sendende Domäne und die Signierungseinstellungen für diesen Pfad. Wenn sich der signierte Inhalt ändert oder der sendende Server während des Zustellprozesses unterschiedlich ist, können die Ergebnisse variieren. Dass die Authentifizierung erfolgreich ist, garantiert keine Zustellung in den Posteingang, und auch Reputation, Spam- und Inhaltsrichtlinien haben Einfluss.

Die Werte der Einträge variieren je nach Domain und Zeitpunkt der Konfiguration. Der Zweck dieses Artikels ist nicht, die Werte auswendig zu lernen, sondern die vom Admin Center bereitgestellten Werte mit den tatsächlichen Werten im DNS und den Authentifizierungsergebnissen auf der empfangenden Seite zu vergleichen. Wenn es Probleme beim Empfangen oder Senden von E-Mails gibt, bestimmen Sie den Umfang der Auswirkungen basierend auf den DNS-Einträgen vor den Änderungen. Wenn legitime E-Mails betroffen sind, vergleichen Sie die vorherige Richtlinie und die Konfiguration des Absenders, um nur die problematischen Änderungen wiederherzustellen und testen Sie erneut. Löschen Sie nicht alle SPF-, DKIM- und DMARC-Einträge und behalten Sie bei ungeklärten Zustellproblemen nicht blind eine strikte DMARC-Richtlinie bei. Unterscheiden Sie im Bericht zwischen Ausfällen legitimer Absender und verdächtigen gefälschten Sendungen und bestimmen Sie die weiteren Maßnahmen entsprechend.