Dostarczalność e-maili: SPF, DKIM, DMARC i rozgrzewanie IP

Czego Gmail, Yahoo i Outlook wymagają od masowych nadawców w 2026 roku?

Trzej najwięksi dostawcy prywatnych skrzynek wymagają dziś od dużych nadawców poczty uwierzytelnionej. Potrzebujesz SPF i DKIM oraz rekordu DMARC co najmniej p=none, który przechodzi dzięki domenie wyrównanej z adresem From widocznym dla odbiorcy. Gmail i Yahoo wymagają też wypisu jednym kliknięciem i wskaźnika skarg na spam poniżej 0,3%. Outlook.com niezgodną pocztę po prostu odrzuca.

Stan na 2026-10-17. Źródła: wytyczne Google, FAQ Google, Yahoo best practices, ogłoszenie Microsoft.

Dwa szczegóły, na których potykają się osoby wysyłające z własnego serwera:

• Wskaźnik spamu w Gmailu jest mierzony, nie szacowany. Liczy się wartość z Postmaster Tools. Google każe nigdy nie dochodzić do 0,30% i trzymać się poniżej 0,10%.
• Microsoft zmienił zdanie. Wpis z kwietnia 2025 zapowiadał najpierw przenoszenie niezgodnej poczty do folderu Wiadomości-śmieci. Aktualizacja z 29 kwietnia zastąpiła to odrzucaniem od 5 maja 2025, z błędem 5.7.515.

Jeśli wysyłasz mniej niż 5000 dziennie, Google i tak wymaga od wszystkich nadawców SPF lub DKIM, poprawnych rekordów PTR, TLS, formatu zgodnego z RFC 5322 i wskaźnika spamu poniżej 0,3%. Skonfiguruj wszystko od razu. Wolumen rośnie, a status masowego nadawcy nie wygasa.

Polskie skrzynki (WP, Onet, Interia, o2) nie zostały w tym przewodniku sprawdzone pod kątem własnych progów. Te same podstawy uwierzytelniania i higieny listy działają jednak wszędzie.

Dlaczego dostarczalność jest trudniejsza przy wysyłce z własnego serwera?

Własny serwer nie zmienia zasad. Zmienia tylko to, kto za nie odpowiada. Na platformie SaaS infrastrukturę wysyłki prowadzi dostawca i to on pilnuje innych klientów na współdzielonych IP. Gdy prowadzisz własną platformę, każde ogniwo jest Twoje:

1. DNS: SPF, DKIM, DMARC, a przy własnych IP także PTR.
2. Ścieżka wysyłki: przekaźnik SMTP albo API (Amazon SES, Mailgun, SendGrid, Gmail API) lub własny serwer MTA.
3. Reputacja IP: współdzielone czy dedykowane, a przy nowym IP rozgrzewanie.
4. Jakość listy: zgody, zwroty, lista wykluczeń, nieaktywni.
5. Monitoring: Postmaster Tools, SNDS, raporty DMARC, czarne listy.

Zaletą jest kontrola. Nikt nie zablokuje Ci konta przez cudzy spam, a koszty nie rosną z każdym kontaktem. Wadą jest to, że nikt nie naprawi problemów za Ciebie. Jest też kwestia zgód: podstawą wysyłki marketingowej jest udokumentowana zgoda odbiorcy (RODO i przepisy o komunikacji elektronicznej). Dane o zgodach trzymasz u siebie, ale to Ty odpowiadasz za ich poprawność.

Jak współpracują SPF, DKIM i DMARC?

SPF wskazuje serwery uprawnione do wysyłki dla domeny kopertowej (zwrotnej). DKIM podpisuje wiadomość kluczem opublikowanym w DNS. DMARC sprawdza, czy co najmniej jeden z nich przechodzi dla domeny wyrównanej z adresem From, który widzi odbiorca, i mówi serwerowi odbiorcy, co zrobić, gdy żaden nie przechodzi.

Cztery zapytania DNS, które serwer odbiorcy wykonuje dla jednej wiadomości, i domena, której dotyczy każde z nich.

Przykładowe rekordy DNS

Poniżej example.com to Twoja domena From, bounce.example.com to subdomena kopertowa (Return-Path), a 203.0.113.10 to adres IP z puli dokumentacyjnej. Podmień wszystkie trzy.

