Ein Organisationsbereich ist eine Grenze, die in verwendet wird DMARC Verarbeitung. Es hilft einem Empfänger, Richtlinien zu finden, wenn eine sichtbare Absenderdomäne keinen eigenen Datensatz hat, und es hilft, authentifizierte Identitäten entspannt zu vergleichen Ausrichtung. Das sind verwandte Operationen, aber es handelt sich nicht um dieselbe Frage.
Die Abkürzung „Nimm die letzten beiden Labels“ ist unzuverlässig. Ein Name unter einem mehrteiligen öffentlichen Suffix, wie z. B. co.uk , zeigt bereits, warum beim Zählen zweier Labels das Suffix anstelle der Organisation ausgewählt werden kann. Die aktuelle Spezifikation fügt einen weiteren Grund hinzu, Abkürzungen zu vermeiden: RFC 9989 Definiert DNS Tree-Walking, anstatt sich auf a zu verlassen öffentliche Suffixliste allein.
Schreiben Sie die drei Fragen getrennt auf
Beginnen Sie mit der eigentlichen Domäne in der Absenderadresse der Nachricht, der so genannten Autorendomäne. Dann fragen Sie:
- Welcher DMARC Richtlinieneintrag gilt für diese Autorendomäne?
- Welche Organisationsdomäne legt der anwendbare Ermittlungsprozess für jede verglichene Identität fest?
- Macht das Passieren SPF oder DKIM Identität entspricht dem ausgewählten Ausrichtungsmodus?
Ein gültiger Datensatz direkt in der Autorendomäne gewinnt die Richtlinienauswahl. Dies beweist nicht automatisch, dass die Autorendomäne die Organisationsdomäne ist, die für die entspannte Ausrichtung verwendet wird. Behandeln Sie einen DNS Prüfer, der nur ein „Domänen“-Feld anzeigt, als Startansicht und sammeln Sie die tatsächlichen Namen und Antworten, die zur Erklärung seiner Schlussfolgerung erforderlich sind.
Der Leitfaden zur Identitätskette hilft bei der Identifizierung der Absender-, Umschlag- und DKIM Domänen, bevor mit der Erkennung begonnen wird.
Folgen Sie einem beschrifteten Beispiel
Das Folgende ist ein synthetischer DNS Snapshot. Es zeigt eine fiktive Registrierung unterhalb des reservierten .example-Namespace; Es handelt sich nicht um ein Live-Abfrageergebnis oder eine Aussage über ein echtes öffentliches Suffix.
Gehen Sie davon aus, dass die vorhandene Autorendomäne invoice.harbour.registry.example ist. Seine Botschaft hat eine vorübergehende Bedeutung DKIM Signatur mit d=sign.harbour.registry.example. SPF gilt für eine separate Dienstdomäne, die nicht ausgerichtet ist.
| Abfrageziel | Illustrative Antwort | Folge |
|---|---|---|
| _dmarc.invoice.harbour.registry.example | Kein DMARC -Richtlinieneintrag | Entdecken Sie weiter |
| _dmarc.harbour.registry.example | v=DMARC1; p=none; sp=quarantine; psd=n | Legen Sie diese klare organisatorische Grenze fest und stoppen Sie den Spaziergang |
| _dmarc.registry.example | Keine Abfrage nach dem Stopp | Für diesen Spaziergang ist keine weitere Reaktion erforderlich |
Die ausgewählte Richtlinie ist der Datensatz unter harbour.registry.example . Da invoice.harbour.registry.example existiert und eine Unterdomäne ist, lautet die anwendbare Bewertungsrichtlinie „Quarantäne durch SP“. Die Organisationsdomäne ist harbour.registry.example , da der Datensatz explizit psd=n.
Für die DKIM Identität gibt die beispielhafte Suche unter _dmarc.sign.harbour.registry.example keinen Datensatz zurück, gefolgt vom gleichen psd=n Grenzdatensatz. Die authentifizierte Signaturidentität und die Autorendomäne teilen sich daher eine Organisationsdomäne. Bei einer entspannten DKIM Ausrichtung liefert die vorbeikommende DKIM Signatur einen ausgerichteten Pfad. Eine strikte Angleichung würde eine genaue Identitätsgleichheit erfordern, die diese beiden unterschiedlichen Namen nicht haben.
Das Beispiel hält bewusst die Richtlinienauswahl, Grenzerkennung, Authentifizierung und Ausrichtung als separate Ergebnisse sichtbar. Eine Änderung des Richtlinienwerts würde die ungleichen Domänenzeichenfolgen nicht in eine exakte Übereinstimmung umwandeln.
Verstehen Sie, was den Spaziergang stoppt
RFC 9989 Abschnitt 4.10 spezifiziert die Abfragen, Datensatzfilterung und Grenzwerte. Ein gültiger Datensatz mit psd=n identifiziert eine Organisationsgrenze. Ein gültiger Datensatz mit psd=y identifiziert eine öffentliche Suffixgrenze, wobei die Auswahlregeln für die Organisationsdomäne gegebenenfalls die Domänenbezeichnung darunter berücksichtigen.
Wenn keines der Signale die Grenze auflöst, stellt die Spezifikation Auswahl- und Fallback-Regeln bereit. Außerdem wird die Erkennung langer Namen eingeschränkt, um zu verhindern, dass ein Angreifer unbegrenzte Suchvorgänge erzwingt. Eine Produktionsimplementierung benötigt diesen vollständigen Algorithmus, einschließlich ungültiger oder mehrerer Datensätze und DNS Fehler; Das Entfernen von Etiketten, bis ein bekannter Name auftaucht, ist kein Ersatz.
Kopieren Sie psd=y nicht in den Datensatz einer gewöhnlichen Organisation. Es beschreibt eine Suffixrolle. psd=n kann absichtliche Organisationsgrenzen, einschließlich delegierter Teilbäume, unterstützen, sollte jedoch einer dokumentierten Namespace-Entscheidung und nicht einer universellen Checkliste folgen.
Untersuchen Sie die Unterschiede zwischen Werkzeugen und Empfängern
Eine ältere Implementierung verwendet möglicherweise den Public-Suffix-Ansatz, der mit verbunden ist RFC 7489. Eine neuere Implementierung folgt möglicherweise RFC 9989 Tree Walking. DNS Antworten, Caches und Implementierungsunterstützung können daher wichtig sein, wenn die Ergebnisse nicht übereinstimmen.
Behalten Sie für einen nützlichen Vergleich die vollständigen Identitätsnamen, Abfrageantworten mit Zeitstempeln, den erkannten Richtliniendatensatz, die Ausrichtungseinstellungen und das Empfängerergebnis bei. Fragen Sie den Tool-Anbieter, welches Erkennungsmodell er implementiert. Schließen Sie nicht aus einem Veröffentlichungsdatum auf eine allgemeine Akzeptanz ab und ändern Sie DNS nicht nur, um sicherzustellen, dass zwei Dashboard-Bezeichnungen übereinstimmen.
Unterscheiden Sie eine echte Grenzübereinstimmung von einem reinen Authentifizierungsproblem. Eine fehlende DKIM Signatur, eine fehlgeschlagene Signatur oder eine nicht genehmigte Senderoute werden nicht gültig, da die Berechnung der Organisationsdomäne korrigiert wird.
Machen Sie die Grenze zu einem Betriebsdatensatz
Für Domänen mit mehreren Geschäftseinheiten oder delegierten DNS Teams erfassen Sie, wer unterhalb jeder Grenze veröffentlichen kann und welche Dienste dort E-Mails authentifizieren dürfen. Besuchen Sie diesen Datensatz erneut, wenn eine Anwendung eine Subdomäne erhält, eine Geschäftseinheit DNS -Verwaltung ändert oder ein Anbieter aus dem Verkehr gezogen wird.
Verwenden Überprüfung der Subdomain-Richtlinie um zu prüfen, welche Richtlinie gilt, und der Ausrichtungsvergleich bei der Entscheidung, welche Domänenbeziehungen akzeptabel sind.
Das nützliche Ergebnis ist eine reproduzierbare Kette: Dies waren die Nachrichtenidentitäten, diese DNS Antworten legten die relevanten Grenzen fest, diese Richtlinie wurde angewendet und diese übergebene Identität stimmte überein oder stimmte nicht. Ein erratenes Domain-Label kann diesen Beweis nicht liefern.
Verwenden Sie eine Grenzentscheidungskarte
Verwenden Sie diese Karte zur Auswahl der Organisationsdomäne und nicht als Ersatz für die Richtlinienerkennung. Überprüfen Sie zunächst die Autorendomäne auf ihre eigene Richtlinie. Eine direkte Richtlinie kann auch dann gelten, wenn die Ausrichtung eine andere Grenzberechnung erfordert.
| Beobachtung während des angegebenen Spaziergangs | Grenzentscheidung |
|---|---|
| Ein gültiger Datensatz enthält psd=n | Stoppen; Die Domäne dieses Datensatzes ist die Organisationsdomäne. |
| Ein gültiger Datensatz enthält psd=y außerhalb der Startdomäne | Stoppen; Wählen Sie die Domänenbezeichnung eins unter diesem öffentlichen Suffix. |
| psd=y is at the starting domain | Der Lauf endet, aber die Regel „ein Etikett darunter“ gilt nicht für diesen Startdatensatz. Wenden Sie die Auswahlregeln an, anstatt eine untergeordnete Domäne zu erfinden. |
| Gültige Aufzeichnungen liegen ohne entscheidendes Grenzsignal vor | Wählen Sie den gültigen Datensatz mit dem Namen mit den wenigsten Labels aus. Wählen Sie nicht automatisch den ersten Vorfahrendatensatz aus. |
| Es wird keine Organisationsdomäne festgelegt | Verwenden Sie die ursprüngliche Zieldomäne als Organisationsdomäne. Dieser Fallback erstellt keinen Richtliniendatensatz. |
| Der Betreffname hat viele Bezeichnungen | Wenden Sie die Acht-Abfrage-Grenze an: Behalten Sie die ursprüngliche Abfrage bei und kürzen Sie sie dann wie angegeben. Fragen Sie nicht jeden Vorfahren eines beliebig langen Namens ab. |
Diese Zeilen fassen zusammen RFC 9989 Abschnitte 4.10–4.10.2; Datensatzfilterung und DNS-Fehlerbehandlung gelten weiterhin. Bei der Richtlinienerkennung wurde keine Richtlinie gefunden. Das bedeutet, dass DMARC nicht angewendet wird, obwohl der Ausrichtungsalgorithmus über einen Grenzfallback verfügt.
Nehmen wir als zweite fiktive Spur an, dass der Walk für a.mail.example.com gültige Datensätze bei mail.example.com und example.com findet, weder mit psd=n noch mit psd=y, und auch sonst keine. Die ausgewählte Organisationsdomäne ist example.com . Wenn mail.example.com stattdessen psd=n, stoppt der Spaziergang an dieser Stelle und die spezifischere Grenze gewinnt. Bewahren Sie den DNS Snapshot mit dem Ergebnis auf, damit ein anderer Bediener den Vergleich reproduzieren kann.