Zakres i przesłanki
Ta procedura dotyczy trasy domeny niestandardowej Recenzje i lojalność opisanej w Yotpo CNAME przewodnik uwierzytelniania. Nie jest twierdzeniem, że każdy produkt Yotpo, w tym SMS i e-mail, korzysta z tej samej konfiguracji. Udokumentowana trasa wykorzystuje SendGrid za Yotpo i wymaga dostarczonych przez wsparcie rekordów specyficznych dla domeny. Przed zażądaniem rekordów poproś właściciela recenzji lub programu lojalnościowego o potwierdzenie dokładnej domeny wskazanej w ustawieniach poczty e-mail produktu.
Skonfiguruj udokumentowaną trasę
- Krok 1. Zapisz produkt, konto, które ma być widoczne z domeny i istniejącego właściciela DNS . Zidentyfikuj dowolną inną aplikację, która już korzysta SendGrid dla tej domeny.
- Krok 2. Poproś o zestaw CNAME domeny od wsparcia Yotpo Reviews lub Yotpo Loyalty Support. Podaj dokładną domenę ustawień poczty e-mail i ujawnij istniejącą integrację SendGrid , aby obsługa mogła zapewnić strukturę rekordów pozbawioną konfliktów.
- Krok 3. Skopiuj każdy dostarczony host i cel do autorytatywnej strefy DNS . Ilustracja Yotpo zawiera CNAME związany z kopertą i dwa DKIM CNAME, ale ich ciągi hosta i wartości są unikalne w każdej domenie. Ilustracja nie przedstawia konfiguracji Twojego konta.
- Krok 4. Zachowaj typy rekordów. Nie zastępuj żądanego CNAME przez a Rekord TXT lub nadpisz a selektor przekazane innemu nadawcy. U właściciela rekordu CNAME przed opublikowaniem nowego delegowania należy rozwiązać konflikty zwykłych rekordów.
- Krok 5. Poproś obsługę Yotpo o sprawdzenie opublikowanych rekordów i dokończenie aktywacji. Sama publikacja DNS nie jest ostatnim udokumentowanym krokiem.
- Krok 6. Wywołaj reprezentatywną wiadomość Recenzje lub Lojalność po potwierdzeniu przez dział pomocy technicznej zakończenia. Przechwyć powstałe tożsamości przed wdrożeniem konfiguracji w innym produkcie lub witrynie sklepowej.
Ryzyko specyficzne dla produktu
Jeśli domena w dalszym ciągu nie przejdzie weryfikacji, porównaj właściciela DNS i obiekt docelowy CNAME z najnowszym zestawem wydanym przez pomoc techniczną, a nie starym zrzutem ekranu. Jeśli istniejący selektor SendGrid jest zajęty, wróć do obsługi prawidłowej alternatywnej struktury zamiast usuwać działającą integrację. Działający link śledzący lub wyświetlana nazwa marki nie mogą ustanowić DKIM wyrównanie. Zachowaj identyfikator zgłoszenia do pomocy technicznej wraz z rekordem zmiany, aby później można było powiązać kluczowe pytania lub pytania dotyczące domeny z pierwotnym delegowaniem.
Udowodnij trasę u odbiorcy
Użyj zatwierdzonej zewnętrznej skrzynki pocztowej i zapisz całą nieprzetworzoną wiadomość ze znacznikiem czasu i identyfikatorem wiadomości. W tym przewodniku nie opisano żadnego testu najemcy na żywo. Poniżej znajduje się arkusz akceptacji, który należy wypełnić podczas wdrażania, a nie rekord zaobserwowanych wyników.
- Pole dowodu: Widoczne od; Co rejestrować: Rzeczywisty adres i domena; Pytanie dotyczące akceptacji: czy jest to zamierzona tożsamość nadawcy?
- Pole dowodowe: Koperta; Co nagrywać: Return-Path i zgłoszone przez odbiorcę SPF domena; Pytanie o akceptację: która domena została faktycznie uwierzytelniona SPF ?
- Pole dowodowe: SPF ; Co rejestrować: Wynik zaufanego odbiorcy i oceniona tożsamość; Pytanie akceptacji: czy przeszło i czy ta tożsamość się zgadza?
- Pole dowodowe: DKIM ; Co rejestrować: Każda d= domena, s= wynik selektora i odbiorcy; Pytanie dotyczące akceptacji: czy co najmniej jeden przechodzący podpis jest zgodny?
- Pole dowodowe: DMARC; Co należy rejestrować: Wynik odbiorcy i obowiązujące zasady; Pytanie dotyczące akceptacji: czy istnieje wyrównana ścieżka mijania?
- Pole dowodowe: Trasa; Co rejestrować: typ produktu, konta i wiadomości; Pytanie akceptacyjne: Czy w teście wykorzystano ścieżkę produkcyjną?
DMARC potrzebuje co najmniej jednej wyrównanej, przechodzącej ścieżki SPF lub DKIM . Przechodzący podpis z niepowiązanej domeny usługowej nie wystarczy. Ścisłe wyrównanie wymaga dokładnej równości domeny; zrelaksowane dopasowanie wykorzystuje odpowiednią relację organizacja-domena. Zanim ogłosisz sukces, sprawdź aktualne ustawienia wyrównania domeny. Subdomena nie jest automatycznym ścisłym dopasowaniem. SPF używa tożsamości SMTP , a nie nazwy wyświetlanej lub funkcji Reply-To. Skonsultuj się z słownik wyrównania podczas zapisywania decyzji.
Używać Authentication-Results z zaufanego systemu odbiorczego, a nie nagłówka dostarczonego przez dowolnego nadawcę. Przechwytuj wszystkie podpisy, zamiast zatrzymywać się przy pierwszym niepowodzeniu. W przypadku poczty przekazywanej porównaj test bezpośredni z przesłaną kopią: przekazywanie może zmienić ocenę SPF lub podpisaną treść. Nie diagnozuj tych skutków dodając adres spedytora do autoryzacji swojego dostawcy.
Diagnozuj awarie bez poszerzania dostępu
Najpierw porównaj autorytatywny DNS z dokładnie skonfigurowanymi nazwami rekordów, a następnie sprawdź widoczność rekurencyjną i weryfikację usługi. Niewłaściwa nazwa, skrócony klucz lub konflikt CNAME nie są naprawiane przez oczekiwanie na pamięci podręczne. Zachowaj tylko jedną zasadę SPF dla właściciela i sprawdź limit dziesięciu terminów wyszukiwania DNS dla ocenianych dołączeń i przekierowań przed połączeniem innego nadawcy. Selektory DKIM należą do indywidualnych konfiguracji podpisywania; nie nadpisuj rekordu innej aplikacji, aby wymusić wynik walidacji.
Jeśli uwierzytelnienie przebiegło pomyślnie, ale dostawa jest słaba, sprawdź osobno odpowiedź odbiorcy, reputację, treść i uprawnienia do wysyłania. Karnet DMARC nie gwarantuje akceptacji ani umieszczenia w skrzynce odbiorczej. Jeśli żadna ze ścieżek nie jest zgodna, zatrzymaj rozwijanie i popraw rzeczywistą konfigurację nadawcy. Nie osłabiaj polityki DMARC całej domeny, aby ukryć awarię pojedynczego produktu.
Przekazanie i odzyskanie
Zapisz zatwierdzoną różnicę DNS , wyniki wyszukiwania publicznego, stan usługi i zredagowany arkusz otrzymanych wiadomości z nazwanym właścicielem. Trzymaj dane uwierzytelniające i klucze prywatne poza biletami. W przypadku niepowodzenia wstrzymaj zadanie wysyłania, którego dotyczy problem, lub użyj wcześniej przetestowanej trasy pod kontrolą właściciela usługi. Przywróć tylko zmienione rekordy należące do tej integracji; przechowuj klucze publiczne potrzebne w wiadomościach przesyłanych w locie. Przetestuj ponownie po wycofaniu zmian, zmianie klucza, migracji domeny lub zmianie przekaźnika ruchu wychodzącego. Zamknij zmianę tylko wtedy, gdy właściciel produktu i administrator poczty będą w stanie wyjaśnić zaobserwowany łańcuch tożsamości.
Potwierdź granicę dostawcy
Ilustracja CNAME źródła jest specyficzna dla domeny, a metadane produktu zawierają niedokończone elementy zastępcze dla innych produktów Yotpo. Traktuj wyłącznie wyraźne instrukcje dotyczące recenzji/lojalności zgodnie z niniejszym opisem. Uwierzytelnianie domeny deleguje rolę wysyłającą; nie stanowi o zaufaniu konkretnego autora ani o tym, że każda wiadomość jest bezpieczna.
Przeanalizuj fikcyjny przypadek diagnostyczny
Tylko fikcyjny przypadek pisemny: YO-01 zakłada, że Recenzje wymagają reviews@shop.example , ale s1._domainkey.shop.example już deleguje do innej zatwierdzonej aplikacji SendGrid . Żadna wiadomość Yotpo nie została przechwycona, więc wyniki dotyczące kopert i DKIM są nieznane. Właściciel recenzji musi ujawnić kolizję działowi pomocy technicznej, uzyskać zestaw alternatywny dla danej domeny i zachować drugą aplikację przed testowaniem. Próbka Loyalty lub niepowiązana SendGrid nie może zamknąć tej trasy. W tym przypadku nie wykonano żadnego dzierżawcy, DNS , polecenia serwera ani wiadomości.
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.