SPF, DKIM i DMARC: jak je ustawić, żeby maile nie wpadały do spamu (2026)

Jeśli Twoje maile wpadają do spamu albo wracają z odbiciem, w większości przypadków powodem nie jest treść, tylko brak uwierzytelnienia domeny. Gmail, Outlook i Yahoo sprawdzają dziś trzy rekordy DNS: SPF, DKIM i DMARC. Bez nich serwer odbiorcy nie ma jak potwierdzić, że wiadomość z adresu w Twojej domenie wysłałeś Ty, a nie ktoś, kto się pod Ciebie podszywa.

Ten przewodnik prowadzi od zera do działającej konfiguracji: co robi każdy rekord, jak wygląda w DNS, w jakiej kolejności je wdrażać, jak sprawdzić, czy działają, i jakie wymagania stawiają najwięksi dostawcy poczty. Napisaliśmy go dla osób bez zaplecza technicznego, które chcą mieć kontrolę nad dostarczalnością poczty w firmie.

Trzy rekordy w jednym zdaniu

• SPF mówi, które serwery mogą wysyłać pocztę w imieniu Twojej domeny.
• DKIM podpisuje każdą wiadomość kluczem kryptograficznym, więc odbiorca wie, że treść nie została zmieniona po drodze i że pochodzi z Twojej domeny.
• DMARC łączy oba powyższe: sprawdza, czy domena w polu Od zgadza się z domeną z SPF lub DKIM, mówi odbiorcy, co zrobić z wiadomością, która nie przeszła weryfikacji, i wysyła Ci raporty.

Wszystkie trzy to rekordy DNS, czyli wpisy w ustawieniach domeny u jej dostawcy (home.pl, nazwa.pl, OVH, Cloudflare i inni). Nie instalujesz niczego na komputerze ani w Sugesterze.

SPF: lista serwerów uprawnionych do wysyłki

SPF (Sender Policy Framework) to rekord TXT w głównej domenie. Kiedy serwer odbiorcy dostaje wiadomość, sprawdza, czy adres IP serwera nadawcy jest na liście. Przykładowy rekord dla firmy, która wysyła pocztę przez Google Workspace:

v=spf1 include:_spf.google.com ~all

Składowe:

• v=spf1 otwiera rekord i zawsze jest na początku,
• include: dodaje serwery innego dostawcy (poczta, newsletter, CRM),
• mx pozwala wysyłać serwerom z rekordów MX domeny, ip4: i ip6: dodają konkretne adresy,
• ~all (softfail) albo -all (fail) zamyka listę: wszystko, czego nie ma wyżej, ma być traktowane podejrzliwie albo odrzucane.

Jeśli wysyłasz przez kilku dostawców, wszystkie wpisy idą do jednego rekordu. Domena może mieć tylko jeden rekord SPF, a liczba zapytań DNS (głównie include) nie może przekroczyć 10. Przykład dla firmy, która ma pocztę w Google, newslettery wysyła przez Mailgun, a pojedyncze maile z Sugestera przez SendGrid:

v=spf1 mx include:_spf.google.com include:mailgun.org include:u908313.wl.sendgrid.net ~all

Gotowe wpisy include dla dostawców, z których korzysta Sugester (SendGrid, Mailgun, Amazon SES, EmailLabs, Google), znajdziesz w bazie wiedzy: Rekord TXT SPF dla różnych providerów.

Słabość SPF: nie radzi sobie z przekazywaniem wiadomości dalej (forward), bo serwer przekazujący nie jest na Twojej liście. Dlatego SPF nigdy nie występuje sam, zawsze w parze z DKIM.

DKIM: podpis cyfrowy w nagłówku wiadomości

DKIM (DomainKeys Identified Mail) działa na parze kluczy. Serwer wysyłający podpisuje wiadomość kluczem prywatnym, a klucz publiczny publikujesz w DNS. Odbiorca pobiera klucz publiczny, sprawdza podpis i wie dwie rzeczy: wiadomość wyszła z serwera, który ma klucz prywatny do Twojej domeny, a jej treść i nagłówki nie zostały zmienione po drodze. DKIM przeżywa też forward, czego SPF nie potrafi.

