Mając obowiązującą politykę i przeprowadzoną ocenę, SPF I DKIM oba mogą minąć DMARC zawodzi pod RFC 9989 §5.3.5. Dzieje się tak, gdy domeny uwierzytelniane przez te mechanizmy nie są zgodne z domeną, którą ludzie widzą w adresie Od.
Każdy mechanizm odpowiada na inne pytanie. SPF sprawdza, czy źródło połączenia jest autoryzowane dla ocenianej tożsamości koperty. DKIM weryfikuje podpis powiązany z domeną podpisującą. Następnie DMARC sprawdza, czy przekazująca tożsamość ma wymaganą relację z widoczną domeną From. Sposobem zdiagnozowania tego problemu jest porównanie tych tożsamości, a nie zliczenie etykiet zielonej przepustki.
Zbierz tożsamość z otrzymanej wiadomości
Uzyskaj oryginalną wiadomość od systemu odbierającego, zawierającą wyniki zaufanego uwierzytelnienia. Dowolny nagłówek z informacją pass może zostać dostarczony przez niezaufanego nadawcę; zidentyfikować granicę odbiorczą, która wygenerowała dowód RFC 8601 §7.1.
Zapisz te pola:
- Dowód: Widoczny z domeny; Co ustanawia: Domena autora, czyli domena w widocznym adresie Od
- Dowody: wynik SPF i ocena POCZTA OD tożsamość; Co ustala: czy źródło łączące zostało autoryzowane dla tej tożsamości koperty
- Dowód: każdy wynik DKIM i jego domena d=; Co ustala: Który podpis domeny został zweryfikowany
- Dowód: Obowiązujące tryby aspf i adkim; Co ustala: czy wymagane są dokładne czy luźne relacje w domenie
- Dowody: Zaufany wynik DMARC i kontekst diagnostyczny; Co ustala: Obserwowana ocena odbiorcy
Pod RFC 5321 §4.4, w przypadku zwykłych wiadomości, wartość dostarczona Return-Path może pomóc w identyfikacji tożsamości zwrotnej koperty. Powiąż to z zaufanymi wynikami SPF i dowodami trasy, zamiast zakładać, że pole wyświetlania opowiada całą historię SMTP .
Sprawdzony przykład: dwa przebiegi, brak wyrównanej tożsamości
To jest syntetyczna ilustracja zakładająca obowiązującą, ważną politykę i zakończone kontrole, a nie przechwyconą wiadomość klienta:
- Pole: Od; Zaobserwowana wartość: accounts@example.com
- Pole: SPF ; Obserwowana wartość: pass dla bounce.example.net
- Pole: DKIM ; Obserwowana wartość: pass z d=example.org
- Pole: DMARC wyrównanie; Zaobserwowana wartość: Żadna przekazująca domena nie jest zgodna z example.com
Obydwa mechanizmy spełniły swoje zadanie. Żadne z nich nie ustanawia wymaganego związku z example.com, więc nie udostępniają ścieżki przekazywania DMARC dla widocznej domeny From.
Obsługiwana poprawka może skonfigurować domenę klienta Podpis DKIM. Inną możliwością jest obsługiwana niestandardowa domena koperty, która tworzy przechodzącą, wyrównaną ścieżkę SPF . To, która opcja jest dostępna, zależy od faktycznego produktu i trasy wysyłania.
Nie wymyślaj wartości DNS . Uzyskaj obsługiwaną konfigurację z usługi, opublikuj ją pod właściwymi nazwami właścicieli, włącz odpowiednią funkcję wysyłania i wyślij nowy test w ramach tego samego przepływu pracy aplikacji.
Prawidłowo zastosuj ścisłe i rozluźnione ustawienie
W przypadku ścisłego wyrównania odpowiednie domeny muszą dokładnie pasować do poniżej RFC 9989 §3.2.10.2dla któregokolwiek mechanizmu. Odpowiednie identyfikatory DKIM i SPF są określone w RFC 9989 §4.4.1 I RFC 9989 §4.4.2odpowiednio. Dzięki luźnemu dostosowaniu DMARC wykorzystuje obowiązujące zasady relacji organizacja-domena i odkrywania w RFC 9989 §4.10.2.
W prostym ilustracyjnym przypadku, przechodząca tożsamość koperty o godz bounce.example.com można dopasować do domeny From z example.com przy rozluźnionym ustawieniu SPF . Nie spełnia ścisłego dostosowania SPF , ponieważ te dwie nazwy są różne.
Nie uogólniaj odkrywania domeny organizacyjnej na regułę, która zawsze przyjmuje dwie ostatnie etykiety. Granice domen i aktualne zasady odkrywania DMARC mają znaczenie. Sprawdź rzeczywistą politykę i implementację w przypadku bardziej złożonych struktur domen.
Jeśli istnieje wiele podpisów DKIM , sprawdź wszystkie odpowiednie podpisy. Jeden niewyrównany przechodzący podpis nie unieważnia oddzielnego wyrównanego przechodzącego podpisu. I odwrotnie, obecność Twojej domeny w nieudanym podpisie nie tworzy ścieżki przechodzącej.
Znajdź obsługiwane ustawienia tożsamości w usłudze wysyłającej
Często pojawia się to, gdy zespół zaczyna korzystać z CRM, narzędzia rozliczeniowego lub usługi kampanii. Dostawca twierdzi, że uwierzytelnianie jest włączone, ale niektórzy odbiorcy odrzucają wiadomości. Obydwa stwierdzenia mogą być prawdziwe, jeśli platforma uwierzytelnia własną domenę, podczas gdy firma wyświetla Twoją.
Poproś operatora o pokazanie jednej wiadomości, której dotyczy problem, i wyjaśnienie widocznego nadawcy, nadawcy w kopercie i domeny podpisującej. Przydatna rozdzielczość pokazuje, że rzeczywisty przepływ pracy biznesowej przesyłany jest za pośrednictwem obsługiwanej, dopasowanej tożsamości. Zrzut ekranu przedstawiający dwa zielone znaczniki jest niewystarczający.
Zaangażuj właściciela aplikacji. Właściwą poprawką może być ustawienie lub funkcja specyficzna dla planu w tej usłudze, a nie zmiana platformy poczty elektronicznej dla pracowników.
Przetestuj korektę na oryginalnej trasie
Wyślij wiadomość o kontrolowanej wymianie za pośrednictwem usługi, której dotyczy problem. Porównaj domenę nadawcy, tożsamość koperty i każdy odpowiedni podpis DKIM z poprzednią próbką. Zachowaj wynik zaufanego odbiornika i zmianę konfiguracji razem.
Jeśli prosty test bezpośredni zakończy się pomyślnie, ale droga biznesowa nadal nie powiedzie się, sprawdź przekazywanie, bramy i modyfikacje wiadomości. Mogą zmienić, która ścieżka uwierzytelniania pozostanie. Rozróżnij także przepustkę DMARC od umieszczenia w skrzynce odbiorczej; odbiornik może zastosować dodatkowe filtrowanie RFC 9989 §5.4.
Skorzystaj z Przewodnik po platformie Microsoft 365 Lub Przewodnik Google Workspace gdzie te systemy są faktycznymi nadawcami. Jeśli wiadomość korzysta z innej aplikacji, sprawdź własną trasę tej aplikacji. Używać raporty zbiorcze szukać tego samego wzorca w obserwowanym ruchu.
Zdecyduj, co mówi Ci porażka
Nieprawidłowe ustawienie osi stanowi wynik techniczny. Samo w sobie nie ustala, czy wiadomość była zgodna z prawem, czy stanowiła nieautoryzowaną usługę, czy doszło do wypadku w przekazywaniu, czy też stanowiła próbę podszywania się.
Wymagaj właściciela i celu biznesowego nadawcy przed zatwierdzeniem nowego zaufania. Wspólna infrastruktura i rozpoznawalna nazwa dostawcy to przydatne wskazówki, ale nie dowodzą, że Twoja organizacja autoryzowała konto lub przepływ pracy.
Zapisz zaakceptowany zakres poprawki. Dopasowana tożsamość podpisu może spełnić wymagania DMARC , gdy konto zostanie później naruszone lub aplikacja wygeneruje niebezpieczną zawartość. Kontynuuj kontrolę konta, sprawdzanie poprawności aplikacji i niezależne zatwierdzanie wrażliwych transakcji.
Praktyczne dania na wynos
Zamknij problem, gdy przepływ pracy, którego to dotyczy, wygeneruje nową wiadomość z dopasowanym, zaufanym wynikiem. Zachowaj porównanie tożsamości i zmianę konfiguracji razem. To wyjaśnia zarówno, dlaczego pierwotna wiadomość nie powiodła się, jak i dlaczego poprawka działa.
Podejmij następną decyzję jasno
W przypadku urządzenia dwuprzebiegowego zapisz „brak wyrównanej ścieżki przejścia” zamiast „Zepsuty SPF ”. Wybierz tożsamość obsługiwaną przez usługę, którą chcesz naprawić, i pozostaw zmianę w oczekiwaniu na weryfikację nowego komunikatu dotyczącego tego samego przepływu pracy. Jeśli wykrywanie zasad lub przetwarzanie DNS jest niekompletne, nie narzucaj obserwacji etykiety Pass/Fail; RFC 9989 §5.3.6 oddzielnie traktuje wymagane błędy DNS . Nie przeprowadzono konfiguracji klienta ani testu dostawy.