SPF, DKIM i DMARC: wdrożenie w firmie

Księgowa klienta otrzymuje fakturę od znanego dostawcy. Zgadza się nazwa firmy, kwota, numer dokumentu i podpis handlowca. W polu nadawcy widzi k.nowak@twojafirma.pl. Zmieniony jest tylko rachunek bankowy. Przelew wychodzi tego samego dnia, a informacja o oszustwie pojawia się kilka tygodni później.

W tym samym czasie prawdziwa oferta wysłana przez Waszego handlowca trafia do spamu. Serwer działa, kolejka jest pusta, a monitoring SMTP nie pokazuje awarii. Problem nie dotyczy dostępności poczty, lecz zaufania do domeny i poprawności jej uwierzytelniania.

SPF, DKIM i DMARC pozwalają odbiorcy sprawdzić trzy rzeczy: czy serwer miał prawo użyć domeny w kopercie SMTP, czy wiadomość została podpisana przez uprawnioną domenę oraz czy przynajmniej jedna z tych zweryfikowanych domen jest zgodna z adresem widocznym w polu From:. Dopiero komplet tych mechanizmów daje właścicielowi domeny realny wpływ na ograniczenie spoofingu własnej nazwy.

Trzeba jednak od razu postawić granicę: DMARC nie jest gwarancją dostarczenia prawidłowej poczty ani bezwarunkową blokadą każdej fałszywej wiadomości. Zgodnie z aktualnym RFC 9989 ostateczne postępowanie zależy od lokalnej polityki odbiorcy. Dobrze wdrożony DMARC znacząco ogranicza skuteczne podszywanie się pod dokładną domenę i dostarcza danych potrzebnych do wykrywania nadużyć, ale pozostaje jednym z elementów systemu antyphishingowego.

Co naprawdę chronią SPF, DKIM i DMARC

Poczta elektroniczna posługuje się kilkoma tożsamościami, które użytkownik zwykle odbiera jako jeden adres.

RFC5321.MailFrom, potocznie MAIL FROM albo envelope sender, jest adresem koperty SMTP. Po dostarczeniu zwykle pojawia się jako Return-Path.
RFC5322.From jest nagłówkiem wyświetlanym użytkownikowi jako nadawca wiadomości.
DKIM Signing Domain to domena z tagu d= w poprawnie zweryfikowanym podpisie DKIM.
HELO/EHLO identyfikuje host nawiązujący sesję SMTP i ma szczególne znaczenie, gdy koperta zawiera pusty reverse-path, na przykład w wiadomościach zwrotnych.

SPF może uwierzytelnić domenę z MAIL FROM albo nazwę HELO/EHLO, lecz DMARC wykorzystuje wynik SPF odnoszący się do domeny koperty. Gdy reverse-path jest pusty, SPF wyprowadza tę tożsamość z HELO/EHLO zgodnie z regułą postmaster@HELO. DKIM uwierzytelnia domenę podpisującą z tagu d=. DMARC porównuje domenę SPF lub DKIM z domeną widocznego nagłówka From: i sprawdza alignment, czyli zgodność identyfikatorów.

Trzy ataki, których nie wolno ze sobą mylić

Spoofing dokładnej domeny. Wiadomość ma From: prezes@twojafirma.pl, ale została wysłana z infrastruktury nieuprawnionej przez właściciela domeny. SPF, DKIM i DMARC są projektowane właśnie dla tego przypadku. Polityka p=reject informuje odbiorców, że wiadomości niespełniające DMARC powinny zostać odrzucone, choć odbiorca może zastosować lokalny wyjątek.

Domena podobna wizualnie. Adres pochodzi z twojaflrma.pl, twojafirma-pl.com albo domeny zapisanej znakami podobnymi do łacińskich. Atakujący kontroluje tę nazwę i może poprawnie skonfigurować dla niej SPF, DKIM oraz DMARC. Ochrona wymaga monitorowania podobnych domen, filtrów antyphishingowych i procedur biznesowych, na przykład niezależnego potwierdzania zmiany rachunku bankowego.

Przejęte konto lub legalna platforma. Wiadomość wysłana z przejętej skrzynki, zhakowanego systemu CRM albo skradzionym kluczem DKIM może poprawnie przejść wszystkie trzy mechanizmy. DMARC potwierdza, że domena została użyta w sposób kryptograficznie lub infrastrukturalnie autoryzowany. Nie potwierdza uczciwości nadawcy ani bezpieczeństwa treści. Ten scenariusz ograniczają MFA, ochrona sesji, analiza nietypowych logowań i procedura reagowania opisana w artykule o pierwszych 60 minutach incydentu bezpieczeństwa.

SPF: autoryzacja domeny w kopercie SMTP

SPF opisuje RFC 7208. Rekord publikuje się jako TXT; dawny typ zasobu DNS SPF nie jest używany.

example.com. IN TXT "v=spf1 mx a:smtp.example.com include:_spf.example-provider.net ip4:203.0.113.10 -all"

Ewaluacja przebiega od lewej do prawej i kończy się na pierwszym pasującym mechanizmie. ip4 oraz ip6 wskazują adresy i sieci, a odwołuje się do adresów przypisanych nazwie, mx do hostów obsługujących pocztę przychodzącą, a include uruchamia sprawdzenie polityki innej domeny.

redirect= nie jest mechanizmem, lecz modyfikatorem: zastępuje całą politykę polityką wskazanej domeny i jest oceniany dopiero wtedy, gdy żaden mechanizm w rekordzie się nie dopasował, niezależnie od miejsca zapisu w rekordzie. Obecność all gdziekolwiek w rekordzie unieważnia redirect= całkowicie, więc w rekordzie zakończonym -all dopisany modyfikator zostanie zignorowany bez sygnalizowania błędu. Jeżeli wskazana domena nie ma rekordu SPF, wynikiem jest permerror, a nie none.

Kwalifikator przy mechanizmie all określa wynik dla pozostałych źródeł:

-all zwraca fail i jest właściwym ustawieniem docelowym po pełnej inwentaryzacji nadawców,
~all zwraca softfail i bywa używany podczas porządkowania konfiguracji,
?all zwraca neutral,
+all autoryzuje każdy adres IP i praktycznie unieważnia ochronę SPF.

Sam wynik SPF nie rozstrzyga, czy wiadomość zostanie przyjęta. Jest sygnałem dla polityki odbiorcy oraz jednym z identyfikatorów wykorzystywanych przez DMARC.

Jeden rekord SPF i limit dziesięciu terminów DNS