; SPF + MX dla własnej domeny MAIL FROM w Amazon SES (wartości z dokumentacji SES)
bounce.example.com.          TXT  "v=spf1 include:amazonses.com ~all"
bounce.example.com.          MX   10 feedback-smtp.eu-west-1.amazonses.com.

; SPF przy wysyłce z własnego IP (np. NMI)
example.com.                 TXT  "v=spf1 ip4:203.0.113.10 ~all"

; DKIM: selektor "ns1", klucz publiczny z panelu dostawcy lub NMI (skrócony)
ns1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."

; DMARC: zacznij od trybu monitorowania i zbieraj raporty zbiorcze
_dmarc.example.com.          TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

; PTR dla własnego IP: ustawia go właściciel adresu (hosting), nie Ty w swojej strefie
10.113.0.203.in-addr.arpa.   PTR  mail1.example.com.

Zasady, które oszczędzają godziny debugowania:

• Jeden rekord SPF na nazwę i najwyżej 10 zapytań DNS. RFC 7208 wlicza do limitu include, a, mx, ptr, exists i redirect, a jego przekroczenie daje wynik permerror. ip4 i ip6 się nie liczą.
• SPF sprawdza domenę kopertową, nie nagłówek From. Żeby SPF liczył się do DMARC, domena MAIL FROM musi być wyrównana z domeną From. Dlatego AWS zaleca własną subdomenę MAIL FROM. Przy domyślnej kopercie amazonses.com wyrównany może być tylko DKIM.
• Niech wyrównanie zapewnia DKIM. Podpisuj z d=example.com lub subdomeną tej domeny, kluczem 2048-bitowym. Gmail wymaga co najmniej 1024 bitów.
• DMARC przestawiaj z none na egzekwowanie stopniowo. dmarc.org zaleca kolejność: opublikuj p=none, czytaj raporty, napraw każde legalne źródło wysyłki, potem przejdź na quarantine, a na końcu na reject.
• PTR musi się zgadzać. Nazwa zwrotna IP powinna wskazywać z powrotem na ten sam adres (Gmail i Yahoo chcą poprawnego DNS w przód i wstecz). Yahoo dodatkowo oczekuje nazwy „znaczącej, nie generycznej”.

Jak dodać wypis jednym kliknięciem (RFC 8058)?

Dodajesz dwa nagłówki do każdej wiadomości marketingowej, udostępniasz adres HTTPS, który wypisuje po otrzymaniu żądania POST, i pilnujesz, żeby DKIM podpisywał oba nagłówki.

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

Wymagania RFC 8058:

• List-Unsubscribe musi zawierać jeden adres HTTPS. Można dodać też adres mailto.
• Wiadomość musi mieć poprawny podpis DKIM obejmujący oba nagłówki. Bez niego odbiorca nie powinien oferować wypisu jednym kliknięciem.
• Skrzynka wysyła POST z treścią List-Unsubscribe=One-Click, bez ciasteczek i autoryzacji. Twój serwer nie może odpowiedzieć przekierowaniem, a sam adres musi identyfikować subskrybenta, zwykle przez podpisany token.
• Potem trzeba faktycznie przestać wysyłać: w ciągu 48 godzin dla Gmaila i 2 dni dla Yahoo.

W NetSendo: changelog wymienia obsługę RFC 8058 w sekcji Unreleased (stan na 17 października 2026), czyli w wydaniu po v2.1.3. Podpisane adresy wypisu przyjmują wtedy POST jednym kliknięciem, a mailingi i autorespondery wysyłane do listy dostają oba nagłówki automatycznie. Ręcznie ustawiony List-Unsubscribe ma pierwszeństwo, a EMAIL_LIST_UNSUBSCRIBE=false wyłącza automatyczne nagłówki. W v2.1.3 i starszych adres wypisu odpowiada tylko na GET, więc zanim na tym oprzesz wysyłkę, sprawdź swoją wersję.

IP współdzielone czy dedykowane przy wysyłce z własnego serwera?

Wybierz IP współdzielone, chyba że wysyłasz duże wolumeny według stałego harmonogramu. Dedykowane IP oddziela Twoją reputację od innych nadawców, ale nowe IP nie ma żadnej reputacji. Trzeba je rozgrzać, a potem stale używać.

Stan na 2026-10-17. Źródła: Amazon SES: dedykowane IP, cennik SES, dokumentacja NMI. Ceny w USD, tak jak na stronie AWS.

