DMARC dla Office 365: Konfiguracja krok po kroku i najlepsze praktyki

Firma Microsoft wspiera i zachęca użytkowników usługi Microsoft 365 (zwanej również Office 365 lub M365) do wdrażania protokołu DMARC, co pozwala im na jednolite stosowanie protokołów uwierzytelniania poczty elektronicznej we wszystkich zarejestrowanych domenach. W tym wpisie na blogu wyjaśniamy, jak skonfigurować protokół DMARC dla usługi Office 365 w celu weryfikacji wszystkich wiadomości e-mail z usługi Office 365, które:

• Routing adresów e-mail online z Microsoft
• Domeny niestandardowe dodane w centrum administracyjnym
• Zaparkowane lub nieaktywne, ale zarejestrowane domeny

Czym jest DMARC i dlaczego ma znaczenie dla usługi Microsoft 365

DMARC to protokół uwierzytelniania wiadomości e-mail, który chroni domeny przed spoofingiem i phishingiem. (Domain-based Message Authentication, Reporting, and Conformance) działa w oparciu o protokoły SPF i DKIM, dostosowując wyniki uwierzytelniania do zasad obowiązujących w domenie oraz informując serwery odbiorcze, jak postępować z wiadomościami, które nie przeszły tych kontroli.

W środowisku Microsoft 365 protokół DMARC pełni podwójną rolę. Chroni on Twoją domenę przed podszywaniem się pod nią przez atakujących, a także pomaga zapewnić, że Twoje autentyczne wiadomości e-mail będą traktowane jako wiarygodne przez odbiorców zewnętrznych.

Czy usługa Microsoft 365 obsługuje protokół DMARC za Ciebie?

Jednym z najczęstszych błędnych przekonań wśród administratorów jest to, że usługa Microsoft 365 sama zajmuje się obsługą protokołu DMARC.

Usługa Microsoft 365 przeprowadza weryfikację DMARC, ale dotyczy to wyłącznie wiadomości przychodzących. Usługa Exchange Online Protection (EOP) automatycznie sprawdza poprawność rekordów SPF, DKIM i DMARC w wiadomościach otrzymywanych przez organizację. Oznacza to, że użytkownicy są w pewnym stopniu chronieni przed fałszywymi wiadomościami e-mail.

Jednak w przypadku wiadomości wychodzących firma Microsoft nie podejmuje żadnych działań, dopóki użytkownik sam tego nie skonfiguruje. Jeśli chcesz zabezpieczyć swoją domenę i spełnić aktualne wymogi dotyczące zgodności, musisz opublikować rekord DMARC w swoim systemie DNS.

To rozróżnienie ma kluczowe znaczenie. Microsoft chroni Twoją skrzynkę odbiorczą, ale to DMARC chroni reputację Twojej domeny, dlatego Microsoft 365 wymaga wdrożenia DMARC nawet przy aktywnej usłudze EOP. Konfiguracja, którą zamierzasz wdrożyć, dotyczy ochrony wiadomości wychodzących.

Wymagania wstępne: Skonfiguruj protokoły SPF i DKIM dla usługi Microsoft 365

Przed opublikowaniem rekordu DMARC należy upewnić się, że protokoły SPF i DKIM są prawidłowo skonfigurowane dla danej domeny. DMARC sam w sobie nie uwierzytelnia wiadomości e-mail – opiera się wyłącznie na wynikach protokołów SPF i/lub DKIM. Jeśli protokoły te nie są skonfigurowane lub nie są ze sobą zsynchronizowane, DMARC nie będzie działać prawidłowo, co może mieć negatywny wpływ na legalne wiadomości e-mail po włączeniu egzekwowania.

Krok 1: Skonfiguruj SPF dla usługi Microsoft 365

Protokół SPF (Sender Policy Framework) określa, które serwery pocztowe są uprawnione do wysyłania wiadomości e-mail w imieniu Twojej domeny. W przypadku usługi Microsoft 365 są to zazwyczaj serwery pocztowe firmy Microsoft oraz wszelkie usługi innych dostawców, z których korzystasz.

Ręczna konfiguracja SPF (metoda DNS)

Aby ręcznie skonfigurować SPF:

1. Wejdź na stronę swojego dostawcy usług hostingowych DNS (np. GoDaddy, Cloudflare itp.)
2. Utwórz lub zaktualizuj rekord TXT dla swojej domeny głównej

Użyj następującego standardowego rekordu SPF dla usługi Microsoft 365:

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