Dla jednej nazwy DNS może istnieć dokładnie jeden rekord TXT rozpoczynający się od v=spf1. Opublikowanie dwóch oddzielnych rekordów SPF powoduje permerror. Jeden rekord może być w pliku strefy zapisany jako kilka sąsiadujących ciągów tekstowych, które DNS składa w jedną wartość. Limit 255 oktetów dotyczy pojedynczego ciągu, a nie całego rekordu.

RFC 7208 ogranicza do dziesięciu łączną liczbę terminów, które podczas ewaluacji mogą powodować zapytania DNS. Do limitu należą include, a, mx, ptr, exists oraz redirect. Mechanizmy ip4, ip6 i all nie zużywają tej puli. Limit obejmuje również zapytania wykonywane rekurencyjnie wewnątrz rekordów wskazanych przez include.

Przekroczenie limitu daje permerror, a nie softfail. Przy mechanizmie mx do puli dziesięciu terminów wlicza się liczba odpytanych rekordów MX, a nie sam mechanizm liczony jako jeden termin. Domena z kilkunastoma hostami pocztowymi potrafi więc wyczerpać cały limit jednym mx. Tak samo przy mechanizmie ptr oraz makrze %{p} do tej puli wlicza się liczba odpytanych rekordów PTR.

Osobno obowiązuje limit adresowy: ewaluacja każdego pojedynczego rekordu MX nie może pociągnąć za sobą odpytania więcej niż dziesięciu rekordów adresowych A lub AAAA, a przekroczenie tego progu daje permerror. W tym drugim limicie liczy się liczba adresów przypadająca na jeden host MX, a nie ich suma dla wszystkich hostów. Analogiczny limit adresowy obowiązuje dla ptr, ale ze skutkiem odmiennym, ponieważ rekordy poza pierwszymi dziesięcioma są ignorowane zamiast dawać błąd. RFC 7208 tłumaczy tę różnicę tym, że zawartość rekordów MX kontroluje właściciel domeny publikującej politykę, a zawartość rekordów PTR — właściciel łączącego się adresu IP. Niezależnie od tego implementacje powinny ograniczać tak zwane void lookups, czyli odpowiedzi NXDOMAIN i puste odpowiedzi pozytywne, do dwóch.

dig +short TXT example.com

Wynik trzeba analizować rekurencyjnie, ponieważ samo policzenie słów include: w rekordzie głównym nie pokazuje rzeczywistego kosztu DNS.

Jak zmniejszyć złożoność SPF bez tworzenia nowego ryzyka

Najbezpieczniejsza kolejność działań wygląda następująco:

Usuń dostawców, z których firma już nie wysyła.
Zastąp szerokie mechanizmy a i mx konkretnymi adresami, jeżeli ich użycie nie jest faktycznie potrzebne.
Rozdziel ruch transakcyjny, marketingowy i techniczny na kontrolowane subdomeny z własnymi rekordami.
Zweryfikuj u dostawcy, czy jego dokumentowany rekord include jest aktualny i przeznaczony dla danego produktu.
Traktuj SPF flattening jako rozwiązanie wymagające automatycznej synchronizacji i monitorowania, a nie jednorazowe skopiowanie adresów IP.

Ręczne spłaszczenie include do listy ip4 lub ip6 usuwa zależność od kolejnych lookupów, ale przenosi odpowiedzialność za aktualizację sieci dostawcy na administratora domeny. Nieaktualny rekord może blokować prawidłową pocztę albo pozostawić autoryzację dla wycofanych adresów.

Dlaczego SPF często przestaje działać po przekazaniu wiadomości

Forwarder wysyła wiadomość z własnego adresu IP, zachowując oryginalny envelope sender. Nowy adres IP zwykle nie znajduje się w SPF pierwotnej domeny, więc wynik przestaje być pass: przy -all będzie to fail, przy ~all softfail, a przy ?all lub rekordzie bez all i redirect= neutral. Dla DMARC różnica nie ma znaczenia, ponieważ alignment wymaga wyniku SPF pass. Mechanizm SRS może przepisać kopertę i przywrócić poprawny SPF dla domeny forwardera, ale nie jest wdrażany wszędzie.

Z tego powodu odporność na zwykłe przekierowanie powinna opierać się przede wszystkim na poprawnym, zgodnym DKIM. Sam SPF nie jest wystarczającą podstawą dla DMARC w środowisku, w którym wiadomości przechodzą przez pośredników.

DKIM: kryptograficzne powiązanie wiadomości z domeną

DKIM opisuje RFC 6376, wymagania dotyczące algorytmów i długości kluczy uzupełnia RFC 8301, a algorytm Ed25519-SHA256 wprowadza RFC 8463. Serwer nadawczy liczy dwa niezależne skróty: jeden z treści, drugi z wybranych nagłówków. Skrót treści trafia do tagu bh=, a kluczem prywatnym podpisywany jest wyłącznie skrót nagłówkowy. Obejmuje on jednak również sam nagłówek DKIM-Signature razem z tagiem bh=, z pominięciem wartości b=, więc treść jest chroniona pośrednio. Gotowy podpis trafia do tagu b=. Dlatego modyfikacja samej treści daje przy weryfikacji niezgodny skrót treści mimo nienaruszonych nagłówków. Odbiorca pobiera klucz publiczny z DNS spod nazwy złożonej z selektora i domeny podpisującej.

mail2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Selektor z tagu s= umożliwia równoległe używanie wielu kluczy i bezpieczną rotację. Domena z tagu d= jest identyfikatorem uwierzytelnianym przez DKIM i to ona bierze udział w sprawdzaniu alignmentu DMARC.

Długość klucza, algorytm i rotacja

RSA 2048 bitów pozostaje szeroko interoperacyjnym ustawieniem domyślnym. RFC 8301 wymaga obsługi co najmniej 1024 bitów i zaleca 2048 bitów, a Google również rekomenduje 2048 bitów, jeżeli dostawca DNS i platforma pocztowa je obsługują. RFC 8301 zabrania używania rsa-sha1 do podpisywania i weryfikacji, a podpisywać nakazuje algorytmem rsa-sha256. Podpis wykonany rsa-sha1 ma trwale nieudany wynik weryfikacji, a sha1 figuruje w rejestrze IANA ze statusem historycznym.

Ed25519-SHA256 oferuje krótsze klucze przy wysokim poziomie bezpieczeństwa, ale przed wdrożeniem trzeba potwierdzić obsługę po stronie platformy wysyłkowej, bibliotek podpisujących i istotnych odbiorców. Bezpieczna migracja może polegać na równoległym dodaniu podpisów RSA-SHA256 i Ed25519-SHA256 z oddzielnymi selektorami. Podpisu RSA nie należy usuwać, dopóki pomiary nie potwierdzą akceptowalnej interoperacyjności nowego algorytmu.