AWS pisze wprost, że jeśli nie planujesz regularnej i przewidywalnej wysyłki dużych wolumenów, lepiej używać adresów współdzielonych. NetSendo nie ma własnych limitów wysyłki i działa z każdą z tych ścieżek. Pod Ustawienia → Skrzynki możesz podłączyć SMTP (SES, Mailgun lub własny serwer), Gmail API, SendGrid albo wbudowany MTA NMI (dokumentacja konfiguracji).

Jeśli planujesz własne IP, sprawdź najpierw, czy hosting pozwala ustawić rekord PTR i nie blokuje wychodzącego SMTP na porcie 25.

Jak wygląda bezpieczny harmonogram rozgrzewania IP?

Zwiększaj dzienny wolumen stopniowo przez mniej więcej dwa do sześciu tygodni, zaczynaj od najbardziej zaangażowanych subskrybentów i zwalniaj, gdy tylko zobaczysz ograniczanie przepustowości albo blokady. AWS podaje, że u części dostawców reputację da się zbudować w około dwa tygodnie, a u innych trwa to do sześciu. Automatyczne rozgrzewanie dedykowanych IP w SES trwa 45 dni.

NMI w NetSendo ma domyślny harmonogram 28-dniowy (NMI_WARMING_DAYS=28, z automatycznym przechodzeniem do kolejnego dnia):

Źródło: dokumentacja NMI, sprawdzona 2026-10-17. To ustawienie domyślne, nie uniwersalny standard. Wydłuż je, jeśli lista jest słabiej zaangażowana.

Domyślne zakresy rozgrzewania w NMI na skali logarytmicznej. Każdy słupek obejmuje minimalny i maksymalny dzienny limit danej fazy.

Zasady ważniejsze od dokładnych liczb:

• Najpierw zaangażowani odbiorcy. Zacznij od osób, które niedawno otwierały albo klikały. Według AWS to utrzymuje niski wskaźnik skarg.
• Codziennie sprawdzaj zwroty. Gdy pojawiają się komunikaty o blokadzie lub ograniczaniu (odroczenia 4xx, „rate limited”), wstrzymaj albo zmniejsz wolumen na dzień.
• Bez skoków po rozgrzaniu. AWS ostrzega, że nagłe duże wzrosty kończą się blokadą lub ograniczaniem. Po rozgrzaniu wysyłaj ok. 1000 maili dziennie do każdego dostawcy, u którego chcesz utrzymać reputację.
• Jedno IP, jeden rodzaj poczty. Marketing i maile transakcyjne trzymaj na osobnych IP lub pulach, żeby słaba kampania nie zaszkodziła resetom haseł.

Jak utrzymać listę na tyle czystą, żeby skargi nie przekroczyły 0,3%?

Wysyłaj tylko do osób, które o to prosiły, usuwaj adresy, które się odbijają, i przestań pisać do tych, którzy przestali czytać. Skargi biorą się głównie od ludzi, którzy zapomnieli, że się zapisali, albo nigdy się nie zapisali.

• Double opt-in dla nowych zapisów. Blokuje literówki, boty i złośliwe zapisy. Przy okazji zostawia czytelny ślad zgody, przydatny przy RODO.
• Automatyczna obsługa zwrotów. NetSendo czyta raporty doręczeń ze skrzynki zwrotnej (Return-Path) przez IMAP, oznacza twarde zwroty, liczy miękkie zwroty względem progu ustawionego dla listy i pomija przy wysyłce kontakty odbite i wypisane (według changelogu).
• Lista wykluczeń. Adresy z listy wykluczeń obowiązującej w całym koncie NetSendo są pomijane wszędzie, także przy przyszłych importach.
• Wygaszanie nieaktywnych. Otaguj osoby bez otwarć i kliknięć od 6–12 miesięcy, wyślij jedną prośbę o potwierdzenie zainteresowania, a potem przestań wysyłać. Serwer MCP NetSendo ma analyze_list_health, verify_list_emails i clean_list, który domyślnie działa na sucho. Zobacz przewodnik o serwerze MCP do e-mail marketingu.
• Nigdy nie importuj kupionych ani zebranych automatycznie list. Żaden harmonogram rozgrzewania nie przetrwa pułapek spamowych (spam traps).
• Wypisanie musi być łatwiejsze niż zgłoszenie spamu. Daj widoczny link w stopce i nagłówki jednego kliknięcia. Kto nie znajdzie linku, kliknie „Zgłoś spam”.

