Najemca może zawierać kilka marek, nabytych domen i adresów pracowników bez podpisywania ich wszystkich w ten sam sposób. DKIM współpracuje z domeną podpisującą znajdującą się w każdej wiadomości, a nie z etykietą dzierżawcy w portalu administracyjnym. Ustal, jakie tożsamości obsługuje usługa, a następnie udowodnij wyniki dla każdej istotnej domeny.
W tym przewodniku opisano proces weryfikacji niezależny od dostawcy. Nie gwarantuje, że konkretny produkt lub subskrypcja obsługuje podpisywanie domeny niestandardowej. Przed opublikowaniem zapisów lub zmianą ich konfiguracji uzyskaj aktualne instrukcje dotyczące aktualnej usługi i trasy.
Zbuduj zasoby domeny i tras
Zapisz widoczną domenę Od, właściciela firmy, najemcę, aplikację wysyłającą, oczekiwaną domenę DKIM d, selektor, właściciel DNS i stan podpisania. Uwzględnij pocztę internetową, uwierzytelniony SMTP , interfejsy API aplikacji, delegowane konta i faktycznie używaną trasę bramy. Pomyślny test poczty pracowniczej nie pozwala ustalić, w jaki sposób podpisuje się wniosek o fakturę.
Oddziel zweryfikowaną domenę w dzierżawie od domeny skonfigurowanej do podpisywania ruchu wychodzącego. Aktywnie oddziel obecny rekord DNS od nadawcy, używając odpowiedniego klucza prywatnego. Są to różne stany i ani sprawdzenie własności, ani opublikowany klucz nie dowodzą, że otrzymana wiadomość ma ważny podpis.
Mapuj tożsamość w otrzymanej poczcie
Dla każdej trasy wyślij kontrolowaną wiadomość do zewnętrznej skrzynki pocztowej, którą możesz sprawdzić. Zachowaj surową formę i zaufanie odbiorcy Authentication-Results. Przeczytaj d i s z każdego z nich DKIM-Signature. RFC 6376 definiuje nazwę wyszukiwania jako selektor w obszarze _domainkey domeny podpisującej. Podpis z d=brand.example i s=tenant1 wskazuje zatem na tenant1._domainkey.brand.example .
Oceń weryfikację podpisu i DMARC wyrównanie osobno. Domena w d jest odpowiednią tożsamością DKIM dla DMARC . Ścisłe wyrównanie wymaga dokładnego dopasowania domeny; zrelaksowane dopasowanie porównuje domeny organizacyjne zgodnie z obowiązującymi regułami odkrywania. Posiadanie obu domen w tym samym dzierżawie komercyjnym nie powoduje wyrównania niepowiązanych domen. RFC 9989 sekcje 3.2.10 i 4.4 wyjaśniają to rozróżnienie.
Przeanalizuj przykład dwóch marek
Przykładowy asortyment: najemca wysyła pocztę pracowniczą z brand.example , używając d=brand.example i pocztę kampanii z second.example , używając d=provider.example. Załóżmy, że oba podpisy przeszły. Pierwszym z nich jest dokładne dopasowanie wyrównania DKIM . Drugi nie zapewnia wyrównanego DKIM dla second.example tylko dlatego, że ten sam najemca jest właścicielem obu przepływów pracy.
Dodaj osobny wynik dla SPF zamiast deklarować drugą wiadomość jako awarię DMARC bez jej sprawdzenia. Przy obowiązujących zasadach i braku nierozwiązanych błędów oceny przekazująca, dopasowana tożsamość SPF może nadal spełniać DMARC dla wiadomości. Jednakże sekcje 7.4 i 8 RFC 9989 wymagają publikacji domeny p=reject nie polegać wyłącznie na SPF w zakresie przepustki DMARC i stosować ważne podpisy DKIM . Traktuj brakującą ścieżkę wyrównanego DKIM jako lukę we wdrożeniu dla tej zasady, a nie jako kompletny projekt zasady odrzucania. Przykład pokazuje brakującą ścieżkę DKIM , a nie pełną ocenę odbiorcy. Są to syntetyczne tożsamości i zakładane wyniki, a nie testy prawdziwego dostawcy.
Skonfiguruj tylko obsługiwane tożsamości podpisujące
Zapytaj dostawcę, jak włączyć każdą domenę, czy aliasy są zgodne z konfiguracją domeny podstawowej i czy trasy SMTP i API zachowują się inaczej. Postępuj zgodnie z jego dokładnym TXT lub CNAME instrukcje. W przypadku modelu CNAME postępuj zgodnie z delegacją do danych weryfikacyjnych zarządzanych przez dostawcę; nie zastępuj odgadniętego klucza publicznego ani nie kopiuj celu innego dzierżawcy.
Używaj oddzielnych selektorów, jeśli wymaga tego usługa, i prowadź rejestr własności. Ponowne użycie etykiety selektora w różnych domenach nie jest z natury kolizją, ponieważ pełne nazwy DNS różnią się. RFC 6376 sekcja 3.6.2.2 wymaga klucza Rekord TXT być unikatowa dla nazwy selektora; wiele rekordów TXT pod tą nazwą wyszukiwania daje niezdefiniowane wyniki. Nie publikuj tam konkurencyjnych kluczy.
Zamknąć inwentarz za pomocą dowodów
Oznacz każdy wiersz jako zweryfikowany tylko wtedy, gdy zawiera próbkę otrzymanej wiadomości z datą, oczekiwaną tożsamość, zaobserwowany wynik podpisu i ocenę zgodności. Zapisz każdą nieobsługiwaną trasę jako ograniczenie wraz z właścicielem i alternatywą, zamiast ukrywać ją za statusem włączenia dzierżawcy.
Przetestuj ponownie po dodaniu domeny, zmianie reguły routingu lub migracji marki. Uwzględnij delegowane rekordy w procesie offboardingu, aby uprawnienia do podpisywania i zależności dostawców nie przekroczyły swojego celu. Przydatnym rezultatem jest zrozumiała mapa domeny do podpisania, a nie zrzut ekranu przedstawiający przełącznik globalny.
Wypełnij jeden rząd dowodów na każdą trasę
- Oczekiwane: właściciel firmy, z domeny, trasa aplikacji, domena podpisująca i selektor.
- Opublikowano: dokładna nazwa DNS selektora, typ rekordu i delegowany cel, jeśli jest używany.
- Zaobserwowano: otrzymaną wiadomość z datą, każdą parę d=/s= i zaufany wynik weryfikacji.
- Wyrównane: porównaj przekazywane tożsamości DKIM i SPF z opcją From w ramach odpowiednich zasad.
- Decyzja: zweryfikowana, nieobsługiwana lub nierozwiązana, z właścicielem i następnym testem.
- Wycofanie się: zapisz, kiedy trasa przestaje się podpisywać, limit poczty w kolejce i kto usuwa przestarzałe delegacje.