Warum ein übergeordneter DMARC Eintrag kein Absenderinventar ersetzt

Ein Elternteil DMARC Die Richtlinie kann festlegen, wie Empfänger mit einigen Subdomain-E-Mails umgehen sollen, deren Authentifizierung fehlschlägt. Es kann Ihnen nicht sagen, welche Anwendung diese E-Mail sendet, wer sie genehmigt hat oder ob ein wichtiger Benachrichtigungsdienst noch funktioniert. Für diese Fragen ist ein Absenderverzeichnis erforderlich, das mit den Beweisen für den Empfang der Nachricht verknüpft ist.

Die Unterscheidung ist bei der Durchsetzung von Bedeutung. Bei einer DNS Prüfung kann eine Schutzrichtlinie in der Hauptdomäne der Organisation angezeigt werden, während eine alte Kampagnenplattform eine explizite untergeordnete Richtlinie verwendet, eine Tochtergesellschaft ihren eigenen Namespace kontrolliert oder ein Passwort-Reset-Dienst sich mit einer nicht verwandten Anbieteridentität authentifiziert. Die Akte und das Inventar beantworten unterschiedliche Fragen.

Beginnen Sie mit der Domain, die der Empfänger sieht

Erfassen Sie für jeden Geschäftsworkflow die Domäne in der Absenderadresse der Nachricht. Ersetzen Sie nicht die Website-Domäne, die Anmeldedomäne des Kontos oder den Markennamen des E-Mail-Anbieters. Identifizieren Sie dann die anwendbare Richtlinie, die SPF-evaluierte Identität und die DKIM Domäne oder Domänen signieren.

Bei der aktuellen DMARC Erkennung hat ein anwendbarer Datensatz, der speziell für die Autorendomäne gefunden wurde, Vorrang vor einem Fallback auf die Organisationsbereich oder öffentliches Suffix. Die aktuelle Spezifikation verwendet a DNS Baumwanderung. Ein unmittelbarer Elternteil ist nicht automatisch die anwendbare Organisationsgrenze. Sehen RFC 9989 §4.10.1.

Ihr Inventar sollte daher die erkannte Richtliniendomäne aufzeichnen und nicht nur ein Kontrollkästchen mit der Aufschrift „Von übergeordneter Richtlinie abgedeckt“. Notieren Sie außerdem den verwendeten Empfänger bzw. Prüfer und das Testdatum. Ältere Implementierungen verwenden möglicherweise veraltetes Erkennungsverhalten, sodass eine dokumentarische Berechnung keinen universellen Einsatz begründet.

Vergleichen Sie drei Subdomain-Fälle

Das Folgende ist eine synthetische Darstellung, keine beobachtete Kundenkonfiguration. Annehmen example.com ist die Organisationsdomäne, die Erkennung wählt ihren Datensatz aus, wenn kein untergeordneter Datensatz vorhanden ist, und ihr Datensatz enthält p=reject; sp=quarantine; np=reject. Das Versions-Tag wird in diesem Satz nur zur besseren Lesbarkeit weggelassen; Eine echte Policenaufzeichnung muss beginnen v=DMARC1.

• Autorendomänenfall: Vorhanden billing.example.com, ohne explizit DMARC Eintrag; Anwendbare Richtlinie in diesem Beispiel: Übergeordnet sp=quarantine für fehlgeschlagene Post; Was das Inventar noch ermitteln muss: Welcher Abrechnungsworkflow sendet, seinen Besitzer und das abgeglichene Authentifizierungsergebnis einer empfangenen Nachricht
• Autorendomänenfall: Nicht vorhanden unused.example.com, ohne explizite Richtlinie; Anwendbare Richtlinie in diesem Beispiel: Übergeordnet np=reject für fehlgeschlagene Post; Was die Bestandsaufnahme noch feststellen muss: Ob es tatsächlich nicht im DNS vorhanden ist und ob irgendein legitimer Workflow es unerwartet verwendet
• Autorendomänenfall: Vorhanden news.example.com, mit eigenem v=DMARC1; p=none aufzeichnen; In diesem Beispiel anwendbare Richtlinie: Das explizite untergeordnete Element p=none Politik; Was die Bestandsaufnahme noch klären muss: Wem gehört diese Ausnahme, warum besteht sie und wann wird sie neu bewertet

In allen drei Fällen kann eine bestandene ausgerichtete Identität zu DMARC Bestanden führen. Die Richtlinienspalte beschreibt die angeforderte Behandlung von Fehlern und keinen Befehl, jede Nachricht von der Domäne abzulehnen. Empfängerentscheidungen bleiben gesondert RFC 9989 §5.4. Der sp Und np Auswahlregeln sind in angegeben RFC 9989 , Abschnitt 4.10.1.

