A Selektor DKIM jest ograniczony do domeny podpisującej. Dwie usługi mogą bezpiecznie używać słowa „domyślny” w różnych domenach d=, ale default._domainkey.example.com to jedna nazwa właściciela DNS . Jeśli dwie niezależne usługi wymagają różnych kluczy o tej samej nazwie, dodanie drugiej usługi może przerwać weryfikację pierwszej. Rozwiąż kolizję własności przed zmianą DNS .
Porównaj pełne nazwy
Zbierz niedawno odebraną podpisaną wiadomość z każdej aktywnej usługi i zapisz d= i s=. Porównaj te wartości z oczekującymi instrukcjami konfiguracji dostawcy. W przypadku pobierania kluczy w oparciu o DNS nazwa wyszukiwania jest określana przez selektor i domenę podpisującą. Etykieta dostawcy, taka jak „selektor 1”, na ekranie konfiguracji nie wystarczy, aby zidentyfikować prawdziwego właściciela DNS . RFC 6376 §3.5 I RFC 6376 §3.6.2.1.
Przykład ilustrujący: płace i marketing żądają s=default z d=example.com, ale każde z nich posiada inny klucz prywatny. Obydwa podpisy prowadzą weryfikatorów do default._domainkey.example.com . Zastąpienie klucza publicznego listy płac kluczem marketingu może sprawić, że wiadomości dotyczące płac nie będą mogły zostać zweryfikowane, w tym wiadomości już przesyłane. I odwrotnie, domyślne nazwy w d=payroll.example.com i domyślne w d=marketing.example.com to różne nazwy wyszukiwania. Wyrównanie konsekwencje nadal wymagają osobnej kontroli.
Wybierz obsługiwany projekt separacji
Preferuj odrębne selektory dla niezależnych usług podpisywania, jeśli dostawcy je obsługują. Opublikuj wygenerowany rekord klucza publicznego nowej usługi pod własną nazwą właściciela, zatwierdź go, a następnie włącz tę osobę podpisującą i przetestuj otrzymaną pocztę. Jeśli usługa poprawia swoją nazwę selektora, zapytaj, czy obsługuje oddzielną subdomenę podpisującą lub inną udokumentowaną konfigurację. Nie wymyślaj A CNAME wybierz lub zmień nazwę selektora wyłącznie w DNS : osoba podpisująca musi wyemitować pasującą wartość s=.
Zmiana d= na subdomenę może mieć wpływ DMARC. Subdomena może podlegać złagodzonym zasadom, ale nie może być zgodna z nadrzędną domeną autora. Przed wybraniem obejścia nazewnictwa potwierdź zamierzoną relację. RFC 9989 §4.4.1 I RFC 9989 §4.10.2.
Nie polegaj na niejednoznacznych kluczowych odpowiedziach
Pod RFC 6376 §3.6.2.2, rekordy kluczy TXT muszą być unikalne dla nazwy selektora; wyniki z wieloma rekordami są niezdefiniowane. Publikowanie wielu różnych kluczy u jednego właściciela narusza tę zasadę publikacji i nie stanowi projektu separacji usług. RFC 6376 pozwala weryfikatorowi wybrać jeden zwrócony klucz lub wypróbować kilka według własnego uznania, z nieokreśloną kolejnością. Konfiguracja, która działa na jednym odbiorniku, może zatem być zawodna gdzie indziej. Oddzielne selektory zapewniają jawne mapowanie zamiast polegać na zachowaniu związanym z wyborem klucza. RFC 6376 §6.1.2.
Wiele ciągów znaków w cudzysłowie w jednym rekordzie zasobu TXT to inny problem: mogą one stanowić części pojedynczego rekordu. Nie należy mylić opakowania wyświetlacza dostawcy z wieloma różnymi kluczami. Porównaj rzeczywiste odpowiedzi DNS z wartością wygenerowaną przez dostawcę, korzystając z odpowiedniego narzędzia DNS .
Bezpiecznie poradź sobie z istniejącą kolizją
Jeśli kolizja już wystąpiła, przechwyć bieżący DNS , historię konfiguracji, dotknięte pary d/s i awarie odbiornika. Przywróć poprzednie mapowanie tylko wtedy, gdy jest bezpieczne i nadal potrzebne, a następnie udostępnij nową usługę online w ramach obsługiwanego odrębnego selektora. Unikaj udostępniania kluczy prywatnych pomiędzy niepowiązanymi usługami jedynie po to, aby dopasować je do jednego publicznego rekordu; co zwiększa wpływ opieki i incydentów.
Zachowaj stary zapis weryfikacyjny pod kątem pokrywania się uzasadnionych potrzeb związanych ze ścieżką opóźnionej poczty, z zastrzeżeniem względów bezpieczeństwa i procesu rotacji dostawcy. Zhakowany klucz to inny przypadek i może wymagać natychmiastowego unieważnienia pomimo wpływu na dostawę. Po zmianie przetestuj obie usługi niezależnie, zapisz ich właścicieli i zarezerwuj ich nazwy selektorów w ekwipunku. Test akceptacyjny to dwie możliwe do zweryfikowania, zamierzone tożsamości, a nie tylko dwa ekrany konfiguracji ekologicznego dostawcy.
Rozwiąż syntetyczne żądanie dwóch usług
Załóżmy, że lista płac obecnie podpisuje się za pomocą s=default i d=example.com, a marketing żąda tej samej pary z innym kluczem. Właściciel wyszukiwania jest identyczny, więc nie nadpisuj go ani nie publikuj obok niego drugiego niezależnego klucza. Jeśli dział marketingu obsługuje s=marketing2026, opublikuj wygenerowany klucz pod adresem marketing2026._domainkey.example.com i skonfiguruj ten sam selektor w jego osobie podpisującej. Następnie przetestuj niezależnie płace/domyślne i marketing/marketing2026. Jeśli obsługiwana jest tylko opcja podpisywania subdomeny, sprawdź jej wyrównanie przed zmianą d. Są to etapy planowania, a nie sprawdzona procedura dostawcy.