DKIM pozwala domenie wziąć odpowiedzialność za wiadomość za pomocą podpisu kryptograficznego. Aby zrozumieć, co to oznacza dla konkretnego e-maila, zacznij od otrzymanego oryginału, a nie od narzędzia sprawdzającego DNS . Przydatnym łańcuchem dowodów jest podpis wiadomości, domena podpisu i selektor, klucz publiczny, wynik weryfikacji odbiorcy, a następnie dowolny DMARC wyrównanie decyzja.
Przeczytaj tożsamość, która została podpisana
Zlokalizuj każdy DKIM-Signature nagłówek w oryginalnej wiadomości. Wartość d= identyfikuje domenę podpisującą, a s= identyfikuje jej selektor. Aby uzyskać klucz w oparciu o DNS, połącz je jako selektor. _domainkey.signing-domain. Domena podpisująca może należeć do organizacji autora, przekaźnika lub działającej na jej rzecz służby. DKIM celowo oddziela odpowiedzialność za podpisywanie od rzekomego autora. RFC 6376 §1, RFC 6376 §3.5, RFC 6376 §3.6.2.
Przykład ilustrujący: From to accounts@example.com , a podpis zawiera d=example.com; s=mail2026. Weryfikator wyszukuje mail2026._domainkey.example.com . Ten rekord DNS dostarcza publicznych materiałów weryfikacyjnych. Prywatny klucz do podpisu pozostaje u autoryzowanego podpisującego i nie można go publikować. Ten przykład wyjaśnia wyszukiwanie; nie jest to prawdziwy podpis ani sprawdzona wiadomość.
Oddziel obecność od pomyślnej weryfikacji
Nagłówek DKIM-Signature może być obecny i nieprawidłowy. Klucz DNS może istnieć, gdy aplikacja w ogóle nie wysyła podpisów. Weryfikacja sprawdza strukturę podpisu, klucz, wybrane nagłówki i reprezentację treści. Zmiany po podpisaniu mogą to złamać, w zależności od tego, co się zmieniło i kanonizacja używany. Ciąg wyglądający na skrót nie jest dowodem na to, że te kontrole poszły pomyślnie. RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §3.7, RFC 6376 §6.
Sprawdź zaufany system odbierający Authentication-Results lub równoważne dzienniki. Dowiedz się, która usługa uwierzytelniania dodała ten wynik i gdzie niezaufane nagłówki wyników przychodzących są usuwane lub ignorowane. Nadawca może wstawić do wiadomości wiarygodnie wyglądający tekst hasła, więc dowolna treść Authentication-Results nie jest dowodem. RFC 8601 §1.2, RFC 8601 §7.1.
Połącz wynik z widocznym autorem
W przypadku DMARC porównaj pomyślnie zweryfikowaną domenę d= z domeną autora z From. Ścisłe wyrównanie DKIM wymaga dokładnego dopasowania poniżej RFC 9989 §3.2.10; zrelaksowane dopasowanie wykorzystuje odkrywanie domeny organizacyjnej w RFC 9989 §4.10.2. Selektor i opcjonalna wartość i= nie są domenami używanymi w tym porównaniu DMARC . Jeśli obecnych jest kilka podpisów DKIM , jeden przechodzący, wyrównany podpis może dostarczyć ścieżkę DKIM do przepustki DMARC . RFC 9989 §4.4.1.
W przykładzie d=example.com odpowiada domenie From. Jeśli zamiast tego weryfikuje d=service.example.net , surowy DKIM przechodzi, ale niepowiązana domena nie ustala zgodności z example.com . Nie „naprawiaj” tego poprzez edycję otrzymanego nagłówka: skonfiguruj uprawnionego podpisującego, aby korzystał z odpowiedniej obsługiwanej tożsamości.
Zbuduj przydatny zapis dochodzenia
Zapisz czas wiadomości, trasę, z domeny, każdą parę d/s, zaufany wynik DKIM i przyczynę, czas obserwacji DNS i wynik wyrównania. Chroń oryginalną wiadomość, ponieważ może zawierać informacje osobiste lub poufne. Redakcja kopii może unieważnić jej podpis; zachować oryginał z kontrolą dostępu, gdy konieczna jest ponowna weryfikacja.
Jeśli weryfikacja się nie powiedzie, sprawdź, czy włączono podpisywanie, czy dostępny jest właściwy klucz, czy algorytm jest obsługiwany i czy wiadomość została zmieniona w trakcie przesyłania. Obecne wskazówki kryptograficzne zastępują przestarzałe ustawienia domyślne: RFC 8301 §3.1 zabrania rsa-sha1 do podpisywania i weryfikacji; RFC 8301 §3.2 aktualizuje wytyczne dotyczące kluczy RSA. Nie używaj opcji kryptograficznych ze starego samouczka tylko dlatego, że jego składnia nadal wygląda na poprawną. Zakończ dowodem otrzymanego wyniku, a nie tylko dowodem na to, że DNS zawiera klucz.
Zastosuj rozróżnienie
W przypadku wiadomości hipotetycznej wpisz po jednym wierszu dla każdego podpisu: d, s, właściciel wyszukiwania, zaufany wynik weryfikacji i wyrównanie. Jeśli podpis example.com nie powiedzie się, podczas gdy niepowiązany podpis service.example.net przejdzie pomyślnie, nie łącz pierwszej domeny z drugim wynikiem. Zbadaj nieudany podpis i oceń SPF oddzielnie przed przypisaniem DMARC . Dla tego artykułu nie przeprowadzono weryfikacji wiadomości.