A DKIM Selektor ist auf eine signierende Domäne beschränkt. Zwei Dienste können das Wort „default“ sicher unter verschiedenen d=-Domänen verwenden, aber default._domainkey.example.com ist ein DNS Besitzername. Wenn zwei unabhängige Dienste unterschiedliche Schlüssel mit demselben Namen benötigen, kann das Hinzufügen des zweiten Dienstes die Überprüfung für den ersten beeinträchtigen. Lösen Sie den Eigentumskonflikt, bevor Sie DNS ändern.
Vergleichen Sie die vollständigen Namen
Sammeln Sie eine kürzlich empfangene signierte Nachricht von jedem aktiven Dienst und zeichnen Sie d= und s=. Vergleichen Sie diese Werte mit den ausstehenden Einrichtungsanweisungen des Anbieters. Beim DNS-basierten Schlüsselabruf bestimmen der Selektor und die Signaturdomäne den Suchnamen. Eine Anbieterbezeichnung wie „Selektor 1“ in einem Setup-Bildschirm reicht nicht aus, um den tatsächlichen DNS Besitzer zu identifizieren. RFC 6376 §3.5 Und RFC 6376 §3.6.2.1.
Anschauliches Beispiel: Gehaltsabrechnung und Marketing fordern beide s=default mit d=example.com, verfügen jedoch jeweils über einen anderen privaten Schlüssel. Beide Signaturen führen Prüfer zu default._domainkey.example.com . Das Ersetzen des öffentlichen Schlüssels der Lohn- und Gehaltsabrechnung durch den Schlüssel des Marketings kann dazu führen, dass Nachrichten zur Lohn- und Gehaltsabrechnung nicht überprüfbar sind, einschließlich Nachrichten, die bereits übertragen wurden. Umgekehrt sind „Default unter d=payroll.example.com und „Default unter d=marketing.example.com unterschiedliche Suchnamen. Ausrichtung Auswirkungen bedürfen noch einer gesonderten Prüfung.
Wählen Sie ein unterstütztes Trennungsdesign
Bevorzugen Sie unterschiedliche Selektoren für unabhängige Signaturdienste, wenn die Anbieter diese unterstützen. Veröffentlichen Sie den generierten Public-Key-Datensatz des neuen Dienstes unter seinem eigenen Besitzernamen, validieren Sie ihn, aktivieren Sie dann diesen Unterzeichner und testen Sie empfangene E-Mails. Wenn ein Dienst seinen Selektornamen korrigiert, fragen Sie, ob er eine separate Signatur-Subdomäne oder eine andere dokumentierte Konfiguration unterstützt. Erfinden Sie kein CNAME Zielen Sie auf einen Selektor oder benennen Sie ihn ausschließlich im DNS um: Der Unterzeichner muss den passenden s=-Wert ausgeben.
Das Ändern von d= in eine Subdomain kann Auswirkungen haben DMARC. Eine Subdomain kann nach lockeren Regeln ausgerichtet werden, während die strikte Ausrichtung an einer übergeordneten Autorendomäne fehlschlägt. Bestätigen Sie die beabsichtigte Beziehung, bevor Sie die Namensumgehung auswählen. RFC 9989 §4.4.1 Und RFC 9989 §4.10.2.
Verlassen Sie sich nicht auf mehrdeutige Schlüsselantworten
Unter RFC 6376 §3.6.2.2, TXT Schlüsseldatensätze müssen für einen Selektornamen eindeutig sein; Ergebnisse mit mehreren Datensätzen sind undefiniert. Das Veröffentlichen mehrerer verschiedener Schlüssel bei einem Eigentümer verstößt gegen diese Veröffentlichungsregel und stellt kein Design zur Diensttrennung dar. RFC 6376 ermöglicht es einem Prüfer, nach eigenem Ermessen einen zurückgegebenen Schlüssel auszuwählen oder mehrere in unbestimmter Reihenfolge auszuprobieren. Eine Konfiguration, die bei einem Empfänger funktioniert, kann daher an anderer Stelle unzuverlässig sein. Separate Selektoren bieten eine explizite Zuordnung, anstatt sich auf das Schlüsselauswahlverhalten zu verlassen. RFC 6376 §6.1.2.
Ein anderes Problem stellen mehrere in Anführungszeichen gesetzte Zeichenfolgen innerhalb eines TXT Ressourcendatensatzes dar: Sie können Teile eines einzelnen Datensatzes sein. Verwechseln Sie den Display-Wrapping des Anbieters nicht mit mehreren unterschiedlichen Schlüsseln. Vergleichen Sie die tatsächlichen DNS Antworten und den vom Anbieter generierten Wert mit einem geeigneten DNS Tool.
Behandeln Sie eine bestehende Kollision sicher
Wenn bereits eine Kollision aufgetreten ist, erfassen Sie den aktuellen DNS , den Konfigurationsverlauf, betroffene D/S-Paare und Empfängerausfälle. Stellen Sie die vorherige Zuordnung nur dann wieder her, wenn sie sicher ist und noch benötigt wird, und schalten Sie dann den neuen Dienst unter einem unterstützten eindeutigen Selektor online. Vermeiden Sie es, private Schlüssel zwischen unabhängigen Diensten zu teilen, nur um sie in einen öffentlichen Datensatz zu integrieren. das erweitert das Sorgerecht und die Auswirkungen von Vorfällen.
Behalten Sie den alten Verifizierungsdatensatz für die Überschneidung bei, die Ihr legitimer Pfad für verzögerte E-Mails benötigt, vorbehaltlich Sicherheitsüberlegungen und des Rotationsprozesses des Anbieters. Ein kompromittierter Schlüssel ist ein anderer Fall und kann trotz Auswirkungen auf die Zustellung einen sofortigen Widerruf erfordern. Testen Sie beide Dienste nach der Änderung unabhängig voneinander, erfassen Sie ihre Besitzer und reservieren Sie ihre Selektornamen im Inventar. Beim Akzeptanztest handelt es sich um zwei überprüfbare, beabsichtigte Identitäten, nicht nur um zwei grüne Anbieter-Setup-Bildschirme.
Lösen Sie eine synthetische Zwei-Service-Anfrage
Angenommen, die Gehaltsabrechnung signiert derzeit mit s=default und d=example.com, und das Marketing fordert dasselbe Paar mit einem anderen Schlüssel an. Der Lookup-Eigentümer ist identisch. Überschreiben Sie ihn daher nicht und veröffentlichen Sie den zweiten unabhängigen Schlüssel nicht daneben. Wenn Marketing s=marketing2026, veröffentlichen Sie den generierten Schlüssel unter marketing2026._domainkey.example.com und konfigurieren Sie denselben Selektor in seinem Unterzeichner. Dann testen Sie payroll/default und marketing/marketing2026 unabhängig voneinander. Wenn nur eine signing-subdomain-Option unterstützt wird, überprüfen Sie deren Ausrichtung, bevor Sie d ändern. Hierbei handelt es sich um Planungsschritte, nicht um ein erprobtes Anbieterverfahren.