Jeśli korzystasz z dodatkowych usług (takich jak Mailchimp lub Salesforce), musisz je również uwzględnić. Na przykład:

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

Automatyczna konfiguracja SPF (z wykorzystaniem PowerDMARC)

Ręczne tworzenie rekordów SPF może być skomplikowane, zwłaszcza gdy w grę wchodzi wiele usług. Często zdarzają się błędy, takie jak przekroczenie limitów wyszukiwania DNS lub nieprawidłowe konfiguracje.

Korzystanie z narzędzi SPF firmy PowerDMARC ułatwia ten proces. Generator SPF automatycznie tworzy poprawny rekord na podstawie Twoich źródeł wysyłania.

Krok 2: Włącz DKIM dla usługi Microsoft 365

DKIM (DomainKeys Identified Mail) dodaje podpis kryptograficzny do Twoich wiadomości e-mail. Dzięki temu serwery odbiorcze mogą sprawdzić, czy treść wiadomości nie została zmieniona i czy rzeczywiście pochodzi ona z Twojej domeny.

W przeciwieństwie do SPF, funkcja DKIM w usłudze Microsoft 365 wymaga zarówno konfiguracji DNS, jak i aktywacji w Centrum administracyjnym.

Ręczna konfiguracja DKIM (DNS + Centrum administracyjne)

Aby ręcznie włączyć DKIM:

1. Przejdź do portalu Microsoft 365 Defender
2. Przejdź do sekcji „Poczta e-mail i współpraca” → „Zasady i reguły” → „Zasady dotyczące zagrożeń” → „DKIM”
3. Wybierz swoją domenę

Źródło obrazu

Zanim będzie można włączyć DKIM, firma Microsoft poprosi o dodanie dwóch rekordów CNAME do serwera DNS.

Zazwyczaj wyglądają one następująco:

selector1._domainkey.twojadomena.com → selector1-twojadomena.com._domainkey.twojadomena.onmicrosoft.com

selector2._domainkey.twojadomena.com → selector2-twojadomena-com._domainkey.twojadomena.onmicrosoft.com

Po opublikowaniu tych rekordów wróć do panelu administracyjnego i kliknij opcję „Włącz” dla DKIM. Po aktywacji Microsoft zacznie podpisywać wszystkie wychodzące wiadomości e-mail za pomocą DKIM.

Automatyczna konfiguracja DKIM (z wykorzystaniem PowerDMARC)

Konfiguracja DKIM może budzić wątpliwości, zwłaszcza wśród administratorów, którzy nie znają się na rekordach CNAME i formatach selektorów.

PowerDMARC ułatwia ten proces, automatycznie generując odpowiednie rekordy DKIM dla Twojej domeny, oferując funkcję automatycznej publikacji w DNS, która pozwala uniknąć błędów wynikających z ręcznego wprowadzania danych, oraz udostępniając narzędzie do sprawdzania DKIM, które pozwala upewnić się, że DKIM jest prawidłowo włączony

Jak skonfigurować DMARC w usłudze Office 365?

Po prawidłowym skonfigurowaniu protokołów SPF i DKIM można przejść do konfiguracji DMARC. W usłudze Microsoft 365 proces ten odbywa się na poziomie DNS, ale jego prawidłowe przeprowadzenie wymaga zrozumienia ekosystemu poczty elektronicznej, wyboru odpowiedniej polityki oraz monitorowania wyników przed jej wdrożeniem.

Krok 1: Zidentyfikuj wszystkie źródła wysyłania wiadomości e-mail

Przed opublikowaniem rekordu DMARC należy uzyskać pełny obraz tego, kto wysyła wiadomości e-mail w imieniu Twojej domeny. Jest to jeden z najważniejszych kroków, ponieważ pominięcie legalnego nadawcy może spowodować późniejsze problemy z dostarczaniem wiadomości.

Do typowych źródeł wysyłania należą:

• Microsoft 365 (Exchange Online)
• Platformy marketingowe (Mailchimp, HubSpot itp.)
• Systemy CRM (Salesforce)
• Narzędzia do obsługi klienta (Zendesk, Freshdesk)
• Aplikacje wewnętrzne lub serwery

Jeśli którekolwiek z nich nie zostaną prawidłowo uwierzytelnione za pomocą SPF lub DKIM, nie przejdą testu DMARC po włączeniu egzekwowania.

Krok 2: Utwórz rekord DMARC

