PCI DSS a DMARC: co jest wymagane, a co nie

PCI DSS, czyli standard bezpieczeństwa, którego musi przestrzegać każda firma przyjmująca płatności kartą, nie wymienia DMARC jako wymaganego mechanizmu kontroli. Ale od 31 marca 2025 r. wersja 4.0.1 tego standardu wymaga zautomatyzowanych zabezpieczeń antyphishingowych, a PCI Security Standards Council wymienia DMARC, SPF i DKIM w swoich wytycznych jako uznane sposoby spełnienia tego wymogu. Jeśli przyjmujesz płatności kartą, powinieneś więc traktować DMARC jako oczekiwany, mimo że standard nigdy nie wymienia go jako obowiązkowego.

Wpisy na blogach dostawców rutynowo twierdzą, że PCI DSS "wymaga DMARC". To twierdzenie nie jest do końca trafne, a różnica ma znaczenie podczas audytu PCI. Ten artykuł wyjaśnia, co mówi wymóg 5.4.1, gdzie wpisuje się DMARC oraz co muszą zrobić osoby zarządzające Twoim DNS i zgodnością. Jeśli przyjmujesz płatności kartą przez stronę internetową, praca spada na Twój zespół IT lub bezpieczeństwa albo na agencję zarządzającą Twoją domeną.

Kliknij w odnośniki, aby przejść do konkretnej sekcji.

• Czy PCI DSS wymaga DMARC?
• Co mówi wymóg 5.4.1 i kiedy wszedł w życie
• Jeśli nie DMARC, to co innego mogłoby spełnić ten wymóg?
• Czy rekord DMARC działający tylko w trybie monitorowania wystarczy?
• Co powinieneś zrobić, jeśli przyjmujesz płatności kartą?
• Jak to się ma do reguł Google, Yahoo i Microsoftu?
• Podsumowanie

Czy PCI DSS wymaga DMARC?

Nie z nazwy. PCI DSS w wersji 4.0.1, czyli aktualnym wydaniu standardu, nakazuje organizacjom wdrożenie zautomatyzowanych mechanizmów antyphishingowych. Sam wymóg nie wskazuje konkretnej technologii. Konkretne nazwy pojawiają się w wytycznych, gdzie PCI Security Standards Council pisze, że mechanizmy ochrony przed podszywaniem się, takie jak DMARC, SPF i DKIM, "mogą pomóc powstrzymać sprawców phishingu przed fałszowaniem domeny podmiotu i podszywaniem się pod jego pracowników".

Wytyczne PCI rekomendują więc DMARC; nie wymieniają DMARC jako wymaganego mechanizmu kontroli. W praktyce różnica między "rekomendowanym" a "wymaganym" jest tu niewielka. SPF, DKIM i DMARC to standardowy, udokumentowany sposób na powstrzymanie fałszowania domeny, więc audytor szukający zautomatyzowanych mechanizmów antyphishingowych będzie się ich spodziewał. Praktyczna rada jest prosta: wdróż DMARC, bo audytor będzie go szukał. Nie twierdź, że standard wymaga DMARC z nazwy, bo tak nie jest, a audytor zna tę różnicę.

Co mówi wymóg 5.4.1 i kiedy wszedł w życie

Właściwą regułą jest wymóg 5.4.1: muszą istnieć procesy i zautomatyzowane mechanizmy wykrywające ataki phishingowe i chroniące przed nimi pracowników. Kluczowym słowem jest tu "zautomatyzowane". Samo szkolenie z zakresu świadomości bezpieczeństwa nie spełnia tego wymogu, ponieważ standard oczekuje działającego mechanizmu technicznego, a nie tylko przeszkolonych pracowników.

Wymóg 5.4.1 opublikowano jako wymóg z odroczonym terminem, co oznaczało, że był opcjonalny, dopóki organizacje się przygotowywały. Ten okres przejściowy zakończył się 31 marca 2025 r. Od tej daty jest to pełny wymóg, który audytor sprawdza podczas oceny zgodności z PCI DSS, a nie dobra praktyka, którą można odłożyć.