Eine delegierte DNS Zone ist ein weiteres Inventarelement und kein Beweis für eine explizite DMARC Richtlinie. Zeichnen Sie auf, wer es kontrolliert, und testen Sie die Erkennung anhand der tatsächlichen Autorendomänen. Schließen Sie aus Ihrem Unternehmensdiagramm keine organisatorischen Grenzen ab.

Verbinden Sie jeden Absender mit einem Geschäftsinhaber

Erstellen Sie eine Zeile pro sinnvollem Sendeworkflow. Eine einzelne Anwendung benötigt möglicherweise separate Zeilen für Kampagnen, Transaktionsbenachrichtigungen und von Mitarbeitern ausgelöste Nachrichten, wenn sie unterschiedliche Identitäten oder Routen verwenden.

Behalten Sie mindestens den Workflow, den verantwortlichen Eigentümer, die Autorendomäne, die Umschlagdomäne, die Signaturdomäne usw. bei Wähler, Versandservice, geltende Richtlinie, letzter Test und Ruhestandsbedingung. Fügen Sie den Beweisort und alle ungelösten Probleme hinzu. Ein benannter Anbieter ohne identifiziertes Kundenkonto oder Geschäftsinhaber bleibt ein Ermittlungsleiter und keine genehmigte Sendebehörde.

Verwenden aggregierte Berichte um den beobachteten Verkehr zu finden und ihn mit diesem Register zu vergleichen. Unter RFC 9990 §3.1 Und RFC 9989 §5.3.8, Berichte beschreiben den von teilnehmenden Empfängern gesehenen Verkehr; Das Fehlen eines Berichts ist kein Beweis dafür, dass kein monatlicher oder selten verwendeter Workflow vorhanden ist. Bitten Sie Anwendungseigentümer, das Zurücksetzen von Passwörtern, Quittungen, Benachrichtigungen und geplante Aufgaben bewusst durchzuführen.

Ändern Sie die Richtlinien für das Inventar

Bevor Sie die übergeordnete Richtlinie ändern, identifizieren Sie die Zeilen, die die Änderung erben, und die Zeilen mit unabhängiger untergeordneter Richtlinie. Weisen Sie Tests ihren Besitzern zu. Bei einer sicheren Überprüfung wird gefragt, ob legitime E-Mails weiterhin authentifiziert und abgeglichen werden, ob Ausnahmen gerechtfertigt sind und ob die Wiederherstellung auf den betroffenen Workflow beschränkt werden kann.

Vermeiden Sie es, die übergeordnete Richtlinie zu schwächen, nur weil die Konfiguration einer Anwendung unvollständig ist. Stellen Sie zunächst fest, ob der Dienst eine unterstützte, ausgerichtete Signaturdomäne verwenden kann. Wenn eine Ausnahme erforderlich ist, dokumentieren Sie deren Umfang, Genehmiger, Ablauf und Überprüfungsplan. Betrachten Sie dies als eine explizite Risikoentscheidung, anstatt den Absender stillschweigend vor dem Inventar zu verbergen.

Vergleichen Sie nach der Änderung neue Nachrichtenergebnisse und Berichte mit den Zeilen vor der Änderung. Halten Sie den politischen Unterschied und die Beweise zusammen. Schließen Sie die Änderung erst ab, wenn die betroffenen Geschäftsinhaber ihre tatsächlichen Arbeitsabläufe bestätigen und ungelöste Absender eine benannte nächste Aktion haben.

Halten Sie Versicherungsschutz und Absenderschutz getrennt

Ein nützliches Dashboard verfügt über zwei Kennzahlen: Domänen mit einer verifizierten anwendbaren Richtlinie und geschäftliche Sendeworkflows mit einem aktuellen Eigentümer und einer getesteten ausgerichteten Route. Die Verbesserung des einen führt nicht automatisch zu einer Verbesserung des anderen. Benutzen Sie die Leitfaden zur Absenderinventur für das Betriebsregister und die Richtlinienleitfaden für Subdomains für Entdeckungsdetails.

Treffen Sie die nächste Entscheidung explizit

Für die Drei-Domänen-Fixture gilt die Gruppenabrechnung gemäß der geerbten SP-Richtlinie, die Nichtverwendung gemäß der angenommenen anwendbaren NP-Richtlinie und die Nachrichten gemäß der expliziten P-Richtlinie. Eine Änderung des übergeordneten SP sollte nicht als Änderung der expliziten Nachrichtenrichtlinie beschrieben werden. Halten Sie jeden Workflow-Eigentümer und jede Beweislücke getrennt. Dies ist eine Folge der genannten Entdeckungsannahmen, kein Live-Baumspaziergang oder die Genehmigung zur Änderung der Richtlinie.