[ Przewodniki po usługach wysyłkowych ]

Uwierzytelnij wiadomość e-mail wysłaną za pośrednictwem Campaign Monitor: konfiguracja i weryfikacja

Uwierzytelnij dokładną domenę wysyłającą Campaign Monitor, zachowaj aktualną politykę i odróżnij dopasowanie DKIM od opcjonalnej autoryzacji SPF .

Przez zespół badawczy EmailAuth · 4 minuty czytania

[Kluczowe punkty]

  • Uwierzytelnij dokładną domenę wysyłającą Campaign Monitor, zachowaj aktualną politykę i odróżnij dopasowanie DKIM od opcjonalnej autoryzacji SPF .
  • Nieskonfigurowana subdomena w produkcie nie oznacza automatycznie błędu dostosowania protokołu.
Na tej stronie

Campaign Monitor uwierzytelnia domenę wysyłającą poprzez konfigurację konta, publiczny DNS i kontrolę weryfikacyjną. Użyj dokładnie tej domeny, która pojawi się w adresie Od, łącznie z jej subdomeną. Jest to konfiguracja specyficzna dla nadawcy: uwierzytelnianie Campaign Monitor nie uwierzytelnia innej usługi, która korzysta z tej samej domeny marki.

Ustal tożsamość i zmień właściciela

Potwierdź, że organizacja kontroluje zamierzoną domenę i że operator DNS może zmienić jej strefę autorytatywną. Zapisz istniejące selektor, SPF I Rekordy DMARC. Przed zaakceptowaniem sugerowanej zmiany zasad zidentyfikuj innych legalnych nadawców. Utrzymuj, że osoba konfigurująca kampanie i osoba publikująca DNS są wyrównane w całej domenie, a nie tylko w krótkiej etykiecie, takiej jak poczta.

The przewodnik po domenie wysyłającej mówi, że uwierzytelnienie domeny drugiego poziomu nie uwierzytelnia jej subdomen na platformie. Jeśli kampanie wykorzystują news.example.com , dodaj dokładnie tę domenę, zamiast zakładać, że example.com obejmuje ustawienie konta.

Skonfiguruj domenę i wygenerowany klucz

Otwórz menu profilu, Ustawienia konta, a następnie Wysyłanie domen. Wybierz opcję Skonfiguruj domenę wysyłającą lub Dodaj domenę, wprowadź pełną domenę i kontynuuj. Opublikuj wygenerowaną nazwę i wartość TXT w autorytatywnym DNS , stosując poprawną konwencję imienia i nazwiska redaktora lub nazwy względnej. Wróć do Monitora kampanii i wybierz opcję Dodałem rekordy lub Sprawdź ponownie rekord, jeśli wrócisz później.

Do tej konfiguracji użyj nowo wygenerowanego klucza, zamiast dla wygody importować istniejący klucz prywatny. Trzymaj prywatne materiały do ​​​​podpisywania z dala od DNS , biletów i udostępnionych arkuszy. Jeśli wygenerowany selektor koliduje z innym aktywnym rekordem, rozwiąż konflikt przed jego zastąpieniem. Przykłady publiczne nie są kluczem do Twojego konta.

Zachowaj DMARC i ostrożnie godź SPF

Udokumentowany przepływ pracy akceptuje istniejący ważny DMARC konfiguracja. Zachowaj zasady egzekwowania zasad i miejsca docelowe raportowania, chyba że właściciel domeny zatwierdzi osobną zmianę. Jeżeli nie ma zastosowania żadna polisa, ustal ją u odpowiedniego właściciela. A p=none przykładem jest żądanie monitorowania, a nie egzekwowanie i nie powód do osłabienia polityki odziedziczonej od rodzica.

Campaign Monitor zaleca opcjonalną autoryzację SPF przy użyciu narzędzia include:_spf.createsend.com. Jeśli ta autoryzacja jest odpowiednia dla Twojej konfiguracji, połącz ją z jedną istniejącą polityką SPF , zamiast dodawać drugą. Zachowaj innych legalnych nadawców i sprawdź obliczoną ścieżkę zależności pod kątem limitu wyszukiwania SPF . Dostawcy przegląd uwierzytelniania poczty e-mail dostarcza kontekst, ale odebrana koperta określa, którą domenę odbiorca faktycznie sprawdza.

Karnet SPF dla koperty należącej do usługi niekoniecznie jest zgodny z widocznym adresem Od. Przejście wyrównane Podpis DKIM może spełnić DMARC nawet wtedy, gdy ścieżka SPF nie jest wyrównana. Nie obiecuj ścisłego SPF wyrównanie tylko dlatego, że do domeny From dodano dołączenie Rekord TXT.

Sprawdź zapisy przed testem kampanii