Rekord DMARC to rekord TXT opublikowany w Twojej strefie DNS. Określa on Twoje zasady i informuje serwery odbiorcze, jak postępować z wiadomościami e-mail, które nie przeszły uwierzytelnienia. Możesz utworzyć unikalny rekord DMARC dla Office 365 dla swojej domeny, korzystając z narzędzia PowerDMARC do błyskawicznego generowania rekordów DMARC.

Podstawowy rekord DMARC wygląda następująco: v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Przeanalizujmy to:

v=DMARC1 – Określa wersję DMARC
p=none – Tryb monitorowania (bez egzekwowania)
rua=mailto:[email protected] – Adres, na który wysyłane są raporty zbiorcze
fo=1 – Włącza raportowanie błędów

Jest to zalecany punkt wyjścia, ponieważ pozwala na gromadzenie danych bez wpływu na dostarczanie wiadomości e-mail.

Krok 3: Opublikuj rekord DMARC w systemie DNS

Gdy rekord będzie gotowy, należy dodać go do serwera DNS.

Użyj następujących ustawień:

Typ rekordu: TXT
Host/Nazwa: _dmarc
Wartość: Twój rekord DMARC
TTL: 1 godzina (lub wartość domyślna)

Krok 4: Monitorowanie raportów DMARC

Po włączeniu protokołu DMARC z polityką p=none zaczniesz otrzymywać raporty od serwerów odbierających. Raporty te pozwalają sprawdzić, kto wysyła wiadomości e-mail przy użyciu Twojej domeny, które wiadomości przeszły lub nie przeszły uwierzytelnianie, a także podają status zgodności dla SPF i DKIM.

Raporty DMARC są zazwyczaj wysyłane w formacie XML i mogą być trudne do zinterpretowania ręcznie. Bez odpowiedniej analizy łatwo przeoczyć błędy w konfiguracji lub nieautoryzowanych nadawców.

Krok 5: Stopniowe przechodzenie do egzekwowania przepisów

Po przejrzeniu raportów i upewnieniu się, że wszyscy wiarygodni nadawcy są prawidłowo uwierzytelnieni, możesz zacząć zaostrzać zasady DMARC.

Typowy przebieg wygląda następująco:

Zacznij od monitorowania: v=DMARC1; p=none; rua=mailto:[email protected]

↓

Przenieś do kwarantanny (podejrzane wiadomości e-mail trafiają do folderu spam): v=DMARC1; p=quarantine; rua=mailto:[email protected];

↓

Na koniec ustaw opcję odrzucania: v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

Krok 6: Skonfiguruj DMARC dla różnych typów domen

Sposób postępowania może się różnić w zależności od konfigurowanej domeny.

Krok 7: Sprawdź poprawność konfiguracji DMARC w usłudze Microsoft 365 i dbaj o jej utrzymanie

Konfiguracja DMARC nie jest działaniem jednorazowym. Wraz ze zmianami w ekosystemie poczty elektronicznej konieczne jest dostosowywanie konfiguracji. Nawet po osiągnięciu poziomu p=reject niezbędne jest ciągłe monitorowanie, aby zapewnić dostarczalność i bezpieczeństwo.

Powinieneś regularnie:

• Przejrzyj raporty DMARC
• Zaktualizuj rekord SPF przy dodawaniu nowych nadawców
• Upewnij się, że DKIM pozostaje włączony i poprawnie skonfigurowany
• Monitoruj nieautoryzowaną aktywność

Wdrażanie polityki DMARC: dlaczego stopniowe egzekwowanie ma znaczenie

Jednym z najczęstszych błędów popełnianych podczas wdrażania protokołu DMARC jest bezpośrednie przejście na politykę odrzucania wiadomości. Bez wglądu w przepływ wiadomości e-mail egzekwowanie tej polityki może zakłócić prawidłową komunikację.

Wdrażanie etapowe pozwala monitorować i korygować problemy przed wprowadzeniem rygorystycznych zasad. Większość organizacji stosuje podejście polegające na przejściu od monitorowania przez kwarantannę aż po ostateczne odrzucenie. Czas trwania każdego etapu zależy od złożoności środowiska poczty elektronicznej, jednak pomijanie poszczególnych etapów zwiększa ryzyko niezamierzonych błędów w dostarczaniu wiadomości.

Jak usługa Exchange Online obsługuje przychodzące wiadomości DMARC

