Przewodnik po konfiguracji DMARC dla Office 365 (2026)

Skorzystaj z tego przewodnika krok po kroku, aby skonfigurować DMARC w usłudze Office 365. Dowiedz się o istotnych zmianach dotyczących zgodności, popularnych metodach rozwiązywania problemów oraz o tym, dlaczego sama usługa Microsoft 365 nie wystarcza do zapewnienia bezpieczeństwa poczty elektronicznej.

Firma Microsoft wspiera i zachęca do wdrażania protokołu DMARC w usłudze Office 365, znanej również jako Microsoft 365 lub M365. Pozwala to na jednolite stosowanie protokołów uwierzytelniania poczty elektronicznej we wszystkich zarejestrowanych domenach. Jako eksperci w dziedzinie protokołów uwierzytelniania, na tym blogu wyjaśniamy procesy konfiguracji protokołu DMARC w usłudze Office 365 w celu weryfikacji wszystkich wiadomości e-mail, które:

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

Zapoznaj się z tym przewodnikiem, aby zrozumieć działanie protokołu DMARC w usłudze Microsoft 365, poznać kroki niezbędne do jego skonfigurowania, dowiedzieć się, jak zmienić wymagania dotyczące uwierzytelniania, oraz zrozumieć, dlaczego narzędzia takie jak PowerDMARC są niezbędne do stopniowego wdrażania egzekwowania zasad.

Szybka odpowiedź

Jeśli potrzebujesz skróconej wersji, oto podstawowy proces konfiguracji DMARC w usłudze Microsoft 365:

1. Skonfiguruj SPF: dodaj do swoich ustawień DNS wpis v=spf1 include:spf.protection.outlook.com -all
2. Włącz DKIM: przejdź do Microsoft 365 Defender → Poczta e-mail i współpraca → Zasady i reguły → Zasady dotyczące zagrożeń → DKIM → wybierz domenę → Włącz (wymagane są dwa rekordy CNAME)
3. Opublikuj DMARC: utwórz rekord TXT pod adresem _dmarc.twojadomena.com, zaczynający się od v=DMARC1; p=none; rua=mailto:[email protected]
4. Przez 2–4 tygodnie należy monitorować raporty, a następnie stopniowo przechodzić do p=kwarantanna → p=odrzucenie

Aby uzyskać bardziej szczegółowy przewodnik, przeczytaj ten wpis na blogu do końca.
Uwaga: Ta skrócona procedura działa tylko wtedy, gdy wszystkie legalne źródła wysyłające z Microsoft 365 i innych dostawców są poprawnie uwierzytelnione i zsynchronizowane. Jeśli korzystasz z platform takich jak systemy CRM, narzędzia do automatyzacji marketingu, systemy pomocy technicznej lub narzędzia do fakturowania, zidentyfikuj je przed przejściem do etapu egzekwowania.

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

DMARC to skrót od Domain-based Message Authentication, Reporting, and Conformance. Jest to protokół uwierzytelniania wiadomości e-mail, który pomaga chronić domeny przed spoofingiem, phishingiem i nieuprawnionym wykorzystaniem.

DMARC działa w oparciu o protokoły SPF i DKIM. Sprawdza, czy wiadomość spełnia wymagania SPF lub DKIM oraz czy domena, która przeszła weryfikację, pokrywa się z widoczną domeną nadawcy („From”). Następnie przekazuje serwerom pocztowym odbierającym wiadomości instrukcje dotyczące postępowania z wiadomościami, które nie przeszły uwierzytelnienia.

Dla użytkowników Microsoft 365 protokół DMARC ma znaczenie z dwóch powodów:

• Pomaga to zapobiegać podszywaniu się atakujących pod Twoją domenę.
• Zwiększa to zaufanie i poprawia dostarczalność legalnych wiadomości wychodzących.

Usługa Exchange Online Protection sprawdza zgodność z protokołem DMARC w przypadku poczty przychodzącej, ale nie zapewnia to automatycznej ochrony Twojej domeny przed podszywaniem się pod nią w innych miejscach. Aby zabezpieczyć tożsamość w komunikacji wychodzącej, musisz opublikować rekordy SPF, DKIM i DMARC dla swojej domeny.

