Aby skonfigurować DMARC w przypadku domeny niestandardowej Microsoft 365 ustal trasy wysyłania domeny i skonfiguruj odpowiednie SPF zasady, włącz domenę niestandardową DKIM i zweryfikuj wyrównany wynik w otrzymanej poczcie. Publikacja DMARC Rekord TXT jest jednym krokiem w tej sekwencji.
W tym przewodniku opisano wysyłanie domeny niestandardowej za pośrednictwem Microsoft 365 . Przed skorzystaniem z przykładów sprawdź środowisko chmury Microsoft oraz wszelkie ustalenia dotyczące bram hybrydowych, przekaźnikowych lub bram wychodzących. Aplikacje wysyłające poza Microsoft 365 potrzebują własnej obsługiwanej konfiguracji uwierzytelniania, nawet jeśli korzystają z tej samej widocznej domeny From.
Potwierdź domenę, hosta DNS i środowisko Microsoft
Potwierdź domenę niestandardową, jej autorytatywny host DNS , środowisko Microsoft 365 i uprawnienia potrzebne do zarządzania podpisywaniem. Zapisz istniejące SPF , DKIM i Rekordy DMARC przed ich zmianą.
Nie myl administracji publicznym DNS z listą domen dzierżawcy. Rejestrator może być także hostem DNS , ale nie musi. Przed edycją strefy sprawdź delegowane serwery nazw.
Wymień wszystkie trasy korzystające z domeny. W szczególności należy rozróżnić zwykłe wysyłanie Exchange Online od aplikacji korzystających z przekaźnika, wysyłania bezpośredniego, innego dostawcy SMTP lub bramy wychodzącej. Sama nazwa produktu nie pozwala na identyfikację ostatecznego sygnatariusza.
Mapuj pocztę pracowniczą i pocztę aplikacyjną
Przejście na Microsoft 365 nie powoduje automatycznego przeniesienia aplikacji do fakturowania, formularza kontaktowego w witrynie czy platformy rekrutacyjnej. Usługi te mogą nadal wyświetlać Twoją domenę podczas wysyłania za pośrednictwem innego dostawcy.
Poproś o prostą mapę usług: poczta pracownicza, poczta aplikacyjna i komunikacja zewnętrzna, z właścicielem obok każdej trasy. Wymagaj testu odebranych wiadomości w przypadku krytycznych przepływów, takich jak resetowanie haseł i powiadomienia o rozliczeniach. Produkt działa, odpowiedzialna komunikacja, a nie zrzut ekranu przedstawiający włączone ustawienie dzierżawy.
Skonfiguruj odpowiednią politykę SPF
Udokumentowany przykład firmy Microsoft dotyczący wysyłania domeny **tylko za pośrednictwem standardowej usługi Microsoft 365 lub GCC** to:
v=spf1 include:spf.protection.outlook.com -all
To jest przykład o ograniczonym zakresie, a nie zamiennik istniejących zasad dotyczących usług mieszanych. Różne dokumenty Microsoft obejmują domeny dla GCC High/DoD i dla usług obsługiwanych przez 21Vianet. Postępuj zgodnie z bieżącymi instrukcjami dla swojego środowiska.
Opublikuj jedną odpowiednią politykę SPF w ocenianej domenie. Jeśli ważna polityka już istnieje, przejrzyj ją i zaktualizuj, zamiast dodawać kolejną Rekord SPF. Uwzględnij tylko uzasadnione uprawnienia do wysyłania i sprawdź pełną ścieżkę zależności pod kątem limitów SPF .
Opublikuj oba rekordy CNAME DKIM wygenerowane przez dzierżawcę
DKIM domeny niestandardowej Microsoft 365 używa dwóch CNAME dokumentacja. Uzyskaj ich dokładne wartości z konfiguracji DKIM portalu Defender lub Exchange Online PowerShell. Nie twórz elementu docelowego na podstawie starego szablonu nazewnictwa: firma Microsoft dokumentuje więcej niż jeden format docelowy, a wygenerowane wartości mogą zawierać składnik specyficzny dla dzierżawy.
W autoryzowanej sesji Exchange Online PowerShell ta kontrola tylko do odczytu pobiera skonfigurowane elementy docelowe:
Get-DkimSigningConfig -Tożsamość example.com | Lista formatów włączona, Stan, Selector1CNAME, Selector2CNAME
Jeśli domena nie ma konfiguracji podpisywania, przed oczekiwaniem istnienia tych właściwości skorzystaj z udokumentowanej procedury konfiguracji początkowej firmy Microsoft. W portalu Defender odpowiednim obszarem są Ustawienia uwierzytelniania poczty e-mail, a następnie DKIM .
Opublikuj **oba** wygenerowane rekordy CNAME , zweryfikuj ich publiczne odpowiedzi i włącz podpisywanie domeny niestandardowej za pomocą obsługiwanej procedury dzierżawy. Rekord CNAME deleguje zarządzanie kluczami weryfikacyjnymi; nie jest to prośba o wklejenie klucza prywatnego ani wymyślonego klucza TXT .
Sprawdź dokładnie zachowanie edytora DNS . Panel dołączający nazwę strefy może zamienić w pełni wprowadzoną nazwę hosta na zduplikowaną nazwę. Zachowaj dokładnie opublikowane wartości właściciela i wartości docelowe w rekordzie zmiany.
Dodaj zamierzoną politykę DMARC i miejsce docelowe raportowania
Jeśli domena rozpoczyna monitorowane wdrożenie, ilustracyjny zapis pod adresem _dmarc.example.com Jest:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
W przykładzie założono, że docelowe miejsce docelowe raportu roboczego znajduje się w tej samej domenie. Zastąp go zatwierdzonym adresem i zweryfikuj odbiór. Zewnętrzne miejsca docelowe mogą wymagać dodatkowych uprawnień do raportowania. Nie należy osłabiać istniejącej polityki egzekwowania prawa tylko po to, by dopasować ją do tego przykładu.
Skorzystaj z przewodnika tworzenia rekordu dotyczącego sekwencji publikowania i weryfikacji oraz DMARCbis przewodnik po gotowości podczas przeglądania starszych ustawień wdrażania.
Sprawdź wiadomości po pełnej trasie wysyłania
Wyślij kontrolowaną wiadomość do osobnego odbiorcy zewnętrznego i sprawdź tam oryginalną wiadomość. Zapisz widoczną tożsamość From, ocenioną przez SPF, każdą odpowiednią domenę DKIM d= i zaufany wynik DMARC .
Powtórz test dla aplikacji krytycznych i dowolnej końcowej bramy wychodzącej. Jeśli widoczny element From to domena niestandardowa, ale jedyny przekazujący podpis używa niepowiązanej tożsamości dzierżawy, sprawdź podpisywanie domeny niestandardowej i rzeczywistą trasę. Jeśli brama modyfikuje podpisaną treść, sprawdź wynik po tej bramie.
- Sprawdź: politykę SPF ; Dowody do zachowania: wiarygodna odpowiedź i oceniona trasa wysyłki
- Sprawdź: delegacja DKIM ; Dowody do zachowania: zarówno dokładne rekordy CNAME, jak i stan konfiguracji dzierżawy
- Sprawdź: Podpisywanie na żywo; Dowód do zachowania: Otrzymany podpis i zaufany wynik weryfikacji
- Sprawdź: DMARC ; Dowody do zachowania: przelotna, dostosowana ścieżka i obserwowany kontekst polityki
- Sprawdź: Ubezpieczenie biznesowe; Dowody do zachowania: Testy aplikacji, z których faktycznie korzysta organizacja
- Rekordowa akceptacja i ciągła własność
Zatwierdź wdrożenie względem nazwanego spisu usług. Zapisz osobę zatwierdzającą zmianę, własność DNS , wyniki przepływu krytycznego i pozostałe wyjątki. Status prawidłowego podpisania przez dzierżawcę nie wskazuje, że usługa obejmuje każdą aplikację zewnętrzną.
Zachowaj wyraźnie środowisko chmury w dokumentacji operacyjnej. Przykład chmury standardowej nie może po cichu stać się instrukcją dotyczącą chmury rządowej. Przypisz okresowe kontrole porzuconych usług i delegowanych selektorów, a także awarii w bieżącym ruchu.
Zachowaj możliwość przywrócenia wcześniej zatwierdzonego stanu, gdy zmiana się nie powiedzie, zachowując jednocześnie dowody zdarzenia. Ostateczna weryfikacja powinna wyjaśnić pozostałe ryzyko związane z przejętymi kontami i uwierzytelnioną złośliwą pocztą, zamiast zapewniać, że przepustka DMARC zapewni bezpieczeństwo każdej wiadomości.
Praktyczne dania na wynos
Konfiguracja jest zakończona, gdy opublikowane rekordy, stan podpisania dzierżawcy, tożsamości odebranych wiadomości i ścieżka raportowania są zgodne. Zachowaj spis usług i wyjątki wraz z zapisem zmian; stanowią one punkt odniesienia dla następnej zmiany aplikacji lub bramy.
Oddziel dowody przesyłane e-mailem do pracowników od wyjątku CRM
W przypadku pisemnym M365-01 zakłada się, że poczta pracownika z adresu staff@example.org ma zaufany przekaz Podpis DKIM z d=example.org. System CRM do rozliczeń używa billing@example.org , ale jego jedyny zarejestrowany podpis pochodzi z domeny niepowiązanego dostawcy, a jego wynik SPF jest nieznany. Dowody przesłane pocztą elektroniczną nie potwierdzają wyniku CRM, a częściowe dowody CRM nie mogą uzasadniać pełnego wyroku DMARC . Właściciel CRM musi zidentyfikować obsługiwaną dostosowaną tożsamość i zebrać kontrolowany komunikat zewnętrzny, zanim właściciel domeny oceni gotowość do egzekwowania. Są to fikcyjne tożsamości i wyniki; brak dzierżawcy, nastąpiła zmiana DNS lub wysłanie poczty.