Udostępnij za pośrednictwem

Konfigurowanie SPF w celu identyfikowania prawidłowych źródeł poczty e-mail dla domeny platformy Microsoft 365

Porada

Czy wiesz, że możesz bezpłatnie wypróbować funkcje w Microsoft Defender XDR Office 365 planie 2? Użyj 90-dniowej wersji próbnej Ochrona usługi Office 365 w usłudze Defender w centrum wersji próbnej portalu Microsoft Defender. Dowiedz się, kto może zarejestrować się i zapoznać się z warunkami wersji próbnej w witrynie Try Ochrona usługi Office 365 w usłudze Microsoft Defender.

Sender Policy Framework (SPF) to metoda uwierzytelniania poczty e-mail , która pomaga zweryfikować pocztę wysłaną z organizacji platformy Microsoft 365, aby zapobiec fałszowaniu nadawców używanych w przypadku naruszenia zabezpieczeń poczty e-mail (BEC), oprogramowania wymuszającego okup i innych ataków wyłudzania informacji.

Podstawowym celem SPF jest zweryfikowanie źródeł wiadomości e-mail dla domeny. W szczególności SPF używa rekordu TXT w systemie DNS do identyfikowania prawidłowych źródeł poczty dla domeny. Systemy odbierające wiadomości e-mail używają rekordu SPF TXT, aby sprawdzić, czy wiadomość e-mail z adresu nadawcy używanego podczas transmisji wiadomości SMTP (znana jako adres, adres, 5321.MailFrom adres, nadawca P1 lub nadawca koperty) pochodzi ze znanego, wyznaczonego źródła poczty dla tej domeny.

Jeśli na przykład domena poczty e-mail w usłudze Microsoft 365 jest contoso.com, utworzysz rekord SPF TXT w systemie DNS dla domeny contoso.com, aby zidentyfikować usługę Microsoft 365 jako autoryzowane źródło poczty z contoso.com. Docelowe systemy poczty e-mail sprawdzają rekord SPF TXT w contoso.com, aby ustalić, czy wiadomość pochodzi z autoryzowanego źródła contoso.com wiadomości e-mail.