Aby uzyskać bardziej szczegółowe informacje dotyczące wdrożenia, zapoznaj się z przewodnik PowerDMARC dotyczący DMARC.

DMARC 2026: Aktualizacja dokumentów RFC 9989, 9990 i 9991

W maju 2026 r. standard DMARC został zaktualizowany na podstawie trzech dokumentów RFC organizacji IETF:

Dokument RFC 9989 unieważnia dokumenty RFC 7489 i RFC 9091 oraz nadaje standardowi DMARC status „proponowanego standardu”. Dla właścicieli domen najważniejszą zmianą praktyczną jest przejście z wykrywania domen organizacyjnych w oparciu o listę sufiksów publicznych (Public Suffix List) na metodę przeszukiwania drzewa DNS (DNS Tree Walk).

Istniejące rekordy DMARC nadal zaczynają się od:

txt

v=DMARC1

Większość administratorów Microsoft 365 nie nie muszą od razu przebudowywać swoich rekordów DNS. Należy jednak sprawdzić:

• sp= zachowanie zasad dotyczących subdomen
• Dowolna złożona struktura subdomen delegowanych
• Domeny i subdomeny, które wysyłają wiadomości e-mail za pośrednictwem usługi Microsoft 365 lub platform innych dostawców
• Domeny, z których nie wysyłane są wiadomości, oraz domeny nieaktywne, które należy zablokować

Jeśli Twoja organizacja korzysta ze złożonej hierarchii domen, opublikuj wyraźne rekordy DMARC dla każdej domeny i subdomeny, z której wysyłane są wiadomości e-mail. Pozwoli to ograniczyć niejasności w miarę jak odbiorcy przechodzą ze starszego sposobu przetwarzania DMARC na zachowanie zgodne z RFC 9989.

Więcej szczegółów znajdziesz w przewodniku PowerDMARC dotyczącym aktualizacji standardów DMARC RFC 9989, 9990 i 9991.

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

Usługa Microsoft 365 przeprowadza weryfikację DMARC dla przychodzących wiadomości e-mail, ale nie konfiguruje w pełni ochrony domeny wychodzącej dla domeny niestandardowej użytkownika.

Usługa Exchange Online Protection automatycznie weryfikuje poprawność ustawień SPF, DKIM i DMARC w wiadomościach otrzymywanych przez organizację. Pomaga to chronić użytkowników przed sfałszowaną pocztą przychodzącą.

W przypadku wiadomości wychodzących obowiązki są inne. Należy skonfigurować rekord SPF, włączyć DKIM oraz opublikować rekord DMARC w systemie DNS dla każdej domeny wysyłającej.

Najprościej można to wyjaśnić w ten sposób: Microsoft chroni skrzynkę odbiorczą usługi Microsoft 365, natomiast DMARC chroni tożsamość domeny w całym ekosystemie poczty elektronicznej.

Jeśli korzystasz wyłącznie z natywnych elementów sterujących pakietu Microsoft 365, nadal mogą Ci brakować:

• Raporty DMARC w formacie czytelnym dla człowieka
• Wgląd w dane nadawców zewnętrznych
• Wskazówki dotyczące przejścia ze stanu „p=none” do stanu „enforcement”
• Scentralizowane monitorowanie we wszystkich domenach
• Zarządzanie limitami wyszukiwania SPF
• Powiadomienia w przypadku utraty zgodności przez dostawców lub rekordy DNS

Szczegółowe zestawienie można znaleźć w artykule dlaczego użytkownicy Microsoft 365 nadal potrzebują DMARC.

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

Przed opublikowaniem rekordu DMARC upewnij się, że zarówno SPF, jak i DKIM są poprawnie skonfigurowane dla Twojej domeny. DMARC sam w sobie nie uwierzytelnia wiadomości e-mail; opiera się wyłącznie na wynikach SPF i/lub DKIM. Jeśli brakuje tych elementów lub są one nieprawidłowo skonfigurowane, DMARC nie zadziała, a po włączeniu egzekwowania może to mieć negatywny wpływ na prawidłowe wiadomości e-mail.

Krok 1: Skonfiguruj SPF dla usługi Microsoft 365

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 domeny przeznaczonej wyłącznie dla usługi Microsoft 365 standardowy rekord SPF ma następującą postać:

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

