Użyj konfiguracji konta jako punktu wyjścia
Sendloop zapewnia przepływ pracy na koncie w celu uwierzytelnienia w domenie nadawcy, podczas gdy jego kreator uwierzytelniania publicznego wspomina również o dedykowanym DKIM I wyrównanie ustawienia. Strony te stwierdzają, że uwierzytelnianie jest dostępne, ale nie określają dokładnego zestawu rekordów, tożsamości podpisującej ani kontroli kopert dla konkretnego konta. Ten przewodnik przeprowadzi Cię przez udokumentowany przepływ pracy na koncie i plan kontrolowanej weryfikacji. Dedykowana umowa DKIM lub wymóg niestandardowej koperty pozostają przedmiotem potwierdzenia dostawcy. Kreator uwierzytelniania Sendloop, ustawienia DKIM i wyrównania domeny.
Najpierw zidentyfikuj konto, zatwierdzone z domen i kampanii lub automatyzacji, które korzystają z każdej z nich. Zapisz, czy konto ma dedykowaną usługę dostawy i kto może to potwierdzić. Nie wnioskuj o dedykowanej infrastrukturze na podstawie etykiety cenowej, starego e-maila wprowadzającego lub zewnętrznej listy wysyłających adresów IP. Przypisz administratora Sendloop, właściciela DNS i recenzenta dla organizacji DMARC polityka.
Przed wprowadzeniem zmian wyeksportuj bieżące wpisy DNS odpowiednich właścicieli. Zachowaj wiadomość otrzymaną przez jednego przedstawiciela z istniejącej zatwierdzonej trasy, jeśli jest dostępna. Spis tego, co już działa, zapobiega przypadkowemu wyłączeniu innego nadawcy przez nowy projekt uwierzytelniania. Celem jest uwierzytelniona i dostosowana trasa Sendloop, a nie hurtowa wymiana konfiguracji poczty e-mail domeny.
Otwórz panel sterowania domeny nadawcy
Przewodnik dostawcy poprowadzi Cię przez Ustawienia > Uwierzytelnianie domeny nadawcy > Uwierzytelnij domenę nadawcy, a następnie Dodaj domenę. Wynikowy Panel sterowania domeny dostarcza wartości istotne dla konta i akcję Sprawdź rekordy DNS . Przechwyć te dane wyjściowe przed edycją DNS . Jeśli bieżący interfejs jest inny, skorzystaj z instrukcji bieżącego dostawcy lub pomocy technicznej, zamiast zgadywać równoważne przyciski. Przewodnik Sendloop, Korzystanie z kreatora autoryzacji poczty e-mail i Sprawdź konfigurację uwierzytelniania.
Zapisz każdego pełnego właściciela, typ DNS , wartość i TTL wraz z jego przeznaczeniem. Zachowaj wyświetlony zestaw rekordów dołączony do biletu zmiany. Jeżeli panel wskazuje brakujący rekord, należy ustalić, czy go nie ma, czy został opublikowany u niewłaściwego właściciela, czy też występuje z inną wartością. Domena już skonfigurowana dla innego konta Sendloop może wymagać koordynacji dostawcy, a nie wymiany.
Przewodnik publiczny ma SPF przykład i poprawka do istniejącego rekordu, która nie zawiera identycznych elementów. Opisano także przygotowanie plików tekstowych. Nie zamieniaj żadnego szczegółu w automatyczną recepturę produkcyjną. DNS musi zawierać aktualną, obowiązującą politykę; plik tekstowy zapisany na stacji roboczej nie powoduje jego publikacji. Przed wdrożeniem usuń wszelkie rozbieżności pomiędzy panelem konta a stroną publiczną. Przewodnik Sendloop, Konfigurowanie rekordu SPF.
Przejrzyj SPF bez poszerzania niepowiązanych uprawnień
Określ, z której domeny koperty korzysta prawdziwa wiadomość Sendloop. To jest tożsamość, którą należy zbadać pod kątem SPF , zamiast zakładać, że widoczna domena From musi być właścicielem oceny. Jeśli istnieje autoryzowany niestandardowy układ kopert, przechwyć wydane ustawienia i zakres. Jeśli tak nie jest, zapisz obserwowaną tożsamość koperty dostawcy i oddzielnie oceń dopasowanie DKIM .
W przypadku zmiany właściciela należy zachować jedną politykę SPF i zachować autoryzacje wymagane przez innych aktywnych nadawców. Przed dodaniem nowych terminów przejrzyj zagnieżdżone wyszukiwania DNS . Limit dziesięciu terminów SPF dotyczy mechanizmów i modyfikatorów powodujących wyszukiwanie DNS podczas oceny, a nie liczby słów widocznych w rekordzie. Warto również przejrzeć istniejące mechanizmy zezwalające, ale ich usunięcie to osobna decyzja dotycząca zależności. RFC 7208 , sekcje 4.5 i 4.6.4.
Nie kopiuj szerokiej przykładowej polityki w celu zastąpienia istniejącego rekordu. Może to spowodować autoryzację niechcianych hostów, zmianę kwalifikatora niepowodzenia lub usunięcie innego dostawcy. Jeśli wymagana autoryzacja nie zmieści się bezpiecznie, zatrzymaj się i poproś właściciela poczty o wybranie obsługiwanego projektu. Nie rozwiązuj problemu, publikując inną politykę SPF lub usuwając nieznane usługi.
Publikuj wyłącznie wyemitowane publiczne materiały DKIM
Użyj wartości właściciela i publicznej podanej dla tego konta. W publicznym przewodniku przedstawiono konfigurację DKIM TXT , ale klucz demonstracyjny nie jest kluczem klienta. Jeśli panel lub wsparcie dostarczy inny obsługiwany formularz zapisu, należy zachować tę instrukcję zamiast konwertować ją bez dowodów. Przewodnik Sendloop, Konfigurowanie rekordu DKIM.
Tylko publiczny klucz weryfikacyjny należy do DNS . DKIM tworzy podpis kryptograficzny za pomocą klucza prywatnego; nie osadza klucza prywatnego w wiadomości wychodzącej. Nieformalnych wyjaśnień publicznego przewodnika nie należy czytać jako prośby o udostępnienie tajemnicy podpisania. Wiadomość jest opatrzona podpisem, a weryfikator wykorzystuje klucz publiczny identyfikowany przez domenę podpisującą selektor. RFC 6376 , sekcje 3.5 i 6.1.
Sprawdź proponowanego właściciela pod kątem aktywnego klucza należącego do innej trasy. Kolizja wymaga koordynacji; nadpisywanie działającego selektora tylko po to, aby usunąć czerwony status, nie jest bezpieczne. Po publikacji sprawdź pełną nazwę, łącznie z sufiksem domeny dodanym przez edytor DNS . Przechowuj znaczniki czasu i wyniki zapytań, aby późniejsze raporty mogły odróżnić nieaktualną pamięć podręczną od nieprawidłowego właściciela lub klucza.
Trzymaj markę linków poza wnioskiem o wyrównanie
Przewodnik dostawcy opisuje opcję opcjonalną CNAME dla aliasów łączy do wiadomości. Jego celem jest budowanie marki linków, a nie dowód zgodności SPF lub DKIM . Wdrażaj go tylko wtedy, gdy odpowiednia zmiana śledzenia zostanie zatwierdzona, a konto zapewni dokładny cel. Przewodnik Sendloop, OPCJONALNIE: skonfiguruj rekord CNAME.
Zanim zgłosisz proponowanego właściciela, sprawdź istniejącą witrynę lub sposób jej śledzenia. Nie kieruj witryny głównej ani nazwy hosta działającej aplikacji na cel śledzenia. Zachowaj nieszkodliwy link testowy w kontrolowanej kampanii, aby recenzent mógł zweryfikować zarówno miejsce docelowe, jak i wyświetlaną nazwę hosta. Uwierzytelnianie i funkcja łącza to oddzielne kontrole akceptacji; działający link markowy nie ustanawia prawidłowego podpisu.
Po publikacji wróć do sprawdzania DNS konta. Porównaj każdy wyświetlony wynik z niezależnym wyszukiwaniem publicznym. Uczciwie zapisuj stany oczekujące. Jeśli konto jest zweryfikowane, a test zewnętrzny nadal kończy się niepowodzeniem, pozostaw zmianę otwartą i skorzystaj z dowodów komunikatu, aby zlokalizować pozostałą granicę.
Zbierz rekord tożsamości otrzymanej wiadomości
Wysyłaj poprzez rzeczywisty przebieg kampanii do kontrolowanych zewnętrznych skrzynek pocztowych, nie wykorzystując danych klientów. Powtórz tę czynność dla znacząco różniących się od domen lub konfiguracji dostarczania. Zachowaj oryginalną wiadomość i wyniki zaufanego odbiorcy wraz z identyfikatorem wiadomości i znacznikiem czasu UTC. Rejestruj wszystkie podpisy DKIM , zamiast zatrzymywać się na pierwszym mijającym podpisie.
Akta dowodowe powinny zawierać widoczną domenę From, uwierzytelnioną tożsamość koperty, Return-Path, wartości DKIM d= i s=, wyniki SPF i DKIM oraz wynik DMARC odbiorcy. Ustal, który mechanizm przekazywania jest zgodny z domeną From. Swobodne i ścisłe dopasowanie narzuca różne porównania domen; zapisz używany tryb. RFC 9989 , wyjaśnienie wyrównania identyfikatorów.
Jeśli jedyny przekazujący podpis korzysta z niepowiązanej domeny dostawcy, poproś o obsługiwaną opcję podpisywania domeny klienta i warunki jej aktywacji. Publiczna notatka kontaktowa kreatora poświęcona DKIM nie udowadnia, że opcja jest włączona, bezpłatna, dostępna w każdym planie lub skonfigurowana automatycznie. Uzyskaj te odpowiedzi dla konkretnego konta. Nie przedstawiaj aliasu śledzącego jako alternatywnej domeny kopertowej.
Wykorzystaj porażkę, aby wybrać następną kontrolę
Za zaginionego Podpis DKIM, potwierdź konto, wybrane Z tożsamości i aktywacji dostawcy. W przypadku niepowodzenia podpisu porównaj zaobserwowany selektor i klucz publiczny przed zbadaniem dalszych zmian w podpisanej treści. Test z innym adresem nadawcy może zakończyć się sukcesem, ale kampania, której dotyczy problem, nadal zakończy się niepowodzeniem, dlatego podczas diagnozowania należy zachować stały przebieg pracy.
W przypadku awarii SPF zidentyfikuj ocenianą domenę i ostateczne źródło wysyłania. W przypadku przejścia SPF z niepowodzeniem DMARC sprawdź wyrównanie, zamiast dodawać więcej elementów SPF . Jeśli dostawca nie może udokumentować wymaganej opcji tożsamości, blokuj to wymaganie i oceń inną obsługiwaną ścieżkę z właścicielem firmy. Nie obniżaj polityki całej domeny tylko po to, aby test jednego dostawcy przestał zawieść.
Przygotuj pakiet wsparcia zawierający identyfikację konta, domenę, której dotyczy problem, wydane rejestry publiczne, zaobserwowane odpowiedzi DNS , identyfikator wiadomości, godzinę i odpowiednie wyniki odbiorcy. Wyklucz hasła, klucze API, listy odbiorców i niepowiązaną treść wiadomości. Zwięzły, powtarzalny błąd jest bardziej przydatny niż wiele nieskorelowanych zrzutów ekranu zmian DNS .
Odzyskiwanie i akceptacja arkusza
Użyj arkusza uwierzytelniania Sendloop (utwórz osobny rekord przeglądu z opisanymi tutaj polami), aby śledzić przegląd rozbieżności rekordów, potwierdzenie dedykowanej funkcji i ostateczne porównanie tożsamości. Odpowiedź dotycząca brakującej możliwości obwiedni może pozostać nierozwiązana, nawet jeśli działa zwykły dostosowany DKIM . Zdefiniuj akceptację w oparciu o wymagania biznesowe, zamiast wypełniać każdą lukę założeniami.
Jeśli zmiana się nie powiedzie, wstrzymaj wysyłanie, których to dotyczy, i przywróć wcześniej zatwierdzoną konfigurację za pomocą zapisanego planu zmian. Koordynuj zmiany DKIM z aktywacją dostawcy; usunięcie klucza publicznego, gdy usługa nadal się nim podpisuje, powoduje nową awarię. Wycofując Sendloop, potwierdź zatrzymanie wszystkich kampanii i automatyzacji oraz przejrzyj udostępnione zależności SPF przed usunięciem rekordów zaufania lub śledzenia.
Fikcyjny przykład rozbieżności SPF
Tylko fikcyjny przypadek pisemny: zakłada się, że SLP-01 jest zamierzony Z offers@workshop.example . Przykład publiczny zawiera dwa dołączenia dostawcy, podczas gdy instrukcja istniejącej polityki zawiera jedną; autoryzacja rachunku bieżącego, tożsamość koperty i wyniki DKIM / SPF nie są znane. Właściciel DNS wstrzymuje zmianę i prosi właściciela konta o uzyskanie potwierdzenia dotyczącego konkretnej trasy. Plik tekstowy i link markowy nie stanowią uwierzytelnienia. Po wyjaśnieniu zespół przeglądał jedną z zasad i zbierał kontrolowany przekaz kampanii. Nie wykonano żadnego konta, DNS ani testu wysyłania.
Relacja dokumentalna i pozostałe bramy
Ta wersja robocza obejmuje obieg kont publicznych i bezpieczną weryfikację. Nie ustanawia uniwersalnej dedykowanej konfiguracji DKIM ani niestandardowej konfiguracji Return-Path i nie twierdzi, że sprawdzono dostosowaną na żywo wiadomość Sendloop. Szczegóły dotyczące konta, aktualne dane DNS i nagłówki, niezależna weryfikacja, weryfikacja wizualna i zatwierdzenie przez MŚP pozostają w toku. Wstrzymaj pierwotny pełny zakres wdrożenia do czasu, aż wymagane dowody konta uzupełnią luki.
Oddziel przekazywaną wiadomość od gotowości do egzekwowania
RFC 9989 Sekcja 7.4 wymaga ważnego DKIM do publikowania w domenie p=reject i ostrzega o interoperacyjności poczty pośredniej. Pojedynczy dopasowany wynik SPF sam w sobie nie uzasadnia wdrożenia zasady odrzucania. Przejrzyj wszystkie legalne trasy i zasady własności niezależnie od konfiguracji tego dostawcy.