Nie ma jednej poprawnej częstotliwości rotacji dla każdej firmy. Harmonogram powinien wynikać z modelu ryzyka, możliwości dostawcy i procedur zarządzania sekretami. Klucz należy wymienić niezwłocznie po podejrzeniu ujawnienia, nieautoryzowanym dostępie, wycofaniu platformy albo zmianie odpowiedzialnego zespołu. Rotacja okresowa ogranicza czas użycia jednego sekretu, ale musi być wykonywana według przetestowanego runbooka.

Prawidłowa kolejność jest zawsze taka sama:

Wygeneruj nową parę kluczy pod nowym selektorem.
Opublikuj klucz publiczny i poczekaj co najmniej przez czas wynikający z TTL oraz propagacji DNS.
Potwierdź dostępność rekordu z niezależnych resolverów.
Przełącz podpisywanie na nowy selektor.
Obserwuj raporty DMARC i nagłówki wiadomości.
Usuń stary klucz dopiero po wygaśnięciu wiadomości, które mogły zostać nim podpisane i nadal pozostawać w kolejkach.

Klucz prywatny należy chronić tak samo jak klucz SSH lub sekret aplikacyjny. Zasady przechowywania takich danych opisujemy szerzej w materiale o kontroli poświadczeń i dostępu administracyjnego w Linuxie.

Kanonikalizacja i nagłówki objęte podpisem

Kanonikalizacja określa, jaką zmianę formatowania podpis toleruje. simple zachowuje wysoką wrażliwość na modyfikacje, a relaxed normalizuje część różnic w białych znakach i zapisie nazw nagłówków.

Dla zwykłej poczty biznesowej relaxed/relaxed jest najczęściej najlepszym wyborem operacyjnym, ponieważ lepiej znosi nieistotne zmiany po drodze. Nie jest jednak jedyną poprawną konfiguracją. System wysyłający niezmienne dokumenty transakcyjne, które nie przechodzą przez modyfikujących pośredników, może świadomie wybrać bardziej restrykcyjne ustawienie.

Nagłówek From musi być podpisany. W praktyce warto podpisywać również nagłówki wpływające na interpretację i prezentację wiadomości, między innymi Date, Subject, Reply-To, Sender, To, Cc, Message-ID, nagłówki MIME oraz nagłówki rezygnacji z subskrypcji. Nie należy podpisywać pól normalnie modyfikowanych w transporcie, takich jak Return-Path i Received.

Ważne nagłówki warto też objąć tak zwanym oversigningiem, czyli umieścić ich nazwę w h= o jeden raz więcej, niż występuje w wiadomości. Dzięki temu późniejsze dołożenie drugiego From, Reply-To albo Subject unieważni podpis. To ogranicza klasę ataków wykorzystujących różnice w sposobie prezentowania powtórzonych nagłówków przez klientów pocztowych.

Tag l=, ograniczający podpis do początkowej części treści, powinien być unikany. Pozwala on dopisać dane poza podpisanym fragmentem bez unieważnienia DKIM.

DKIM może przetrwać forwarding, ale nie każdą modyfikację

Zwykłe przekazanie, które dodaje wyłącznie Received i zmienia kopertę, zwykle pozostawia podpis ważny. Stopka listy dyskusyjnej, banner bezpieczeństwa, przepisanie odnośników, zmiana tematu albo konwersja MIME mogą go unieważnić. Dlatego nie należy pisać, że DKIM zawsze „przeżywa” forwarding. Poprawne stwierdzenie brzmi: DKIM może zachować ważność po przekazaniu, o ile pośrednik nie zmieni podpisanej treści ani podpisanych nagłówków.

DMARC: alignment z adresem widocznym dla odbiorcy

Od maja 2026 aktualnym standardem jest RFC 9989, który zastąpił RFC 7489 i RFC 9091. Raporty zbiorcze opisuje RFC 9990, a raporty dotyczące pojedynczych niepowodzeń RFC 9991. W rekordzie nadal używa się v=DMARC1.

DMARC daje wynik pass, jeżeli co najmniej jeden z następujących warunków jest spełniony:

SPF zwrócił pass, a uwierzytelniona domena RFC5321.MailFrom jest zgodna z domeną RFC5322.From,
DKIM zwrócił pass, a domena d= co najmniej jednego poprawnego podpisu jest zgodna z domeną RFC5322.From.

Tryb relaxed, domyślny dla aspf i adkim, porównuje domeny organizacyjne. Tryb strict wymaga identycznych nazw. Dlatego bounce.mail.example.com może być zgodne z example.com w trybie relaxed, ale nie w strict.

Wynik DMARC pass mówi wyłącznie, że użycie domeny z From: zostało autoryzowane. Nie oznacza, że treść jest bezpieczna, konto nie zostało przejęte ani że wiadomość trafi do skrzynki odbiorczej.

Polityki p, sp, np i nowy tryb testowy

Najprostszy rekord obserwacyjny wygląda tak:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Tag p= może mieć trzy wartości:

none nie zmienia istniejącego sposobu obsługi wiadomości i służy do monitorowania,
quarantine wyraża preferencję, aby wiadomość z wynikiem DMARC fail została potraktowana podejrzliwie, zwykle skierowana do spamu,
reject wyraża preferencję, aby wiadomość z wynikiem fail została odrzucona.

Ostateczna decyzja zawsze należy do odbiorcy. RFC 9989 dopuszcza przyjęcie wiadomości mimo p=reject, na przykład ze względu na wiarygodnego pośrednika, listę dyskusyjną lub inne lokalne informacje. Odbiorca może również odrzucić wiadomość, która przechodzi DMARC, jeżeli inne filtry wykryją nadużycie.

sp= określa politykę dla istniejących subdomen, gdy zastosowany rekord pochodzi z domeny organizacyjnej. np= dotyczy nieistniejących subdomen. Kolejność dziedziczenia bywa myląca: przy braku sp= istniejące subdomeny przejmują wartość z p=, natomiast przy braku np= nieistniejące subdomeny przejmują wartość z sp=, jeżeli jest obecny, i dopiero w jego braku z p=. Dlatego rekord p=none; sp=quarantine bez np= obejmuje nieistniejące subdomeny polityką quarantine, a nie none.