Jeśli korzystasz z serwerów wysyłających innych dostawców, uwzględnij je w tym samym wpisie SPF:

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

Ważne: W każdej domenie może istnieć tylko jeden rekord SPF typu TXT. Wiele rekordów SPF powoduje błąd SPF PermError i może uniemożliwić uwierzytelnianie.

SPF ma również sztywny limit 10 zapytań DNS. Przekroczenie tego limitu powoduje błąd SPF PermError, który DMARC interpretuje jako niepowodzenie. Jeśli korzystasz z wielu usług SaaS, użyj z hostowanego SPF z makrami od PowerSPF , aby zawsze pozostawać poniżej limitu bez konieczności ręcznej edycji DNS. Możesz również sprawdzić swój aktualny rekord SPF lub skorzystać z tego generatora SPF za darmo.

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ą zweryfikować, czy wiadomość nie została zmieniona i czy rzeczywiście pochodzi z Twojej domeny.

⚠️  Funkcja DKIM w usłudze Microsoft 365 nie jest domyślnie włączony dla domen niestandardowych. Należy go wyraźnie włączyć w centrum administracyjnym.

Ręczna konfiguracja DKIM: DNS + Centrum administracyjne

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ń” → „Ustawienia uwierzytelniania poczty e-mail” → „DKIM”
3. Wybierz swoją domenę.

Zanim będzie można włączyć tę funkcję, firma Microsoft poprosi o dodanie dwóch rekordów CNAME:

selector1._domainkey
selector1-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

selector2._domainkey
selector2-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

1. Po opublikowaniu tych rekordów CNAME wróć do portalu Defender i włącz opcję „Włącz” dla DKIM

Po aktywacji usługa Microsoft zaczyna podpisywać wszystkie wychodzące wiadomości e-mail za pomocą DKIM. Sprawdź swoją konfigurację, korzystając z bezpłatnego narzędzia do sprawdzania DKIM.

Jak skonfigurować DMARC w usłudze Office 365

Po skonfigurowaniu protokołów SPF i DKIM można opublikować DMARC. W przypadku większości domen niestandardowych proces konfiguracji DMARC w usłudze Microsoft 365 odbywa się w systemie DNS, a nie w Centrum administracyjnym Microsoft 365.

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. Pominięcie jakiegokolwiek legalnego nadawcy może spowodować problemy z dostarczaniem wiadomości po włączeniu egzekwowania zasad.

Do typowych źródeł wysyłania wiadomości w usłudze Microsoft 365 należą:

• Microsoft 365 (Exchange Online)
• Platformy marketingowe (Mailchimp, HubSpot, Klaviyo)
• Systemy CRM (Salesforce, HubSpot CRM)
• Narzędzia do obsługi klienta (Zendesk, Freshdesk, Intercom)
• Aplikacje wewnętrzne lub lokalne serwery pocztowe
• Zewnętrzne bramy pocztowe lub urządzenia zabezpieczające

Właśnie w tym miejscu wiele wdrożeń DMARC kończy się niepowodzeniem. Domena może sprawiać wrażenie, jakby była przeznaczona wyłącznie dla „Microsoft 365”, jednak faktury, biuletyny, wiadomości dotyczące resetowania haseł, aktualizacje zgłoszeń oraz powiadomienia z działu kadr często pochodzą spoza środowiska Microsoft 365.

Jeśli nie masz pewności, które systemy wysyłają wiadomości w Twoim imieniu, zacznij od ustawienia p=none i skorzystaj z raportów zbiorczych DMARC, aby je zidentyfikować.

Krok 2: Utwórz rekord DMARC

Rekord DMARC to rekord typu TXT opublikowany w systemie DNS pod adresem _dmarc.twojadomena.com. Skorzystaj z generatora rekordów DMARC , aby w ciągu kilku sekund utworzyć poprawny, wolny od błędów rekord.

Zalecany wpis początkowy wygląda następująco:

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

Podsumowując:

• v=DMARC1 — określa wersję DMARC
• p=none — tryb monitorowania (bez egzekwowania; wyłącznie gromadzenie danych)
• rua=mailto:… — adres, na który wysyłane są zbiorcze raporty (RUA)