Zanim zaczniemy, oto, co musisz wiedzieć o platformie SPF na platformie Microsoft 365 w oparciu o domenę poczty e-mail:

  • Jeśli używasz tylko domeny microsoft online Email routingu (MOERA) dla poczty e-mail (na przykład contoso.onmicrosoft.com): Nie musisz nic robić. Rekord SPF TXT jest już skonfigurowany. Firma Microsoft jest właścicielem domeny onmicrosoft.com, dlatego jesteśmy odpowiedzialni za tworzenie i utrzymywanie rekordów DNS w tej domenie i poddomenach. Aby uzyskać więcej informacji na temat domen *.onmicrosoft.com, zobacz Dlaczego mam domenę "onmicrosoft.com"?

  • Jeśli używasz co najmniej jednej domeny niestandardowej do obsługi poczty e-mail (na przykład contoso.com): proces rejestracji platformy Microsoft 365 wymagał już utworzenia lub zmodyfikowania rekordu SPF TXT w systemie DNS dla domeny niestandardowej w celu zidentyfikowania platformy Microsoft 365 jako autoryzowanego źródła poczty e-mail. Jednak nadal masz więcej pracy do wykonania w celu zapewnienia maksymalnej ochrony poczty e-mail:

    • Zagadnienia dotyczące domeny podrzędnej:

      • W przypadku usług poczty e-mail, które nie są pod bezpośrednią kontrolą (na przykład zbiorczych usług poczty e-mail), zalecamy użycie poddomeny (na przykład marketing.contoso.com) zamiast głównej domeny poczty e-mail (na przykład contoso.com). Nie chcesz, aby problemy z pocztą wysłaną z tych usług poczty e-mail miały wpływ na reputację poczty wysyłanej przez pracowników w głównej domenie poczty e-mail. Aby uzyskać więcej informacji na temat dodawania domen podrzędnych, zobacz Czy mogę dodać niestandardowe domeny podrzędne lub wiele domen do platformy Microsoft 365?

      • Każda poddomena używana do wysyłania wiadomości e-mail z platformy Microsoft 365 wymaga własnego rekordu SPF TXT. Na przykład rekord SPF TXT dla contoso.com nie obejmuje marketing.contoso.com; marketing.contoso.com potrzebuje własnego rekordu SPF TXT.

        Porada

        Email ochrona uwierzytelniania dla niezdefiniowanych domen podrzędnych jest objęta usługą DMARC. Wszystkie poddomeny (zdefiniowane lub nie) dziedziczą ustawienia DMARC domeny nadrzędnej (które można zastąpić na poddomenę). Aby uzyskać więcej informacji, zobacz Konfigurowanie usługi DMARC w celu zweryfikowania domeny Z adresu dla nadawców w usłudze Microsoft 365.

    • Jeśli jesteś właścicielem zarejestrowanych, ale nieużywanych domen: jeśli jesteś właścicielem zarejestrowanych domen, które nie są używane do obsługi poczty e-mail lub w ogóle (znanych również jako domeny zaparkowane), skonfiguruj rekordy SPF TXT, aby wskazać, że żadna wiadomość e-mail nie powinna nigdy pochodzić z tych domen zgodnie z opisem w dalszej części tego artykułu.

  • Sam SPF to za mało. Aby uzyskać najlepszy poziom ochrony poczty e-mail dla domen niestandardowych, należy również skonfigurować usługi DKIM i DMARC w ramach ogólnej strategii uwierzytelniania poczty e-mail . Aby uzyskać więcej informacji, zobacz sekcję Następne kroki na końcu tego artykułu.

    Ważna

    W złożonych organizacjach, w których trudno jest zidentyfikować wszystkie prawidłowe źródła poczty dla domeny, ważne jest, aby szybko skonfigurować podpisywanie DKIM i DMARC (w trybie "nie podejmij żadnej akcji" dla domeny). Usługa raportowania DMARC jest bardzo przydatna do identyfikowania źródeł wiadomości e-mail i błędów SPF dla domeny.

W pozostałej części tego artykułu opisano rekordy TXT SPF, które należy utworzyć dla domen niestandardowych na platformie Microsoft 365.

Porada

W usłudze Microsoft 365 nie ma portali administracyjnych ani poleceń cmdlet programu PowerShell do zarządzania rekordami SPF w domenie. Zamiast tego należy utworzyć rekord SPF TXT u rejestratora domen lub usługi hostingu DNS (często tej samej firmy).

Udostępniamy instrukcje dotyczące tworzenia dowodu posiadania domeny rekordu TXT dla platformy Microsoft 365 u wielu rejestratorów domen. Możesz użyć tych instrukcji jako punktu początkowego, aby utworzyć wartość rekordu SPF TXT. Aby uzyskać więcej informacji, zobacz Dodawanie rekordów DNS w celu nawiązania połączenia z domeną.

Jeśli nie znasz konfiguracji DNS, skontaktuj się z rejestratorem domen i poproś o pomoc.

Składnia rekordów SPF TXT

Rekordy SPF TXT są wyczerpująco opisane w dokumencie RFC 7208.

Podstawowa składnia rekordu SPF TX dla domeny niestandardowej w usłudze Microsoft 365 to:

v=spf1 <valid mail sources> <enforcement rule>

Lub:

v=spf1 [<ip4>|<ip6>:<PublicIPAddress1> <ip4>|<ip6>:<PublicIPAddress2>... <ip4>|<ip6>:<PublicIPAddressN>] [include:<DomainName1> include:<DomainName1>... include:<DomainNameN>] <-all | ~all>

Przykład:

v=spf1 ip4:192.168.0.10 ip4:192.168.0.12 include:spf.protection.outlook.com -all

  • v=spf1 identyfikuje rekord TXT jako rekord SPF TXT.

  • Prawidłowe źródła poczty: określono prawidłowe źródła poczty dla domeny. Używa domen, adresów IP lub obu tych domen:

    • Domeny: include: wartości określają inne usługi lub domeny jako prawidłowe źródła poczty z oryginalnej domeny. Te wartości ostatecznie prowadzą do adresu IP przy użyciu wyszukiwań DNS.

      Większość organizacji platformy Microsoft 365 wymaga include:spf.protection.outlook.com w rekordzie SPF TXT domeny. Inne usługi poczty e-mail innych firm często wymagają dodatkowej include: wartości, aby zidentyfikować usługę jako prawidłowe źródło wiadomości e-mail z oryginalnej domeny.

    • Adresy IP: Wartość adresu IP obejmuje oba następujące elementy:

      • Wartość ip4: lub ip6: do identyfikowania typu adresu IP.
      • Publicznie rozpoznawalny adres IP źródłowego systemu poczty e-mail. Przykład:
        • Indywidualny adres IP (na przykład 192.168.0.10).
        • Zakres adresów IP przy użyciu notacji CIDR (Classless Inter-Domain Routing) (na przykład 192.168.0.1/26). Upewnij się, że zakres nie jest zbyt duży ani zbyt mały.

      W usłudze Microsoft 365 zwykle używasz adresów IP w rekordzie SPF TXT tylko wtedy, gdy masz lokalne serwery poczty e-mail, które wysyłają wiadomości e-mail z domeny platformy Microsoft 365 (na przykład Exchange Server wdrożenia hybrydowe). Niektóre usługi poczty e-mail innych firm mogą również używać zakresu adresów include: IP zamiast wartości w rekordzie SPF TXT.

  • Reguła wymuszania: informuje docelowe systemy poczty e-mail, co zrobić z komunikatami ze źródeł, które nie są określone w rekordzie SPF TXT dla domeny. Prawidłowe wartości to:

    • -all (trudne niepowodzenie): źródła niewymienione w rekordzie SPF TXT nie są autoryzowane do wysyłania wiadomości e-mail do domeny, więc wiadomości powinny zostać odrzucone. To, co faktycznie dzieje się z wiadomością, zależy od docelowego systemu poczty e-mail, ale wiadomości są zwykle odrzucane.

      W przypadku domen platformy Microsoft 365 zalecamy -all (trudne niepowodzenie), ponieważ zalecamy również DKIM i DMARC dla domeny. Zasady DMARC określają, co zrobić z komunikatami, które nie działają WSPF lub DKIM, a raporty DMARC umożliwiają weryfikowanie wyników.

      Porada

      Jak wspomniano wcześniej, narzędzie DMARC skonfigurowane za pomocą usługi raportowania DMARC pomaga w bardzo identyfikowaniu źródeł wiadomości e-mail i błędów SPF dla domeny.

    • ~all (niepowodzenie nietrwałe): źródła niewymienione w rekordzie SPF TXT prawdopodobnie nie są autoryzowane do wysyłania wiadomości e-mail dla domeny, więc wiadomości powinny być akceptowane, ale oznaczone. To, co faktycznie dzieje się z komunikatem, zależy od docelowego systemu poczty e-mail. Na przykład wiadomość może zostać poddana kwarantannie jako spam, dostarczona do folderu Junk Email lub dostarczona do skrzynki odbiorczej z identyfikatorem dodanym do treści tematu lub wiadomości.

      Ponieważ zalecamy również DKIM i DMARC dla domen platformy Microsoft 365, różnice między -all (niepowodzeniem twardym) i ~all (niepowodzeniem nietrwałym) są skutecznie eliminowane (DMARC traktuje oba wyniki jako awarię SPF). Usługa DMARC używa SPF do potwierdzenia, że domeny w adresach MAIL FROM i From są wyrównane , a wiadomość pochodzi z prawidłowego źródła dla domeny From.

    Porada

    ?all (neutralny) jest również dostępny do sugerowania żadnych konkretnych działań dotyczących komunikatów z niezidentyfikowanych źródeł. Ta wartość jest używana do testowania i nie zalecamy tej wartości w środowiskach produkcyjnych.

