Ordnen Sie die Entscheidungen zu, die Mailsysteme tatsächlich treffen
Eine nützliche E-Mail-Abhängigkeitskarte verbindet einen geschäftlichen Sendedienst mit den von ihm verwendeten Identitäten, DNS Einträgen und Transportdiensten. Eine Liste aller TXT Eintrag ist nicht genug. Die Karte sollte es einem Eigentümer ermöglichen, zu beantworten, was kaputt gehen könnte, wenn sich ein Anbieter, ein Hostname, ein Schlüssel oder eine Richtlinie ändert, und die erforderlichen Nachweise zu ermitteln, bevor er diese Änderung genehmigt.
Behalten Sie die ausgehende Identitätsauthentifizierung und die eingehende Transportrichtlinie als separate Zweige bei. Sie teilen sich möglicherweise Administratoren und Domänen, schützen jedoch nicht dieselbe Entscheidung. Bei der hier vorgeschlagenen Karte handelt es sich um ein Betriebsmodell, das eine Organisation aus ihrem eigenen autorisierten Inventar und Nachrichtennachweisen füllen muss. Es wird nicht behauptet, dass ein DNS Scan jeden Absender entdecken oder das Verhalten aller Empfänger ermitteln kann.
Beginnen Sie jeden ausgehenden Zweig mit einer echten Senderoute
Erstellen Sie einen Eintrag für jeden Service und jede im Wesentlichen unterschiedliche Route, einschließlich periodischer Abrechnung, Support-Systemen und extern verwalteten Kampagnen. Erfassen Sie den Geschäftsinhaber, den technischen Eigentümer, die sichtbare Autorendomäne, die Umschlagdomäne, die Sendeinfrastruktur und die Beobachtung DKIM Domain signieren und Wähler. Markieren Sie jeden Wert als beobachtet, vom Anbieter dokumentiert oder noch unbekannt. Nutzen Sie die allgemeine Einrichtungsanleitung eines Anbieters nicht als Beweis für die Konfiguration dieses Kontos.
Der SPF Der Zweig beginnt mit der bewerteten Identität und folgt den Richtlinienbedingungen, die für diese Route tatsächlich relevant sind. Beziehen Sie externe Richtlinienverweise und die Teams ein, die sie kontrollieren. RFC 7208 Abschnitte 2.3 und 4.6.4 Identitätsbewertung und DNS-abhängige Grenzwerte erläutern. Eine Abhängigkeitskarte kann zeigen, wo externe Änderungen die Auswertung beeinflussen könnten, aber eine statische Anzahl von Knoten ermittelt das Ergebnis nicht für jede Verbindungsadresse.
Der DKIM Zweig beginnt mit den d- und s-Werten der Signatur und führt zum Verifizierungsdatensatz des Selektors. Fügen Sie ein beliebiges Alias-Ziel, Zielzonenbesitzer und Schlüssellebenszyklusbesitzer hinzu. RFC 6376 Abschnitt 3.6.2.1 definiert diesen Lookup-Namespace. Halten Sie private Schlüssel von der Karte fern; Erfassen Sie sichere Betriebseigentümer und verweisen Sie stattdessen auf ein genehmigtes Schlüsselverwaltungssystem.
Verbinden Sie die Authentifizierung mit der entsprechenden DMARC Entscheidung
Fügen Sie gegebenenfalls die Autorendomäne hinzu DMARC Versicherungsunterlagen und die Beweise dafür, wie die Police entdeckt wurde. Link übergibt authentifizierte Identifikatoren an den Ausrichtung Entscheidung, wobei der strenge oder entspannte Modus identifiziert wird. Unter RFC 9989 Abschnitt 4.4, eine gültige ausgerichtete SPF oder DKIM Kennung kann DMARC erfüllen; Zwei unabhängige Authentifizierungsdurchgänge können keine Ausrichtung herstellen.
Zeichnen Sie den Spezifikations- und Implementierungskontext auf, der für die Bewertung der Richtlinienerkennung verwendet wird. RFC 9989 beschreibt a DNS BaumwanderungDaher sollte eine übernommene Kalkulationstabellenannahme zur Entdeckung überprüft und nicht stillschweigend übernommen werden. Die Karte sollte Unsicherheiten über Empfänger enthalten, deren Implementierung nicht verifiziert wurde. Geben Sie Meldeziele und deren Eigentümer an, aber trennen Sie die Meldeverfügbarkeit vom Nachweis, dass jeder legitime Absender beobachtet wurde.
Zeigen Sie die angeforderte Richtlinie des Eigentümers und die beobachtete Handhabung des Empfängers in verschiedenen Feldern an. Dies macht es für einen zukünftigen Prüfer schwieriger, eine Richtlinienzeichenfolge mit einem Beweis dafür zu verwechseln, dass eine Nachricht abgelehnt, zugestellt oder in einem Posteingang abgelegt wurde.
Fügen Sie den unabhängigen Transportzweig hinzu
Verbinden Sie für eingehende E-Mails die Empfängerdomäne mit ihren MX Hosts und deren Adressabhängigkeiten. Wenn MTA-STS Wird bereitgestellt, fügen Sie den Erkennungs- TXT Eintrag, den HTTPS-Richtlinienhost, den Zertifikatswartungseigentümer, den veröffentlichten Modus, die zulässigen MX Namen und die Richtlinienlebensdauer hinzu. RFC 8461 Abschnitte 3 und 6 Beschreiben Sie die Erkennung und das Caching. Die Gültigkeitsdauer der Richtlinie ist nicht dasselbe Feld wie DNS TTL, und durch die Änderung eines Feldes wird das andere Feld nicht direkt neu geschrieben.
Wo DANE SMTP ist bereitgestellt, ordnen Sie das zu DNSSEC Kette, MX Auflösung, TLSA Datensätze und den entsprechenden TLS Dienst. RFC 7672 Abschnitt 2 macht authentifiziertes DNS zu einer zentralen Abhängigkeit. Ein TLSA-Datensatz, der ohne Validierung und Zertifikatsbeziehung in den Bestand kopiert wird, ist ein unvollständiger Betriebsbeweis.
Fügen Sie TLS Berichterstellung als Beobachtungskanal und nicht als Durchsetzungsmechanismus hinzu. RFC 8460 Abschnitt 3 Definiert die Erkennung von Berichtsrichtlinien. Das Meldeziel benötigt einen Eigentümer und einen Überprüfungsprozess, während die eigentliche Transportrichtlinie eine eindeutige Abhängigkeit bleibt.
Fiktives Beispiel einer Provider-Migration
Die fiktive Organisation „Example Repairs“ plant, den Rechnungsversand an einen neuen Anbieter zu verlagern. Die vorgeschlagene Karte verknüpft den Rechnungsdienst mit billing.example.com als Autorendomäne, einer separaten Umschlagdomäne und einem alten DKIM Selektor, der über einen Alias gehostet wird. Der Migrationseigentümer stellt fest, dass der eingestellte Anbieter weiterhin das Aliasziel kontrolliert und dass einige Nachrichten in der Warteschlange möglicherweise die alte Signatur tragen.
Die Überprüfung schlägt daher einen schrittweisen Wechsel der Vertragsunterzeichnung, eine Überprüfung des Ersatzweges und eine gesondert genehmigte Entscheidung über den Rücktritt vor. In der Zwischenzeit bleiben eingehende MX und MTA-STS -Einträge ein anderer Zweig und werden im Rahmen eines ausgehenden Anbieterwechsels nicht automatisch bearbeitet. Dieses Beispiel ist erfunden; Die Identitäten, Genehmigungen und Nachrichtenergebnisse wurden nicht von einem echten Konto erhalten.
Der Vorteil der Karte liegt in der Frage, die sie aufwirft: Welche Beweise erlauben es, diesen Alias zu entfernen, ohne die Überprüfung legitimer Nachrichten zu unterbrechen? Die Karte selbst antwortet darauf nicht. Der Serviceeigentümer muss Warteschlangen- und Signaturinformationen bereitstellen, und der Prüfer muss diese Fakten mit der vorgeschlagenen Änderung verknüpfen.
Bewahren Sie Beweise und Eigentum mit der Karte
Geben Sie für jede Kante ein Datum der letzten Überprüfung, eine Beweisreferenz, einen Eigentümer und einen Überprüfungsauslöser ein. Besuchen Sie es nach einer Anbietermigration, einer Selektorrotation, einer Delegationsänderung, einer Änderung der Transportrichtlinie oder einem unerklärlichen Authentifizierungsfehler erneut. Unbekannte Besitzer und ungeprüfte Kanten sollten sichtbar bleiben und nicht mit Vermutungen gefüllt werden.
Erstellen Sie vor der Einführung die Bereitschaftsmatrix für jeden Sender, die genauen Richtlinienunterschiede und den Genehmigungsdatensatz. Hängen Sie nach der autorisierten Ausführung die entsprechende Nachricht und DNS Beobachtungen an. Dies sind die erforderlichen Originalartefakte des Katalogs und bleiben hier offen. Dieses Manuskript bietet einen Kartenentwurf und eine fiktive Entscheidungsübung, keinen ausgefüllten Mieterbestand oder verifizierten Rollout.