RFC 9989 usunął pct i wprowadził t=. Wartość t=y prosi zgodnego odbiorcę o zastosowanie polityki o jeden poziom łagodniejszej: quarantine jest traktowane jak none, a reject jak quarantine. Starszy odbiorca, który nie zna t, powinien zignorować nieznany tag i może zastosować pełną politykę. Nie wolno więc traktować t=y jako gwarantowanego bezpiecznika wdrożenia.

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; t=y; rua=mailto:dmarc@example.com"

Raporty rua i ruf

rua= wskazuje adresy raportów zbiorczych. To podstawowe źródło danych do wdrożenia i utrzymania DMARC. Odbiorcy nie mają obowiązku wysyłania raportów, choć uczestniczący dostawcy powinni robić to co najmniej raz na 24 godziny.

ruf= dotyczy raportów o pojedynczych niepowodzeniach. Mogą zawierać dane z wiadomości, są wysyłane przez mniejszą liczbę operatorów i wymagają oceny prywatności oraz podstawy retencji. W większości wdrożeń warto zacząć od rua, a ruf uruchamiać tylko wtedy, gdy istnieje konkretny cel diagnostyczny i procedura ochrony danych.

Gdy raporty mają trafiać do innej domeny organizacyjnej, odbiorca raportów musi autoryzować taką relację. Jeżeli old-example.com wysyła raporty do dmarc@example.com, w domenie example.com potrzebny jest rekord:

old-example.com._report._dmarc.example.com. IN TXT "v=DMARC1"

Brak autoryzacji zewnętrznego adresu jest częstą przyczyną sytuacji, w której poprawnie wyglądający rekord nie generuje żadnych raportów.

DNS Tree Walk w RFC 9989

Nowy standard ustala domenę organizacyjną przez kontrolowane przejście po drzewie DNS zamiast polegania wyłącznie na zewnętrznej liście publicznych sufiksów. Liczba zapytań jest ograniczona do ośmiu. Ma to znaczenie przede wszystkim przy rozbudowanych strukturach subdomen i delegowaniu odpowiedzialności za polityki pocztowe.

Audyt przed zmianą DNS: inwentaryzacja wszystkich nadawców

Największym ryzykiem nie jest literówka w rekordzie. Jest nim legalny system, o którym nikt nie pamiętał. Przed wdrożeniem trzeba zinwentaryzować każdy strumień używający firmowej domeny w From::

główną platformę pocztową,
system ERP i fakturowanie,
CRM, helpdesk i narzędzia marketingowe,
sklep internetowy i aplikacje transakcyjne,
formularze WWW,
serwery monitoringu, backupu i automatyzacji,
urządzenia wielofunkcyjne,
platformy rekrutacyjne,
agencje oraz podwykonawców wysyłających w imieniu firmy.

Dla każdego źródła należy zapisać:

domenę w From:,
domenę RFC5321.MailFrom widoczną jako Return-Path,
domenę d= podpisu DKIM,
adresy IP lub rekord include używany przez SPF,
selektor DKIM i właściciela klucza,
typ wiadomości oraz przybliżony wolumen,
osobę odpowiedzialną biznesowo i technicznie,
sposób wyłączenia źródła w razie incydentu.

Brak właściciela integracji jest sygnałem shadow IT działającego poza kontrolą firmy. Nie należy przechodzić do egzekwowania polityki, dopóki każdy legalny strumień nie ma co najmniej jednej zgodnej ścieżki DMARC.

Bezpieczne wdrożenie DMARC etapami

Kalendarz nie powinien być jedynym kryterium przejścia. Firma wysyłająca niewielką liczbę wiadomości może potrzebować dłuższego okresu obserwacji, ponieważ raporty będą mniej reprezentatywne. Lepsze są mierzalne warunki wyjścia z każdego etapu.

Etap 1: punkt odniesienia

Zapisz aktualne rekordy i ich TTL.
Potwierdź, że każda nazwa ma najwyżej jeden rekord SPF.
Sprawdź rekurencyjny koszt DNS.
Wyślij próbki ze wszystkich znanych systemów do kilku niezależnych operatorów.
Zarchiwizuj pełne nagłówki i wyniki Authentication-Results.

Etap 2: p=none i analiza raportów

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Raporty powinny być przetwarzane maszynowo. Kryterium przejścia nie może brzmieć „minęły dwa tygodnie”. Należy potwierdzić, że:

wszystkie legalne źródła są rozpoznane,
każde legalne źródło przechodzi DMARC przez zgodny DKIM lub SPF,
nie ma powtarzalnego legalnego ruchu o nieznanym właścicielu,
zespół potrafi odróżnić forwarding i lokalne wyjątki od błędnej konfiguracji.

Etap 3: kontrolowane egzekwowanie

Można użyć p=quarantine; t=y, ale wyłącznie ze świadomością, że starsi odbiorcy mogą nie obsługiwać t i zastosować kwarantannę bez złagodzenia. Przed publikacją należy obniżyć TTL z odpowiednim wyprzedzeniem, odczekać poprzedni TTL i przygotować procedurę wycofania zmiany. Po stabilizacji warto przywrócić normalny, dłuższy TTL.

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com"

Następnie usuwa się t=y i obserwuje pełne quarantine. Dopiero na podstawie charakteru domeny oraz rzeczywistych przepływów podejmuje się decyzję, czy kolejnym krokiem ma być reject.

Czy p=reject jest właściwym celem dla każdej domeny?

Nie. RFC 9989 wyraźnie ostrzega przed p=reject w domenach poczty ogólnego przeznaczenia, których użytkownicy wysyłają wiadomości na listy dyskusyjne, używają aliasów przekazujących albo uczestniczą w innych pośrednich przepływach. Taka poczta może być legalna, lecz po modyfikacji przez pośrednika utracić DKIM i nie przejść SPF. W takim środowisku p=quarantine może pozostać świadomą polityką docelową, a ruch o innych wymaganiach warto wydzielić do kontrolowanych subdomen.

p=reject jest znacznie lepszym kandydatem dla domen niewysyłających poczty, domen transakcyjnych o zamkniętym zestawie nadawców oraz strumieni, dla których firma kontroluje zgodny DKIM i potwierdziła brak problematycznych przepływów pośrednich. Jeżeli domena ogólnego przeznaczenia mimo tych ograniczeń ma dojść do reject, RFC 9989 zaleca co najmniej miesiąc obserwacji z p=none, a następnie równie długi okres z p=quarantine. To minimalny czas obserwacji, a nie automatyczna zgoda na zmianę polityki: nadal trzeba przeanalizować każdy istotny legalny strumień. Przykładowy rekord dla domeny, która spełniła te warunki, może wyglądać następująco:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.com"