Zapytaj wygenerowany selektor na każdym autorytatywnym serwerze, a następnie sprawdź odpowiednie odpowiedzi DMARC i SPF . Zapisz pełnego właściciela, typ, wartość i sygnaturę czasową. Edytor DNS może podzielić długą wartość TXT na ciągi znaków w jednym rekordzie; różni się to od publikowania wielu plików DKIM dokumentacja. Postępuj zgodnie ze wskazówkami dostawcy DNS i porównaj zrekonstruowaną wartość.

Jeśli Campaign Monitor nie może zweryfikować, sprawdź, czy nie ma zduplikowanego sufiksu domeny, nieprawidłowego typu rekordu, pominiętych kluczowych znaków i niezgodności z serwerem autorytatywnym. TTL to kontrola buforowania, a nie gwarantowany czas aktualizacji każdego walidatora. Odpowiedź negatywna przechowywana w pamięci podręcznej może przetrwać moment utworzenia nowego rekordu.

Potwierdź, że rzeczywista kampania korzysta z zamierzonej domeny

Wyślij kontrolowaną kampanię testową z nowo uwierzytelnionym adresem Od. Zachowaj zaufanych Authentication-Results, Z, Return-Path i wszystkie pary DKIM d=/s= . Upewnij się, że przekazujący podpis jest zgodny z domeną Od w skonfigurowanym trybie. Jeśli test zakończy się pomyślnie, ale późniejsza kampania zakończy się niepowodzeniem, porównaj adresy nadawców i trasy przed zmodyfikowaniem DNS .

Przykładowy przypadek: skonfigurowana jest example.com , ale kampania wykorzystuje news.example.com , która nigdy nie została dodana do konta. Popraw konfigurację domeny pod kątem rzeczywistej tożsamości kampanii; nie zastępuj prawidłowego klucza domeny nadrzędnej, aby rozwiązać konfigurację innej tożsamości.

Jeśli to możliwe, zatrzymaj poprzedniego działającego nadawcę do czasu akceptacji. Sprawdź ponownie po zmianach konta, nowych subdomenach wysyłających, migracjach DNS lub rotacji kluczy. Przed wycofaniem zatrzymaj zaplanowane kampanie i potwierdź, że zależności nie są już używane. Ten artykuł stanowi przewodnik dokumentalny i proponowany plan weryfikacji, a nie dowód testu na żywo Campaign Monitor lub gwarantowanej dostawy.

Nie należy mylić luki w zakresie produktu ze ścisłym dostosowaniem

W przypadku pisemnym CM-01 założono, że produkt ma skonfigurowaną example.com , ale kampania From to news@news.example.com . Oddzielnie określ zaufany przekazujący podpis DKIM d=example.com, s=demo1. Przy zwykłym, swobodnym dopasowaniu organizacji do domeny podpis ten można dopasować do news.example.com ; z adkim=s nie pasuje dokładnie. SPF i inne sygnatury są nieznane, więc ogólny werdykt w trybie ścisłym jest nierozstrzygnięty, a nie stwierdzona awaria DMARC . Żadna z przesłanek nie dowodzi, że Campaign Monitor ma skonfigurowaną zamierzoną subdomenę. Właściciel kampanii powinien dokończyć dokładną konfigurację domeny i sprawdzić wynikową kontrolowaną kampanię przed jej udostępnieniem. Są to fikcyjne dane wejściowe, a nie przechwycona dostawa ani powód do rozluźnienia polityki.

Zachowaj granicę egzekwowania

RFC 9989 Sekcja 7.4 wymaga prawidłowego DKIM , a nie samego SPF , dla domen publikujących p=reject, i ostrzega o interoperacyjności poczty pośredniej i list mailingowych. Pojedynczy pomyślny test wiadomości bezpośredniej nie jest dowodem na to, że każda legalna droga jest gotowa na silniejszą politykę. Zachowaj istniejącą zatwierdzoną ochronę podczas diagnozowania rzeczywistej luki; każda zmiana polityki wymaga własnej decyzji.

[Na wynos]

Nieskonfigurowana subdomena w produkcie nie oznacza automatycznie błędu dostosowania protokołu.

[ Według roli ]

Co to oznacza dla Ciebie

Wybierz swoją rolę, aby uzyskać praktyczne dalsze kroki.

Administrator IT / poczty

Sprawdź rzeczywistą trasę

Porównaj wygenerowany TXT , status konta i prawdziwą tożsamość podpisu, a nie tylko obecność DNS .

Kolejne kroki

  1. Skonfiguruj każdą zamierzoną subdomenę osobno.
  2. Sprawdź wygenerowany TXT i prawdziwą tożsamość DKIM d=.
  3. Przetestuj ponownie po zmianie domeny wysyłającej lub dostawcy DNS.

CISO / SecOps

Kontroluj granicę autoryzacji

Unikaj niepotrzebnego importu kluczy prywatnych i zapewniaj możliwość audytu zmian autoryzacji w całej domenie.

Kolejne kroki

  1. Preferuj nowe klucze zamiast niepotrzebnego importu kluczy prywatnych.
  2. Sprawdź zmianę SPF dla innych nadawców i sprawdź zależności.
  3. Zachowaj zatwierdzone decyzje dotyczące przywrócenia działania i wycofania dostawcy.

