Alias domeny zmienia sposób, w jaki adres może być używany lub odbierany w ramach usługi. Samo w sobie nie definiuje domeny umieszczanej w wiadomości wychodzącej Podpis DKIM. Przed użyciem aliasu do poczty klienta sprawdź wiadomość wysłaną zamierzoną trasą i określ, jaką tożsamość podpisuje usługa.
Alias jest również przeciążonym terminem produktu. Może opisywać alternatywny adres skrzynki pocztowej, domenę dołączoną do dzierżawcy lub tożsamość nadawcy na poziomie aplikacji. Ten przepływ pracy dotyczy wynikowej wiadomości i dowodów DNS . Zanim założysz, że obsługuje ona wysyłanie lub domenę niestandardową, zapoznaj się z aktualną dokumentacją konkretnej funkcji aliasu DKIM.
Oddziel konfigurację odbierania od wysyłania tożsamości
Najpierw ustal, do czego ma służyć alias. Adres, który odbiera wiadomości do istniejącej skrzynki pocztowej, może nigdy nie zostać autoryzowany do użytku wychodzącego. Jeśli wysyłanie jest obsługiwane, określ, czy usługa zachowuje alias w polu Od, zapisuje go na adres podstawowy, czy też kieruje go przez innego nadawcę.
Zapisz widoczny adres Od po dostarczeniu, a nie tylko adres wybrany w oknie tworzenia wiadomości. Zapisz także dowolne pole nadawcy i tożsamość koperty, ale nie myl ich z domeną sd DKIM . RFC 6376 §3.5 definiuje domenę podpisującą d, różną od adresu autora wiadomości. RFC 9989 §4.4 korzysta z domeny autora i uwierzytelnionych identyfikatorów wyrównanie.
Przeczytaj każdy podpis kontrolowanej wiadomości
Wyślij test z aliasu, korzystając z tego samego klienta, interfejsu API lub delegowanej trasy skrzynki pocztowej co produkcja. Eksportuj otrzymaną wiadomość bez jej edycji. Zidentyfikuj każdy DKIM-Signature , jego wartości d i s oraz wynik zaufanego odbiorcy. Usługa może dodać zarówno podpis dostawcy, jak i podpis domeny klienta; pierwszy wyświetlony przez narzędzie może nie być tym, którego dotyczy DMARC.
Dla każdego przechodzącego podpisu oceń zgodność z odebraną domeną From. Tryb ścisły wymaga dokładnego dopasowania domeny poniżej RFC 9989 §3.2.10. Tryb relaksu pozwala na to samo domena organizacyjna pod RFC 9989 §4.10.2. Dwie różne zarejestrowane domeny nie są ze sobą zgodne po prostu dlatego, że jedna jest aliasem drugiej w portalu administracyjnym.
Użyj małego arkusza tożsamości
Przykładowy przypadek, zakładając odrębne Domeny Organizacyjne i obowiązującą politykę DMARC : adres podstawowy to person@company.example , natomiast alias wychodzący to person@newbrand.example . Odbiorca widzi From w newbrand.example i przechodzący podpis z d=company.example. Ten podpis nie jest zgodny z newbrand.example . Jeśli inny przekazujący podpis używa d=newbrand.example, ten drugi podpis dostarcza wyrównaną ścieżkę DKIM .
Zapisz oba wyniki, zamiast wywoływać całą wiadomość bez znaku lub mówić, że DKIM jest uszkodzony. Ważny podpis pod domeną podstawową jest nadal ważnym DKIM . Brakującą właściwością jest wyrównanie aliasu. Oceniać SPF oddzielnie przed przypisaniem ogólnego wyniku DMARC . Ten arkusz jest syntetycznym przykładem, a nie dowodem zachowania aliasu jakiejkolwiek usługi.
Poproś o obsługiwany środek zaradczy
Zapytaj, czy dostawca może podpisywać alias poczty za pomocą aliasu domeny i czy wymaga to dodania domeny jako odrębnej tożsamości wysyłającej. Uzyskaj aktualne nazwy rekordów DNS , typy rekordów i wartości. Sprawdź, kto kontroluje strefę DNS i czy proponowana zmiana koliduje z istniejącą selektor.
Nie kopiuj ręcznie klucza publicznego domeny podstawowej i załóż, że usługa zacznie używać nowej wartości d. Publikacja DNS nie może instruować dowolnego podpisującego o zmianie tożsamości. Konfiguracja wysyłania i opublikowany materiał weryfikacyjny muszą być zgodne.
Zachowaj alias w przeglądach cyklu życia
Powtórz test dla odpowiedzi, klientów mobilnych i wiadomości generowanych przez aplikacje, jeśli te trasy są używane. Zachowaj mapę od selektora do dostawcy z właścicielem firmy aliasu i datowaną próbką. W przypadku migracji lub wycofywania przed usunięciem delegowanych rekordów sprawdź, czy inne tożsamości nadal korzystają z tego samego dostawcy.
Instrukcja zamknięcia powinna określać, który alias i trasa zostały przetestowane, która domena przeszła i czy została dopasowana. Jeśli produkt nie może zapewnić wymaganej tożsamości, udokumentuj to ograniczenie i wybierz obsługiwany projekt wysyłania, zamiast zgłaszać alias jako uwierzytelniony bez zastrzeżeń.
Zapisz następną decyzję
Użyj jednego wiersza na rzeczywistą trasę: żądany alias, otrzymany od, każda para d/s, zaufany wynik, tryb wyrównania i pozostała przerwa. Karnet domeny podstawowej z niepowiązanym aliasem From jest prawidłowym DKIM , ale nie jest dopasowanym DKIM . Nie nazywaj całej wiadomości niepowodzeniem DMARC , dopóki nie zostanie oceniony SPF i obowiązujące zasady. Nie zapewnia się tutaj możliwości aliasów specyficznych dla dostawcy ani wyników na żywo.