Wytyczne zalecają też stosowanie mechanizmów antyphishingowych w całej organizacji, a nie tylko w systemach, które przechowują lub przetwarzają dane kart. DMARC robi to domyślnie: jedna polityka DMARC obejmuje każdy adres w Twojej domenie, więc nie musisz wdrażać jej system po systemie.

Jeśli nie DMARC, to co innego mogłoby spełnić ten wymóg?

To oczywiste pytanie, bo standard nie wymienia DMARC. Wymóg 5.4.1 dotyczy ochrony Twoich ludzi przed phishingiem, więc część z niego możesz spełnić innymi narzędziami: bezpieczną bramą poczty, filtrem antyphishingowym, skanowaniem odnośników i załączników albo zautomatyzowanym szkoleniem z zakresu świadomości bezpieczeństwa. Większość firm przyjmujących płatności kartą korzysta już z części z nich i warto je zachować.

Ale te narzędzia sprawdzają pocztę dopiero w momencie, gdy trafia do Twoich własnych skrzynek odbiorczych. Nic nie robią, żeby powstrzymać atakującego przed sfałszowaniem Twojej domeny w polu nadawcy, by łowić phishingiem Twoich klientów, partnerów czy pracowników. Jedynym praktycznym sposobem na powstrzymanie takiego fałszowania domeny jest uwierzytelnianie poczty: SPF, DKIM i DMARC działające razem. Nie ma tu realnego zamiennika. Dlatego wytyczne PCI wymieniają całą trójkę i dlatego audytor spodziewa się ich zobaczyć, mimo że sam wymóg nigdy ich nie wyszczególnia.

Czy rekord DMARC działający tylko w trybie monitorowania wystarczy?

Opublikowanie rekordu DMARC to nie to samo co jego egzekwowanie i właśnie tutaj wiele firm nie sięga tego, do czego dąży ten wymóg.

Rekord DMARC ustawiony na p=none działa w trybie monitorowania. Mówi serwerom odbiorczym, by raportowały pocztę, która nie przechodzi uwierzytelniania, ale i tak ją dostarczały. Zyskujesz widoczność, co jest przydatne, ale sfałszowana wiadomość podająca się za wysłaną z Twojej domeny wciąż trafia do skrzynki odbiorczej. Nic nie jest blokowane. Jako mechanizm antyphishingowy rekord p=none powstrzymuje zero ataków.

Aby zablokować sfałszowaną pocztę, potrzebujesz DMARC w trybie egzekwowania: p=quarantine kieruje wiadomości, które nie przeszły uwierzytelniania, do spamu, a p=reject odrzuca je całkowicie. Egzekwowanie to coś, co powstrzymuje kogoś przed sfałszowaniem Twojej domeny w celu łowienia phishingiem Twoich klientów lub pracowników. PCI nie wskazuje wymaganego poziomu polityki, więc jest to nasza interpretacja, a nie zapis w standardzie. Ale rekord DMARC, który niczego nie blokuje, trudno obronić przed audytorem jako mechanizm antyphishingowy.

To tutaj większość domen jest narażona. W raporcie branżowym DMARCeye za Q1 2026, spośród domen publikujących DMARC, 36,7% jest ustawionych na p=none, 36,8% na p=quarantine, a 26,5% na p=reject. Ponad jedna trzecia publikuje rekord DMARC, który niczego nie blokuje, bo jest ustawiony wyłącznie na monitorowanie. Nasza pełna analiza luki w egzekwowaniu zawiera kompletne liczby pokazujące, ile domen nigdy nie wychodzi poza monitorowanie.

Wpisz swoją domenę, aby zobaczyć swoją obecną politykę DMARC i sprawdzić, czy jest ustawiona na egzekwowanie:

Co powinieneś zrobić, jeśli przyjmujesz płatności kartą?