Usługa Exchange Online Protection automatycznie weryfikuje zgodność z protokołem DMARC wszystkich przychodzących wiadomości, a od lipca 2023 r. firma Microsoft domyślnie stosuje się do opublikowanych zasad nadawcy. Gdy rekord MX domeny odbiorcy wskazuje bezpośrednio na usługę Microsoft 365, wiadomości niezgodne z protokołem DMARC w ramach zasad p=reject są odrzucane na poziomie bramy. Podobnie wiadomości, które nie spełniają wymagań p=quarantine, są wysyłane do kwarantanny. Kontroluje to ustawienie„Honoruj zasady rekordu DMARC, gdy wiadomość zostanie wykryta jako sfałszowana”w zasadach antyphishingowych, które jest domyślnie włączone.

Źródło obrazu

Wyjaśnienie działania funkcji „oreject”

Przed lipcem 2023 r. firma Microsoft stosowała wewnętrzne obejście o nazwie action=oreject (odrzucenie źródłowe) w przypadku wiadomości przychodzących, które nie spełniały wymogów polityki p=reject nadawcy. Zamiast odrzucać wiadomość bezpośrednio na bramce, usługa EOP przekierowywała ją do folderu wiadomości-śmieci odbiorcy i dodawała do nagłówka oznaczenie oreject.

Firma Microsoft postąpiła tak celowo, ponieważ wiadomości przekazywane dalej oraz ruch na listach mailingowych często naruszają reguły SPF i DKIM podczas przesyłania. Oznacza to, że legalna wiadomość, która przeszła uwierzytelnienie u pierwotnego nadawcy, może nie przejść go w momencie, gdy trafi do kolejnego odbiorcy. Twarde odrzucenie przy ustawieniu p=reject spowodowałoby odrzucenie znacznej ilości legalnych wiadomości wraz z tymi sfałszowanymi. Folder ze spamem stanowił kompromisowe rozwiązanie: odbiorcy mogli w razie potrzeby odzyskać wiadomość, a zasady nadawcy były technicznie przestrzegane.

Problem polegał na tym, że sfałszowane wiadomości, które powinny były zostać odrzucone, nadal trafiały do skrzynek odbiorczych użytkowników (do folderu ze spamem), gdzie rozkojarzony odbiorca mógł je otworzyć. Dla zespołów ds. bezpieczeństwa oznaczało to, że egzekwowanie zasad DMARC nigdy nie wydawało się tak rygorystyczne, jak sugerowała polityka.

Kiedy dzisiaj nadal zobaczysz „oreject”

Ponieważ domyślne ustawienie uległo zmianie: EOP traktuje teraz p=reject jako rzeczywiste odrzucenie w przypadku przepływów bezpośrednich MX. Jednak poprzednie zachowanie nie zniknęło całkowicie. Nadal można spotkać się z oreject w trzech sytuacjach:

1. W Twojej polityce antyphishingowej opcja „Honor DMARC” jest wyłączona.

Aby rozwiązać ten problem: sprawdź ustawienia w sekcji Microsoft 365 Defender → Poczta e-mail i współpraca → Zasady dotyczące zagrożeń → Ochrona przed phishingiem → Ustawienia dotyczące fałszowania adresów. Przełącznik jest domyślnie włączony, ale w przypadku dzierżawców, którzy przeprowadzili migrację ze starszych konfiguracji, może być wyłączony.

2. Poczta przechodzi przez bramę zewnętrzną, zanim dotrze do usługi Microsoft 365.

Jeśli serwer MX kieruje wiadomości do urządzenia zabezpieczającego (np. Proofpoint, Mimecast itp.), które następnie przekazuje je do usługi EOP, firma Microsoft nie będzie mogła ponownie ocenić zgodności z protokołem DMARC, chyba że w portalu Defender włączysz opcję „Rozszerzone filtrowanie dla łączników”. Bez tej opcji usługa EOP uznaje werdykt bramy źródłowej za miarodajny i domyślnie odrzuca wiadomości, które nie spełniają wymogów.

3. Reguła zezwalająca na poziomie najemcy omija filtrowanie.

Wiadomości od nadawców z listy dozwolonych, zaufanych łączników przychodzących lub reguł transportowych, którym przypisano poziom pewności spamu (SCL -1), całkowicie omijają mechanizm egzekwowania DMARC i trafiają do skrzynki odbiorczej niezależnie od zasad.

