Dostawca może emitować valid DKIM podpisów bez obsługi domeny podpisującej Twojej organizacji. To ograniczenie ma znaczenie, gdy podpis usługi nie jest zgodny z domeną, którą klienci widzą w polu Od. Ustal dokładne ograniczenia przed zmianą DNS lub wymianą usługi.
Sprawdź, co dostawca faktycznie obsługuje
Poproś o aktualną dokumentację dotyczącą poziomu konta, interfejsu wysyłającego i typu domeny, z której korzystasz. Zweryfikowany adres nadawcy, niestandardowa domena śledzenia lub markowa ścieżka zwrotna nie są dowodem niestandardowej obsługi DKIM . Uzyskaj nieprzetworzoną wiadomość odebraną z rzeczywistej trasy i zapisz wartości d i s każdego podpisu oraz wyniki weryfikacji zaufanego odbiorcy.
RFC 6376 definiuje d jako domenę podpisującą i używa s w tej domenie do zlokalizowania danych weryfikacyjnych. Opublikowanie klucza we własnej domenie nie może zmienić d podpisu utworzonego przez dostawcę. A CNAME podobnie wymaga konfiguracji podpisywania obsługiwanej przez dostawcę; Sam alias DNS nie nakazuje usłudze podpisania się za Ciebie.
Sprawdź, czy istnieje inna wyrównana ścieżka
Przy obowiązującej polityce i braku nierozwiązanych błędów w ocenie, DMARC może przejść przez albo przejście wyrównane SPF lub wynik DKIM . Oceń wartość usługi POCZTA OD domena i wynik SPF osobno. Obsługiwana niestandardowa ścieżka zwrotna może zapewniać wyrównany SPF nawet wtedy, gdy niestandardowy DKIM jest niedostępny. Sprawdź wyrównanie tryb i związek domeny; ścieżka powrotu należąca do dostawcy nie jest zgodna tylko dlatego, że płacisz za konto.
Przykładowy przypadek: poczta używa From= notices@brand.example i przekazuje DKIM z d=vendor.example. Jej domena MAIL FROM to bounce.brand.example i przepustki SPF . Zakładając, że kwalifikuje się relacja organizacja-domena, luźne dostosowanie SPF może spełnić DMARC . Przy ścisłym dostosowaniu SPF subdomena nie jest dokładnie dopasowana. To jest syntetyczny przykład decyzji, a nie twierdzenie dotyczące żadnego dostawcy.
RFC 9989 sekcje 7.4 i 8 wymagają publikowania domen p=reject nie polegać wyłącznie na SPF w przypadku przepustki DMARC i stosować ważne podpisy DKIM . Dlatego przepustka SPF z dostawą bezpośrednią nie jest kompletnym projektem wdrożenia p=reject . Rozwiąż brakującą ścieżkę DKIM, zanim potraktujesz tę usługę jako gotową do spełnienia tych zasad.
Nie opisuj SPF jako identycznego zamiennika wyrównanego DKIM . Przekazywanie może zmienić łączący się adres IP i zakłócić SPF , przy jednoczesnym nienaruszonym wyrównaniu Podpis DKIM może przetrwać. Zamiast polegać na jednym teście bezpośredniego dostarczania, oceń trasy ważne dla Twoich użytkowników.
Porównaj obsługiwane alternatywy
Praktyczne możliwości to zachowanie usługi z udokumentowaną ścieżką dostosowanego SPF, jeśli jest to zgodne z zasadami domeny i zaakceptowanymi ograniczeniami, przeniesienie wysyłania do usługi obsługującej wymaganą tożsamość DKIM lub użycie obsługiwanego autoryzowanego przekaźnika, który podpisuje końcową wiadomość. Każdy wymaga testów i właściciela. Przekaźnik musi zachować niezbędne zachowanie aplikacji i podpisać się po przetworzeniu zmieniającym treść; samo dodanie niepowiązanego podpisu nie rozwiązuje wyrównania.
Zmiana widocznej domeny From to kolejna decyzja dotycząca produktu, a nie ukryta poprawka techniczna. Ma to wpływ na rozpoznawanie i odpowiedzi, a domena zastępcza nadal wymaga prawidłowego uwierzytelnienia. Unikaj osłabiania polityki DMARC całej organizacji tylko po to, aby ukryć jedną nieudokumentowaną ścieżkę wysyłania.
Zapisz zaakceptowane ograniczenie
Zachowaj oświadczenie o możliwościach dostawcy, dowód otrzymanej wiadomości, wybraną ścieżkę dostosowania, właściciela firmy i wyzwalacz przeglądu. Testuj komunikaty transakcyjne i scenariusze przekazywania istotne dla usługi. Jeżeli ograniczenie pozostaje, należy wyraźnie określić decyzję o narażeniu i migracji. Ukończenie oznacza zweryfikowaną obsługiwaną trasę lub posiadany wyjątek, a nie zielony zrzut ekranu DNS .
Użyj wypełnionego rekordu decyzji
Rozważ tę wyraźnie fikcyjną macierz dwóch tras. Billing API A ma From= brand.example , d=vendor.example, selektor sprzedawca1, MAIL FROM= bounce.brand.example , nieprzetworzona przepustka SPF i surowa przepustka DKIM . Załóżmy, że wyrównanie SPF jest luźne i określone wspólne domena organizacyjna: jego pomyślna ścieżka jest wyrównana tylko SPF . Zamienny przekaźnik B ma From= brand.example , d=brand.example, przekaźnik selektora2 i MAIL FROM= vendor.example , przy czym obydwa surowe testy przeszły pomyślnie: jego pomyślna ścieżka jest wyrównana tylko DKIM . Każda zdolność i wynik są tutaj zakładane, a nie obserwowane przez dostawcę.
Te porównania terenowe wyjaśniają zakładane wyniki; nie wymaga się wykonania urządzenia ani weryfikacji dostawcy. Billing API A ilustruje wynik tylko SPF, a nie akceptowalną jedyną ścieżkę dla wdrożenia p=reject . Przed wdrożeniem któregokolwiek projektu uzyskaj przestarzałe instrukcje dostawcy dotyczące konkretnej trasy, wygenerowane wartości DNS , surową otrzymaną pocztę i wynik zaufanego odbiorcy. Porównaj zamierzone i zaobserwowane tożsamości, przetestuj formaty krytyczne i odpowiednie przekazywanie oraz odnotuj, że właściciel akceptuje wszelkie pozostałe ograniczenia. Te pola akceptacji w świecie rzeczywistym pozostają w toku.
Wybierz obsługiwany następny krok
- Nieznana możliwość: uzyskaj aktualne instrukcje dotyczące dokładnego poziomu konta i trasy wysyłki; nie zgaduj wartości DNS .
- Dostępne tylko dostosowane SPF : rekordowe limity dostaw bezpośrednich i aktualna polityka; nie używaj jej jako jedynej ścieżki DMARC dla p=reject.
- Dostępny obsługiwany przekaźnik podpisywania: sprawdź zachowanie aplikacji, ostateczną zawartość, wyrównane d= i opiekę nad kluczem przed migracją.
- Brak odpowiedniej ścieżki: zmień dostawcę lub podejmij wyraźną decyzję dotyczącą produktu dotyczącą tożsamości From.
- Zamknięcie: zapisz dowody otrzymanej wiadomości, pozostałe ograniczenia, odpowiedzialnego właściciela i wyzwalacz następnego przeglądu.