Wiadomość z własnej domeny trafia do spamu albo wraca z błędem 550, choć nadawca i treść się nie zmieniły. Najczęściej problem nie leży w słowach, tylko w konfiguracji trzech mechanizmów: SPF, DKIM i DMARC. Każdy odpowiada na inne pytanie, a dopiero razem dają odbiorcy podstawę, żeby odróżnić prawdziwą pocztę od podszycia.
SPF sprawdza kopertę, nie nagłówek From
SPF, czyli Sender Policy Framework, to rekord DNS w rodzaju v=spf1 include:_spf.google.com -all. Serwer odbiorcy sprawdza w nim, czy adres IP, z którego przyszła wiadomość, jest upoważniony do wysyłki w imieniu domeny.[1] Kluczowe zastrzeżenie: chodzi o kopertę SMTP, adres MAIL FROM, a nie o pole From widoczne w kliencie poczty. To rozróżnienie wyjaśnia, dlaczego sam SPF nie chroni przed podszywaniem się pod znaną markę.
Rekord ma też twarde limity. Standard pozwala na najwyżej dziesięć mechanizmów i modyfikatorów, które powodują zapytania DNS, oraz na dwa tak zwane puste zapytania.[1] Rozbudowany łańcuch include: potrafi wyczerpać limit, a wtedy wynikiem jest permerror, niezależnie od tego, czy adres IP jest poprawny. W praktyce warto policzyć zapytania przed dodaniem kolejnej usługi wysyłkowej.
Drugi problem to przekazywanie. Jeśli wiadomość trafia do skrzynki przekierowującej albo na listę dyskusyjną, dalej wysyła ją inny serwer, którego adresu IP nie ma w rekordzie. SPF nie przechodzi, choć wiadomość jest legalna. Dlatego odbiorcy traktują SPF jako jeden z sygnałów, a nie wyrok.
DKIM podpisuje treść i wybrane nagłówki
DKIM (DomainKeys Identified Mail) dodaje do wiadomości nagłówek z podpisem kryptograficznym. Podpis obejmuje skrót treści oraz wybrane nagłówki, a klucz publiczny jest publikowany w DNS pod adresem selektor._domainkey.domena.[2] Domena w polu d= bierze w ten sposób odpowiedzialność za wiadomość. To deklaracja, nie gwarancja dobrej woli: podpis mówi tylko, że wiadomość wyszła spod kontroli właściciela klucza i nie została zmieniona po drodze.
Właśnie dlatego DKIM jest bardziej odporny na przekazywanie niż SPF. Jeśli serwer pośredniczący nie zmieni treści ani podpisanych nagłówków, podpis pozostaje ważny mimo nowego adresu IP. Listy dyskusyjne często dopisują jednak stopkę albo zmieniają temat, a wtedy podpis pęka. Część serwerów radzi sobie z tym, dopisując własny podpis, ale nie każdy to robi.
Siła podpisu zależy od klucza. Google wymaga od nadawców wysyłających do osobistych kont Gmail klucza co najmniej 1024-bitowego i zaleca 2048 bitów.[4] Starsze konfiguracje z krótkim kluczem nadal przechodzą weryfikację, ale są łatwiejsze do złamania, więc przy okazji porządków warto sprawdzić selektory.
DMARC łączy wyniki z domeną widoczną dla człowieka
DMARC nie jest kolejnym podpisem. To rekord w _dmarc.domena, który mówi odbiorcy, co zrobić z wiadomością, gdy SPF i DKIM nie potwierdzają domeny z pola From, oraz gdzie wysyłać raporty.[3] Warunkiem zaliczenia jest tak zwane wyrównanie: domena uwierzytelniona przez SPF lub DKIM musi zgadzać się z domeną w polu From, dokładnie w trybie strict albo na poziomie domeny organizacyjnej w trybie relaxed.[3]
Polityka p= ma trzy wartości. none oznacza brak działań, tylko obserwację. quarantine kieruje podejrzane wiadomości do spamu, a reject każe je odrzucić.[3] Rekord może też zawierać rua= ze skrzynką na raporty zbiorcze, sp= dla poddomen i, od nowszej wersji standardu, np= dla nieistniejących poddomen.
W maju 2026 roku IETF opublikował nową wersję specyfikacji jako RFC 9989, które zastępuje dokumenty RFC 7489 i RFC 9091.[3] Zmiany porządkują zapis i usuwają tag pct=, czyli procent wiadomości objętych polityką. To warto wiedzieć, jeśli w dokumentacji firm trzecich nadal pojawia się pct=0 jako sposób na tryb testowy.
Start od p=none, potem zaostrzanie
Sensowna kolejność wdrożenia jest odwrotna do intuicji. Najpierw publikuje się p=none z adresem na raporty, potem przez kilka tygodni analizuje raporty zbiorcze, poprawia nieautoryzowane źródła wysyłki, a dopiero na końcu przechodzi do quarantine i reject.[3] Dopiero raporty pokazują, ile legalnych strumieni poczty korzysta z domeny: newsletter, system zgłoszeń, faktury, skrzynka biurowa, aplikacja do kampanii.
Raporty zbiorcze to pliki XML wysyłane cyklicznie przez odbiorców. Standard opisuje ich format osobno, w RFC 9990, a do codziennej pracy zwykle potrzebny jest parser albo usługa, która zamienia je na czytelne zestawienie.[3] Ręczne czytanie pojedynczych plików szybko przestaje mieć sens.
Wymagania Gmaila nie są dobrowolne
Google od lutego 2024 roku wymaga od nadawców wysyłających ponad 5000 wiadomości dziennie na konta Gmail jednoczesnego SPF i DKIM, rekordu DMARC z co najmniej p=none i wyrównaniem do domeny z pola From oraz obsługi wypisu jednym kliknięciem w wiadomościach marketingowych.[4] Limit liczy się dla domeny głównej, więc subdomeny wchodzą do tej samej puli.[5] Od listopada 2025 roku Google zaostrza egzekwowanie, a wiadomości niespełniające wymagań mogą dostawać tymczasowe lub trwałe odrzucenia.[5] Wymagania dotyczą poczty do osobistych kont Gmail, nie wewnętrznej komunikacji w Google Workspace.[5]
Wypis jednym kliknięciem opisuje RFC 8058: nagłówek List-Unsubscribe-Post pozwala klientowi poczty wysłać żądanie bez otwierania strony.[6] To wygoda dla odbiorcy i mniejsze ryzyko, że zamiast się wypisać, oznaczy wiadomość jako spam. Wysoki odsetek oznaczeń jest zresztą osobnym problemem: próg 0,3% w Gmailu działa niezależnie od tego, jak dobrze skonfigurowane jest uwierzytelnianie.[4]
Czego DMARC nie chroni
Po pierwsze, domen podobnych. Rekord dla twojadomena.pl nie ma nic do powiedzenia o twojadomena-pl.com. Po drugie, nazw wyświetlanych: nadawca z darmowej skrzynki może podpisać się jako dział księgowości twojej firmy, a DMARC sprawdzi tylko jego własną domenę. Po trzecie, przejętych kont: wiadomość wysłana z legalnego serwera i legalnego konta przechodzi wszystkie kontrole, bo technicznie jest prawdziwa. Po czwarte, treści: DMARC nie analizuje linków ani załączników i nie gwarantuje, że wiadomość trafi do skrzynki odbiorczej, a nie do spamu.
Warto też nie mylić DMARC z DNSSEC. DMARC opiera się na rekordach DNS, więc podpisanie strefy utrudnia ich podmianę, ale jest osobnym mechanizmem, opisanym w tekście o DNSSEC i podpisie DNS. Szyfrowanie transportu to z kolei TLS, niezależny element układanki.
Jak sprawdzić własną domenę
Podstawowy odczyt to dwa zapytania: dig TXT domena oraz dig TXT _dmarc.domena. Warto sprawdzić, czy w SPF nie ma zbyt wielu include:, czy polityka nie kończy się na ?all albo +all i czy DMARC wskazuje skrzynkę, którą ktoś faktycznie czyta. Przy wielu dostawcach wysyłki każdy powinien mieć własny selektor DKIM i podpis ustawiony na domenę klienta, a nie na domenę dostawcy. Jeśli dostawca podpisuje własną domeną, DKIM przechodzi, ale wyrównanie do pola From nie, więc DMARC nadal zawodzi.
Na koniec zostaje najtrudniejsza część: utrzymanie listy legalnych nadawców. Nowy formularz kontaktowy, nowy system biletowy albo przeniesienie skrzynki na inny serwer potrafią zepsuć uwierzytelnianie bez żadnej zmiany w treści maili. Domena z polityką reject nie wybacza takich przeoczeń, dlatego raporty i alerty o błędach dostarczania są częścią wdrożenia, a nie dodatkiem.
Źródła
- S. Kitterman, „Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1”, RFC 7208, IETF, kwiecień 2014. https://www.rfc-editor.org/rfc/rfc7208.txt
- D. Crocker, T. Hansen, M. Kucherawy (red.), „DomainKeys Identified Mail (DKIM) Signatures”, RFC 6376, IETF, wrzesień 2011. https://www.rfc-editor.org/rfc/rfc6376.txt
- T. Herr, J. Levine (red.), „Domain-Based Message Authentication, Reporting, and Conformance (DMARC)”, RFC 9989, IETF, maj 2026. https://www.rfc-editor.org/rfc/rfc9989.txt
- Google, „Email sender guidelines”, Google Workspace Admin Help, dostęp 22 października 2026. https://support.google.com/mail/answer/81126?hl=en
- Google, „Email sender guidelines FAQ”, Google Workspace Admin Help, dostęp 22 października 2026. https://support.google.com/mail/answer/14229414?hl=en
- J. Levine, T. Herkula, „Signaling One-Click Functionality for List Email Headers”, RFC 8058, IETF, styczeń 2017. https://www.rfc-editor.org/rfc/rfc8058.txt