Jakich narzędzi używać do monitorowania dostarczalności?

Korzystaj z paneli samych dostawców skrzynek, czytaj raporty DMARC i sprawdzaj czarne listy. Testy na skrzynkach kontrolnych (seed tests) bywają pomocne, ale najpierw liczą się dane od dostawców.

Stan na 2026-10-17.

NetSendo pozwala też dodawać własne nagłówki dla skrzynki lub pojedynczej wysyłki przez API, np. Feedback-ID dla pętli zwrotnej w Postmaster Tools.

Jak NetSendo pomaga w dostarczalności?

NetSendo daje narzędzia kontroli. To, czy mail trafi do skrzynki, nadal zależy od Twojej listy i treści. Poniższe funkcje opisują dokumentacja NMI, changelog i dokumentacja konfiguracji:

• Dowolna ścieżka wysyłki: SMTP (Amazon SES, Mailgun, własny serwer), Gmail API, SendGrid albo NMI. Sam NetSendo nie ma limitów wysyłki.
• NMI (NetSendo Mail Infrastructure). Opcjonalny MTA oparty na Haraka, uruchamiany poleceniem docker compose --profile nmi up -d. Daje pule IP współdzielonych i dedykowanych, 28-dniowy harmonogram rozgrzewania, automatyczne 2048-bitowe klucze DKIM z weryfikacją DNS i opcjonalną rotacją, monitoring DNSBL i progi reputacji. Domyślnie wstrzymuje wysyłkę poniżej wyniku 50 i ogranicza zwroty do 5%, a skargi do 0,1%.
• Pomoc przy uwierzytelnianiu domeny: generator SPF sprawdzający limit zapytań, generator i kreator DMARC (none, quarantine, reject) oraz kontrola statusu domeny.
• Obsługa zwrotów i wykluczeń: przetwarzanie zwrotów przez IMAP, progi miękkich zwrotów, zakres zwrotów dla listy lub globalny i lista wykluczeń obowiązująca w całym koncie.
• Wypis jednym kliknięciem: automatyczne nagłówki RFC 8058 w najbliższym wydaniu (patrz wyżej).
• Własne nagłówki na poziomie konta, listy, skrzynki lub wiadomości.

Warunki licencji są w cenniku. SILVER to darmowa licencja do użytku we własnej firmie, a za serwer i wysyłkę płacisz osobno. NetSendo jest source-available, a nie open source. Tu wyjaśniamy różnicę.

Checklista dostarczalności przy wysyłce z własnego serwera

1. Wysyłaj z własnej domeny, nigdy z darmowej skrzynki. Jeśli chcesz oddzielić reputację marketingu, użyj subdomeny, np. news.example.com.
2. Opublikuj jeden rekord SPF na nazwę i zmieść się w 10 zapytaniach.
3. Podpisuj DKIM (2048 bitów) w domenie wyrównanej z adresem From.
4. Użyj własnej subdomeny MAIL FROM (zwrotnej), żeby wyrównać też SPF.
5. Opublikuj DMARC p=none z adresem rua i czytaj raporty co tydzień.
6. Przy własnych IP ustaw PTR na znaczącą nazwę, która wskazuje z powrotem na to IP, i włącz TLS.
7. Dodaj List-Unsubscribe i List-Unsubscribe-Post i realizuj wypisy w ciągu 48 godzin.
8. Zacznij od IP współdzielonego. Na dedykowane przejdź dopiero przy stałym, dużym wolumenie.
9. Rozgrzewaj nowe IP przez co najmniej 2–4 tygodnie, zaczynając od zaangażowanych odbiorców.
10. Używaj double opt-in, automatycznej obsługi zwrotów i listy wykluczeń.
11. Wygaszaj kontakty bez aktywności od 6–12 miesięcy.
12. Zarejestruj Postmaster Tools, Yahoo CFL i SNDS/JMRP. Trzymaj wskaźnik spamu poniżej 0,10%.
13. Monitoruj czarne listy i wstrzymuj wysyłkę, gdy rosną zwroty lub skargi.
14. Gdy raporty DMARC są czyste, przejdź na quarantine, potem na reject.

Przenosisz się z SaaS? Migrację opisuje przewodnik o alternatywie dla Mailchimp na własnym serwerze. Skrzynki i zmienne środowiskowe znajdziesz w dokumentacji konfiguracji.