Ważne kwestie do zapamiętania:

  • Każda zdefiniowana domena lub poddomena w systemie DNS wymaga rekordu SPF TXT, a tylko jeden rekord SPF jest dozwolony dla domeny lub poddomeny. Email ochrona uwierzytelniania dla niezdefiniowanych domen podrzędnych jest najlepiej obsługiwana przez usługę DMARC.
  • Nie można zmodyfikować istniejącego rekordu SPF TXT dla domeny *.onmicrosoft.com.
  • Gdy docelowy system poczty e-mail sprawdza prawidłowe źródła poczty e-mail w rekordzie SPF, sprawdzanie poprawności SPF kończy się niepowodzeniem, jeśli sprawdzanie wymaga zbyt wielu wyszukiwań DNS. Aby uzyskać więcej informacji, zobacz sekcję Rozwiązywanie problemów z rekordami TXT SPF w dalszej części tego artykułu.

Rekordy TXT SPF dla domen niestandardowych na platformie Microsoft 365

Porada

Jak wspomniano wcześniej w tym artykule, należy utworzyć rekord SPF TXT dla domeny lub domeny podrzędnej u rejestratora domeny dla domeny. Konfiguracja rekordu SPF TXT nie jest dostępna na platformie Microsoft 365.

  • Scenariusz: używasz contoso.com na potrzeby poczty e-mail na platformie Microsoft 365, a platforma Microsoft 365 jest jedynym źródłem wiadomości e-mail z contoso.com.

    Rekord TXT SPF dla contoso.com na platformach Microsoft 365 i Microsoft 365 Government Community Cloud (GCC):

    v=spf1 include:spf.protection.outlook.com -all

    Rekord SPF TXT dla contoso.com w usłudze Microsoft 365 Government Community Cloud High (GCC High) i Microsoft 365 Department of Defense (DoD):

    v=spf1 include:spf.protection.office365.us -all

    Rekord SPF TXT dla contoso.com na platformie Microsoft 365 obsługiwany przez firmę 21Vianet

    v=spf1 include:spf.protection.partner.outlook.cn -all

  • Scenariusz: używasz contoso.com na potrzeby poczty e-mail w usłudze Microsoft 365 i już skonfigurowano rekord SPF TXT w contoso.com ze wszystkimi źródłami wiadomości e-mail z domeny. Masz również domeny contoso.net i contoso.org, ale nie używasz ich do obsługi poczty e-mail. Chcesz określić, że nikt nie ma autoryzacji do wysyłania wiadomości e-mail z contoso.net lub contoso.org.

    Rekord TXT SPF dla contoso.net:

    v=spf1 -all

    Rekord TXT SPF dla contoso.org:

    v=spf1 -all

  • Scenariusz: używasz contoso.com na potrzeby poczty e-mail na platformie Microsoft 365. Planujesz wysyłanie wiadomości e-mail z następujących źródeł:

    • Lokalny serwer poczty e-mail z zewnętrznym adresem e-mail 192.168.0.10. Ponieważ masz bezpośrednią kontrolę nad tym źródłem wiadomości e-mail, uważamy, że użycie serwera dla nadawców w domenie contoso.com jest prawidłowe.
    • Usługa poczty zbiorczej Adatum. Ponieważ nie masz bezpośredniej kontroli nad tym źródłem wiadomości e-mail, zalecamy użycie poddomeny, dlatego należy utworzyć marketing.contoso.com w tym celu. Zgodnie z dokumentacją usługi Adatum należy dodać include:servers.adatum.com rekord SPF TXT dla domeny.

    Rekord TXT SPF dla contoso.com:

    v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all

    Rekord TXT SPF dla marketing.contoso.com:

    v=spf1 include:servers.adatum.com include:spf.protection.outlook.com -all