Krok 3: Opublikuj rekord DMARC w systemie DNS

Dodaj następujący rekord TXT u swojego dostawcy usług DNS:

Uwaga: Po opublikowaniu może minąć trochę czasu (zazwyczaj od kilku minut do kilku godzin), zanim wpis zostanie rozpropagowany na całym świecie.

Po opublikowaniu sprawdź swój rekord za pomocą narzędzia do sprawdzania DMARC, aby upewnić się, że nie zawiera on błędów składniowych i że jest poprawnie rozpoznawany.

Krok 4: Monitorowanie raportów DMARC

Po włączeniu DMARC z polityką p=none zaczniesz otrzymywać zagregowane raporty DMARC (RUA) z serwerów odbierających. Raporty te zapewniają wgląd w to, kto wysyła wiadomości e-mail przy użyciu Twojej domeny, które wiadomości przechodzą uwierzytelnianie, a które nie, oraz w status zgodności z SPF i DKIM.

Raporty DMARC są dostarczane w postaci surowego kodu XML, który bez odpowiednich narzędzi trudno zinterpretować. Analizator raportów PowerDMARC przekształca je w przejrzyste pulpity nawigacyjne, dzięki czemu możesz zidentyfikować problemy i bezpiecznie dążyć do wdrożenia odpowiednich środków.

Krok 5: Stopniowe przechodzenie do egzekwowania przepisów

Po upewnieniu się, że wszyscy wiarygodni nadawcy są prawidłowo uwierzytelnieni, stopniowo zaostrzaj zasady DMARC:

Etap 1 — Monitorowanie (p = brak):

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

Etap 2 — Kwarantanna (podejrzane wiadomości e-mail trafiają do folderu spam):

v=DMARC1; p=kwarantanna; rua=mailto:[email protected]; pct=25; t=y

Etap 3 — Egzekwowanie (odrzucanie wiadomości nieautoryzowanych):

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

Wskazówka: Nie należy pochopnie odrzucać wiadomości. Przedwczesne wdrożenie jest najczęstszą przyczyną blokowania prawidłowych wiadomości e-mail podczas wdrażania.

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

Sposób postępowania zależy od domeny, którą konfigurujesz.

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, a pomijanie poszczególnych etapów tylko 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 analizuje rekordy DMARC we wszystkich wiadomościach przychodzących. 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, które nie spełniają wymagań DMARC zgodnie z zasadą p=reject, są odrzucane na bramie. Podobnie wiadomości, które nie spełniają wymagań p=quarantine, są kierowane do kwarantanny. Jest to kontrolowane przez opcję „„Przestrzegaj zasad rekordu DMARC, gdy wiadomość zostanie wykryta jako sfałszowana”” w zasadach antyphishingowych, które są domyślnie włączone.

Szczegółowy opis konfiguracji tego ustawienia oraz wszystkich powiązanych opcji można znaleźć w przewodniku PowerDMARC dotyczącym polityki antyphishingowej Office 365.

Źródło: Microsoft

Wyjaśnienie działania funkcji „oreject”

Wcześniej firma Microsoft stosowała wewnętrzne nadpisanie o nazwie „action=oreject” (odrzucenie ze strony nadawcy) 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; przekazywane wiadomości e-mail i ruch z list mailingowych często naruszają zasady SPF i DKIM podczas przesyłania, a twarde odrzucenie przy ustawieniu p=reject spowodowałoby odrzucenie znacznej ilości legalnych wiadomości. Folder ze spamem stanowił kompromisowe rozwiązanie: odbiorcy mogli w razie potrzeby odzyskać wiadomość, a zasady nadawcy były technicznie przestrzegane.

Kiedy dzisiaj nadal zobaczysz „oreject”

Od czasu zmiany domyślnego ustawienia 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 zasadach ochrony przed phishingiem opcja „Honor DMARC” jest wyłączona: sprawdź 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
2. Poczta przechodzi przez bramę zewnętrznego dostawcy (Proofpoint, Mimecast) przed dotarciem do usługi Microsoft 365: włącz opcję „Rozszerzone filtrowanie dla łączników” w portalu Defender
3. Reguła zezwalająca na poziomie odbiorcy omija filtrowanie: nadawcy z listy dozwolonych, zaufane łączniki przychodzące lub reguły SCL -1 całkowicie pomijają egzekwowanie DMARC