Warunkiem wejścia w reject jest brak legalnego, powtarzalnego ruchu z wynikiem DMARC fail, odporność zapewniana przez zgodny DKIM oraz udokumentowana ocena wpływu na forwarding, aliasy i listy dyskusyjne. Nie wystarczy arbitralny procent globalnego ruchu. Pojedyncze błędy trzeba analizować według ich wpływu: jedna niedostarczona faktura może być ważniejsza niż tysiące prawidłowych newsletterów.

Jak czytać raport zbiorczy DMARC

Raport opisany w RFC 9990 zawiera dane zagregowane według źródła i wyników uwierzytelnienia. Nie należy zakładać, że otrzymacie raport od każdego odbiorcy ani że identyczne wiadomości będą klasyfikowane tak samo przez wszystkie systemy.

<record>
  <row>
    <source_ip>198.51.100.7</source_ip>
    <count>142</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>mailer.provider.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

source_ip wskazuje adres ostatniego nadawcy widzianego przez raportującego odbiorcę, a count liczbę wiadomości w danej grupie. auth_results pokazuje surowe wyniki SPF i DKIM. policy_evaluated uwzględnia alignment oraz lokalne przetwarzanie DMARC.

W przykładzie SPF ma pass dla mailer.provider.example, ale DMARC ocenia ścieżkę SPF jako niezgodną z header_from=example.com. To typowy przypadek poprawnego SPF dostawcy bez własnej, zgodnej domeny zwrotnej.

Atrybucja źródła nie może opierać się wyłącznie na PTR

PTR, WHOIS/RDAP i numer AS pomagają ustalić operatora sieci, ale nie dowodzą, że ruch jest legalny. Adres należący do znanej platformy może pochodzić z cudzego konta, przejętego tenantu albo niewłaściwie skonfigurowanej integracji. Adres z mało znanej sieci może należeć do legalnego podwykonawcy.

Każde nowe źródło należy potwierdzić przez co najmniej dwa niezależne ślady, na przykład:

zgodny selektor i domenę DKIM przypisaną do firmowego konta,
logi platformy lub identyfikator tenantu,
właściciela integracji w CMDB,
próbkę wiadomości wygenerowaną kontrolnie,
potwierdzenie adresów w oficjalnej dokumentacji dostawcy.

Dopiero wtedy źródło można uznać za autoryzowane. Zasady ewidencji takich zależności opisujemy w materiale o CMDB i dokumentacji infrastruktury IT.

Retencja raportów powinna wynikać z potrzeb operacyjnych, wymagań prawnych, polityki prywatności i zdolności do reagowania. Nie istnieje uniwersalny obowiązek przechowywania ich przez rok. W praktyce potrzebny jest okres pozwalający porównać zmiany infrastruktury, kampanie sezonowe i incydenty, bez gromadzenia danych bez określonego celu.

Weryfikacja rekordów i pełnych nagłówków

Podstawowe sprawdzenia DNS można wykonać lokalnie:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT mail2026._domainkey.example.com
dig +short MX example.com
dig +short -x 203.0.113.10

Selektor DKIM trzeba odczytać z tagu s= w DKIM-Signature prawdziwej wiadomości. Samo sprawdzenie domeny bez próbki wiadomości nie potwierdzi, czy platforma rzeczywiście podpisuje odpowiednim kluczem i czy podpis przechodzi po dostarczeniu.

W Polsce można użyć bezpłatnego narzędzia Bezpieczna Poczta CERT Polska, najlepiej wysyłając wiadomość testową. Taki test sprawdza więcej niż samo istnienie rekordów DNS.

Jak bezpiecznie czytać Authentication-Results

Format nagłówka definiuje RFC 8601. Przykład:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce@mailer.provider.example;
  dkim=pass header.d=mailer.provider.example header.s=s1;
  dmarc=fail header.from=example.com

Najważniejsza jest granica zaufania. Nagłówkom dopisanym przed przyjęciem wiadomości przez zaufany system odbiorcy nie wolno automatycznie ufać, ponieważ nadawca może sam wstawić fałszywe Authentication-Results. Analizę zaczyna się od nagłówka dodanego przez znany serwer odbiorczy i od pierwszego zaufanego wpisu Received.

Negatywny wynik nie dowodzi spoofingu. Może oznaczać legalnego nadawcę bez alignmentu, uszkodzony podpis, forwarding, listę dyskusyjną, błąd DNS albo wycofany selektor. Pozytywny wynik również nie dowodzi przejęcia skrzynki. Może pochodzić z legalnej wiadomości, przejętej platformy, skradzionego klucza albo systemu, który zgodnie z konfiguracją miał prawo wysyłać.

Do klasyfikacji incydentu potrzebne są równolegle:

pełny, zaufany łańcuch Received,
Authentication-Results z systemu odbiorcy,
logi wysyłki i logowania,
identyfikator wiadomości i ślady w kolejce,
historia zmian konfiguracji,
potwierdzenie właściciela integracji.

Postfix i DKIM na serwerze Linux

Serwer Linux wysyłający alerty, raporty lub wiadomości aplikacyjne jest pełnoprawnym źródłem poczty i musi znaleźć się w inwentaryzacji. Najprostsza oraz zwykle najbezpieczniejsza architektura polega na przekazywaniu wiadomości do centralnego serwera pośredniczącego SMTP przez port submission z TLS i uwierzytelnieniem. Ogranicza to liczbę publicznych adresów, kluczy DKIM i miejsc wymagających reputacji.

Przykład dla hosta, który nie przyjmuje poczty z sieci i wysyła wyłącznie wiadomości lokalnych aplikacji:

myhostname = app01.example.com
smtp_helo_name = app01.example.com
inet_interfaces = loopback-only
mynetworks = 127.0.0.0/8 [::1]/128