Aby zapewnić bardziej rygorystyczne podejście, włącz funkcję Spoof Intelligence w portalu Defender obok opcji „Honor DMARC”. Funkcja Spoof Intelligence ocenia reputację nadawcy niezależnie od DMARC i umieszcza w kwarantannie wiadomości, które wyglądają na próby podszywania się, nawet jeśli uwierzytelnienie przebiegło pomyślnie.

Zaostrzenie kontroli przywozu poprzez przepisy transportowe

Dla organizacji, które chcą mieć pewność, że wiadomości niezgodne z DMARC zostaną odrzucone, reguła transportowa w usłudze Exchange Online stanowi najbardziej niezawodny mechanizm.

Jak utworzyć regułę:

1. Przejdź do Centrum administracyjnego Exchange → Przepływ poczty → Reguły i utwórz nową regułę.
2. Ustaw warunek: Nagłówek wiadomości zawiera którekolwiek z tych słów. Nazwa nagłówka: Authentication-Results. Wartość nagłówka: dmarc=fail action=oreject.
3. Ustaw działanie: Odrzuć wiadomość wraz z wyjaśnieniem — wpisz np. „Wiadomość nie przeszła uwierzytelnienia DMARC i została odrzucona zgodnie z polityką organizacji”.
4. (Opcjonalnie) Dodaj wyjątek dla zaufanych nadawców wewnętrznych lub znanych, legalnych podmiotów przekazujących wiadomości, aby zapobiec fałszywym alarmom.
5. W pierwszym tygodniu ustaw tryb reguły na „Test z podpowiedziami dotyczącymi zasad”. Przed przełączeniem na tryb „Egzekwuj” przejrzyj komunikaty, które zostały dopasowane, w historii komunikatów.

Więcej informacji można znaleźć w obszernej dokumentacji firmy Microsoft dotyczącej reguł przepływu poczty.

Kiedy stosować to podejście:

Zasady transportu mają sens, gdy przepisy prawne lub wewnętrzne wytyczne wymagają faktycznego odrzucania nieprawidłowej poczty, gdy Twoja organizacja stanowi atrakcyjny cel ataków typu spoofing (komunikacja finansowa, prawna lub na szczeblu kierowniczym) lub gdy zależy Ci na spójnym działaniu zarówno w przypadku bezpośredniego serwera MX, jak i przepływów przez bramki zewnętrzne.

Wprowadzenie przez Microsoft standardu DMARC w maju 2025 r.: co się zmieniło

W maju 2025 roku firma Microsoft wprowadziła istotną zmianę w sposobie obsługi nieautoryzowanych wiadomości e-mail od zewnętrznych nadawców. Zmiana ta dotyczy przede wszystkim nadawców wysyłających duże ilości wiadomości, ale ma szersze konsekwencje dla wszystkich organizacji.

W ujęciu ogólnym wymagania firmy Microsoft dotyczące nadawców wiadomości e-mail wpisują się w szerszy trend branżowy zmierzający w kierunku bardziej rygorystycznego uwierzytelniania i zwiększenia odpowiedzialności nadawców. Aktualizacja wprowadza jasno określone progi, środki egzekucyjne oraz oczekiwania, które wcześniej były stosowane w sposób mniej rygorystyczny.

Najważniejsze zmiany wprowadzone przez firmę Microsoft

• Obowiązkowe stosowanie protokołu DMARC dla nadawców masowych: Domeny wysyłające ponad 5000 wiadomości e-mail dziennie do usług konsumenckich firmy Microsoft muszą teraz posiadać prawidłowy rekord DMARC.
• Dotyczy serwisów Outlook.com, Hotmail.com i Live.com: Środki te są skierowane konkretnie do ekosystemu skrzynek pocztowych Microsoftu przeznaczonych dla użytkowników indywidualnych, a nie tylko do klientów korporacyjnych.
• Minimalne wymaganie: DMARC z ustawieniem p=none: Dopuszczalne jest nawet stosowanie polityki monitorowania, ale brak rekordu DMARC nie jest już akceptowany w przypadku dużych wdrożeń.
• Większy nacisk na zgodność domen: Samo uwierzytelnienie nie wystarczy – aby DMARC zakończył się sukcesem, SPF i DKIM muszą być zgodne z widoczną domeną w polu „Od”.
• Odrzucenie z powodu niezgodności: wiadomości e-mail, które nie spełniają wymagań, mogą zostać zablokowane z komunikatem: 550 5.7.515 Odmowa dostępu, domena nadawcy [SendingDomain] nie spełnia wymaganego poziomu uwierzytelnienia.