Zrozumienie mechanizmu compauth i uwierzytelniania złożonego

Firma Microsoft nakłada sygnały reputacyjne na wyniki DMARC za pomocą systemu zwanego uwierzytelnianiem złożonym (compauth). Oznacza to, że wiadomość może technicznie rzecz biorąc nie przejść weryfikacji DMARC, ale mimo to zostać dostarczona , jeśli sygnały reputacyjne Microsoftu wskazują, że nadawca jest wiarygodny (compauth=pass). Z drugiej strony wiadomość może przejść test DMARC, a mimo to zostać odrzucona , jeśli uwierzytelnianie kompozytowe zakończy się niepowodzeniem. Podczas rozwiązywania problemów z dostarczaniem wiadomości w ramach DMARC w usłudze M365 należy zawsze sprawdzić nagłówek „Authentication-Results” pod kątem kodu „reason=”. Zapoznaj się z tym kompletnym przewodnikiem dotyczącym niepowodzenia compauth i uwierzytelniania złożonego .

Zaostrzenie kontroli przywozu poprzez przepisy transportowe

Dla organizacji, które chcą mieć gwarancję odrzucania wiadomości niezgodnych z DMARC, reguła transportowa w usłudze Exchange Online stanowi najbardziej niezawodny mechanizm:

1. Przejdź do Centrum administracyjne Exchange → Przepływ poczty → Reguły → Utwórz nową regułę
2. Warunek: Nagłówek wiadomości zawiera którekolwiek z poniższych słów. Nazwa nagłówka: Authentication-Results. Wartość nagłówka: dmarc=fail action=oreject
3. Działanie: Odrzuć wiadomość z wyjaśnieniem: „Wiadomość nie przeszła uwierzytelnienia DMARC i została odrzucona zgodnie z polityką organizacji”

1. (Opcjonalnie) Dodaj wyjątek dla zaufanych nadawców wewnętrznych lub znanych, legalnych podmiotów przekazujących wiadomości
2. W pierwszym tygodniu ustaw tryb reguł na „Testuj bez zasad” lub „Testuj z podpowiedziami dotyczącymi zasad”, jeśli są dostępne; przed przełączeniem się na tryb „Egzekwuj” przejrzyj dopasowane komunikaty w historii komunikatów

Zastosuj to podejście, gdy przepisy prawne lub wewnętrzne zasady wymagają faktycznego odrzucania wiadomości, które nie przeszły weryfikacji, gdy Twoja organizacja stanowi atrakcyjny cel ataków typu spoofing (komunikacja finansowa, prawna, kierownictwa) lub gdy zależy Ci na spójnym zachowaniu zarówno w przypadku bezpośredniego serwera MX, jak i przepływów przez bramki stron trzecich.

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

W maju 2025 roku firma Microsoft wprowadziła znaczącą 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.

Porównanie zasad egzekwowania przez dostawców skrzynek pocztowych

Najważniejsze wymagania wprowadzone przez firmę Microsoft

• Obowiązkowy DMARC dla nadawców masowych: domeny wysyłające ponad 5 000 wiadomości e-mail dziennie do usług konsumenckich firmy Microsoft muszą posiadać prawidłowy wpis DMARC
• Dotyczy ekosystemu skrzynek pocztowych firmy Microsoft przeznaczonych dla użytkowników indywidualnych: Outlook.com, Hotmail.com i Live.com
• Wymóg minimalny: DMARC z ustawieniem p=none — dopuszczalna jest nawet polityka monitorowania, ale brak rekordu DMARC nie jest już tolerowany w przypadku dużych wdrożeń
• Duży nacisk kładzie się na zgodność domen: sama autoryzacja nie wystarczy, SPF i DKIM muszą być zgodne z widoczną domeną „Od”
• Odrzucenie z powodu niezgodności: 550 5.7.515 Odmowa dostępu, domena wysyłająca nie spełnia wymaganego poziomu uwierzytelnienia