relayhost = [smtp.example.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = secure
smtp_tls_CApath = /etc/ssl/certs

inet_interfaces = loopback-only jest właściwe tylko wtedy, gdy serwer nie ma odbierać połączeń SMTP z innych hostów. Nie wolno kopiować tego ustawienia na bramę, serwer pośredniczący dla sieci ani serwer obsługujący pocztę przychodzącą.

Sama zmiana inet_interfaces nie zamyka nasłuchu po przeładowaniu usługi. Dokumentacja postconf(5) wymaga w tym przypadku zatrzymania i uruchomienia Postfiksa, ponieważ istniejące gniazda nasłuchu nie są przebudowywane. Efekt trzeba potwierdzić poleceniem ss -tlnp sport = :25, bo postfix check tego nie wykryje. Przeładowanie wystarcza dla zmian map i pozostałych parametrów tej konfiguracji.

Poziom encrypt wymusza szyfrowanie, ale nie uwierzytelnia serwera: Postfix dostarczy wiadomość również wtedy, gdy certyfikat jest niezaufany albo ma niewłaściwą nazwę, a smtp_tls_CApath nie wpływa wtedy na decyzję o dostarczeniu. Ponieważ smtp_sasl_security_options = noanonymous zastępuje domyślne noplaintext, noanonymous i dopuszcza mechanizmy przesyłające hasło jawnym tekstem, dla stałego serwera pośredniczącego właściwy jest weryfikujący poziom secure. Domyślne smtp_tls_secure_cert_match = nexthop, dot-nexthop porówna wtedy nazwę z certyfikatu z smtp.example.com wskazanym w relayhost. Jeżeli serwer pośredniczący używa certyfikatu z prywatnego CA, trzeba dodać ten urząd do zaufanego magazynu.

Plik mapy zawiera sekret. Uprawnienia trzeba nadać zarówno plikowi źródłowemu, jak i plikowi wygenerowanemu przez postmap:

umask 077
[ -e /etc/postfix/sasl_passwd ] || install -o root -g root -m 0600 /dev/null /etc/postfix/sasl_passwd
${EDITOR:-vi} /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
chown root:root /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
chmod 0600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
postfix check
systemctl reload postfix

Warunek [ -e ... ] nie jest ozdobnikiem. install kopiuje plik źródłowy na docelowy, więc samo install /dev/null skasowałoby zawartość istniejącej mapy, a postmap utrwaliłby pustą bazę. Ciche są jednak tylko same polecenia: postmap nie zgłosi błędu, a postfix check tego nie wykryje. Awaria nie poczeka natomiast na przeładowanie usługi. Zgodnie z DATABASE_README zmiana lokalnej bazy typu hash nie wymaga postfix reload, ponieważ demon, który zauważy zmianę pliku, kończy pracę przed obsługą kolejnego żądania, a nowy proces startuje już z pustą mapą. Od tego momentu klient SMTP nie ma poświadczeń dla serwera pośredniczącego, więc wiadomości zaczynają odkładać się w kolejce ze status=deferred i odpowiedzią odmawiającą przekazania nieuwierzytelnionej poczty. Przy pierwszym utworzeniu pliku install z podanymi prawami pozostaje właściwy, ponieważ sekret od początku powstaje z ograniczonym dostępem.

W pliku umieszcza się wpis w formacie:

[smtp.example.com]:587 account@example.com:UNIKALNE_HASLO_APLIKACYJNE

Nie należy wpisywać prawdziwego hasła w poleceniu powłoki, ponieważ może trafić do historii, logów procesu albo systemu zarządzania sesjami. Lepsze jest dedykowane konto przeznaczone wyłącznie do przekazywania poczty, z minimalnymi uprawnieniami, ograniczeniem nadawców i możliwością szybkiego unieważnienia.

Bezpieczne generowanie klucza OpenDKIM

Katalog i plik prywatny powinny od początku powstać z ograniczonymi prawami. Poniższy przykład zakłada istniejącego użytkownika systemowego opendkim:

umask 077
install -d -o opendkim -g opendkim -m 0700 /etc/opendkim/keys/example.com
runuser -u opendkim -- opendkim-genkey \
  -b 2048 \
  -d example.com \
  -s mail2026 \
  -D /etc/opendkim/keys/example.com
chmod 0600 /etc/opendkim/keys/example.com/mail2026.private
opendkim-testkey -d example.com -s mail2026 -vvv

opendkim-testkey osiągnie pełny sukces dopiero po opublikowaniu rekordu DNS. Przed restartem lub przeładowaniem usługi należy sprawdzić składnię konfiguracji, dostęp procesu do klucza i rzeczywiste dodawanie podpisu na wiadomości testowej. Nie wystarczy sam status active demona.

Diagnostykę zaczyna się od kolejki i odpowiedzi serwera odbiorczego:

postqueue -p
journalctl -u 'postfix*' --since "1 hour ago"
journalctl -u opendkim --since "1 hour ago"

Wzorzec postfix* jest tu celowy, ponieważ nazwa jednostki zależy od wersji pakietu. W Debianie 12 i Ubuntu 24.04 postfix.service jest wyłącznie wrapperem, a domyślna instancja działa jako postfix@-.service; dopiero nowsze pakietowanie przenosi logi pod postfix.service.

Sposób logowania zależy od dystrybucji i konfiguracji syslog/journald, dlatego trzeba również sprawdzić /var/log/mail.log, /var/log/maillog lub centralny system logów. W środowisku z wieloma hostami przydatny jest model opisany w artykule o centralizacji i retencji logów Linux.

Aplikacja nie powinna wstawiać adresu użytkownika formularza do From:. Nadawcą ma być kontrolowany adres w firmowej domenie, a adres użytkownika powinien znaleźć się w Reply-To. Inaczej aplikacja próbuje wysyłać jako domeny, których nie kontroluje, i narusza alignment DMARC.

Domeny, z których firma nie wysyła poczty

Domena używana tylko do przekierowania WWW lub ochrony marki również może posłużyć do spoofingu. Dla domeny, która nie wysyła ani nie odbiera poczty, sensowny zestaw wygląda tak:

example-old.com.        IN MX  0 .
example-old.com.        IN TXT "v=spf1 -all"
_dmarc.example-old.com. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.com"

Null MX z RFC 7505 jednoznacznie informuje, że domena nie przyjmuje poczty. SPF -all deklaruje brak uprawnionych adresów wysyłkowych. DMARC z reject obejmuje domenę, istniejące subdomeny i nieistniejące subdomeny.

Jeżeli rua wskazuje inną domenę organizacyjną, trzeba dodać opisaną wcześniej autoryzację raportowania. Dla istniejących subdomen używanych w innych usługach warto osobno zweryfikować, czy nie wysyłają wiadomości. SPF nie jest automatycznie dziedziczony, natomiast polityka DMARC może zostać odnaleziona wyżej w drzewie.

Szyfrowanie transportu, ARC i reputacja

SPF, DKIM oraz DMARC nie wymuszają szyfrowania SMTP. Warstwę ochrony transportu uzupełniają:

MTA-STS, RFC 8461, które pozwala właścicielowi domeny odbiorczej wymagać poprawnego TLS dla dostaw do jego serwerów MX,
SMTP TLS Reporting, RFC 8460, które raportuje problemy z TLS,
DANE for SMTP, RFC 7672, które opiera weryfikację na DNSSEC i rekordach TLSA.

MTA-STS chroni pocztę przychodzącą do domeny, a nie automatycznie każdą wiadomość wychodzącą z jej serwerów. Polityka i host HTTPS muszą być monitorowane, ponieważ błąd certyfikatu albo niezgodność listy MX może utrudnić legalne dostarczanie.

ARC z RFC 8617 pozwala pośrednikowi zapisać wcześniejsze wyniki uwierzytelnienia i własne modyfikacje. Nie zmienia wyniku DMARC na pass i nie nakazuje odbiorcy zaufania do pośrednika. Odbiorca może użyć poprawnego łańcucha ARC jako dodatkowego sygnału lokalnej polityki.

BIMI może zwiększyć rozpoznawalność marki w obsługujących je klientach, ale nie zastępuje uwierzytelniania i nie jest mechanizmem ochrony treści. Należy je wdrażać dopiero przy stabilnej, egzekwującej polityce DMARC i po sprawdzeniu wymagań konkretnego operatora.

Dostarczalność zależy również od reputacji domeny i adresów IP, jakości listy, liczby skarg, wzorców wolumenu oraz treści. Po migracji nie należy gwałtownie wysyłać całego ruchu z nowej infrastruktury. Wolumen zwiększa się stopniowo na podstawie rzeczywistego zapotrzebowania, odpowiedzi SMTP i danych z paneli operatorów, bez sztucznego generowania wiadomości.

Aktualne wymagania Gmaila, Yahoo i Outlook.com

Wymagania operatorów dotyczą głównie dostarczalności do ich skrzynek konsumenckich i mogą się zmieniać. Przed dużą kampanią należy zawsze sprawdzić aktualną dokumentację źródłową.

Gmail

Zgodnie z aktualnymi wytycznymi Google dla nadawców każdy nadawca do prywatnych kont Gmail musi spełnić komplet wymagań: co najmniej SPF albo DKIM, poprawny forward i reverse DNS, TLS, format wiadomości zgodny z RFC 5322, wskaźnik spamu raportowany w Postmaster Tools poniżej 0,3% oraz brak podszywania się pod nagłówek From: Gmaila. Google nazywa te punkty wymaganiami, a nie zaleceniami. Nadawcę, który w oknie 24 godzin wyśle blisko 5000 wiadomości lub więcej do prywatnych kont Gmail, Google klasyfikuje jako nadawcę masowego. Do progu liczy się łączny ruch z całej domeny nadrzędnej, więc 2500 wiadomości z example.com i 2500 z promocje.example.com daje razem 5000 z jednej domeny podstawowej. Status przyznaje się po jednorazowym spełnieniu tego kryterium i nie wygasa: późniejsze zmniejszenie wolumenu ani zmiana praktyk wysyłkowych nie zdejmują wymagań. Nadawcy masowi muszą dodatkowo stosować SPF i DKIM, opublikować DMARC co najmniej z p=none oraz zapewnić alignment domeny From: z SPF albo DKIM.

Dla wiadomości marketingowych i subskrypcyjnych wymagane jest wypisanie jednym kliknięciem zgodne z RFC 8058 oraz widoczna możliwość rezygnacji w treści. Próg 0,3% obowiązuje wszystkich nadawców, a niezależnie od niego Google zaleca utrzymywanie wskaźnika spamu poniżej 0,1%. Szczegóły egzekwowania i kody błędów są publikowane w FAQ wymagań nadawców.

Yahoo

Aktualne Yahoo Sender Best Practices wymagają od nadawców masowych SPF i DKIM, prawidłowego DMARC co najmniej z p=none, przechodzenia DMARC, obsługi one-click unsubscribe i utrzymywania skarg poniżej 0,3%. Yahoo nie publikuje jednego uniwersalnego progu liczbowego, który definiowałby każdego nadawcę masowego.

Outlook.com, Hotmail, Live i MSN

Microsoft od 5 maja 2025 stosuje wymagania dla domen wysyłających ponad 5000 wiadomości dziennie do konsumenckich usług Outlook.com. Wymagane są poprawne wyniki SPF i DKIM oraz DMARC co najmniej z p=none, z alignmentem SPF lub DKIM. Niezgodny ruch może zostać odrzucony kodem 550 5.7.515. Zakres i zasady opisuje oficjalny komunikat Outlook’s New Requirements for High-Volume Senders.

One-click unsubscribe

Dla wiadomości objętych tym wymaganiem potrzebne są oba nagłówki:

List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Oba nagłówki muszą być objęte ważnym podpisem DKIM i wymienione w tagu h=. Wiadomość bez takiego podpisu nie spełnia RFC 8058, a odbiorca nie powinien wystawiać dla niej przycisku wypisania jednym kliknięciem. Żądanie POST musi wypisać odbiorcę bez logowania i bez dodatkowego potwierdzenia. Link w treści wiadomości nadal jest potrzebny, ale sam w sobie nie spełnia technicznego wymagania RFC 8058.

Obowiązki prawne w Polsce

Art. 24 ustawy z 28 lipca 2023 r. o zwalczaniu nadużyć w komunikacji elektronicznej nakłada obowiązek stosowania SPF, DKIM i DMARC na dostawcę poczty elektronicznej, który świadczy usługę dla co najmniej 500 000 użytkowników albo dla podmiotu publicznego. Podmiot publiczny ma obowiązek korzystać z poczty wykorzystującej te mechanizmy, a jego dostawca musi oferować możliwość stosowania uwierzytelniania wieloskładnikowego. CERT Polska opisuje wymagania i udostępnia narzędzie kontrolne w serwisie Bezpieczna Poczta.

Dla zwykłej firmy prywatnej nie jest to bezpośredni, powszechny nakaz wdrożenia tych rekordów. Wymaganie może jednak wynikać z umowy, przetargu, polityki grupy kapitałowej, oceny dostawcy albo analizy ryzyka.

Dlaczego wiadomości nadal trafiają do spamu

Uwierzytelnienie domeny jest warunkiem zaufania, ale nie daje prawa do skrzynki odbiorczej. Gdy wiadomości po poprawnym wdrożeniu nadal trafiają do spamu, należy sprawdzić:

reputację domeny i adresu IP u konkretnego operatora,
wskaźnik skarg i historię nagłych zmian wolumenu,
jakość oraz legalność listy odbiorców,
poprawność PTR, HELO i TLS,
błędy 4xx i 5xx w logach SMTP,
zgodność treści oraz nagłówków z RFC 5322,
obecność działającego mechanizmu rezygnacji,
rozdzielenie ruchu transakcyjnego od marketingowego,
powtarzalne wysyłanie do nieistniejących adresów.

Jeden operator może klasyfikować ruch inaczej niż pozostali, ponieważ każdy buduje własną reputację i lokalną politykę. To, co należy monitorować przed zgłoszeniem klienta, opisujemy szerzej w artykule o WWW, poczcie i DNS jako usługach publicznych.

Utrzymanie i monitoring po wdrożeniu

Przejście do polityki egzekwującej nie kończy projektu. Zmiana dostawcy, przywrócenie starej strefy DNS, rotacja klucza albo nowa aplikacja mogą ponownie otworzyć problem.

Monitoring powinien obejmować:

istnienie dokładnie jednego SPF i jego oczekiwaną treść,
rekurencyjny koszt DNS oraz wyniki permerror,
rekord DMARC, politykę oraz adresy raportowe,
dostępność aktywnych selektorów DKIM,
termin i status rotacji kluczy,
forward-confirmed reverse DNS dla publicznych serwerów wysyłkowych,
wyniki kontrolnych wiadomości wysyłanych do niezależnych operatorów,
udział legalnych źródeł przechodzących DMARC,
nowe źródła i nowe domeny d= w raportach,
certyfikaty i politykę MTA-STS, jeżeli są wdrożone.

Alert nie powinien opierać się wyłącznie na jednym globalnym procencie. Potrzebne są osobne oczekiwania dla każdego znanego strumienia. Brak stu wiadomości z fakturami i brak stu wiadomości marketingowych mają inny wpływ biznesowy.

Każdy nadawca, selektor, rekord include, właściciel i termin rotacji powinien znajdować się w CMDB. Powtarzalne działania warto opisać w runbookach operacyjnych. Samą kontrolę można włączyć do monitoringu infrastruktury IT, aby zniknięcie rekordu nie zostało wykryte dopiero po odrzuceniu wiadomości przez klienta.

Najczęstsze pytania

Czy SPF wystarczy do ochrony przed podszywaniem się pod domenę?

Nie. SPF weryfikuje domenę koperty SMTP, a nie adres wyświetlany w From:. Atakujący może użyć własnej domeny z poprawnym SPF w kopercie i firmowej domeny w widocznym nagłówku. Powiązanie tych tożsamości zapewnia DMARC.

Dlaczego SPF i DKIM mają pass, a DMARC ma fail?

Najczęściej oba mechanizmy uwierzytelniły domeny dostawcy, które nie są zgodne z domeną w From:. Trzeba porównać smtp.mailfrom, header.d oraz header.from. Rozwiązaniem jest zgodna domena w Return-Path, podpis DKIM z firmowym d= albo oba mechanizmy jednocześnie.

Czy p=reject może zablokować legalną pocztę?

Tak, jeżeli legalny system nie ma zgodnego SPF ani DKIM albo wiadomość została zmodyfikowana przez pośrednika. RFC 9989 odradza p=reject dla domen poczty ogólnego przeznaczenia, których użytkownicy mogą korzystać z list dyskusyjnych lub złożonego przekazywania. Dlatego politykę dobiera się do konkretnej domeny i strumienia dopiero po inwentaryzacji, analizie raportów oraz testach krytycznej korespondencji. Odbiorcy mogą stosować wyjątki, ale nadawca nie powinien na nich polegać.

Ile trwa wdrożenie DMARC?

Nie istnieje wiarygodny uniwersalny termin. Czas zależy od liczby źródeł, wolumenu, częstotliwości raportów, możliwości dostawców i krytyczności korespondencji. Prosta domena z jednym nadawcą może zostać zweryfikowana szybko, a rozproszone środowisko z systemami sezonowymi wymaga obserwacji obejmującej ich realny cykl wysyłki.

Czy DMARC chroni przed domeną podobną wizualnie?

Nie. DMARC chroni użycie dokładnej domeny z From:. Domena podobna pozostaje osobną domeną kontrolowaną przez atakującego. Potrzebne są procedury biznesowe, monitoring rejestracji i filtry analizujące podobieństwo nazw.

Co zrobić po zgłoszeniu fałszywej faktury z naszej domeny?

Należy zabezpieczyć oryginalną wiadomość w formacie EML lub MSG wraz z pełnymi nagłówkami, ustalić zaufaną granicę Received i Authentication-Results, porównać identyfikatory z logami wysyłki oraz sprawdzić logowania i reguły skrzynki. Wynik SPF, DKIM lub DMARC samodzielnie nie wystarcza do rozstrzygnięcia, czy doszło do zewnętrznego spoofingu, przejęcia konta albo nadużycia legalnej platformy.

Jak często rotować klucz DKIM?

Według polityki ryzyka i możliwości operacyjnych, a natychmiast po podejrzeniu kompromitacji. Ważniejsza od arbitralnej daty jest bezpieczna procedura z równoległymi selektorami, kontrolą DNS, testem wiadomości i usunięciem starego klucza dopiero po okresie przejściowym.

Czy p=none chroni domenę?

p=none uruchamia raportowanie i alignment, ale zgodnie ze standardem nie powinno zmieniać istniejącej obsługi wiadomości. Jest niezbędnym etapem bezpiecznego wdrożenia, lecz nie jest polityką egzekwującą.

Źródła i standardy

Najważniejsze dokumenty użyte przy przygotowaniu artykułu:

Podsumowanie

SPF, DKIM i DMARC rozwiązują precyzyjny problem: pozwalają wiarygodniej ocenić, czy użycie domeny widocznej w polu nadawcy zostało autoryzowane przez jej właściciela. Najsilniejszy efekt daje poprawny alignment, raportowanie i docelowa polityka egzekwująca, ale odbiorca nadal stosuje własne filtry oraz lokalne wyjątki.

Najtrudniejszą częścią wdrożenia nie jest zapis rekordu TXT. Jest nią znalezienie wszystkich legalnych nadawców, przypisanie im właścicieli, doprowadzenie do zgodnego DKIM lub SPF i utrzymanie tego stanu po kolejnych zmianach infrastruktury.

Pełny proces można połączyć z audytem bezpieczeństwa środowiska IT, utrzymaniem serwerów w ramach administracji Linux oraz stałą kontrolą DNS i poczty w monitoringu infrastruktury IT. Dzięki temu uwierzytelnianie poczty pozostaje działającym mechanizmem bezpieczeństwa, a nie jednorazowym wpisem pozostawionym w DNS.

SPF, DKIM i DMARC: jak zabezpieczyć firmową pocztę przed podszywaniem