Zum Einrichten DMARC Richten Sie für eine benutzerdefinierte Microsoft 365 Domäne die Senderouten der Domäne ein und konfigurieren Sie die entsprechenden SPF Richtlinie, benutzerdefinierte Domäne aktivieren DKIM und überprüfen Sie ein abgestimmtes Ergebnis anhand der empfangenen E-Mails. Veröffentlichung eines DMARC TXT Eintrag ist ein Schritt in dieser Reihenfolge.
In diesem Leitfaden wird das Senden benutzerdefinierter Domänen über Microsoft 365 behandelt. Bestätigen Sie die Microsoft-Cloud-Umgebung und alle Hybrid-, Relay- oder Outbound-Gateway-Anordnungen, bevor Sie die Beispiele verwenden. Anwendungen, die außerhalb von Microsoft 365 gesendet werden, benötigen ihre eigene unterstützte Authentifizierungskonfiguration, auch wenn sie dieselbe sichtbare Von-Domäne verwenden.
Bestätigen Sie die Domäne, DNS Host und die Microsoft-Umgebung
Bestätigen Sie die benutzerdefinierte Domäne, ihren autorisierenden DNS Host, die Microsoft 365 -Umgebung und die zum Verwalten der Signatur erforderliche Berechtigung. Speichern Sie den vorhandenen SPF , DKIM und DMARC Datensätze bevor Sie sie ändern.
Verwechseln Sie die öffentliche DNS -Verwaltung nicht mit der Domänenliste des Mandanten. Der Registrar kann auch der DNS Host sein, muss es aber nicht. Überprüfen Sie die delegierten Nameserver, bevor Sie eine Zone bearbeiten.
Listen Sie jede Route auf, die die Domäne verwendet. Unterscheiden Sie insbesondere den gewöhnlichen Exchange Online Versand von Anwendungen, die Relay, Direct Send, einen anderen SMTP Anbieter oder ein Outbound-Gateway verwenden. Der Produktname allein identifiziert den endgültigen Unterzeichner nicht.
Ordnen Sie Mitarbeitermails und Bewerbungsmails zu
Bei einem Wechsel zu Microsoft 365 werden nicht automatisch auch die Rechnungsanwendung, das Website-Kontaktformular oder die Rekrutierungsplattform verschoben. Bei diesen Diensten wird Ihre Domain möglicherweise weiterhin angezeigt, während der Versand über einen anderen Anbieter erfolgt.
Fordern Sie eine einfache Servicekarte an: Mitarbeiter-Mail, Bewerbungs-Mail und ausgelagerte Kommunikation, mit einem Eigentümer neben jeder Route. Erfordern Sie einen Test empfangener Nachrichten für kritische Abläufe wie das Zurücksetzen von Passwörtern und Rechnungsbenachrichtigungen. Das Ergebnis ist eine funktionierende, nachvollziehbare Kommunikation, kein Screenshot einer aktivierten Mandanteneinstellung.
Konfigurieren Sie die anwendbare SPF Richtlinie
Das dokumentierte Beispiel von Microsoft für eine Domäne, die **nur über ihren Standard- Microsoft 365 -Dienst oder GCC** sendet, ist:
v=spf1 include:spf.protection.outlook.com -allDies ist ein bereichsbezogenes Beispiel und kein Ersatz für eine bestehende Richtlinie für gemischte Dienste. Microsoft dokumentiert verschiedene Domänen für GCC High/DoD und für seinen von 21Vianet betriebenen Dienst. Befolgen Sie die aktuellen Anweisungen für Ihre Umgebung.
Veröffentlichen Sie eine anwendbare SPF Richtlinie in der bewerteten Domäne. Wenn bereits eine gültige Richtlinie vorhanden ist, überprüfen und aktualisieren Sie diese, anstatt eine weitere hinzuzufügen SPF Eintrag. Schließen Sie nur berechtigte Sendeberechtigungen ein und prüfen Sie den vollständigen Abhängigkeitspfad anhand SPF Grenzwerte.
Veröffentlichen Sie beide vom Mandanten generierten DKIM CNAMEs
Microsoft 365 - DKIM für benutzerdefinierte Domänen verwendet zwei CNAME Aufzeichnungen. Erhalten Sie ihre genauen Werte aus der DKIM Konfiguration des Defender-Portals oder Exchange Online PowerShell. Erstellen Sie kein Ziel aus einer alten Benennungsvorlage: Microsoft dokumentiert mehr als ein Zielformat und generierte Werte können eine mandantenspezifische Komponente enthalten.
In einer autorisierten Exchange Online PowerShell-Sitzung ruft diese schreibgeschützte Prüfung die konfigurierten Ziele ab:
Get-DkimSigningConfig -Identity example.com | Formatliste aktiviert, Status, Selector1CNAME, Selector2CNAMEWenn die Domäne über keine Signaturkonfiguration verfügt, verwenden Sie das dokumentierte Erstkonfigurationsverfahren von Microsoft, bevor Sie davon ausgehen, dass diese Eigenschaften vorhanden sind. Im Defender-Portal ist der relevante Bereich E-Mail-Authentifizierungseinstellungen und dann DKIM .
Veröffentlichen Sie **beide** generierte CNAME Datensätze, überprüfen Sie ihre öffentlichen Antworten und aktivieren Sie die benutzerdefinierte Domänensignierung über das unterstützte Mandantenverfahren. Ein CNAME Eintrag delegiert die Verwaltung des Verifizierungsschlüssels. Es handelt sich nicht um eine Aufforderung zum Einfügen eines privaten Schlüssels oder eines erfundenen TXT Schlüssels.
Überprüfen Sie das Verhalten DNS Editors sorgfältig. Ein Panel, das den Zonennamen anfügt, kann einen vollständig eingegebenen Hostnamen in einen duplizierten Namen umwandeln. Behalten Sie die genauen veröffentlichten Eigentümer- und Zielwerte im Änderungsdatensatz bei.
Fügen Sie die beabsichtigte DMARC Richtlinie und das Berichtsziel hinzu
Wenn die Domäne mit einer überwachten Bereitstellung beginnt, ein veranschaulichender Datensatz unter _dmarc.example.com Ist:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comDas Beispiel setzt ein funktionierendes Berichtsziel in derselben Domäne voraus. Ersetzen Sie es durch die genehmigte Adresse und bestätigen Sie die Abholung. Für externe Ziele ist möglicherweise eine zusätzliche Berichtserlaubnis erforderlich. Schwächt eine bestehende Durchsetzungsrichtlinie nicht, nur um diesem Beispiel zu entsprechen.
Verwenden Sie den Datensatzerstellungsleitfaden für die Veröffentlichungs- und Überprüfungssequenz und die DMARCbis Bereitschaftsleitfaden bei der Überprüfung älterer Rollout-Einstellungen.
Überprüfen Sie Nachrichten nach der vollständigen Senderoute
Senden Sie eine kontrollierte Nachricht an einen separaten externen Empfänger und prüfen Sie dort die Originalnachricht. Zeichnen Sie den sichtbaren Absender, die SPF-evaluierte Identität, jede relevante DKIM -d=-Domäne und das vertrauenswürdige DMARC Ergebnis auf.
Wiederholen Sie den Test für kritische Anwendungen und jedes endgültige ausgehende Gateway. Wenn der sichtbare Absender Ihre benutzerdefinierte Domäne ist, die einzige vorbeigehende Signatur jedoch eine unabhängige Mandantenidentität verwendet, untersuchen Sie die Signatur der benutzerdefinierten Domäne und die tatsächliche Route. Wenn ein Gateway signierte Inhalte ändert, überprüfen Sie das Ergebnis nach diesem Gateway.
- Überprüfen Sie: SPF -Richtlinie; Zu bewahrende Nachweise: Maßgebliche Antwort und ausgewerteter Sendeweg
- Check: DKIM Delegation; Zu bewahrende Nachweise: Sowohl die genauen CNAMEs als auch der Mandantenkonfigurationsstatus
- Prüfen: Live-Signatur; Zu bewahrende Nachweise: Erhaltene Signatur und vertrauenswürdiges Verifizierungsergebnis
- Prüfen: DMARC ; Zu behaltende Beweise: Ein vorübergehender, abgestimmter Weg und ein beobachteter politischer Kontext
- Überprüfen Sie: Geschäftsabdeckung; Zu bewahrende Nachweise: Tests für die Anwendungen, die die Organisation tatsächlich nutzt
- Zeichnen Sie die Akzeptanz und die laufende Eigentümerschaft auf
Genehmigen Sie die Implementierung anhand eines benannten Serviceinventars. Notieren Sie den Änderungsgenehmiger, DNS Besitz, die Ergebnisse des kritischen Ablaufs und die verbleibenden Ausnahmen. Der gültige Unterzeichnungsstatus eines Mieters beweist nicht, dass alle externen Anwendungen abgedeckt sind.
Halten Sie die Cloud-Umgebung in der Betriebsdokumentation explizit dar. Ein Standard-Cloud-Beispiel darf nicht stillschweigend zu einer Regierungs-Cloud-Anweisung werden. Weisen Sie regelmäßige Überprüfungen auf verlassene Dienste und delegierte Selektoren sowie auf Ausfälle im aktuellen Datenverkehr zu.
Behalten Sie die Möglichkeit bei, den zuvor genehmigten Zustand wiederherzustellen, wenn eine Änderung fehlschlägt, und bewahren Sie gleichzeitig die Beweise für den Vorfall. Eine abschließende Überprüfung sollte die verbleibenden Risiken kompromittierter Konten und authentifizierter bösartiger E-Mails erläutern, anstatt zu versprechen, dass ein DMARC Pass jede Nachricht sicher macht.
Der praktische Imbiss
Die Einrichtung ist abgeschlossen, wenn die veröffentlichten Datensätze, der Signaturstatus des Mandanten, die Identitäten der empfangenen Nachrichten und der Berichtspfad übereinstimmen. Bewahren Sie das Serviceinventar und die Ausnahmen im Änderungsdatensatz auf; Sie bilden die Grundlage für die nächste Anwendungs- oder Gateway-Änderung.
Trennen Sie Mitarbeiter-Mail-Beweise von einer CRM-Ausnahme
Im schriftlichen Fall M365-01 wird davon ausgegangen, dass Mitarbeiter-E-Mails von staff@example.org vertrauenswürdig sind DKIM Signatur mit d=example.org. Das Abrechnungs-CRM verwendet billing@example.org , aber seine einzige aufgezeichnete Signatur stammt von einer unabhängigen Anbieterdomäne und sein SPF Ergebnis ist unbekannt. Die E-Mail-Beweise der Mitarbeiter belegen das CRM-Ergebnis nicht, und die teilweisen CRM-Beweise können kein vollständiges DMARC Urteil rechtfertigen. Der CRM-Eigentümer muss seine unterstützte ausgerichtete Identität identifizieren und eine kontrollierte externe Nachricht sammeln, bevor der Domänenbesitzer die Durchsetzungsbereitschaft bewertet. Dabei handelt es sich um fiktive Identitäten und Ergebnisse; Es ist kein Mandant, keine DNS Änderung oder kein E-Mail-Versand aufgetreten.