Zacznij od konta Delivra i spisu domen
Linki do strony pomocy dotyczącej publicznego uwierzytelniania Delivry prowadzą do szczegółowych informacji Instrukcje uwierzytelniania poczty e-mail. Instrukcje te opisują administratora witryny współpracującego z operatorem DNS domeny, unikalnym Selektor DKIM i klucz dla każdej domeny wysyłającej oraz oddzielny krok Włącz podpisywanie. W tym przewodniku opisano ten udokumentowany przepływ pracy. Nie określa dostępu do funkcji konkretnego konta, wygenerowanych wartości ani zakończonej konfiguracji.
Zidentyfikuj każdą domenę przeznaczoną dla adresów nadawców kampanii i zmapuj ją na odpowiednie konto i witrynę. Wiele skrzynek pocztowych w tej samej domenie nie wymaga automatycznie oddzielnych kluczy domeny, natomiast inna domena nie może z założenia dziedziczyć klucza innej domeny. Przed zmianą jakichkolwiek rekordów należy wyraźnie określić zakres administracyjny, zwłaszcza jeśli jedna lokalizacja obsługuje wiele marek lub niezależnie zarządzane jednostki biznesowe.
Szczegółowe instrukcje publiczne nie ujawniają wiarygodnej daty publikacji w przechwyconym tekście artykułu. Możliwość stosowania rachunku bieżącego i wszelkie zmiany w interfejsie pozostają otwarte. Podczas wdrażania planu korzystaj z faktycznie wyświetlonych zapisów i aktualnego potwierdzenia administratora. Selektor próbek ze zrzutu ekranu nie jest wartością wygenerowaną przez konto, a rękopis nie wygenerował klucza ani nie uzyskał dostępu do żadnej dzierżawy.
Połącz udokumentowaną autoryzację SPF
Instrukcje include:ne16.com dla istniejącego SPF policy i oferują kompletny przykład dla domen bez niej. Przejrzyj ten mechanizm w ramach pełnego spisu legalnych nadawców domeny, zamiast zastępować istniejące autoryzacje pracowników lub aplikacji. Termin mx, kwalifikator miękkiego błędu i TTL w przykładzie nie są ustawieniami uniwersalnymi dla każdej domeny. Zachowaj dokładną zatwierdzoną różnicę widoczną w żądaniu zmiany. Instrukcje uwierzytelniania Delivra
RFC 7208 , sekcja 3.2 zabrania wielu wybranych zasad SPF u jednego właściciela. Zachowaj jedną spójną politykę TXT i przejrzyj ocenione terminy zależne od DNS w sekcji 4.6.4, łącznie z pracą zagnieżdżoną. Zliczanie tylko widocznych pakietów DNS lub obserwowanych jest niewystarczające. Polityka może być obecna i ważna pod względem składniowym, bez autoryzacji rzeczywistego nadawcy na określonej ścieżce oceny.
Nie traktuj 255 znaków jako maksymalnej całkowitej długości polityki SPF . Sekcja 3.3 opisuje wiele ciągów znaków w jednym Rekord TXT i ich łączenie bez dodanych spacji. Różni się to od rywalizacji wielu konkurentów Rekordy SPF. Kiedy redaktor dzieli długą wartość, zweryfikuj wynikowy rekord logiczny, zamiast usuwać autoryzacje jedynie po to, aby zmieścić się w limicie prezentacji. Jest to rozróżnienie protokołu, a nie twierdzenie, że każdy edytor DNS obsługuje ten sam format wejściowy.
Utwórz klucz domeny i opublikuj jego dokładną wartość
Udokumentowana ścieżka administratora to Ustawienia, Konto, Klucze domeny, a następnie Utwórz klucz domeny. Administrator wchodzi do domeny, wybiera rozmiar klucza i zapisuje, aby uzyskać instrukcje DNS . Przekazanie obejmuje nazwę domeny, DKIM Adres rekordu TXT i wartość rekordu DNS TXT . Należą one do siebie: poprawny klucz u niewłaściwego właściciela nie może obsługiwać zamierzonego wyszukiwania selektora. Instrukcje uwierzytelniania Delivra
Operator DNS publikuje rekord TXT wykorzystując wydany adres i wartość. W przewodniku zauważono, że wielu dostawców oczekuje wyłącznie selektora. _domainkey w polu hosta, ale jest to zależne od edytora. Potwierdź pełnego właściciela wynikowego, zamiast uniwersalnie usuwać lub dołączać domenę. Nie używaj ponownie długiego selektora zrzutu ekranu: źródło wyraźnie identyfikuje te wartości jako przykłady unikalne dla konta i domeny wysyłającej.
W przypadku niezgodności porównaj cały wygenerowany klucz publiczny z opublikowaną wartością logiczną, łącznie z przypadkowymi spacjami, obcięciem i podziałem wiersza. Instrukcje sugerują wygenerowanie mniejszego klucza w przypadku niektórych starszych ograniczeń DNS , ale ten przewodnik nie zaleca automatycznego usunięcia lub obniżenia wersji w pierwszej kolejności. Przed autoryzowaniem wymiany ustal aktualne wsparcie dostawcy DNS, kluczowe wymagania organizacyjne i wpływ na aktywne podpisywanie. Problem reprezentacji i decyzja dotycząca polityki kryptograficznej to odrębne kwestie.
Włącz podpisywanie po publikacji
Udokumentowanym następnym krokiem jest powrót do Ustawień, Konta, Kluczy domeny i użycie opcji Włącz podpisywanie, gdy klucz jest obecny i ważny w DNS . Zachowaj ten etap aktywacji w planie akceptacji. Wypełniony bilet DNS nie jest dowodem na podpisanie konta, a obecność przycisku nie jest dowodem na jego użycie. Rejestruj faktyczne potwierdzenie administratora, gdy nastąpi autoryzowana implementacja. Instrukcje uwierzytelniania Delivra
Te same instrukcje opisują wskaźniki uwierzytelniania obok nazwy nadawcy i adresu w przepływie pracy kampanii. Traktuj je jako kontrole dostawcy, niezależne od wyników odbiorcy wiadomości. Zielone wskaźniki są użytecznym dowodem opinii konta, ale nie potwierdzają każdej trasy kampanii, decyzji odbiorcy czy przyszłego podpisu. Źródło twierdzi również, że niepełne uwierzytelnienie samo w sobie nie uniemożliwia wysyłania; brak bloku peronu nie jest zatem kryterium akceptacji.
Przejrzyj niestandardową ścieżkę powrotu w zakresie witryny
Delivry niestandardowy przewodnik po ścieżce powrotnej opisuje konfigurację obejmującą całą witrynę, a nie opcję dotyczącą poszczególnych kont. Mówi, że wszystkie konta powinny wysyłać z tej samej domeny głównej dla tej wspólnej aranżacji. Udokumentowany krok DNS wykorzystuje subdomenę zwrotną CNAME do lists.n-email1.net ; Następnie dział wsparcia weryfikuje i konfiguruje witrynę oraz wysyła test potwierdzający. Są to wymagania wstępne i kroki dostawcy, a nie wykonywane tutaj działania.
Przed zatwierdzeniem udostępnionej zmiany zapisz każdego właściciela firmy, którego to dotyczy, i nierozwiązany wyjątek. Jeżeli inwentarz jest niekompletny, decyzję należy pozostawić w oczekiwaniu.
Polityka kwarantanny lub odrzucenia to nie to samo, co rygorystyczna dopasowanie identyfikatora. RFC 9989 , sekcja 4.4 definiuje relację wyrównania niezależnie od żądanej dyspozycji. Subdomena zwrotna może obsługiwać luźne dopasowanie do powiązanej domeny autora bez ustalania dokładnej równości w przypadku ścisłego dopasowania. Nie obiecuj ścisłej zgodności lub usunięcia wyświetlacza „w imieniu” każdego odbiornika w oparciu wyłącznie o udokumentowaną CNAME .
Oceń komunikat, a nie sam ekran konfiguracji
Proponowane ćwiczenie autoryzacji powinno wykorzystywać nieszkodliwą treść i rejestrować rzeczywistą domenę autora, tożsamość koperty, domenę podpisu i selektor. RFC 6376 , sekcja 3.5 definiuje pola podpisu używane do łączenia odebranej wiadomości z jej kluczem DNS . Porównaj wyniki zaufanego odbiorcy z zatwierdzonymi tożsamościami i zamierzoną trasą. Nie przesyłaj prawdziwych informacji o subskrybencie ani poufnych treści kampanii do zewnętrznego narzędzia sprawdzającego bez autoryzacji.
DMARC może przejść przez wyrównany przechodzący wynik SPF lub wyrównany przechodzący wynik DKIM . Nie zaświadcza, że wiadomość jest nieszkodliwa, a uwierzytelnioną pocztę nadal można filtrować. Przykładem polityki publicznej nie jest pozwolenie na zastąpienie polityki egzekwowania organizacji ani dodanie odbiorcy raportu. Trzymaj decyzje polityczne dotyczące całej domeny i zatwierdzanie udostępniania danych oddzielnie od kopiowania wydanych publicznych rekordów DNS .
Fikcyjna diagnoza i pusty arkusz akceptacji
Fikcyjny wydawca edukacyjny, Maple Folio, publikuje wygenerowany klucz, ale nigdy nie wraca do opcji Włącz podpisywanie. Jego rekord zmian DNS wygląda na kompletny, natomiast gotowość wiadomości pozostaje niesprawdzona. Z przeglądu wynika również, że proponowana ścieżka powrotu obejmowałaby wspólną witrynę z drugą marką. Zespół oddziela oczekującą aktywację od decyzji projektowej obejmującej całą witrynę i prosi autoryzowanych właścicieli o rozwiązanie obu kwestii przed wydaniem. Ten fikcyjny scenariusz nie zawiera żadnych faktycznych działań na koncie ani wyników wiadomości.
- Witryna, konta, domeny wysyłające i aktualne zastosowanie przepływu pracy: ______
- Istniejące i zatwierdzone zasady SPF obejmują zmiany: ______
- Unikalny właściciel DKIM , klucz publiczny i dowód publikacji: ______
- Włącz potwierdzenie podpisania i obserwacje wskaźników kampanii: ______
- W całej witrynie ścieżka powrotna zgodność i kompletność dostawcy, jeśli jest używany: ______
- Rzeczywiste tożsamości wiadomości, zaufane wyniki i tryb wyrównania: ______
- Właściciel polityki, nierozwiązane wyjątki i decyzja o zwolnieniu: ______
Oryginalne dowody wdrożenia, przegląd ręczny, aktualne zastosowanie, trasy produkcji, dostępność wizualna i zezwolenie właściciela pozostają otwarte. Nie utworzono żadnego klucza, wpisu DNS , prośby o pomoc, wiadomości testowej ani publikacji.