Rekord DMARC może wyglądać jak postęp w email security, a jednocześnie prawie niczego nie blokować. To niewygodny wniosek z danych CipherCue: w zbiorze 67,336 company domains sprawdzonych między 14 kwietnia a 28 lipca 2026 roku 68.4% nie miało DMARC record albo nadal było na p=none.

DMARC email policy przechodzi od monitoring do quarantine i reject gates

To nie jest nowa luka. To niedokończona kontrola. DMARC jest publiczny od 2012 roku, a w maju 2026 IETF zastąpił RFC 7489 dokumentami RFC 9989, RFC 9990 i RFC 9991. Core protocol ma teraz status Standards Track Proposed Standard. Problemem jest ostatni etap: przejście od „zbieramy raporty” do „prosimy odbiorców o odrzucanie fałszywego użycia naszej domeny”.

DMARC jest użyteczny, ale nie jest magiczną ochroną przed phishingiem. Pomaga przeciw exact-domain spoofing w widocznym From. Nie zatrzyma lookalike domains, display-name spoofing, przejętych prawdziwych kont ani phishingu wysłanego z dużej platformy z poprawną autentykacją.

DMARC działa nad SPF i DKIM. SPF mówi, które serwery mogą wysyłać dla domeny. DKIM podpisuje wiadomości kluczem domeny. DMARC sprawdza, czy uwierzytelniona tożsamość jest aligned z visible From domain, i mówi odbiorcom, co zrobić przy fail.

Typowe policies są trzy. p=none monitoruje i tworzy reports. p=quarantine prosi o potraktowanie złych wiadomości jako podejrzanych. p=reject prosi o odrzucenie. Odbiorcy zachowują własną decyzję, ale różnica jest jasna: p=none to alarm zapisujący logi, nie zamknięte drzwi.

W snapshot CipherCue 30,362 domains, czyli 45.1%, nie miało DMARC record. Wśród domen z rekordem 15,709 było na p=none, 10,258 na p=quarantine, a 10,963 na p=reject. CipherCue liczy enforcement jako p=quarantine lub p=reject, więc 46,071 domains w sample było non-enforcing.

Liczby wymagają ostrożności. CipherCue opisuje tracked entity set, nie reprezentatywną próbę wszystkich firm na świecie. W komentarzach Hacker News padło też rozsądne pytanie: ile domen było parked, inactive, send-only albo bez normalnych MX records? To nie usuwa problemu, ale ogranicza zbyt szerokie wnioski.

Luka trwa, bo p=reject to nie tylko zmiana DNS. To inwentaryzacja.

Firma musi znać wszystkie legalne źródła poczty: Microsoft 365 lub Google Workspace, CRM, marketing automation, billing, helpdesk, HR tools, ticketing, stare serwery, skanery, usługodawców i zapomniane aplikacje. Każdy strumień potrzebuje SPF lub DKIM alignment. Unknown senders trzeba naprawić, przenieść na subdomain albo wyłączyć.

Raporty też są problemem. DMARC aggregate reports, opisane teraz w RFC 9990, to XML dla maszyn. Dla małej organizacji, która skopiowała przykład DNS record, może to być stos plików bez decyzji.

Strach przed zepsuciem legalnej poczty jest realny. Jeśli system faktur nie przechodzi DKIM alignment, p=reject może zgubić faktury. Jeśli support platform wysyła z błędną trasą, enforcement może skończyć się skargami klientów. Nikt nie chce poprawić bezpieczeństwa i zepsuć password resets.

Microsoft w styczniu 2026 opisał phishing wykorzystujący complex routing i misconfigured spoof protections. Wniosek praktyczny: routing, connectors, forwarding i gateways zmieniają to, jak authentication wygląda po stronie odbiorcy.

Bezpieczna ścieżka jest stopniowa. Najpierw inventory domen: primary sending domains, marketing subdomains, transactional subdomains, parked domains i domeny, które nigdy nie powinny wysyłać poczty. Dla no-send domains SPF v=spf1 -all i DMARC p=reject; sp=reject często zamykają prosty wektor nadużyć.

Dla active domains p=none powinno być tylko temporary monitoring phase. Ustaw reporting address, który ktoś czyta, i narzędzie zamieniające XML w decyzje. Potem napraw alignment, zwłaszcza DKIM dla usług zewnętrznych i forwarded mail.

Następnie idź etapami: p=none, p=quarantine, p=reject. Obserwuj helpdesk tickets, bounce logs, deliverability dashboards i DMARC reports. Dla każdego sender zapisz owner, platform, domain/subdomain, authentication method i rollback contact.

DMARC nie usuwa phishingu. Enforcement usuwa jednak tani trik: wiadomość wygląda, jakby wyszła prosto z twojej domeny, mimo że authentication fails. p=none jest dobre jako faza nauki; jako stan końcowy to kontrola, która patrzy, ale nie blokuje.