Dzięki tej zmianie Microsoft dostosowuje się do standardów firmy Apple, Google i Yahoo w zakresie uwierzytelniania wiadomości e-mail, co oznacza, że wszyscy najwięksi dostawcy skrzynek pocztowych wymagają obecnie uwierzytelniania od nadawców masowych wiadomości. Zobacz wymagania Microsoftu dotyczące DMARC w programie Outlook , aby zapoznać się z pełną listą kontrolną zgodności.

Dlaczego sam pakiet Microsoft 365 to za mało

Chociaż usługa Microsoft 365 zapewnia skuteczną ochronę poczty przychodzącej, oferuje ograniczone możliwości zarządzania i monitorowania protokołu DMARC na dużą skalę.

Brak raportów w formie czytelnej dla człowieka

Firma Microsoft wysyła obecnie raporty DMARC dla użytkowników korporacyjnych , gdy rekord MX wskazuje bezpośrednio na Office 365. Jednak te surowe pliki XML są trudne do zinterpretowania bez specjalistycznych narzędzi. Bez odpowiedniej analizy organizacje 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 nie tylko przekształca surowe dane z 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 Microsoft 365 po prostu nie zapewnia.

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

Możesz również dołączyć do społeczności edukacyjnej firmy Microsoft , aby być na bieżąco z Office 365 i wymaganiami dotyczącymi protokołów uwierzytelniania.

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

DMARC w usłudze Microsoft 365 stanowi problem dwustronny. Usługa Exchange Online Protection automatycznie zajmuje się weryfikacją wiadomości przychodzących, jednak ochrona wiadomości wychodzących leży wyłącznie w gestii użytkownika. Zmiany w egzekwowaniu zasad, które wejdą w życie w maju 2025 r., sprawiają, że ta odpowiedzialność staje się pilna dla każdego, kto wysyła duże ilości wiadomości, a opublikowanie specyfikacji DMARCbis w maju 2026 r. sygnalizuje, że branża poczty elektronicznej traktuje DMARC jako stałą, formalną infrastrukturę.

Najbezpieczniejsze podejście jest wolniejsze, ale skuteczne: należy ustawić parametr p=none, obserwować raporty przez dwa do czterech tygodni, zablokować nadawców, którzy się pojawią, a następnie przejść do ustawienia p=quarantine i ostatecznie p=reject. Pominięcie tych kroków prowadzi do zakłóceń w działaniu legalnej poczty służbowej podczas wdrażania rozwiązania.

Po osiągnięciu etapu egzekwowania zadania zmieniają się z konfiguracji na monitorowanie. Dodawani są nowi nadawcy, a zewnętrzni dostawcy modyfikują swoją infrastrukturę – wszystko to może niepostrzeżenie zakłócić zgodność, jeśli nikt nie śledzi raportów. Potraktuj bezpieczeństwo poczty elektronicznej priorytetowo, sprawdzając swój aktualny rekord DMARC, aby zorientować się, na jakim etapie obecnie się znajdujesz.

Pełny opis wszystkich znaczników DMARC, zasad i opcji wdrożeniowych można znaleźć w przewodnik po DMARC.

Najczęściej zadawane pytania

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

Firma Microsoft weryfikuje zgodność z protokołem DMARC dla wiadomości e-mail przychodzących, ale nie konfiguruje go dla Twojej domeny niestandardowej. Musisz samodzielnie opublikować rekord TXT DMARC dla wiadomości wychodzących. Ochrona domeny wymaga samodzielnego opublikowania rekordów SPF, DKIM i DMARC w systemie DNS.

Czy firma Microsoft wymaga stosowania protokołu DMARC?

Tak. Firma Microsoft wprowadziła w 2025 r. obowiązkowe stosowanie protokołu DMARC (co najmniej z ustawieniem p=none) dla domen wysyłających ponad 5 000 wiadomości e-mail dziennie do serwisów Outlook.com, Hotmail.com i Live.com. Wiadomości od nadawców niespełniających tych wymagań są odrzucane na poziomie serwera i nie docierają do żadnej skrzynki odbiorczej. Firma Microsoft zdecydowanie zaleca również wszystkim nadawcom wdrożenie protokołu DMARC, niezależnie od liczby wysyłanych wiadomości.

Czym jest błąd 550 5.7.515?