Po pierwsze, ustal, kto za to odpowiada. Opublikowanie i zaostrzenie rekordu DMARC to zadanie z obszaru DNS i uwierzytelniania poczty, a nie marketingu. W większej firmie należy do IT lub bezpieczeństwa. W małej firmie zwykle spada na tego, kto zarządza Twoją domeną: Twojego wykonawcę IT, dostawcę hostingu albo agencję obsługującą Twoją pocztę i DNS. Jeśli odpowiadasz za zgodność z PCI, ale sam nie zarządzasz DNS, Twoim zadaniem jest zlecić to właściwej osobie i potwierdzić, że zostało wykonane przed Twoją oceną.

Kroki techniczne, po kolei:

1. Opublikuj SPF i DKIM dla każdej usługi, która wysyła pocztę z Twojej domeny. DMARC zależy od obu.
2. Opublikuj rekord DMARC na p=none, aby zacząć zbierać raporty bez wpływu na dostarczanie.
3. Przejrzyj raporty, aby znaleźć każdego legalnego nadawcę, w tym Twojego operatora płatności, platformę e-mailową, CRM i helpdesk. Narzędzie monitorujące, takie jak darmowy plan DMARCeye, zamienia te surowe raporty w czytelną listę nadawców.
4. Przejdź na p=quarantine, a potem na p=reject, gdy raporty pokazują już tylko nadawców, których rozpoznajesz. To ustawienie spełnia intencję antyphishingową.
5. Zachowaj dowody. Audytor będzie chciał zobaczyć Twoją politykę DMARC i potwierdzić, że jest ustawiona na egzekwowanie, więc zapisz politykę i datę, w której osiągnąłeś egzekwowanie.

Pułapka, której należy unikać, to przeskoczenie do p=reject, zanim zmapujesz swoich nadawców. Włącz egzekwowanie zbyt wcześnie, a legalna poczta, w tym potwierdzenia płatności, na które czekają Twoi klienci, zaczyna być blokowana. Nasz kompletny przewodnik wdrażania DMARC krok po kroku omawia przejście do egzekwowania.

Jak to się ma do reguł Google, Yahoo i Microsoftu?

PCI DSS to nie jedyna siła popychająca firmy w stronę egzekwowania DMARC. Od 2024 r. Google i Yahoo wymagają od nadawców masowych publikowania DMARC, a Microsoft od tego czasu postawił to samo oczekiwanie wobec nadawców o dużym wolumenie kierujących pocztę do Outlooka i Hotmaila. Główni dostawcy skrzynek pocztowych i standard płatności oczekują teraz tego samego: uwierzytelnij swoją pocztę i powstrzymaj innych przed fałszowaniem Twojej domeny.

Dla firmy, która przyjmuje płatności kartą i jednocześnie wysyła pocztę marketingową lub transakcyjną, jeden projekt pokrywa oba obowiązki. Egzekwowanie DMARC, które wdrażasz dla PCI, to ten sam mechanizm, którego oczekują dostawcy skrzynek pocztowych. Nasz przewodnik po wymaganiach Google i Yahoo wobec nadawców szczegółowo omawia tę stronę zagadnienia.

Podsumowanie

PCI DSS v4.0.1 nie dodał DMARC do swojej listy wymaganych mechanizmów kontroli i powinieneś podchodzić ostrożnie do każdego, kto mówi, że było inaczej. To, co faktycznie zrobił, to uczynił ochronę antyphishingową obowiązkową i wskazał DMARC, SPF oraz DKIM jako sposób jej zapewnienia. Najbardziej liczy się egzekwowanie: rekord DMARC na p=none dokumentuje problem, a p=quarantine lub p=reject go rozwiązuje.

DMARCeye czyta raporty DMARC, które otrzymuje Twoja domena, i pokazuje Ci prostym językiem, którzy nadawcy są legalni i kiedy można bezpiecznie przejść na egzekwowanie, tak aby krok od monitorowania do zgodności nie zepsuł poczty, na której polegają Twoi klienci.