Dzięki tej zmianie Microsoft dostosowuje się do praktyki stosowanej przez Google i Yahoo, które wprowadziły podobne wymagania w lutym 2024 r., co oznacza, że wszyscy trzej najwięksi dostawcy usług pocztowych wymagają obecnie uwierzytelniania od nadawców wysyłających wiadomości masowe.

Platformy takie jak PowerDMARC wypełniają tę lukę, oferując specjalne programy zapewniające zgodność z wymaganiami dostawców skrzynek pocztowych we wszystkich źródłach wysyłania wiadomości.

Dlaczego sam pakiet Microsoft 365 to za mało

Chociaż Microsoft 365 zapewnia skuteczną ochronę poczty przychodzącej, oferuje ograniczone możliwości zarządzania i monitorowania protokołu DMARC na dużą skalę – a takie możliwości zapewniają dedykowane platformy do uwierzytelniania poczty elektronicznej.

Brak raportów w formie zrozumiałej dla człowieka

Chociaż firma Microsoft wysyła obecnie raporty DMARC do użytkowników korporacyjnych, nie istnieje wbudowany system umożliwiający agregowanie i interpretowanie tych raportów w sposób przydatny. Raporty te są przesyłane w formacie XML i bez specjalistycznych narzędzi ich analiza może być trudna. W rezultacie organizacje często nie mają wglądu w to, kto wysyła wiadomości e-mail w ich imieniu i czy źródła te są prawidłowo uwierzytelnione.

Brak wytycznych dotyczących egzekwowania przepisów

Firma Microsoft nie udostępnia automatycznych wskazówek dotyczących przejścia od monitorowania do egzekwowania. W związku z tym administratorzy muszą samodzielnie interpretować dane i podejmować decyzje, które mogą mieć wpływ na dostarczanie wiadomości e-mail.

Nie nadaje się do bieżącego zarządzania

Specjalistyczne rozwiązanie DMARC przekształca surowe dane raportów w przydatne informacje. Umożliwia ono ciągłe monitorowanie, upraszcza zarządzanie zasadami i pomaga organizacjom bezpiecznie dążyć do pełnego wdrożenia tych zasad na skalę, której platforma Microsoft 365 nie zapewnia w ramach swoich standardowych funkcji.

Rozwiązywanie typowych problemów związanych z DMARC w usłudze Office 365

1. Nie opublikowano żadnego rekordu DMARC

To najczęstszy problem. Komunikat „Brak opublikowanego rekordu DMARC” oznacza po prostu, że w systemie DNS Twojej domeny brakuje rekordu TXT DMARC, więc odbiorcy nie mają żadnych wytycznych, na podstawie których mogliby podjąć odpowiednie działania.

Aby rozwiązać ten problem, najpierw

• Sprawdź to za pomocą narzędzia do sprawdzania zgodności z DMARC.
• Jeśli narzędzie wyświetli błąd „Brak rekordu DMARC”, należy opublikować rekord o następującej treści: v=DMARC1; p=none; rua=mailto:[email protected], aby umożliwić gromadzenie raportów przed zaostrzeniem zasad.
• Gdy już dobrze opanujesz konfigurację, możesz stopniowo przejść do wdrażania, monitorując jednocześnie swoje raporty.

2. Przekazywanie wiadomości powoduje naruszenie reguł SPF i DKIM

Przekierowywanie wiadomości e-mail stanowi największe źródło legalnych, ale odrzucanych wiadomości. Gdy pośrednik (lista mailingowa, usługa przekierowująca lub urządzenie zabezpieczające) modyfikuje nagłówek zawarty w podpisie DKIM, podpis nie przechodzi weryfikacji, a DKIM kończy się niepowodzeniem. Zazwyczaj w tym samym czasie zawodzi również SPF, ponieważ adres IP serwera przekierowującego nie figuruje w Twoim rekordzie.

Oto trzy sprawdzone sposoby na rozwiązanie tego problemu:

• Zaleca się stosowanie podpisywania zgodnego z DKIM już u nadawcy, ponieważ DKIM lepiej radzi sobie z przekazywaniem wiadomości niż SPF, gdy nagłówki nie są przepisywane
• Nie należy stosować schematu zmiany nadawcy (SRS) jako rozwiązania, ponieważ poprawia on wprawdzie rekord SPF, ale nie przywraca zgodności domeny „From”, przez co DMARC nadal zwraca błąd
• Skonfiguruj zaufane urządzenia pieczętujące ARC (Authenticated Received Chain) w usłudze Microsoft Defender dla każdej usługi przekazującej, która w uzasadniony sposób modyfikuje Twoją pocztę. Firma Microsoft uwzględni wynik uwierzytelnienia z wyższego poziomu łańcucha ARC, zamiast od razu odrzucać wiadomość.

