Zidentyfikuj rzeczywistą trasę wysyłania DreamHost
Ten przewodnik dotyczy poczty hostowanej przez DreamHost, a nie każdej aplikacji lub usługi pocztowej dołączonej do domeny zarejestrowanej w DreamHost. Rejestracja, autorytatywny hosting DNS i transport poczty wychodzącej to odrębne fakty. Indywidualna inwentaryzacja poczty internetowej, klientów poczty na komputery stacjonarne, formularzy kontaktowych na stronie internetowej i wtyczek do biuletynów. Zwykła skrzynka pocztowa domeny może korzystać z DreamHost SMTP podczas gdy jej witryna internetowa wysyła pocztę lokalnie przy użyciu PHP, co zmienia zachowanie podpisywania.
DreamHost twierdzi, że poczta wysyłana przez jego serwer pocztowy za pomocą poczty internetowej, klienta pocztowego lub formularza SMTP jest automatycznie podpisana za pomocą DKIM. Jego dokumentacja wyraźnie wyklucza pocztę internetową, która nie korzysta z SMTP , w tym zwykłą trasę poczty sendmail lub PHP. Opublikowany klucz nie może sam podpisać wiadomości. Przed edycją DNS w celu naprawienia brakujących podpisów sprawdź, czy aplikacja rzeczywiście przesyła dane za pośrednictwem uwierzytelnionego serwera pocztowego.
Znajdź i opublikuj rekord DKIM konta
W przypadku poczty hostowanej przez DreamHost DreamHost tworzy i zarządza DKIM rekordy dla domeny i subdomen za pomocą usługi e-mail. Otwórz Zarządzaj stronami internetowymi, użyj menu z trzema kropkami domeny i wybierz Ustawienia DNS . W widoku siatki menu pojawia się pod domeną; w widoku listy pojawia się po prawej stronie. Sprawdź Rekord TXT z _domainkey w nazwie. Dokumentacja ilustruje Dreamhost. _domainkey selektor I 2048-bitowy klucze, ale wartość dla Twojej domeny musi pochodzić z Twojego własnego panelu.
Jeśli autorytatywny serwery nazw znajdują się poza DreamHost, skopiuj pełny rekord tego konta do rzeczywistej usługi DNS . Rekord widoczny w panelu DreamHost nie ustanawia publicznej publikacji, gdy inny dostawca jest autorytatywny. Dostosuj nazwę właściciela do konwencji nazwy względnej lub nazwy w pełni kwalifikowanej tego redaktora i sprawdź powstałą nazwę publiczną. Zachowaj klucz publiczny bez wstawiania spacji w danych klucza. Nie publikuj przykładowego klucza wydrukowanego w artykule pomocy.
Selektor używany przez inną aktywną usługę musi pozostać nienaruszony. Odrębne usługi mogą publikować różne selektory, ale każdy podpis musi rozpoznać swój własny selektor s= w swojej domenie d=. Potwierdź faktyczny podpis wiadomości, zanim założysz, że używa przykładowego selektora. Jeśli domena wysyła dane za pośrednictwem innego dostawcy, uzyskaj instrukcje podpisywania od tego dostawcy, zamiast oczekiwać, że klucz DreamHost uwierzytelni jego ruch.
Dokładnie przejrzyj domyślny i niestandardowy SPF
DreamHost dokumentuje tę automatyczną politykę dla swojej usługi pocztowej: v=spf1 mx include:netblocks.dreamhost.com include:relay.mailchannels.net -all . Traktuj to jako udokumentowaną opcję domyślną do porównania z bieżącą konfiguracją, a nie uniwersalny zamiennik istniejących zasad dotyczących wielu dostawców. Sprawdź, które hosty i domeny kopertowe rzeczywiście wymagają autoryzacji. SPF jest oceniany oddzielnie dla subdomen, więc rekord wierzchołkowy nie obejmuje automatycznie oddzielnej subdomeny kopertowej.
Dodanie niestandardowego Rekord SPF w DreamHost usuwa swój domyślny rekord. Jeśli DreamHost nadal jest autoryzowanym nadawcą, zachowaj odpowiednie uprawnienia w połączonej polityce niestandardowej po przejrzeniu aktywnych tras i zależności wyszukiwania. Dokumentacja mówi również, że usunięcie niestandardowego rekordu SPF powoduje automatyczne przywrócenie wartości domyślnej. To zachowanie ma znaczenie podczas odzyskiwania: usunięcie niekoniecznie oznacza usunięcie autoryzacji SPF , a przywrócenie ustawień domyślnych może pominąć inne legalne usługi.
W zewnętrznym autorytatywnym DNS zarządzaj tam odpowiednią polityką. Zachowaj u właściciela dokładnie jedną obowiązującą zasadę SPF TXT . Nie dodawaj drugiego, aby zachować ustawienie domyślne, i nie zakładaj, że każde dołączenie pokazane w przykładzie historycznym jest konieczne na zawsze. Sprawdź ponownie opublikowaną politykę po zmianach i po każdym wycofaniu, w tym po efekcie automatycznie przywróconych rekordów.
Napraw pocztę internetową w warstwie transportowej
W przypadku formularza kontaktowego lub wtyczki WordPress korzystającej z sendmaila lub poczty PHP, preferuj obsługiwaną uwierzytelnioną konfigurację SMTP , jeśli zamierzoną trasą jest poczta hostowana przez DreamHost. Sprawdź rzeczywiste dane wyjściowe formularza, a nie tylko test połączenia wtyczki. Uruchom faktyczny przepływ pracy, zachowaj otrzymaną wiadomość i potwierdź tożsamość osoby podpisującej oraz widoczną nadawcę. Aplikacja może pomyślnie nawiązać połączenie, ale w środowisku produkcyjnym nadal używa innego adresu nadawcy.
DreamHost dokumentuje również samodzielnie zarządzaną instalację DKIM na serwerze dedykowanym z udziałem administratora lub na DreamCompute, ale twierdzi, że nie może obsługiwać tego ręcznie zainstalowanego oprogramowania. Jest to osobny projekt administracyjny systemu, a nie pole wyboru odpowiadające zarządzanej trasie SMTP . Nie wprowadzaj go jako niesprawdzonego obejścia formularza kontaktowego. Jeśli wybierzesz tę opcję, wymagaj osobnego planu operacyjnego dotyczącego kluczy, podpisywania, aktualizacji i odzyskiwania.
Zweryfikuj tożsamość nadawcy, a nie tylko panel kontrolny
Zielony wskaźnik konfiguracji oznacza jedynie kontrolę przeprowadzoną przez produkt. W celu akceptacji wyślij kontrolowaną wiadomość poprzez rzeczywisty przepływ pracy do skrzynki pocztowej, której otrzymane nagłówki możesz sprawdzić. Zachowaj oryginalną wiadomość, a nie zrzut ekranu przedstawiający pomyślne wyszukiwanie DNS . Zapisz każdą widoczną domenę From, domenę koperty SMTP pokazaną przez system odbierający Podpis DKIM'sd= domena podpisująca i selektor s= oraz system odbierający Authentication-Results. Nie ufaj polu Authentication-Results tylko dlatego, że nadawca je umieścił.
SPF uwierzytelnia tożsamość koperty, a nie automatycznie widoczny adres nadawcy. DKIM weryfikuje podpis swojej domeny podpisującej. DMARC wymaga ścieżki przechodzącej, która jest zgodna z widoczną domeną Od w odpowiednim obszarze wyrównanie tryb. Koperta należąca do dostawcy może przejść SPF bez tworzenia SPF dostosowanego do Twojej marki. I odwrotnie, prawidłowy wyrównany podpis DKIM może zapewnić przechodzącą ścieżkę DMARC , nawet jeśli SPF nie jest wyrównany. Przed zmianą DNS sprawdź rzeczywiste tożsamości.
Użyj tego ilustracyjnego przypadku akceptacji, a nie jako roszczenia dotyczącego niewykonania zobowiązania przez dostawcę: wiadomość zawiera From learning@example.com , kopertę bounce@vendor.example.net i zweryfikowany podpis DKIM z d=example.com. Sukces SPF dla samego vendor.example.net nie jest powiązany z example.com ; prawidłowy podpis z d=example.com zapewnia dokładne wyrównanie DKIM . Jeśli zamiast tego odbiorca zgłosi nieprawidłowy podpis, w przykładzie nie ma już wyrównanej ścieżki przejścia. Zapisz zarówno wynik uwierzytelnienia, jak i domenę, której dotyczy.
Diagnozuj awarie w ustalonej kolejności
Najpierw upewnij się, że serwery nazw delegowane dla konkretnej domeny są serwerami, które edytowałeś. Zapytaj autorytatywne serwery o oczekiwaną nazwę właściciela i typ rekordu. Porównaj ich odpowiedzi z wartościami podanymi na koncie, sprawdzając przypadkowe zduplikowanie sufiksu domeny, brakujące etykiety selektorów, obcięte klucze i konflikty CNAME . Dopiero gdy autorytatywna odpowiedź będzie poprawna, należy zbadać buforowanie rekurencyjne lub poczekać na wygaśnięcie wcześniejszego TTL. Nie ma jednego gwarantowanego terminu rozmnażania na całym świecie.
Następnie powtórz test komunikatu na trasie, która zakończyła się niepowodzeniem. Aplikacja internetowa może korzystać z innego transportu niż ludzka skrzynka pocztowa, a pomyślny podgląd nie jest dowodem na to, że powiadomienia produkcyjne korzystają z tej samej tożsamości. Jeśli DNS jest prawidłowy, ale brakuje podpisu, sprawdź transport wysyłający i konfigurację produktu, zamiast dodawać niepowiązane uprawnienia SPF . Jeśli uwierzytelnienie zakończy się pomyślnie, ale poczta zostanie umieszczona w spamie, zachowaj nagłówki i osobno sprawdź reputację, treść i sposób postępowania z odbiorcami. Uwierzytelnienie nie gwarantuje umieszczenia w skrzynce odbiorczej.
Kontrola zmian i dowód ukończenia
Przed wprowadzeniem zmian zachowaj poprzednie zestawy rekordów, zatwierdzone nowe wartości, właściciela domeny, właściciela firmy każdego przepływu pracy, którego to dotyczy, oraz konkretną decyzję dotyczącą odzyskiwania. Nigdy nie twórz drugiej zasady SPF u tego samego właściciela, aby dodać nadawcę. Przejrzyj jedną połączoną politykę i jej zależności w wyszukiwaniu DNS; niepowiązane rekordy TXT mogą współistnieć, ale wiele kandydujących zasad SPF jest błędem. Nie nadpisuj selektora innego nadawcy. Nie osłabiaj polityki DMARC całej domeny, aby ukryć jedną nieudaną integrację.
Akceptacja wymaga wiarygodnych dowodów DNS , walidacji produktu i rekordu tożsamości odebranej wiadomości dla każdej objętej zakresem trasy wysyłania. Testuj odpowiedzi osobno tam, gdzie przepływ pracy ich oczekuje. Są to proponowane kontrole, a nie ukończone testy: ten przewodnik opiera się na zachowanej dokumentacji i syntetycznym rozumowaniu, bez żadnych zmian dzierżawców na żywo, pomiarów DNS ani wyników dostarczonych wiadomości. Właściciel będący człowiekiem musi przejrzeć dowody i zatwierdzić każde wdrożenie produkcyjne. Zachowaj dostępność istniejących tras roboczych do czasu zademonstrowania zastąpienia i usuń przestarzałe uprawnienia dopiero po potwierdzeniu, że żadna pozostała zależność ich nie używa.
Przed zmianą zasad oceń niedopasowanie transportu
W przypadku pisemnej sprawy DH-01 załóżmy, że poczta internetowa personelu z adresu help@example.com ma zaufany podpis DKIM d=example.com, s=dreamhost. Formularz strony korzysta zamiast tego z poczty PHP i nie ma zaobserwowanego podpisu DKIM ; jego wynik SPF jest nieznany. Pierwsza trasa ma ustaloną, wyrównaną ścieżkę, podczas gdy druga pozostaje nierozwiązana, a nie automatycznie powoduje awarię każdego mechanizmu. Poproś właściciela witryny o zweryfikowanie obsługiwanej konfiguracji SMTP i wywołanie nieszkodliwego zdarzenia formularza w autoryzowanym teście. Klawisz panelu nie dostarcza brakującego podpisu. Żadna wiadomość, wtyczka ani rekord DNS nie została przetestowana ani zmieniona.
Aby odzyskać dane, przed usunięciem jakichkolwiek zasad niestandardowych porównaj bieżący rekord SPF z zatwierdzonym poziomem bazowym. W udokumentowanym zachowaniu tego dostawcy usunięcie przywraca ustawienie domyślne; nie musi to być koniecznie równoznaczne z przywróceniem pełnej poprzedniej zasady dotyczącej wielu nadawców.
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.