Konfiguracja SPF, DKIM i DMARC polega na opublikowaniu w DNS domeny trzech rekordów TXT, dzięki którym dostawcy poczty mogą potwierdzić, że wiadomość naprawdę pochodzi od Ciebie. SPF wskazuje serwery uprawnione do wysyłania poczty z domeny, DKIM dodaje do każdej wiadomości podpis kryptograficzny, a DMARC mówi odbiorcy, co zrobić z pocztą, która nie przejdzie tych testów, i wysyła Ci raporty. Potrzebujesz trzech rekordów (@, selector._domainkey i _dmarc) oraz wiadomości testowej, która potwierdzi, że wszystko przechodzi; ta instrukcja omawia każdy krok z gotowymi do skopiowania przykładami.
Jak to sprawdziliśmy
Wymagania Gmaila, Yahoo i Microsoftu porównaliśmy z oficjalnymi stronami 30.10.2026: wytyczne Google dla nadawców, Yahoo Sender Hub oraz pomoc Microsoftu dotycząca błędu 550 5.7.515. Szczegóły techniczne pochodzą z RFC 7208 (SPF), 6376 i 8301 (DKIM) oraz RFC 9989, 9990 i 9991 (DMARC) w serwisie rfc-editor.org. Wszystkie przykłady DNS używają domeny dokumentacyjnej example.com i testowych zakresów IP 203.0.113.0/24 oraz 198.51.100.0/24.
Dlaczego poczta bez SPF, DKIM i DMARC trafia do spamu
SMTP sam nie weryfikuje nadawcy: każdy serwer może wpisać info@example.com w polu From. Google i Yahoo wymagają uwierzytelniania poczty od lutego 2024 roku, a od listopada 2025 roku Gmail egzekwuje te zasady coraz ostrzej: wiadomości niespełniające wymagań mogą być odrzucane tymczasowo lub na stałe. Od 5 maja 2025 roku Microsoft stosuje podobne reguły w Outlook.com, Hotmail i Live: domeny wysyłające tam ponad 5000 e-maili dziennie muszą mieć SPF, DKIM i DMARC, w przeciwnym razie wiadomości trafiają do wiadomości-śmieci albo są odrzucane z błędem 550 5.7.515.
Wymagania Gmaila na dzień 30.10.2026:
| Wymaganie | Wszyscy nadawcy do Gmaila | Nadawcy masowi (około 5000 wiadomości dziennie lub więcej) |
|---|---|---|
| SPF i DKIM | SPF lub DKIM | SPF i DKIM |
| DMARC | nieobowiązkowy, zalecany | wymagany, wystarczy p=none |
| Domena From zgodna z SPF lub DKIM | nie jest wymagana | tak |
| DNS w przód i wstecz (PTR) dla IP nadawcy | tak | tak |
| Połączenie TLS | tak | tak |
| Wskaźnik spamu w Postmaster Tools | poniżej 0,3% | poniżej 0,3%, najlepiej poniżej 0,1% |
| Wypisanie się jednym kliknięciem | nie jest wymagane | tak, dla poczty marketingowej |
Yahoo wymaga niemal tego samego: nadawcy masowi potrzebują SPF i DKIM, polityki DMARC co najmniej p=none, zgodnej domeny From, wypisania jednym kliknięciem i wskaźnika spamu poniżej 0,3%.
Jak SPF, DKIM i DMARC działają razem
- SPF (RFC 7208) sprawdza, czy IP serwera dostarczającego wiadomość może wysyłać pocztę dla domeny koperty (MAIL FROM, widocznej w nagłówkach jako Return-Path). Nie sprawdza widocznego adresu From.
- DKIM (RFC 6376) weryfikuje podpis cyfrowy. Serwer nadawcy podpisuje nagłówki i treść kluczem prywatnym, a odbiorca pobiera klucz publiczny z selector._domainkey.example.com, by potwierdzić, że wiadomość nie została zmieniona.
- DMARC (RFC 9989, wcześniej RFC 7489) wiąże oba testy z adresem From. Wiadomość przechodzi DMARC, gdy SPF lub DKIM zakończy się sukcesem, a sprawdzona domena zgadza się z domeną From. Nazywa się to dopasowaniem (alignment). Jeśli test się nie powiedzie, odbiorca stosuje Twoją politykę: none, quarantine lub reject.
Domyślnie dopasowanie jest luźne (relaxed): d=mail.example.com wystarcza dla From: info@example.com. Tryb ścisły (strict) wymaga dokładnej zgodności.
Krok 1. Znajdź wszystko, co wysyła pocztę z Twojej domeny
Najczęstszy problem z DMARC to zapomniany nadawca. Spisz wszystkie systemy, które wysyłają pocztę w imieniu Twojej domeny: serwer poczty na hostingu, Google Workspace, Microsoft 365 lub Zoho Mail, stronę i formularze kontaktowe, platformy newsletterowe, CRM, helpdesk i systemy fakturowania.
Następnie uruchom dig NS example.com +short: rekordy trzeba dodać w strefie na tych autorytatywnych serwerach nazw. Jeśli przenosisz właśnie domenę, najpierw sprawdź, jak zmienić serwery DNS domeny. Typy rekordów omawia nasz poradnik o rekordach DNS i zarządzaniu domeną.
Krok 2. Konfiguracja SPF: składnia i przykłady
SPF to jeden rekord TXT na samej domenie (nazwa @), który zaczyna się od v=spf1. Mechanizmy takie jak ip4:, ip6:, a, mx i include: wskazują dozwolonych nadawców, a końcowe all ustala regułę dla pozostałych: -all (fail), ~all (softfail), ?all (neutral). Nigdy nie używaj +all.
; Mail on the hosting server only (typical panel record)
example.com. TXT "v=spf1 a mx ip4:203.0.113.10 -all"
; Google Workspace
example.com. TXT "v=spf1 include:_spf.google.com ~all"
; Microsoft 365
example.com. TXT "v=spf1 include:spf.protection.outlook.com -all"
; Hosting + Google Workspace + website on another server
example.com. TXT "v=spf1 mx ip4:198.51.100.7 include:_spf.google.com ~all"
; Domain that never sends mail
example.com. TXT "v=spf1 -all"Publikuj tylko jeden rekord SPF na domenę: dwa rekordy v=spf1 (na przykład jeden z panelu hostingu i drugi dodany dla Google) dają permerror, więc połącz je w jeden. Przy działającym DMARC sprawdzają się zarówno ~all, jak i -all; używaj ~all, dopóki raporty DMARC nie potwierdzą listy nadawców.
Limit 10 zapytań DNS
Ocena SPF może obejmować najwyżej dziesięć mechanizmów wymagających zapytania DNS: include, a, mx, ptr, exists oraz modyfikator redirect. Liczą się też zagnieżdżone include, natomiast ip4, ip6 i all już nie. Powyżej dziesięciu wynikiem jest permerror. Aby zmieścić się w limicie, usuń include usług, z których już nie korzystasz, zastąp a i mx przez ip4, unikaj przestarzałego ptr i przenieś wysyłkę newsletterów na subdomenę, na przykład news.example.com, z własnym SPF.
Krok 3. Konfiguracja DKIM: selektor, klucz i rekord
Serwer poczty tworzy parę kluczy: klucz prywatny podpisuje wiadomości, a publiczny publikuje się jako rekord TXT (niektóre usługi zamiast tego proszą o CNAME do własnego rekordu). Nazwa rekordu to selektor plus _domainkey, a jedna domena może mieć kilka selektorów, po jednym dla każdego systemu wysyłającego.
; Public key TXT record, selector "mail"
mail._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."Używaj kluczy 2048-bitowych: RFC 8301 uznaje klucze krótsze niż 1024 bity za nieważne i zaleca 2048 bitów. Taki klucz nie mieści się w jednym ciągu TXT o długości 255 znaków, więc dzieli się go na kilka ciągów w cudzysłowach w obrębie jednego rekordu. Wklejając go ręcznie, upewnij się, że w p= nie ma spacji, podziałów wiersza ani brakujących znaków.
- Hosting z panelem sterowania: wiele paneli przy dodaniu domeny pocztowej generuje klucz 2048-bitowy z selektorem mail. Jeśli strefa DNS jest na tym samym serwerze, rekord mail._domainkey zwykle dodaje się automatycznie; w przeciwnym razie skopiuj klucz publiczny z ustawień domeny pocztowej do swojego dostawcy DNS.
- Google Workspace: konsola administracyjna, Aplikacje > Google Workspace > Gmail > Uwierzytelnianie poczty e-mail (w angielskim interfejsie Authenticate email). Wygeneruj klucz 2048-bitowy (domyślny selektor google), dodaj rekord TXT google._domainkey i kliknij Rozpocznij uwierzytelnianie.
- Microsoft 365: portal Microsoft Defender, w angielskim interfejsie Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. Dodaj dwa rekordy CNAME, selector1._domainkey i selector2._domainkey, z dokładnie takimi celami, jakie pokazuje portal, a potem włącz podpisywanie.
- Platformy newsletterowe i CRM: poszukaj w ustawieniach nadawcy opcji „uwierzytelnij domenę”; dostaniesz jeden lub dwa rekordy DKIM i często własną subdomenę Return-Path.
Regularnie wymieniaj klucze, na przykład co 6-12 miesięcy, używając nowego selektora. Przy przenosinach do innego hostingu pamiętaj, że nowy serwer poczty ma własny klucz i IP: podmień rekord DKIM i zaktualizuj SPF.
Krok 4. Konfiguracja DMARC: od monitorowania do p=reject
Rekord DMARC to rekord TXT pod nazwą _dmarc. Tagi oddziela się średnikami; v=DMARC1 jest zawsze pierwszy, a w praktyce potrzebna jest też polityka p.
| Tag | Wartości | Znaczenie |
|---|---|---|
| p | none, quarantine, reject | polityka: tylko raporty, folder spam lub odrzucenie |
| sp | none, quarantine, reject | osobna polityka dla subdomen |
| np | none, quarantine, reject | polityka dla nieistniejących subdomen (nowość w RFC 9989) |
| rua | mailto:dmarc@example.com | adres dziennych raportów zbiorczych |
| ruf | mailto:dmarc@example.com | raporty o błędach (wysyła je niewielu dostawców) |
| adkim, aspf | r lub s | luźne lub ścisłe dopasowanie, domyślnie r |
| t | y lub n | tryb testowy w RFC 9989, zastępuje dawne pct |
; Stage 1: monitoring and reports only
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
; Stage 2: failing mail goes to spam
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
; Stage 3: full protection for the domain and subdomains
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"Nie zaczynaj od p=reject. Zostaw p=none na 2-4 tygodnie i czytaj raporty: duzi dostawcy wysyłają na adres rua pliki XML z każdym IP, które wysłało pocztę w imieniu Twojej domeny, wraz z wynikami SPF i DKIM. Gdy wszystkie prawidłowe źródła przechodzą testy, przejdź na quarantine, a po kilku tygodniach na reject. Jeśli raporty trafiają do innej domeny, musi ona to zatwierdzić rekordem example.com._report._dmarc.reports.example.net TXT "v=DMARC1".
Typowy domyślny rekord w panelach hostingowych to v=DMARC1; p=quarantine; pct=100, co wystarcza, gdy cała poczta wychodzi z serwera hostingu. Jeśli dodasz Google Workspace lub usługę newsletterową, najpierw skonfiguruj dla niej SPF i DKIM. W maju 2026 roku IETF opublikował RFC 9989 (raporty w RFC 9990 i 9991), które zastępuje RFC 7489: rekordy nadal zaczynają się od v=DMARC1 i dalej działają, pct ma teraz status historyczny, a dodano t=y i np.
Jak sprawdzić SPF, DKIM i DMARC
# Linux and macOS
dig +short TXT example.com | grep spf1
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.com
# Windows (cmd or PowerShell)
nslookup -type=TXT _dmarc.example.com
Resolve-DnsName -Type TXT mail._domainkey.example.comPusta odpowiedź oznacza, że rekord jeszcze się nie rozpropagował (poczekaj, aż minie stary TTL), jest w niewłaściwej strefie albo ma literówkę. Klasyczna pułapka: panel sam dopisuje domenę i _dmarc.example.com zamienia się w _dmarc.example.com.example.com; wpisz samo _dmarc.
Następnie wyślij wiadomość na skrzynkę w Gmailu, otwórz ją i wybierz „Pokaż oryginał” z menu z trzema kropkami. SPF, DKIM i DMARC powinny pokazywać PASS. Szczegóły zawiera nagłówek Authentication-Results:
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=mail;
spf=pass (google.com: domain of info@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=info@example.com;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.comJeśli widzisz dkim=pass, ale podpis używa cudzej domeny, na przykład d=sendservice.net, nie liczy się on dla DMARC. MXToolbox, mail-tester.com i Google Postmaster Tools dają te same odpowiedzi w przeglądarce.
Częste błędy w SPF, DKIM i DMARC
| Błąd | Co widzi odbiorca | Rozwiązanie |
|---|---|---|
| Dwa rekordy TXT z v=spf1 | spf=permerror | Połączyć je w jeden rekord |
| Ponad 10 zapytań DNS w SPF | spf=permerror | Usunąć zbędne include, użyć ip4, przenieść newslettery na subdomenę |
| Ucięty klucz DKIM lub spacje w p= | dkim=fail lub dkim=neutral | Wkleić pełny klucz podzielony na ciągi do 255 znaków |
| Usługa newsletterowa podpisuje własną domeną | dmarc=fail mimo spf=pass i dkim=pass | Uwierzytelnić własną domenę w usłudze |
| p=reject od pierwszego dnia | Znika poczta z CRM, strony lub fakturowania | Zacząć od p=none i zaostrzać stopniowo |
| Strona wysyła jako @gmail.com przez PHP mail() | odrzucenie lub folder spam | Wysyłać z własnej domeny przez uwierzytelniony SMTP |
Przekierowanie poczty psuje SPF, dlatego DKIM jest niezbędny; na własnym serwerze sprawdź też rekord PTR i TLS.
FAQ
Czy potrzebuję SPF, DKIM i DMARC, jeśli wysyłam tylko kilka e-maili dziennie?
Tak. Gmail wymaga SPF lub DKIM od wszystkich nadawców, a bez DMARC każdy może podszyć się pod Twój adres. Minimum zajmuje około pół godziny: SPF, DKIM od dostawcy poczty i DMARC z p=none oraz adresem do raportów.
Dlaczego DMARC nie przechodzi, skoro SPF przechodzi?
SPF sprawdził domenę koperty (Return-Path), która różni się od domeny From, na przykład bounce.sendservice.net. DMARC liczy tylko dopasowane wyniki, więc skonfiguruj podpis DKIM z własną domeną albo własny Return-Path.
Co opublikować dla domeny, która nigdy nie wysyła poczty?
Ustaw v=spf1 -all na domenie i v=DMARC1; p=reject pod _dmarc. Opcjonalnie dodaj pusty klucz DKIM, *._domainkey TXT "v=DKIM1; p=", aby zaznaczyć, że nie ma ważnych podpisów.
Rekordy przechodzą, a poczta nadal trafia do spamu. Co dalej?
Uwierzytelnianie tylko otwiera drzwi, o reszcie decyduje reputacja. Sprawdź czarne listy (MXToolbox Blacklist Check), wskaźnik spamu w Postmaster Tools, linki do wypisania się i higienę list adresowych, a nowe domeny rozgrzewaj, stopniowo zwiększając wolumen.
Podsumowanie
W skrócie: jeden rekord SPF obejmujący wszystkich nadawców, klucz DKIM 2048 bitów dla każdej usługi i DMARC, który przechodzi od p=none przez quarantine do reject, gdy raporty potwierdzą listę nadawców. Po każdej zmianie sprawdź wszystko ponownie przez dig i wiadomość testową.
Każdy pakiet hostingowy RichHost obejmuje hosting poczty we własnej domenie z nielimitowaną liczbą skrzynek, którymi zarządzasz we własnym panelu sterowania z asystentem AI. Jeśli nie masz jeszcze domeny, możesz zarejestrować domenę razem z hostingiem i od razu skonfigurować pocztę według tej instrukcji.