3. Błąd SPF spowodowany zbyt dużą liczbą zapytań DNS

Jeśli wskaźnik SPF nagle przestaje działać dla wszystkich prawidłowych źródeł i zwraca błąd Permerror, przyczyna leży zazwyczaj w strukturze systemu, a nie w ustawieniach konfiguracyjnych.

Może to wynikać z dwóch prawdopodobnych przyczyn:

• Po pierwsze, przekroczyłeś limit 10 wyszukiwań, jaki SPF nakłada na mechanizmy include, a, mx, redirect, exists i ptr. Wyszukiwania zagnieżdżone w rekordach include dostawców również się liczą, więc rekord, który na pierwszy rzut oka wygląda poprawnie, może w rzeczywistości zawierać 12 lub 13 wyszukiwań. Gdy limit zostanie przekroczony, każdy odbiorca zwraca komunikat permerror, a zgodność DMARC oparta na SPF załamuje się natychmiast dla całej domeny.

Co należy zrobić: Zacznij od sprawdzenia swoich danych za pomocą narzędzia do wyszukiwania rekordów SPF i usunięcia dostawców, z których usług już nie korzystasz. Jest to jednak rozwiązanie tymczasowe. Długoterminowym rozwiązaniem jest skorzystanie z hostowanego rozwiązania SPF, takiego jak PowerSPF, wyposażonego w optymalizację makr SPF, które umożliwia dynamiczne zarządzanie wyszukiwaniem rekordów SPF.

• Drugą przyczyną, jeśli zauważysz błędy typu „temperror” występujące konkretnie w przypadku serwerów Microsoftu, mogą być przekroczenia limitu czasu DNS. Jeśli przekroczenia te dotyczą konkretnego serwera, należy zrezygnować z usług tego dostawcy lub usunąć go z listy.

4. Zasady dotyczące odrzucania nie są przestrzegane

Od lipca 2023 r. firma Microsoft domyślnie stosuje zasadę „p=reject”, co oznacza, że komunikat, który nie spełnia wymagań, powinien zostać od razu odrzucony. Jeśli tak się nie dzieje, przyczyną może być jedna z czterech następujących sytuacji:

• W polityce antyphishingowej może być wyłączona obsługa DMARC: upewnij się, że opcja „Stosuj zasady rekordu DMARC, gdy wiadomość zostanie wykryta jako sfałszowana” jest włączona, a działanie dla parametru p=reject jest ustawione na Odrzuć (a nie Kwarantanna).
• Przed usługą Microsoft 365 znajduje się brama zewnętrzna: jeśli serwer MX kieruje ruch do zewnętrznej bramy zabezpieczeń, firma Microsoft nie będzie egzekwować zasad DMARC, chyba że włączysz opcję „Rozszerzone filtrowanie dla łączników”.
• Uwierzytelnianie złożone miało pierwszeństwo przed wynikiem: firma Microsoft nakłada sygnały reputacyjne na protokół DMARC. Wiadomość może nie przejść weryfikacji DMARC, a mimo to zostać dostarczona, jeśli compauth=pass
  (Więcej informacji na ten temat można znaleźć w społeczności edukacyjnej firmy Microsoft).
• Reguła zezwalająca dla dzierżawcy omija filtrowanie: nadawca z listy zezwolonych, zaufany łącznik przychodzący lub reguła oznaczająca poziom pewności spamu SCL-1 całkowicie pomija egzekwowanie DMARC.

Wdrażanie protokołu DMARC w usłudze Microsoft 365

DMARC w usłudze Microsoft 365 to problem o dwóch aspektach. Usługa Exchange Online Protection automatycznie zajmuje się weryfikacją wiadomości przychodzących, ale ochrona wiadomości wychodzących leży całkowicie w gestii użytkownika. Zmiany w egzekwowaniu zasad, które wejdą w życie w maju 2025 r., sprawiają, że kwestia ta staje się pilna dla wszystkich, którzy wysyłają duże ilości wiadomości.

