[ Przewodniki po usługach wysyłkowych ]

Konfiguracja Microsoft 365 DMARC : sprawdź całą trasę wysyłania

Skonfiguruj prawidłowe zasady SPF i delegowanie DKIM generowane przez dzierżawę, a następnie sprawdź dopasowanie w przypadku prawdziwej poczty i aplikacji Microsoft 365 wysyłających poza dzierżawę.

Przez zespół badawczy EmailAuth · 5 minut czytania

[Kluczowe punkty]

  • Skonfiguruj prawidłowe zasady SPF i delegowanie DKIM generowane przez dzierżawę, a następnie sprawdź dopasowanie w przypadku prawdziwej poczty i aplikacji Microsoft 365 wysyłających poza dzierżawę.
  • Sukces poczty elektronicznej do pracowników nie obejmuje osobnej ścieżki CRM.
Na tej stronie

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.

[Na wynos]

Sukces poczty elektronicznej do pracowników nie obejmuje osobnej ścieżki CRM.

[ Według roli ]

Co to oznacza dla Ciebie

Wybierz swoją rolę, aby uzyskać praktyczne dalsze kroki.

Administrator IT / poczty

Wykorzystaj wygenerowane wartości i zweryfikuj ostateczną trasę.

Potwierdź środowisko chmurowe firmy Microsoft, a następnie uzyskaj od dzierżawcy oba obiekty DKIM CNAME . Publiczny DNS , włączenie podpisywania i wynik odebrania wiadomości zewnętrznej to oddzielne kontrole.

Kolejne kroki

  1. Przejrzyj istniejące zasady dotyczące pojedynczego SPF .
  2. Opublikuj i zweryfikuj oba dokładne rekordy CNAME DKIM .
  3. Testuj aplikacje i bramy wychodzące wraz z pocztą pracowniczą.

CISO / SecOps

Wymagaj dowodów w całym zadeklarowanym spisie usług.

Włączone ustawienie dzierżawy ustanawia ograniczony stan konfiguracji. Przejrzyj implementację pod kątem nazwanej domeny, środowiska chmury, rzeczywistych nadawców i zatwierdzonych wyjątków.

Kolejne kroki

  1. Zachowaj zatwierdzenia i poprzedni zatwierdzony stan DNS .
  2. Sprawdź dowody przepływu krytycznego i gromadzenie raportów.
  3. Przypisz przegląd nieaktualnych usług i delegowanych selektorów.

Założyciel / Nietechniczny

Dołącz aplikacje poza pocztą pracowniczą.

Twoja implementacja Microsoft 365 może pozostawić CRM, witrynę internetową i platformę rozliczeniową w oddzielnej infrastrukturze. Lista akceptacji biznesowych powinna zawierać tę komunikację i jej właścicieli.

Kolejne kroki

  1. Lista krytycznych wiadomości według usługi.
  2. Poproś o test z każdego ważnego przepływu pracy.
  3. Przypisz właściciela do raportowania i przyszłych zmian nadawcy.

[ Często zadawane pytania ]

Często zadawane pytania

Czy standardowy SPF Microsoft 365 jest odpowiedni dla każdej chmury Microsoft?

Nie. Firma Microsoft dokumentuje różne wartości dla poszczególnych środowisk, w tym GCC High/DoD i 21Vianet. Zanim skorzystasz z przykładu standardowej chmury, potwierdź rzeczywistą usługę.

Czy mogę dodać drugi rekord SPF tylko dla Microsoft 365 ?

Nie dodawaj drugiej obowiązującej zasady SPF w tej samej domenie. Przejrzyj istniejące uprawnienia i opublikuj jedną prawidłową politykę odzwierciedlającą autoryzowane trasy.

Dlaczego powinienem uzyskać cele DKIM od mojego dzierżawcy?

Wygenerowane elementy docelowe mogą używać różnych formatów nazewnictwa i wartości specyficznych dla dzierżawy. Skopiuj bieżące wartości Selector1CNAME i Selector2CNAME zamiast konstruować je na podstawie ogólnego samouczka.

Czy potrzebuję obu rekordów CNAME Microsoft DKIM ?