Założyciel / Nietechniczny

Bądź właścicielem decyzji o wysłaniu

Wymagaj testu przy użyciu dokładnej kampanii z domeny przed zaplanowaniem głównej wersji.

Kolejne kroki

  1. Zatwierdź dokładną kampanię Z domeny.
  2. Zachowaj poprzedniego działającego nadawcę do czasu, aż nowa trasa przejdzie akceptację.
  3. Wymagaj zapisu akceptacji wiadomości kontrolowanej przed uruchomieniem.

[ Często zadawane pytania ]

Często zadawane pytania

Czy uwierzytelnianie example.com konfiguruje news.example.com w Monitorze kampanii?

Nie. Przewodnik po produkcie wymaga dokładnej domeny wysyłającej, łącznie z każdą zamierzoną subdomeną.

Gdzie jest ekran konfiguracji?

Otwórz menu profilu, Ustawienia konta, a następnie Wysyłanie domen.

Czy mogę ponownie wykorzystać stary klucz prywatny?

Produkt oferuje trasę według istniejących szczegółów, ale wygenerowanie nowego klucza pozwala uniknąć niepotrzebnej obsługi klucza prywatnego i zależności klucza współdzielonego.

Czy powinienem zastąpić ważną polisę DMARC ?

Nie. Zachowaj go, chyba że właściciel domeny zatwierdzi osobną zmianę zasad.

Jaką autoryzację SPF dokumentuje Campaign Monitor?

Zaleca include:_spf.createsend.com. Dodaj go tylko w ramach odpowiednich pojedynczych zasad po sprawdzeniu innych nadawców i wyszukaniu zależności.

Czy obejmuje to gwarancję wyrównania SPF ?

Nie. Oceniana domena koperty musi być wyrównana z widocznym polem From; Sama autoryzacja DNS nie wybiera tej tożsamości.

Czego dowodzi zapis ponownego sprawdzenia?

Jest to sprawdzenie konfiguracji. Aby zweryfikować rzeczywistą trasę kampanii, nadal potrzebny jest kontrolowany otrzymany komunikat.

Po co utrzymywać dostępność poprzedniego nadawcy?

Zapewnia opcję kontrolowanego odzyskiwania w przypadku niepowodzenia nowej konfiguracji, bez zmiany niepowiązanych zasad domeny.

[ Źródła ]

Źródła

  1. Uwierzytelnianie domeny wysyłającej Campaign Monitor

    Sekcje Wymagane: skonfiguruj domenę wysyłającą · Wymagane: dodaj rekord DMARC · Zalecane: dodaj rekord SPF

  2. Uwierzytelnianie poczty e-mail Campaign Monitor

    Sekcje SPF · DKIM · DMARC

  3. RFC 7208 SPF

    Sekcje §2.4 · §2.6.5 · §3.2 · §3.3 · §4.6.4

  4. RFC 6376 DKIM

    Sekcje §3.4 · §3.5 · §3.6 · §3.7 · §6.1 · §6.3

  5. RFC 9989 DMARC

    Sekcje §4.4 · §5.3.5 · §5.4 · §7.4 · §8

  6. RFC 2308 Negatywne buforowanie DNS

    Sekcje §5 Buforowanie odpowiedzi negatywnych

[ Słowniczek ]

Słowniczek

Wyrównanie
Wymagana relacja między przechodzącą domeną uwierzytelniającą a widoczną domeną From dla DMARC .
Selektor
Etykieta DKIM używana z domeną podpisującą do lokalizowania jej klucza publicznego w DNS .
Autorytatywny DNS
Usługa serwera nazw odpowiedzialna za publikowanie odpowiednich rekordów stref.
Return-Path
Ślad odebranej wiadomości w ścieżce zwrotnej SMTP , przydatny przy badaniu tożsamości koperty.

Pochodzenie przedsiębiorstwa

Dlaczego najlepsze instytucje finansowe i rządy wycofali swoje panele bezpieczeństwa poczty e-mail.

Tradycyjne platformy uwierzytelniania poczty e-mail oferują pulpit nawigacyjny i proszą inżynierów o wykonanie pracy. W środowiskach o dużej stawce ręczny nadzór oznacza opóźnione egzekwowanie, zmianę konfiguracji i niemonitorowane domeny-cienie.

EmailAuth to platforma agentowego pochodzenia wiadomości e-mail. Nasi agenci egzekwują p=reject, dostosuj zewnętrznych nadawców i przenieś swoje domeny do pełnych adresów RFC 9989 zgodność, nowy standard DMARC , z możliwością kontroli przez człowieka.

Rządy Duże przedsiębiorstwa Instytucje finansowe poziomu 1

SaaS · Dedykowany najem · Lokalne rozwiązanie typu air-gapped · Szyfrowanie BYOK

Baza wiedzy