Najbezpieczniejszą metodą jest ta, w której działa się powoli: najpierw ustaw p=none, obserwuj raporty przez dwa do czterech tygodni, usuń wykryte nadawców, a następnie przejdź do p=quarantine i w końcu do p=reject. Pomijanie etapów to najczęstsza przyczyna problemów z dostarczaniem legalnej poczty podczas wdrażania.

Po wdrożeniu zasad egzekwowania zadania zmieniają się z konfiguracji na monitorowanie. Pojawiają się nowi nadawcy, a zewnętrzni dostawcy modyfikują swoją infrastrukturę – wszystko to może niepostrzeżenie zakłócić spójność, jeśli nikt nie śledzi raportów. Właśnie w tym momencie dedykowana platforma DMARC pokazuje swoją wartość. Narzędzia raportowania i analizy PowerDMARC przekształcają surowe dane XML w przejrzyste wnioski i sygnalizują odchylenia, zanim przerodzą się one w problem z dostarczalnością.

Zacznij od sprawdzenia swojego aktualnego rekordu DMARC, aby zorientować się, jak wygląda Twoja obecna sytuacja.

Najczęściej zadawane pytania

Czy usługa Microsoft 365 automatycznie konfiguruje protokół DMARC?

Firma Microsoft weryfikuje zgodność z protokołem DMARC dla poczty przychodzącej, ale nie konfiguruje go dla Twojej domeny niestandardowej. Musisz samodzielnie opublikować rekord TXT DMARC dla poczty wychodzącej.

Czy firma Microsoft wymaga stosowania protokołu DMARC?

Tak, firma Microsoft wymaga stosowania protokołu DMARC od nadawców wysyłających duże ilości wiadomości. Zaleca się również wszystkim organizacjom stosowanie tego protokołu w celu zapewnienia dostarczalności wiadomości i ochrony.

Czym jest błąd 550 5.7.515?

Ten błąd oznacza, że Twoje wiadomości e-mail są odrzucane z powodu braku zasad DMARC lub ich niezgodności z regułami egzekwowania firmy Microsoft.

Dlaczego wiadomości e-mail nadal są dostarczane z atrybutem „p=reject”?

Firma Microsoft od dawna stosuje wewnętrzne obejście o nazwie „oreject” (odrzucenie źródłowe), które przekierowuje wiadomości niezgodne z protokołem DMARC do folderu „Śmieci” zamiast odrzucać je bezpośrednio na poziomie bramy. Rozwiązanie to miało na celu ochronę legalnych nadawców przed przypadkową utratą wiadomości, jednak sprawia, że wiadomości wysłane z fałszywych adresów pozostają widoczne dla odbiorców.

Dwie rzeczy, o których warto wiedzieć:

1) Od czasu zmian w zasadach egzekwowania przepisów, które weszły w życie w maju 2025 r., firma Microsoft zmierza w kierunku bardziej rygorystycznego, faktycznego blokowania nadawców wysyłających duże ilości wiadomości.

2) Jeśli chcesz mieć pewność, że wiadomości zostaną odrzucone w ramach Twojej własnej dzierżawy Microsoft 365, utwórz regułę transportową Exchange, która powoduje twarde odrzucenie wiadomości.

Czy powinienem zastosować kwarantannę, czy odrzucić?

Zacznij od monitorowania (p=brak), aby śledzić źródła wysyłające i kanały e-mailowe, następnie przejdź do kwarantanny, a opcję odrzucania stosuj dopiero wtedy, gdy upewnisz się, że wszystkie prawidłowe źródła są uwzględnione.

• O
• Latest Posts

Yunes Tarada

Ekspert ds. bezpieczeństwa domen i poczty e-mail w PowerDMARC

Yunes jest liderem zespołu operacyjnego w PowerDMARC z wiedzą ekspercką w zakresie uwierzytelniania i bezpieczeństwa poczty elektronicznej. Yunes jest certyfikowanym przez Microsoft Azure Administrator Associate z certyfikatami CompTIA A+ i wieloma innymi.

Najnowsze posty autorstwa Yunes Tarada (zobacz wszystkie)

• DMARCbis – co się zmienia i jak się przygotować - 16 kwietnia 2026 r.
• Nieprawidłowy format numeru seryjnego SOA: przyczyny i sposoby rozwiązania - 13 kwietnia 2026 r.
• Jak wysyłać bezpieczne wiadomości e-mail w Gmailu: przewodnik krok po kroku - 7 kwietnia 2026 r.