Tak, konfiguracja domeny niestandardowej firmy Microsoft wykorzystuje oba selektory CNAME, w tym rekord niezbędny do rotacji. Tylko jeden aktywny selektor podpisu nie powoduje, że drugie delegowanie jest niepotrzebne.

Czy status CnameMissing oznacza, że ​​powinienem utworzyć kolejny rekord DMARC ?

Nie. Identyfikuje zależność konfiguracji podpisywania, którą należy zbadać. Porównaj dokładnie wygenerowane nazwy i cele CNAME z publicznym DNS przed zmianą niepowiązanych zasad DMARC .

Czy konfiguracja Microsoft 365 obejmuje oddzielnego dostawcę CRM?

Nie automatycznie. CRM może przesyłać dane za pośrednictwem innej infrastruktury i modelu tożsamości. Przetestuj tę aplikację i oddzielnie skonfiguruj obsługiwaną przez nią ścieżkę.

Czy wiadomość podpisana przez domenę onmicrosoft.com może nie zostać dopasowana do mojej niestandardowej domeny Od?

Tak. Przekazywanie podpisu w niepowiązanej domenie nie zapewnia wyrównania DKIM z niestandardową domeną Od. Sprawdź wszystkie podpisy i każdą inną przechodzącą wyrównaną ścieżkę.

Co powinien podpisać recenzent wdrożenia?

Prawidłowe ustawienia specyficzne dla chmury, delegacje DKIM , efektywny DNS , rzeczywiście dopasowane wiadomości na trasach krytycznych, zbieranie raportów, własność i zarejestrowane wyjątki.

[ Źródła ]

Źródła

  1. RFC 9989

    Sekcje §4.4 · §5.3.1 · §5.3.5 · §7.4 · §11.7

  2. RFC 7208

    Sekcje §3.2 · §4.6.4

  3. RFC 6376

    Sekcje §3.4 · §3.6.1 · §3.7 · §6.1.2 · §8.3

  4. Microsoft: skonfiguruj DKIM do podpisywania poczty z domeny w chmurze

    Sekcje Konfigurowanie podpisywania DKIM wiadomości wychodzących w Microsoft 365 · Użyj programu Exchange Online PowerShell do konfigurowania podpisywania DKIM wiadomości wychodzących · Przykłady CNAME specyficzne dla dostawcy DNS

  5. Microsoft: skonfiguruj SPF dla niestandardowych domen w chmurze

    Sekcje Scenariusz: tylko poczta e-mail na Microsoft 365 · Scenariusz: poczta e-mail na platformie Microsoft 365 z lokalną pocztą e-mail i usługą poczty e-mail firmy innej niż Microsoft

[ Słowniczek ]

Słowniczek

DKIM
Wiązanie podpisu obejmowało dane wiadomości przesyłane do domeny podpisującej.
Selektor
Wartość podpisu identyfikująca wyszukiwanie klucza publicznego w domenie podpisującej.
Wyrównanie
Wymagana relacja między uwierzytelnioną tożsamością a widoczną domeną From.
Trasa wysyłania
Rzeczywista ścieżka od usługi przez jej przekaźniki lub bramy do odbiornika.

Pochodzenie przedsiębiorstwa

Dlaczego najlepsze instytucje finansowe i rządy wycofali swoje panele bezpieczeństwa poczty e-mail.

Tradycyjne platformy uwierzytelniania poczty e-mail oferują pulpit nawigacyjny i proszą inżynierów o wykonanie pracy. W środowiskach o dużej stawce ręczny nadzór oznacza opóźnione egzekwowanie, zmianę konfiguracji i niemonitorowane domeny-cienie.

EmailAuth to platforma agentowego pochodzenia wiadomości e-mail. Nasi agenci egzekwują p=reject, dostosuj zewnętrznych nadawców i przenieś swoje domeny do pełnych adresów RFC 9989 zgodność, nowy standard DMARC , z możliwością kontroli przez człowieka.

Rządy Duże przedsiębiorstwa Instytucje finansowe poziomu 1

SaaS · Dedykowany najem · Lokalne rozwiązanie typu air-gapped · Szyfrowanie BYOK

Baza wiedzy