Rekord DKIM to wpis TXT (czasem CNAME) pod adresem z tzw. selektorem, na przykład google._domainkey.twojafirma.pl. Jego treść generuje dostawca, który wysyła pocztę, nie piszesz jej ręcznie:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

Każdy dostawca wysyłki ma własny selektor i własny klucz, więc firma z pocztą w Google i newsletterem w innym systemie będzie miała dwa rekordy DKIM. To normalne.

DMARC: polityka i raporty

DMARC (Domain-based Message Authentication, Reporting and Conformance) nie uwierzytelnia niczego samodzielnie. Sprawdza, czy wynik SPF lub DKIM jest pozytywny i czy domena z tej weryfikacji zgadza się z domeną widoczną w polu Od (to tzw. alignment, zgodność domen). Potem mówi odbiorcy, co zrobić z wiadomością, która testu nie przeszła, i dokąd wysyłać raporty.

Rekord DMARC to TXT pod adresem _dmarc.twojafirma.pl:

v=DMARC1; p=none; rua=mailto:[email protected]

• p= to polityka: none (tylko obserwuj), quarantine (kieruj do spamu), reject (odrzucaj),
• rua= to adres, na który dostawcy poczty wysyłają zbiorcze raporty XML o tym, kto wysyła w Twoim imieniu i z jakim wynikiem,
• opcjonalnie pct= (jaki procent wiadomości objąć polityką) i sp= (polityka dla subdomen).

Od none do reject, bez wypadku

Nie zaczynaj od p=reject. Prawie każda firma ma źródło wysyłki, o którym zapomniała: stary system fakturowania, formularz na stronie, narzędzie do ankiet. Bezpieczna droga:

1. p=none przez 2 do 4 tygodni. Zbierasz raporty i sprawdzasz, które źródła wysyłki nie przechodzą weryfikacji. Dla każdego dodajesz include w SPF albo konfigurujesz DKIM.
2. p=quarantine; pct=10, potem pct=100. Niezweryfikowane wiadomości lądują w spamie, najpierw dla części ruchu.
3. p=reject. Dopiero gdy raporty pokazują, że cała Twoja legalna poczta przechodzi. Od tej chwili podszywanie się pod Twoją domenę przestaje działać.

Raporty XML są nieczytelne gołym okiem. Narzędzia takie jak Postmark DMARC Digests albo EasyDMARC zamieniają je w czytelną tabelę źródeł wysyłki.

Kolejność wdrożenia

1. Spisz wszystkie źródła wysyłki w imieniu domeny: poczta firmowa, CRM, newsletter, fakturowanie, sklep, formularze. Każde musi znaleźć się w SPF i mieć DKIM.
2. Ustaw SPF: jeden rekord TXT w głównej domenie z wszystkimi include.
3. Włącz DKIM u każdego dostawcy i wklej wygenerowane rekordy do DNS.
4. Odczekaj dobę, aż DNS się rozpropaguje, i sprawdź SPF oraz DKIM narzędziem (niżej).
5. Dodaj DMARC z p=none i adresem na raporty.
6. Zaostrzaj politykę według planu powyżej.

Jak sprawdzić, czy wszystko działa

Narzędzia online

W MXToolbox (zakładki SPF Record Lookup, DKIM Lookup, DMARC Lookup) albo w EasyDMARC wpisujesz domenę i widzisz, czy rekordy istnieją, czy mają poprawną składnię i ile zapytań DNS zużywa SPF. Google Workspace ma też własny Check MX.

Nagłówek Authentication-Results

Najpewniejszy test to wysłanie maila na własne konto Gmail i podejrzenie nagłówków (menu wiadomości, opcja Pokaż oryginał). W nagłówku Authentication-Results szukasz trzech wyników:

spf=pass (google.com: domain of [email protected] designates ... as permitted sender)
dkim=pass [email protected]
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=twojafirma.pl

Jeśli przy którymś jest fail, softfail albo none, wiesz dokładnie, który rekord poprawić. Gmail pokazuje te same wyniki w uproszczonej formie w widoku Pokaż oryginał, w wierszach SPF, DKIM i DMARC.

Wymagania Google, Yahoo i Microsoft

Od 2024 roku trzej najwięksi dostawcy poczty nie traktują uwierzytelnienia jako dobrej praktyki, tylko jako warunek przyjęcia wiadomości. Stan na październik 2026, według stron pomocy dostawców:

Źródła: wytyczne Google dla nadawców, zasady Yahoo, ogłoszenie Microsoft z kwietnia 2025 (wymagania obowiązują od 5 maja 2025).

Próg 5000 wiadomości dziennie brzmi wysoko, ale Google i Microsoft liczą go dla domeny, nie dla skrzynki. Firma z dziesięcioma pracownikami, newsletterem i automatycznymi powiadomieniami ze sklepu przekracza go łatwiej, niż się wydaje. A reguła dla wszystkich nadawców (SPF lub DKIM, poprawny rekord PTR, TLS) dotyczy każdej domeny bez wyjątku.

SPF, DKIM i DMARC a wysyłka z Sugestera

Gdy wysyłasz przez serwery Sugestera

Nawet jeśli pocztę wysyła za Ciebie Sugester, adres nadawcy jest w Twojej domenie, więc rekordy muszą być u Ciebie. Do SPF dodajesz dostawcę, przez którego Sugester wysyła Twoje wiadomości (pojedyncze maile przez SendGrid, mailingi przez Mailgun), gotowe wpisy są w bazie wiedzy, link wyżej. Podpis DKIM wstawiamy domyślnie do każdej wiadomości wychodzącej z Sugestera.

Od planu Pro możemy skonfigurować własny DKIM z własnym serwerem wysyłającym, tak żeby wiadomości były podpisywane Twoją domeną. Procedura: piszesz do nas z prośbą o DKIM dla domeny, dostajesz trzy wpisy CNAME, dodajesz je w DNS i dajesz nam znać, żebyśmy domknęli konfigurację.

Gdy wysyłasz przez własny serwer SMTP

Sugester może wysyłać maile przez Twój serwer pocztowy albo dostawcę SMTP, a kopia każdej wiadomości zostaje na Twoim serwerze. Wtedy SPF i DKIM konfigurujesz u tego dostawcy, a Sugester korzysta z jego uwierzytelnienia. Opis na stronach Poczta SMTP i Integracja z własnym dostawcą SMTP.

Najczęstsze błędy

• Dwa rekordy SPF w jednej domenie. Odbiorca traktuje to jak brak SPF. Scal wpisy w jeden rekord.
• Więcej niż 10 zapytań DNS w SPF (za dużo include). Wynik: permerror, czyli SPF nie działa. Usuń dostawców, z których już nie korzystasz.
• DKIM włączony u dostawcy, ale rekord nie dodany w DNS. Podpis jest, ale nie ma czym go sprawdzić.
• Brak zgodności domen. Newsletter wysyłany z adresu w Twojej domenie, ale podpisany domeną dostawcy. DMARC nie przejdzie. Włącz u dostawcy własny DKIM (często nazywany custom domain albo domain authentication).
• p=reject pierwszego dnia. Zanim dodasz wszystkie źródła, własne faktury i powiadomienia ze sklepu zaczną być odrzucane.
• Subdomeny bez polityki. Jeśli główna domena ma p=reject, a subdomeny nie mają własnych rekordów, dziedziczą politykę. Jeśli wysyłasz z subdomeny, ustaw dla niej SPF i DKIM albo użyj sp=.

Jeśli po wdrożeniu nadal masz problem z dostarczalnością, sprawdź reputację domeny w Google Postmaster Tools i poczytaj nasz wpis o tym, co zrobić, żeby mailing nie trafił do spamu.