Ten błąd usługi Microsoft 365 oznacza, że Twoje wiadomości e-mail są odrzucane, ponieważ domena nadawcza nie spełnia wymagań dotyczących uwierzytelniania. Aby rozwiązać ten problem, należy opublikować prawidłowy rekord DMARC (co najmniej p=none) oraz upewnić się, że rekordy SPF i DKIM są skonfigurowane i zgodne z domeną nadawczą.

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

Istnieją cztery typowe przyczyny: (1) opcja „Honor DMARC” jest wyłączona w polityce antyphishingowej; (2) przed usługą Microsoft 365 znajduje się brama zewnętrznego dostawcy; (3) nie włączono funkcji „Enhanced Filtering for Connectors”; (4) złożone uwierzytelnianie Microsoftu (compauth) zastępuje wynik niepowodzenia DMARC; (5) reguła zezwalająca dla dzierżawcy całkowicie omija filtrowanie. Chociaż firma Microsoft przeszła na bardziej rygorystyczne odrzucanie wiadomości od nadawców wysyłających duże ilości wiadomości, te nadpisania pozostają aktywne w nieprawidłowo skonfigurowanych środowiskach.

Czy powinienem zastosować kwarantannę, czy odrzucić?

Zacznij od monitorowania (p=none), aby poznać źródła wysyłające wiadomości, następnie przejdź do kwarantanny, a opcję odrzucania stosuj dopiero wtedy, gdy upewnisz się, że wszystkie prawidłowe źródła zostały uwzględnione. Przejście od razu do odrzucania bez monitorowania jest główną przyczyną utraty legalnych wiadomości e-mail podczas wdrażania DMARC.

Co oznacza DMARCbis dla administratorów Microsoft 365?

DMARCbis (RFC 9989, opublikowany w maju 2026 r.) oficjalnie nadaje standardowi DMARC status „proponowanego standardu”. W przypadku większości administratorów M365 nie są wymagane żadne natychmiastowe zmiany w DNS — istniejące rekordy DMARC pozostają ważne. Kluczową zmianą, o której należy pamiętać, jest podejście oparte na przeszukiwaniu drzewa DNS (DNS Tree Walk) służące do określania domen organizacyjnych, które zastępuje listę sufiksów publicznych (Public Suffix List). Należy sprawdzić tag sp= (polityka subdomeny), aby upewnić się, że nadal działa poprawnie zgodnie z nową logiką.

Czy standard DMARC ma zastosowanie do domen onmicrosoft.com?

Tak. Domena onmicrosoft.com (MOERA) jest często pomijana, ale osoby atakujące aktywnie wykorzystują ją do fałszowania adresów. Microsoft automatycznie konfiguruje SPF dla domen MOERA, ale DKIM i DMARC należy opublikować ręcznie. W przypadku tych domen należy stosować rygorystyczną politykę p=reject, ponieważ zazwyczaj nie są one wykorzystywane do wysyłania legalnej poczty wychodzącej.

Czy protokół DMARC jest wymagany do zapewnienia zgodności z PCI DSS?

Od 31 marca 2025 r. zgodnie z sekcją 5.4.1 standardu PCI DSS w wersji 4.0 środki ochrony przed phishingiem, w tym DMARC, SPF i DKIM, stały się w pełni obowiązkowe dla wszystkich organizacji przetwarzających dane kart płatniczych. Wszystkie audyty w 2026 r. będą przeprowadzane zgodnie ze standardem PCI DSS w wersji 4.0.1, bez okresu przejściowego. Jeśli Twoja organizacja przetwarza płatności kartowe i korzysta z usługi Microsoft 365, stosowanie protokołu DMARC jest bezwzględnym wymogiem zgodności.

• O
• Latest Posts

Yunes Tarada

Ekspert ds. bezpieczeństwa domen i poczty elektronicznej 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)

• Wyrównanie SPF: co to jest i dlaczego jest potrzebne? - 28 lipca 2026 r.
• Przewodnik po konfiguracji DMARC dla Office 365 (2026) - 21 lipca 2026 r.
• Jak naprawić błędy „Podpis DKIM jest nieprawidłowy” i „Skrót treści nie został zweryfikowany” – 16 lipca 2026 r.