Rozwiązywanie problemów z rekordami SPF TXT

  • Jeden rekord SPF na domenę lub poddomenę: wiele rekordów SPF TXT dla tej samej domeny lub poddomeny powoduje pętlę wyszukiwania DNS powodującą niepowodzenie SPF, więc użyj tylko jednego rekordu SPF na domenę lub poddomenę.

  • Mniej niż 10 odnośników DNS: gdy docelowe systemy poczty e-mail wysyłają zapytanie do rekordu SPF TXT dla prawidłowych źródeł dla domeny adresu MAIL FROM, zapytanie skanuje adresy IP i include: instrukcje w rekordzie, aż źródło wiadomości (ostatecznie adres IP) dopasowuje jedno z określonych źródeł. Jeśli liczba wyszukiwań DNS (które mogą być inne niż liczba zapytań DNS) jest większa niż 10, komunikat kończy się niepowodzeniem SPF z trwałym błędem (znanym również jako permerror). Docelowy system poczty e-mail odrzuca wiadomość w raporcie o braku dostarczania (znanym również jako komunikat NDR lub bounce) z jednym z następujących błędów:

    • Komunikat przekroczył liczbę przeskoku.
    • Komunikat wymagał zbyt wielu odnośników.

    W rekordzie SPF TXT poszczególne adresy IP lub zakresy adresów IP nie powodują wyszukiwania DNS. Każda include: instrukcja wymaga co najmniej jednego wyszukiwania DNS, a jeśli wartość wskazuje zasoby zagnieżdżone, może być wymaganych include: więcej odnośników. Innymi słowy, posiadanie mniej niż 10 include: instrukcji nie gwarantuje mniej niż 10 wyszukiwań DNS.

    Należy również pamiętać, że docelowe systemy poczty e-mail oceniają źródła w rekordzie SPF TXT od lewej do prawej. Ocena zostaje zatrzymana po zweryfikowaniu źródła komunikatów i nie są sprawdzane żadne więcej źródeł. W związku z tym rekord SPF TXT może zawierać wystarczająco dużo informacji, aby spowodować więcej niż 10 wyszukiwań DNS, ale walidacja niektórych źródeł poczty przez niektóre miejsca docelowe nie przechodzi wystarczająco głęboko w rekordzie, aby spowodować błąd.

    Oprócz zachowania reputacji głównej domeny poczty e-mail, nie przekroczenie liczby wyszukiwań DNS jest kolejnym powodem, aby używać poddomen dla innych usług poczty e-mail, które nie są kontrolować.

Możesz użyć bezpłatnych narzędzi online, aby wyświetlić rekord SPF TXT i inne rekordy DNS dla twojej domeny. Niektóre narzędzia obliczają nawet liczbę wyszukiwań rekordów DNS wymaganych przez rekord SPF TXT.

Następne kroki

Jak opisano w artykule Jak SPF, DKIM i DMARC współpracują ze sobą w celu uwierzytelniania nadawców wiadomości e-mail, sam SPF nie wystarczy, aby zapobiec fałszowaniu domeny platformy Microsoft 365. Należy również skonfigurować DKIM i DMARC w celu zapewnienia najlepszej możliwej ochrony. Aby uzyskać instrukcje, zobacz:

W przypadku poczty przychodzącej na platformę Microsoft 365 może być również konieczne skonfigurowanie zaufanych uszczelniaczy ARC, jeśli używasz usług modyfikujących wiadomości przesyłane przed dostarczeniem do organizacji. Aby uzyskać więcej informacji, zobacz Konfigurowanie zaufanych uszczelniaczy ARC.