Melden Sie, was beobachtet wurde, bevor Sie es als gesund bezeichnen
A DMARC Der Checker kann DNS Richtlinieninformationen beobachten und Teile seiner Syntax oder seines Erkennungsverhaltens auswerten. Dies bedeutet nicht, dass sich jeder legitime Sendedienst korrekt authentifiziert, dass alle Empfänger dieselbe Implementierung anwenden oder dass eine bestimmte Nachricht einen Posteingang erreicht hat. Eine nützliche Prüferausgabe sollte ihre genauen Eingaben, den Resolver-Kontext, die Beobachtungszeit, die Erkennungsmethode und Einschränkungen identifizieren, bevor sie eine Schlussfolgerung präsentiert.
RFC 9989 Definiert den aktuellen DMARC Mechanismus, einschließlich Richtlinienerkennung und Ausrichtung. In diesem Artikel werden vorgeschlagene Beweisanforderungen für einen Prüfer beschrieben. Es wird nicht behauptet, dass EmailAuth sie implementiert oder dass eine Domäne gescannt wurde. Es wurde keine autorisierende oder rekursive Abfrage für eine Benutzerdomäne durchgeführt und es wurden keine Stichproben empfangener Nachrichten erfasst.
Unterscheiden Sie eine genaue Suche von einer Richtlinienerkennung
Eine Abfrage nach einem bestimmten _dmarc Eigentümernamen ist eine Beobachtung dieses Namens. Um die anwendbare Richtlinie zu bestimmen, kann der Ermittlungsprozess des aktuellen Standards einschließlich dessen erforderlich sein DNS Tree Walk Regeln. Der Prüfer sollte angeben, ob er lediglich eine exakte TXT Antwort anzeigt oder einen definierten Erkennungsalgorithmus implementiert. Ein fehlender Datensatz bei einem Namen sollte nicht als Beweis dafür dienen, dass keine anwendbare Richtlinie existiert, ohne den relevanten Geltungsbereich zu bewerten.
Notieren Sie jeden Eigentümernamen, jeden Abfragetyp, jede Antwort und jeden Zweig, die vom implementierten Erkennungsprozess verwendet werden. Die Ausgabe sollte eine gültige Richtlinie, keine anwendbare Richtlinie, einen ungültigen Kandidaten und einen DNS Fehler gemäß dem unterstützten Algorithmus unterscheiden. Erfinden Sie keine Verknüpfung, die nur auf einer vertrauten Organisationsdomänenliste basiert und gleichzeitig aktuelles Standardverhalten beansprucht. Die Produktversion und die Normreferenz sollten zusammen mit dem Ergebnis aufbewahrt werden.
Behalten Sie maßgebliche und rekursive Perspektiven bei
Eine autorisierende Antwort und eine rekursive Resolver-Antwort können aufgrund von Caching, Delegationsstatus, Timing oder Auflösungsfehlern unterschiedlich sein. Notieren Sie, welcher Server oder Resolver die einzelnen Antworten bereitgestellt hat und wann sie erfasst wurden. Ein Dashboard sollte sie nicht zu einem scheinbar zeitlosen Wert verschmelzen. Wenn ein Prüfer nur rekursive Beweise liefert, sagen Sie dies, anstatt zu implizieren, dass die maßgebliche Konfiguration unabhängig überprüft wurde.
RFC 1035 definiert DNS Nachrichten- und Ressourceneintragsstrukturen, einschließlich TXT Datensätze. Behalten Sie Antwortcodes und Datensatzstruktur bei, anstatt nur eine vereinfachte Richtlinienzeichenfolge anzuzeigen. Mehrere Zeichenfolgen innerhalb eines TXT Datensatzes sind nicht dasselbe wie mehrere TXT Datensätze. Diese Unterscheidung ist wichtig, wenn bestimmt wird, ob die Antwort konkurrierende DMARC -Richtliniendatensätze enthält oder nur einen Datensatz, der in mehreren Zeichenfolgen dargestellt wird.
Interpretieren Sie die Syntax mit dem aktuellen Standard
RFC 9989 Gibt DMARC1 als Versionswert an, bei dem zwischen Groß- und Kleinschreibung unterschieden wird, und erfordert das Versions-Tag an der definierten Position. Ein Prüfer sollte den genauen Grund ermitteln, warum ein Kandidat keine gültige Richtlinie darstellt, anstatt jedes Problem durch eine allgemeine rote Warnung zu ersetzen. Es sollte auch doppelte Richtlinienkandidaten von nicht verwandten TXT Daten unterscheiden. Das anwendbare Ermittlungsverfahren bestimmt, wie Kandidatendatensätze ausgewählt und behandelt werden.
Unbekannte Tags stellen nicht automatisch einen schwerwiegenden Richtlinienfehler dar: Die formale Definition des RFC besagt, dass unbekannte Tags ignoriert werden müssen. Ein Prüfer kann immer noch warnen, dass ein Tag von seinem eigenen Parser nicht unterstützt wird oder in der aktuellen Registrierung fehlt, aber er sollte diese Warnung nicht mit einer normativen Ablehnungsregel verwechseln. Umgekehrt erfordert ein erkanntes Tag mit einem problematischen Wert die Handhabung des entsprechenden Standards und keine erfundene universelle Antwort auf alle Syntaxfehler.
Staatliche Implementierungs- und Kompatibilitätsgrenzen
Der aktuelle RFC entfernt pct und führt das Test-Tag t ein, wie in Anhang A.6 erläutert. Ein Prüfer sollte identifizieren, welchem Standard und welcher Tag-Registrierung seine Interpretation folgt, und vermeiden, den Eindruck zu erwecken, dass sich jeder externe Empfänger identisch verhält. Es sollte keine mechanische Migration von willkürlichen historischen Prozentsätzen ohne eine Überprüfung der Bereitschaft vorgeschlagen werden. Anbieterspezifische Zulassungsregeln erfordern möglicherweise eine separate aktuelle Dokumentation.
Eine syntaktisch akzeptable DNS Richtlinie ist immer noch nur ein Teil des Gesamtbildes. Der Prüfer hat die Liste der legitimen Absender, ihre Zuordnung oder die Auswirkung einer Richtlinienänderung nicht ermittelt. Halten Sie Empfehlungen von den fehlenden Eingaben abhängig. Eine Richtlinie, die eine Durchsetzung fordert, kann korrekt veröffentlicht werden, während legitime Arbeitsabläufe weiterhin falsch konfiguriert sind. Ein DNS Prüfer allein kann nicht bestätigen, dass die Durchsetzung für das Unternehmen sicher ist.
Verbinden Sie DNS -Beweise mit einem vertrauenswürdigen Nachrichtenbeispiel
RFC 8601 erklärt die Vertrauensgrenze für Authentication-Results Felder. Eine Probe der empfangenen Nachricht sollte den Empfänger identifizieren, der das Ergebnis erzeugt hat, und die relevanten sichtbaren Identitäten, Umschlag- und Signaturidentitäten bewahren. Eine kopierte Zeile mit „pass“ reicht nicht aus, um nachzuweisen, dass der vorgesehene Empfänger den tatsächlichen Arbeitsablauf bewertet hat. Die Probe sollte autorisiert und redigiert werden, ohne die für die Analyse erforderlichen Domänenbeziehungen zu zerstören.
Vergleichen Sie die Stichprobenzeit und Identitäten mit den DNS Beobachtungen, aber tun Sie nicht so, als ob eine Stichprobe jeden Absender oder Empfänger abdeckt. Möglicherweise hat sich eine Richtlinie zwischen dem Senden und Überprüfen geändert, und rekursive Caches können unterschiedliche Zustände widerspiegeln. Geben Sie an, was die Probe zeigt und was unbekannt bleibt. Dieser Artikel enthält kein Nachrichtenbeispiel und erhebt keinen Anspruch darauf, dass eine echte Richtlinie mit einem tatsächlich empfangenen Ergebnis übereinstimmt.
Ein Arbeitsblatt zur Annahme einer Prüferausgabe
Erstellen Sie ein Arbeitsblatt mit der abgefragten Domäne, den genauen Eigentümernamen, dem Resolver oder der maßgeblichen Quelle, Zeitstempeln, Antwortcodes, aufbewahrten Transkripten und der Struktur des Kandidatendatensatzes. Fügen Sie den implementierten Erkennungsalgorithmus, die Parser-Version, die ausgewählte Richtlinie, Warnungen und explizite Unsicherheit hinzu. Der Nachrichtenabschnitt sollte den autorisierten Workflow, den vertrauenswürdigen Empfänger, relevante Identitäten, beobachtete Ergebnisse und Verknüpfungsbeschränkungen aufzeichnen.
Verwenden Sie vorgeschlagene Fixtures für eine gültige Richtlinie, fehlende exakte Namenseinträge mit anwendbarer Erkennung auf höherer Ebene, doppelte Kandidaten, nicht unterstützte Tags und nicht verfügbares DNS . Trennen Sie normatives erwartetes Verhalten von produktspezifischer Darstellung. Ein Test sollte die gespeicherten Beweise und Erklärungen überprüfen, nicht nur ein grünes Symbol. Hier wurde kein Fixture ausgeführt und in den Beispielen wird keine echte DNS Antwort dargestellt.
Fiktive Diagnose: eine grüne Akte mit einem fehlgeschlagenen Absender
Ein fiktives Team sieht, wie ein Prüfer eine gültige Durchsetzungsrichtlinie anzeigt, und kommt zu dem Schluss, dass sein Rechnungsdienst bereit ist. Eine autorisierte Stichprobe empfangener Nachrichten kann, wenn sie später erfasst wird, zeigen, dass der Dienst einen nicht ausgerichteten Pfad verwendet. Die DNS Beobachtung und der Nachrichtenfehler widersprechen sich nicht: Das eine beschreibt die Veröffentlichung, das andere einen Sende-Workflow.
Die vorgeschlagene Untersuchung würde beide Beobachtungen bewahren, den Workflow-Eigentümer identifizieren und den beabsichtigten ausgerichteten Pfad überprüfen, bevor Richtlinien geändert oder Berechtigungen hinzugefügt werden. Die Domäne wird nicht als sicher deklariert, nur weil der Datensatz analysiert wird. Hierbei handelt es sich um eine fiktive Übung, nicht um einen echten Fehler beim Rechnungsdienst, DNS Scan oder beim Empfängerergebnis. Sein Zweck besteht darin, die Beweisgrenze des Prüfers sichtbar zu halten.
Halten Sie die endgültige Schlussfolgerung verhältnismäßig
Eine nützliche Prüfschlussfolgerung kann sein, dass eine bestimmte Richtlinie zu einem bestimmten Zeitpunkt unter einem bestimmten Algorithmus beobachtet und interpretiert wurde. Es sollte keine universelle Zustellung, vollständige Übernahme durch den Empfänger oder Schutz vor jeglichem Identitätswechsel versprechen. Die Ausgabe ist am stärksten, wenn fehlende Betriebsnachweise leicht erkennbar sind.
Der Katalog erfordert maßgebliche und rekursive Suchtranskripte, Zeitstempel und ein passendes Beispiel für empfangene Nachrichten. Diese Originalartefakte bleiben offen. Auch die Prüfung durch menschliche Spezialisten, die Anwendbarkeit der Quelle, die Produktionswege, die Zugänglichkeit und die Freigabe durch den Eigentümer bleiben offen. Dieser Entwurf stellt ein vorgeschlagenes Beweismodell bereit, keine durchgeführten Scans oder überprüften EmailAuth Prüffunktionen.