Zacznij od kontaktowego adresu e-mail, który definiuje domenę wysyłającą
Urzędnik ControlShift Przewodnik konfiguracji uwierzytelniania nadawcy, zaktualizowana 20 maja 2025 r., łączy tożsamość wysyłającą platformę z kontaktowym adresem e-mail organizacji. Przewodnik mówi, że ten adres jest używany do poczty platformy do zwolenników podejmujących działania i administratorów subskrybujących powiadomienia. Potwierdź, że skonfigurowany adres należy do zamierzonego domena organizacyjna przed utworzeniem rekordów uwierzytelniających. Literówka lub przestarzała domena marki na tym pierwszym etapie może skutkować technicznie spójną konfiguracją dla niewłaściwej tożsamości.
Udokumentowana ścieżka to strona główna administratora, Ustawienia, Kontakt, gdzie należy wpisać i zapisać adres. Traktuj zmianę tego adresu jako zmianę konfiguracji komunikacji, a nie tylko naprawę uwierzytelnienia. Przed zapisaniem zidentyfikuj kategorie wiadomości, których to dotyczy, oczekiwania dotyczące odpowiedzi i odpowiedzialny personel. Ten artykuł nie zmienia adresu, nie kontaktuje się ze wspierającym ani nie wysyła powiadomienia na platformę. Możliwość zastosowania rachunku bieżącego i faktyczna trasa używana przez reprezentatywne wiadomości pozostają otwarte.
Użyj ustawień dostarczalności, aby uzyskać rekordy specyficzne dla konta
Po ustawieniu kontaktowego adresu e-mail przewodnik kieruje administratora do opcji Ustawienia, Dostarczalność. Wyświetlana nazwa domeny pochodzi z kontaktowego adresu e-mail. Jeśli jest nieprawidłowy, najpierw popraw kontaktowy adres e-mail, zamiast publikować rekordy dla niezamierzonej domeny. Wprowadź adres e-mail kontaktu technicznego organizacji w odpowiednim polu i zapisz, korzystając z autoryzowanego przepływu pracy konta. Adres kontaktowy do spraw technicznych należy podawać wyłącznie po uzyskaniu odpowiedniego zezwolenia i aktualizować w miarę zmiany obowiązków personelu.
Po zapisaniu strona prezentuje trzy CNAME dokumentacja. Opublikuj dokładnych właścicieli i cele za pośrednictwem autorytatywnego dostawcy DNS organizacji. Przewodnik wyjaśnia kierunek mapowania: nazwa po lewej stronie wskazuje na cel po prawej stronie. Nie odwracaj tych pól, zamień rekord skopiowane z innej organizacji lub zastąp wydaną konfigurację ogólnym przykładem SendGrid . Wartości wygenerowane przez ControlShift stanowią dane wejściowe implementacji dla tego przepływu pracy.
Przed edycją porównaj każdą pełną nazwę właściciela z obsługą sufiksów edytora DNS i istniejącymi danymi strefy. W jednym panelu może wystarczyć względna etykieta, podczas gdy w innym oczekuje się w pełni kwalifikowanej nazwy. Zachowaj aktualne zapisy i zapisz zatwierdzone zmiany. Trzy rekordy CNAME reprezentują zależności, które powinny pozostać przypisane do tej konfiguracji platformy, aby można było je przeglądać podczas przyszłych migracji, zmian w domenie lub odłączania się od platformy.
Sprawdź widoczność DNS przed interpretacją Zweryfikuj
Przewodnik mówi, że użytkownicy Cloudflare powinni przechowywać zapisy dotyczące dostarczania wiadomości e-mail bez proxy. Jest to szczegółowa wskazówka dotycząca tych rekordów uwierzytelniania, a nie powód do wyłączenia proxy lub kontroli bezpieczeństwa w całej witrynie. Jeśli host DNS oferuje funkcje proxy, przejrzyj odpowiednie ustawienia rekordów u autoryzowanego właściciela DNS i potwierdź, że wydany alias jest widoczny zgodnie z wymaganiami. Artykuł ten nie zmienia żadnych ustawień DNS .
Po utworzeniu rekordów wróć do Dostarczalności i wybierz opcję Weryfikuj. Udokumentowany komunikat o powodzeniu wskazuje, że kontrola DNS przez ControlShift przebiegła pomyślnie. Zachowaj tę obserwację oddzielnie od zgłoszonej zmiany i faktycznego rejestru publicznego. Kontrola dostawcy nie potwierdza, że wszystkie przyszłe wiadomości są poprawnie podpisane ani że widoczna domena autora jest zgodna. Jeśli weryfikacja się nie powiedzie, sprawdź dokładnego właściciela, cel, strefę autorytatywną i odpowiednie ustawienia rekordów, zanim ponownie zaczekasz lub odbudujesz konfigurację.
Krótkiego oszacowania dostawcy dotyczącego propagacji nie należy traktować jako uniwersalnego terminu. Nieprawidłowy właściciel rekordu lub alias proxy nie są naprawiane wyłącznie na podstawie upływu czasu. Zapisz, co się zmieniło, kiedy się zmieniło i co zaobserwował dostawca. Pozostaw wyraźną niepewność, jeśli wiarygodna odpowiedź i najnowszy status dostawcy nie zostały jeszcze uzgodnione.
Rozwiązuj kolizje selektorów bez nadpisywania innego nadawcy
ControlShift wyraźnie ostrzega, że organizacje już korzystające SendGrid bezpośrednio lub za pośrednictwem innego narzędzia mogą mieć s1. _domainkey i s2. _rekordy _domainkey . Przewodnik oferuje zwyczaj Selektor DKIM poprzez Ustawienia zaawansowane, aby uniknąć takich kolizji. Opisuje sprawdzenie Użyj niestandardowego selektora DKIM , wprowadzenie selektora o długości do trzech znaków i zapisanie tak, aby wygenerowane rekordy CNAME odzwierciedlały wybór. Potwierdź akceptowaną wartość obecnego interfejsu przed wdrożeniem; jest to limit specyficzny dla produktu, a nie uniwersalny DKIM reguła długości selektora.
Nie nadpisuj istniejącego selektora tylko po to, aby dopasować domyślne rekordy nowej strony. Określ usługę, która jest właścicielem każdego istniejącego rekordu i czy nadal podpisuje pocztę. Jeśli konfiguracja została już przeprowadzona do wystawienia rekordów, przewodnik opisuje usunięcie jej i rozpoczęcie od nowa, aby wybrać opcję niestandardową. Jest to zmiana w istniejącej konfiguracji uwierzytelniania i wymaga przeglądu wpływu, zwłaszcza jeśli poczta produkcyjna już od niej zależy.
Źródło dodaje ważne ostrzeżenie: po usunięciu i ponownym utworzeniu konfiguracji pierwsza CNAME prawdopodobnie również ulegnie zmianie. Przejrzyj cały nowo wydany zestaw, a nie tylko dwie nazwy, które w widoczny sposób zawierają selektor. Lista kontrolna akceptacji, która aktualizuje rekordy wyglądające na DKIM, ale zachowuje przestarzały pierwszy alias, może pozostawić ukrytą niezgodność. Zachowaj możliwość rozróżnienia starych i nowych wartości w rekordzie zmian i nie usuwaj niepowiązanych zależności.
Traktuj nową domenę kontaktowego adresu e-mail jako migrację konfiguracji
Poradnik odróżnia zmianę lokalnej części kontaktowego adresu e-mail od zmiany jego domeny. Zmiana adresu w tej samej domenie nie wymaga zmian w ustawieniach dostarczalności zgodnie z udokumentowanym przepływem pracy. Robi to inna domena: przewodnik opisuje usunięcie starej konfiguracji dostarczalności, aktualizację kontaktowego adresu e-mail i ponowne zakończenie konfiguracji. Tę sekwencję należy zaplanować jako migrację z wyraźną decyzją właściciela i wycofaniem, a nie zwykłą edycję kosmetyczną.
Potwierdź, że nowa domena jest kontrolowana przez organizację i że jej właściciel DNS może publikować wydane rekordy. Przed wznowieniem normalnego użytkowania sprawdź harmonogram zaplanowanych powiadomień i potrzebne dowody. Fakt, że poprzednia domena przeszła Verify, nie powoduje przeniesienia tego wyniku na nową. Zachowaj zapis akceptacji poprzedniej konfiguracji dla kontekstu, jednocześnie wyraźnie oznaczając nową tożsamość jako niezweryfikowaną do czasu zakończenia odpowiednich kontroli.
Zweryfikuj tożsamość wiadomości bez obietnicy dostarczenia
Odrębnie autoryzowane ćwiczenie akceptacji powinno sprawdzić nieszkodliwe reprezentatywne wiadomości i wyniki zaufanego odbiorcy. Zapisz widoczną domenę autora, domenę podpisu i selektor, tożsamość koperty i rzeczywistą trasę platformy. RFC 6376 , sekcja 3.5 definiuje Podpis DKIM pola i RFC 9989 , sekcja 4.4 wyjaśnia wyrównanie. Pomyślne sprawdzenie DNS nie zastępuje relacji na poziomie wiadomości.
Zachowany przewodnik konfiguracji zawiera trzy rekordy CNAME zamiast uniwersalnego SPF include, aby dodać w każdym katalogu głównym organizacji. Nie wymyślaj zasady dołączania ani nie dodawaj drugiej zasady SPF tylko dlatego, że ogólna lista kontrolna wymaga podania SPF . Jeśli rzeczywista trasa rzeczywiście wymaga osobnej zmiany SPF , przejrzyj to w sekcji RFC 7208 , sekcje 3.2 i 4.6.4 z odpowiedzialnym operatorem. Uwierzytelnianie może dotyczyć kontroli tożsamości; nie gwarantuje to umieszczenia w skrzynce odbiorczej, zaangażowania kibiców ani bezpieczeństwa każdej powiązanej prośby.
Fikcyjna diagnoza i pusty arkusz akceptacji
Fikcyjna organizacja społeczna, Riverbank Neighbours, ma już selektory SendGrid dla innej platformy. Administrator wybiera niestandardowy selektor w ControlShift, ale po odtworzeniu konfiguracji aktualizuje tylko dwa rekordy CNAME związane z selektorem. Z przeglądu wynika, że zmianie uległ także pierwszy wydany akt. Proponowana korekta polega na porównaniu pełnego nowego zestawu ze strefą autorytatywną, zachowaniu selektorów drugiej platformy i uzyskaniu nowych dowodów weryfikacji. Ten scenariusz jest fikcyjny i nie zawiera żadnych faktycznych obserwacji DNS , informacji o wspierających ani wykonanych działań.
- Bieżąca domena kontaktowego adresu e-mail i kategorie wiadomości, których to dotyczy: ______
- Dostarczalność Nazwa domeny i autoryzowany kontakt techniczny: ______
- Kompletny zestaw trzech właścicieli/docelowych płyt i czas wydania: ______
- Obecni właściciele selektora i decyzja niestandardowego selektora: ______
- Wszystkie zmienione rekordy po jakiejkolwiek rekreacji, łącznie z pierwszym: ______
- Autorytatywny przegląd DNS i odpowiedniego ustawienia proxy: ______
- Sprawdź wynik i zaufany dowód tożsamości otrzymanej wiadomości: ______
- Termin migracji domeny, właściciel wycofania i decyzja o zwolnieniu: ______
Oryginalne dowody wdrożenia, przegląd zagadnień związanych z człowiekiem, aktualne zastosowanie źródła, testowanie trasy produkcyjnej, dostępność wizualna i zezwolenie właściciela pozostają otwarte. Nie zmieniono żadnego adresu kontaktowego, konfiguracji uwierzytelniania ani rekordu DNS i nie wysłano żadnej wiadomości. Szerszy wymóg dotyczący wdrożenia katalogu nadal podlega faktycznemu autoryzowanemu kontu i dowodom wiadomości.