Najbardziej niezawodne miejsce do znalezienia Selektor DKIM jest DKIM-Signature nagłówek wiadomości, którą badasz. Przeczytaj wartość s= i sparuj ją z domeną podpisującą d= z tego samego podpisu.
Selektor określa, gdzie publikowane są materiały weryfikacyjne. Nie identyfikuje widocznego nadawcy ani nie potwierdza, że podpis przeszedł. W tym przewodniku podążamy za dowodem z otrzymanej wiadomości do prawidłowej nazwy DNS , a następnie wyjaśniamy, co można, a czego nie można ustalić podczas wyszukiwania.
Uzyskaj oryginalną otrzymaną wiadomość
Użyj kontrolowanej wiadomości wysłanej za pośrednictwem rzeczywistej usługi do osobnego odbiorcy. Zachowaj oryginalną wiadomość w takiej formie, w jakiej została tam otrzymana. Przesłany zrzut ekranu lub ponownie zapisana, edytowana wiadomość może pominąć lub zmienić dowód.
Znajdź każdy nagłówek DKIM-Signature . Wiadomość może zawierać więcej niż jeden. Dla każdego podpisu zapisz oddzielnie domenę podpisu i selektor, a następnie skoreluj wynik weryfikacji zaufanego odbiorcy.
- d: domena podpisująca.
- s: selektor.
- a: algorytm podpisywania/mieszania.
- h: wybrana lista nagłówków ze podpisem.
- bh i b: skrót ciała i wartości podpisu, a nie rekordy klucza publicznego DNS .
Pola te są definiowane przez RFC 6376 §3.5.
Nie zastępuj widocznej domeny From d= podczas tworzenia wyszukiwania klucza. Wyrównanie jest późniejszym porównaniem pomiędzy przechodzącą tożsamością podpisującą a widoczną tożsamością From.
Utwórz i zapytaj nazwę weryfikacji
Pod RFC 6376 §3.6.2.1, nazwa weryfikacji łączy dwie wartości z tego samego podpisu:
<selektor>. _domainkey .<domena-podpisująca>
W tym syntetycznym przykładzie podpis identyfikuje:
Podpis syntetyczny ma d=example.com i s=mail2026.
Odpowiednie wyszukiwanie to:
dig TXT mail2026._domainkey.example.com +noall +answer
Jeśli dostawca deleguje zarządzanie kluczami za pośrednictwem a CNAME, sprawdź także ten łańcuch:
dig CNAME mail2026._domainkey.example.com +noall +answer
Są to przykładowe kontrole DNS , a nie weryfikacja przechwyconej prawdziwej wiadomości. Użyj rzeczywistych wartości podpisu. Pod RFC 1034 §3.6.2w przypadku opublikowanego aliasu podążaj za zamierzonym celem i ustal, czy dane weryfikacyjne są dostępne w całym łańcuchu.
Publiczny DNS zawiera materiał klucza weryfikacyjnego lub prowadzącą do niego delegację. Prywatny klucz podpisujący należy do autoryzowanego systemu podpisywania, a nie do Rekord TXT.
Zinterpretuj wyszukiwanie wraz z wynikami weryfikacji
Odpowiedź klucza publicznego pokazuje, że mechanizm rozpoznawania nazw może w tym czasie pobrać określony materiał weryfikacyjny. Nie stanowi dowodu, że wiadomość zawiera podpis, że odpowiedni klucz prywatny został użyty prawidłowo lub że podpisana treść pozostała nienaruszona.
Jeśli klucz istnieje, ale podpis się nie powiódł, sprawdź pełny wynik weryfikacji. Zmiany treści, zniekształcone lub niezgodne kluczowe dane, zakres podpisów, warunki związane z czasem i obserwacje DNS mogą wymagać różnych środków zaradczych.
Jeśli nie znaleziono żadnego klucza, sprawdź dokładnie d= I s=, strefa autorytatywna, cel CNAME , historia wycofywania klucza i błędy modułu rozpoznawania nazw. Nie publikuj odgadniętego selektora tylko po to, aby zmienić kolor szachownicy na zielony.
Jeśli oryginał nie ma odpowiedniego podpisu DKIM , wyszukiwanie selektora nie może wygenerować podpisu. Sprawdź, czy rzeczywisty nadawca jest skonfigurowany do podpisywania, czy usługa obsługuje wymaganą tożsamość i czy późniejsza trasa nie zmieniła dowodu.
Obsługuj wiele podpisów i rotację kluczy
Utwórz osobny wiersz dla każdego podpisu i jego zaufanego wyniku. Własny podpis przekazujący usługę może nie być wyrównany, podczas gdy podpis domeny klienta przechodzi wyrównanie. Inna wiadomość może mieć błędny podpis domeny klienta i tylko niepowiązany podpis.
W przypadku rotacji sprawdź, którego selektora użyto prawdziwej wiadomości, a nie tylko, które dwa rekordy są dostępne w DNS . Zachowaj związek między stanem konfiguracji, przeniesieniem podpisu i wiadomościami już przesyłanymi. Wycofanie starego selektora może mieć wpływ na późniejszą weryfikację zapisanych lub opóźnionych wiadomości.
W przypadku Microsoft 365 użyj przewodnik konfiguracji dla konkretnego dzierżawcy. W przypadku Workspace użyj przewodnik konfiguracji wybranej domeny. Wspólny wzorzec selektora żadnego z dostawców nie powinien zastępować czytania rzeczywistych dowodów.
Potwierdź zalogowanie się do właściwej usługi
Jeśli dostawca twierdzi, że Twoja domena ma DKIM skonfigurowany, poproś go o pokazanie wiadomości wysłanej przez odpowiedni przepływ pracy i domenę, która faktycznie ją podpisała. Klucz widoczny publicznie to jedna zależność konfiguracji, a nie dowód podpisania na żywo.
Ma to znaczenie, gdy kilka narzędzi korzysta z tej samej widocznej marki. Poczta pracownicza, zgłoszenia do pomocy technicznej i rachunki mogą mieć różnych selektorów, domeny podpisujące i właścicieli. Pomyślna kontrola jednego nie może zastąpić pozostałych.
Śledź podpisywanie własności i delegowanie
Utrzymuj spis selektorów powiązany z usługą, domeną, modelem zarządzania kluczami i właścicielem firmy. Rozróżnij bezpośrednią kontrolę nad kluczem od delegowania do dostawcy. Przejrzyj delegację, gdy usługa zostanie wyłączona.
Ogranicz dostęp do klucza prywatnego i zdefiniuj reakcję na podejrzenie naruszenia bezpieczeństwa. Ważny rejestr publiczny nie jest dowodem na to, że kluczowy areszt jest prawidłowy. Podobnie ważny podpis stanowi potwierdzenie na poziomie domeny dotyczące objętych treści; nie zatwierdza żądania płatności ani nie wyklucza naruszenia konta.
Przydatny łańcuch dowodów to wiadomość, tożsamość podpisu, wyszukiwanie klucza, zaufana weryfikacja i dopasowanie. Zachowaj te obserwacje razem, aby następny recenzent mógł odtworzyć diagnozę.
Praktyczne dania na wynos
Zachowaj razem oryginalną wiadomość, tożsamość podpisu, obserwację DNS i wynik zaufanego odbiorcy. Dowody te odróżniają brakujący klucz od niepodpisanej wiadomości, podpisu, który się nie powiódł lub podpisu, który przechodzi, ale się nie zgadza.
Zastosuj rozróżnienie
Mając dwa hipotetyczne podpisy, d=example.com/s=mail2026 i d=service.example.net/s=outbound, oddzielnie zapytaj mail2026._domainkey.example.com i outbound._domainkey.service.example.net . Nigdy nie łącz mail2026 z drugim d. Zachowaj każdy czas wyszukiwania i zaufany wynik wraz z parą. Późniejszy brakujący klucz nie usuwa wcześniejszej obserwacji zaufanego odbiorcy.