Trzymaj Account Engagement oddzielnie od innych produktów e-mail Salesforce
Rozwiązanie Salesforce Account Engagement ma własny przepływ pracy związany z zarządzaniem domeną. Rozpocznij od potwierdzenia, że wiadomość została wysłana poprzez usługę Account Engagement, wcześniej nazywaną Pardot, a nie podstawową pocztę Salesforce lub Marketing Cloud Engagement. Receptura DNS dla innego produktu Salesforce może wykorzystywać różne elementy sterujące i nie powinna być importowana tylko dlatego, że organizacja korzysta z usług tego samego dostawcy. W tym przewodniku omówiono weryfikację domeny wysyłającej w ramach zaangażowania konta, DKIM oraz opcjonalna niestandardowa ścieżka zwrotna ze wsparciem technicznym.
Wymień każdą jednostkę biznesową, markę i zamierzoną domenę From używaną przez konto. Uwzględnij rzeczywistego nadawcę wybranego w ustawieniach kampanii i automatyzacji. Domena pojawiająca się w adresie skrzynki pocztowej użytkownika nie jest automatycznie konfigurowana dla każdej trasy Account Engagement. Przypisz właściciela marketingu i administratora DNS do wspólnego przeglądu zasobów przed zmianą rekordów domeny współdzielonej.
Celem akceptacji jest kontrolowana odebrana wiadomość z dostosowanym mechanizmem uwierzytelniania przechodzącego. Weryfikacja własności domeny, publikacja DNS i status ekologicznego zarządzania to przydatne dowody pośrednie. Żadne samo w sobie nie udowadnia, że dana kampania korzystała z zamierzonej tożsamości lub że serwer odbierający zaakceptował jej uwierzytelnienie.
Zapoznaj się z domyślną ścieżką SPF przed edycją głównego DNS
Salesforce's Wskazówki dotyczące DNS dotyczące zaangażowania konta stwierdza, że poczta dotycząca zaangażowania konta jest przekazywana SPF poprzez infrastrukturę kontrolowanego wysyłania i nie wymaga zmiany SPF klienta dla tej domyślnej konfiguracji. Nie dodawaj ogólnego kodu SPF Salesforce do domeny głównej organizacji tylko dlatego, że nazwa produktu pojawia się w pliku DMARC raport. Najpierw potwierdź rzeczywistą trasę i ocenioną tożsamość.
SPF uwierzytelnia SMTP POCZTA OD tożsamość, z oddzielną obsługą HELO, pod RFC 7208. Jego wynik różni się od wyrównanie z widocznym Od. Pomyślne sprawdzenie SPF domeny dostawcy może współistnieć z niewyrównanym SPF . Zmiana zasad innej domeny nie powoduje zmiany domeny koperty używanej przez wiadomość.
Zachowaj politykę SPF wymaganą przez inne usługi organizacji. Jeśli oddzielnie autoryzowana konfiguracja niestandardowa wymaga zmiany zasad, przejrzyj jedną kompletną politykę tego właściciela, w tym zagnieżdżone warunki zapytań DNS i limit wyszukiwania protokołu. Nie twórz drugiego Rekord SPF lub usuń niepowiązanych nadawców, aby zrobić miejsce na niezweryfikowane wymagania.
Zweryfikuj własność i DKIM jako osobne rekordy
Użyj Zarządzania domeną, aby zidentyfikować zamierzoną domenę wysyłającą e-mail i jej oczekiwane wpisy DNS . The Wskazówki dotyczące DNS odróżnia klucz weryfikacyjny domeny od jej DomainKey. Wartość walidacyjna ustanawia własność wysyłania; wartość DKIM obsługuje podpisywanie wiadomości. Zachowaj oba cele w arkuszu, zamiast zajmować się którymkolwiek Rekord TXT zawierające wartość Salesforce jako wymienny dowód.
Skopiuj wartości z rzeczywistego konta. Przed dokonaniem zmiany DNS zapisz pełnego właściciela rekordu, typ, wartość i datę instrukcji. Sprawdź, czy inne konto Account Engagement lub inna usługa nie jest już zależna od tego samego właściciela. Nie nadpisuj sprzecznego rekordu, nie wykorzystuj ponownie wartości innego klienta ani nie zmieniaj selektor na wymyślone imię. Poproś o wsparcie w celu uzyskania obsługiwanego rozwiązania, gdy kolidują ustalenia dotyczące kont.
Trzymaj domenę wysyłającą e-mail odrębną od domeny modułu śledzącego. Salesforce wyraźnie ostrzega przed używaniem tej samej domeny do tych dwóch funkcji. Markowa nazwa hosta śledzącego to nie to samo, co domena Od, nawet jeśli obie mają tę samą nazwę nadrzędną. Zależności śledzenia zapasów oddzielnie, aby uwierzytelnianie nie spowodowało przypadkowej zmiany adresów URL zasobów lub linków do kampanii.
Opublikuj klucz domeny za pomocą udokumentowanego przepływu pracy
Salesforce's Instrukcja wdrożenia DKIM wymagają roli Administratora zaangażowania konta. W aplikacji Lightning otwórz Ustawienia zaangażowania konta, a następnie Zarządzanie domeną. W alternatywnym interfejsie Account Engagement udokumentowanym punktem wyjścia jest Administrator. W obszarze Domeny wysyłania wiadomości e-mail otwórz Oczekiwane wpisy DNS dla wybranej domeny i skopiuj wartość DomainKey do publikacji w formacie TXT .
Użyj właściciela i wartości wyświetlanej dla tego konta i domeny. Obecny artykuł mówi, że od dodania rekordu należy poczekać do 24 godzin na wejście w życie podpisu. Traktuj to jako wskazówki dotyczące czasu dostawcy, a nie gwarancję, że każda pamięć podręczna DNS lub każdy odbiornik zostaną zaktualizowane w tym samym momencie. Zapisz czas publikacji i poczekaj na oczekiwany stan, zanim ocenisz nowy test.
Potwierdź publiczną odpowiedź DNS , podając dokładnego, w pełni wykwalifikowanego właściciela. Redaktorzy DNS czasami dołączają nazwę strefy do pola hosta, tworząc zduplikowany sufiks po wprowadzeniu pełnej nazwy. Zamiast ufać formularzowi wejściowemu, przejrzyj otrzymaną odpowiedź. Zapisz wszelkie błędy zarządzania domeną i ich szczegóły, aby obsługa mogła zbadać rzeczywistą awarię, a nie sparafrazowany status.
Zdecyduj, czy wymagana jest niestandardowa ścieżka zwrotna
Salesforce's Artykuł wsparcia DMARC opisuje wyrównany DKIM jako normalną ścieżkę DMARC i wyjaśnia, że jest to wartość domyślna ścieżka powrotna domena nie jest zgodna z widocznym polem From. Dokumentuje również żądanie niestandardowej ścieżki zwrotnej wspomaganej przez obsługę. Podane ograniczenie dotyczy jednej stałej, niestandardowej domeny ścieżki zwrotnej na jednostkę biznesową, a nie domeny zmiennej wybieranej dla każdej wiadomości.
Zanim zażądasz tej opcji, określ wymagania biznesowe. Organizacja, która potrzebuje dostosowanego SPF i DKIM powinna wraz ze wsparciem ocenić rzeczywistą aranżację domeny i tryb wyrównania. Jednostka biznesowa wysyłająca dla niepowiązanych marek nie powinna zakładać, że jedna stała ścieżka zwrotna może być zgodna z każdą domeną Od. Pozostaw to pytanie projektowe otwarte, dopóki zaobserwowane tożsamości i obsługiwana konfiguracja go nie rozwiążą.
Uzyskaj dokładne rekordy DNS ze zgłoszenia do pomocy technicznej i poproś właściciela DNS o sprawdzenie konfliktów i zależności. W tym artykule nie podano uniwersalnego przełącznika docelowego ani aktywacyjnego o niestandardowej ścieżce zwrotnej. Publikowanie odgadniętych rekordów lub kopiowanie konfiguracji domeny zwrotnej innego produktu może przerwać roboczą trasę bez spełnienia wymagań.
Przetestuj wybranego nadawcę w rzeczywistym przepływie wiadomości
Wysyłaj nieszkodliwe, kontrolowane wiadomości za pośrednictwem każdej zasadniczo innej domeny wysyłającej i trasy jednostki biznesowej. Użyj tego samego wyboru nadawcy, co w planowanej kampanii lub automatyzacji. Zapisz numer referencyjny kampanii, identyfikator wiadomości, czas UTC i zewnętrznego odbiorcę testu. Jeśli funkcja podglądu lub testowania korzysta z innej ścieżki niż wersja produkcyjna, rozwiąż tę różnicę, zanim potraktujesz ją jako reprezentatywny dowód.
W zaufanym systemie odbierającym przechwyć domeny i selektory podpisywania typu From, Return-Path oraz wszystkie domeny i selektory DKIM . RFC 6376 definiuje wartości d= i s= używane do lokalizacji publicznego klucza weryfikacyjnego. Porównaj obserwowaną domenę podpisującą ze skonfigurowaną domeną wysyłającą. Rekord DNS może być poprawny, gdy wiadomość nadal korzysta z nieoczekiwanego nadawcy lub innej trasy.
Stosować RFC 9989 do rzeczywistych wyników. DMARC może przejść przez przejście wyrównane Podpis DKIM lub przechodząc wyrównany SPF . Zapisz, który mechanizm dostarczył wynik i jaki zastosowano tryb wyrównywania. Zachowaj uwierzytelnianie SPF , wyrównanie SPF , uwierzytelnienie DKIM i wyrównanie DKIM w oddzielnych polach. Zapobiega to ukrywaniu nieprzetestowanego wymagania pod pojedynczym zielonym statusem.
Zamiast zmieniać każdą kontrolkę, rozwiąż problemy z nieprawidłową granicą
Jeśli domena wysyłająca nie jest zweryfikowana, porównaj jej klucz weryfikacyjny i dokładnego właściciela DNS z Oczekiwanymi wpisami DNS . Jeśli po oczekiwanym okresie aktywacji brakuje DKIM , potwierdź wybraną opcję Z domeny i konta, a następnie sprawdź Błędy zarządzania domeną. Jeśli podpis się nie powiedzie, sprawdź selektor i wartość publiczną oraz sprawdź każdy system końcowy, który zmienia komunikat po podpisaniu.
Jeśli DMARC zakończy się niepowodzeniem po pomyślnym zakończeniu SPF , sprawdź wyrównanie i to, czy dla tego nadawcy skonfigurowano wyrównany DKIM . Nie traktuj domyślnego sukcesu SPF jako obietnicy sukcesu DMARC . Jeśli w grę wchodzi niestandardowa ścieżka zwrotna, porównaj zaobserwowaną tożsamość koperty z ustawieniem stałej jednostki biznesowej i instrukcjami dostarczonymi przez pomoc techniczną. Zachowaj reprezentatywny komunikat o niepowodzeniu do celów diagnostycznych.
Zachowaj zasady DMARC organizacji i miejsca docelowe raportowania w ramach istniejącej własności. Artykuł Salesforce opisuje potrzebę zewnętrznego monitorowania DMARC , a nie gromadzenia ich przez Account Engagement raporty o awariach. Uwierzytelnianie DNS nie powinno po cichu zastępować miejsc docelowych raportowania ani ograniczać egzekwowania przepisów w przypadku niepowiązanych nadawców. Przejrzyj każdą proponowaną zmianę zasad osobno z właścicielami poczty i zabezpieczeń.
Arkusz domeny zaangażowania konta
- Konto, jednostka biznesowa, marka i przepływ pracy: ____.
- Wybrano opcję Z adresu i skonfigurowano domenę wysyłania wiadomości e-mail: ____.
- Oddzielna domena modułu śledzącego i jej istniejące zależności: ____.
- Klucz weryfikacyjny i odniesienia do rekordów DKIM z oczekiwanych wpisów DNS : ____.
- Publiczne odpowiedzi DNS , czas publikacji i status zarządzania: ____.
- Domyślny lub niestandardowy projekt ścieżki powrotu ze wsparciem: ____.
- Niestandardowe ograniczenie ścieżki zwrotu i potwierdzenie wsparcia, jeśli ma to zastosowanie: ____.
- Przetestuj identyfikator wiadomości, czas UTC, tożsamość nadawcy, Return-Path i DKIM : ____.
- Zaufane wyniki uwierzytelniania i dostosowany mechanizm DMARC : ____.
- Wyjątki, właściciel monitorowania i zatwierdzone odzyskiwanie: ____.
Fikcyjny przykład sukcesu SPF bez wyrównania
Tylko fikcyjny przypadek pisemny: AE-01 zakłada, że jednostka biznesowa North wysyła jako news@example.org , a jednostka biznesowa South wysyła jako news@example.net . Proponowana stała niestandardowa ścieżka powrotu na stronie bounce.example.org może być zgodna z pierwszą w ramach luźnego dostosowania SPF , ale nie można zakładać, że będzie zgodna z niepowiązaną drugą. Sygnatury DKIM i wyniki SPF pozostają nieznane, więc żadna z tras nie ma potwierdzonego werdyktu DMARC . Właściciele marketingu i poczty powinni oddzielić ustawienia jednostki biznesowej i zweryfikować dostosowany DKIM dla każdej wybranej domeny nadawcy przed zażądaniem jakiejkolwiek edycji głównego SPF . Wszystkie tożsamości i układy są wymyślone; brak zgłoszenia do pomocy technicznej, wykonano zapytanie lub wiadomość DNS .
Powiąż ukończenie z żywymi dowodami
Udokumentowany przepływ pracy nie weryfikuje uprawnień prawdziwego dzierżawcy, wygenerowanych wartości ani możliwości niestandardowej ścieżki powrotu. Weryfikacja kont, weryfikacja DNS i nagłówków na żywo, weryfikacja wizualna i zatwierdzenie przez MŚP pozostają w toku. Ten przewodnik nie jest publikowany i nie można go przedstawiać jako dowodu na to, że kampanie organizacji są uwierzytelniane w środowisku produkcyjnym.
Oddziel przekazywaną wiadomość od gotowości do egzekwowania
RFC 9989 sekcja 7.4 wymaga prawidłowego DKIM dla domeny publikującej 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.