Ustalenia z wartościami wyjściowymi
Sześć punktów kontrolnych zmierzonych przed poprawkami.
Maile trafiają do spamu? Przyczyna i lista poprawek
Faktury, oferty lub hasła jednorazowe trafiają do spamu albo wracają do nadawcy? Od listopada 2025 r. Gmail ostrzej egzekwuje zasady dla nadawców, także przez odrzucanie wiadomości (stan: 2026-10). Sprawdzamy SPF, DKIM, DMARC i reputację, a potem przekazujemy pisemną listę poprawek.
- Serwery Postfix i Dovecot oraz poczta transakcyjna dla praktycznie wszystkich klientów
- Odpowiedź w ciągu jednego dnia roboczego
Wiadomość trafia do folderu spam czy wraca do nadawcy?
Wiadomość trafia do folderu spam
Serwer odbiorcy przyjmuje wiadomość, ale uznaje ją za podejrzaną. Częste przyczyny to brak uwierzytelnienia (SPF, DKIM, DMARC), zła reputacja domeny lub adresu IP oraz system, który bez kontroli wysyła pocztę w Państwa imieniu.
Wiadomość wraca do nadawcy
W zwrotce (bounce) widnieje kod błędu, na przykład 4.7.x lub 5.7.x. Serwer odbiorcy odrzuca wiadomość, bo uwierzytelnienie się nie powiodło, brakuje wpisu odwrotnego DNS, połączenie nie jest szyfrowane albo adres IP figuruje na liście blokującej.
Przykładem są wymagania Microsoftu dla nadawców, którzy wysyłają co najmniej 5000 wiadomości z tą samą domeną nadawcy do Outlook.com, Hotmail, Live.com lub MSN. Ich wiadomości muszą przejść kontrolę SPF i DKIM, a domena musi mieć rekord DMARC co najmniej z p=none. Domena adresu nadawcy musi przy tym być zgodna z SPF lub DKIM. W przeciwnym razie wiadomość wraca z kodem błędu „550 5.7.515 Access denied”. Według Microsoftu te wymagania są już egzekwowane (pomoc techniczna Microsoft (otwiera się w nowym oknie), stan: 2026-10).
Typowe sytuacje
- Przeprowadzka na nowy serwer, na przykład z Windows/IIS na Linux. Zmieniają się adres IP, wpis odwrotnego DNS i nazwa HELO, a rekord SPF nadal wskazuje stary adres.
- Nowy CRM, usługa newslettera lub helpdesk wysyła pocztę z Państwa domeną.
- Duży klient pyta o SPF, DKIM i DMARC.
- W firmie nie ma już nikogo, kto zna serwer pocztowy.
Pierwsza diagnoza w 15 minut: sześć punktów kontrolnych
| Punkt kontrolny | Co zapewnia | Jak to sprawdzić | Typowy błąd |
|---|---|---|---|
| SPF | Określa, które serwery mogą wysyłać pocztę w imieniu Państwa domeny. |
Odpytać rekord TXT: dig +short TXT domena-firmy.pl. Rekord zaczyna się od v=spf1.
|
Brakuje jednego z nadawców, istnieją dwa rekordy SPF albo potrzeba więcej niż dziesięciu zapytań DNS. |
| DKIM | Dodaje do wiadomości podpis Państwa domeny, po którym odbiorca sprawdza jej pochodzenie i to, czy nikt jej nie zmienił. | Wysłać wiadomość testową na skrzynkę Gmail i wybrać tam „Pokaż oryginał”. Widać tam też wynik SPF i DMARC. | System nie podpisuje wiadomości albo podpisuje je inną domeną niż domena nadawcy. |
| DMARC | Określa, co dzieje się z wiadomościami, które nie przechodzą SPF i DKIM, i dostarcza raporty na ten temat. | Odpytać rekord TXT pod _dmarc.domena-firmy.pl. Rekord zaczyna się od v=DMARC1. | Brak rekordu albo od lat p=none bez analizy raportów. |
| Odwrotny DNS (PTR) | Przypisuje adresowi IP serwera pocztowego nazwę, która wskazuje z powrotem na ten adres. |
Odpytać dig -x z adresem IP, a potem ponownie rozwiązać otrzymaną nazwę.
|
Domyślna nazwa nadana przez dostawcę hostingu albo nazwa inna niż nazwa HELO serwera. |
| TLS | Szyfruje transmisję między serwerami pocztowymi. |
openssl s_client -starttls smtp -connect mail.domena-firmy.pl:25 pokazuje certyfikat i szyfrowanie.
|
Certyfikat wygasł lub został wystawiony na inną nazwę albo brak STARTTLS. |
| Nagłówek wypisu | Wypis jednym kliknięciem, wymagany przy newsletterach i masowej wysyłce reklamowej. | Sprawdzić w nagłówkach wiadomości z newslettera pola List-Unsubscribe i List-Unsubscribe-Post. | Brakuje nagłówka albo wypisy nie są przetwarzane. |
Jakie systemy jeszcze wysyłają pocztę w Państwa imieniu?
Jeśli sześć punktów kontrolnych jest w porządku, warto sprawdzić inne systemy, które wysyłają pocztę z Państwa domeną: CRM, usługę newslettera, helpdesk, księgowość albo formularz na stronie. Każdy z nich powinien być ujęty w rekordzie SPF i mieć klucz DKIM dla Państwa domeny; bez tego jego wiadomości mogą nie przejść kontroli u odbiorcy.
Takich nadawców szukamy w DNS, w logach Państwa serwera pocztowego i w istniejących raportach DMARC. Raporty pokazują wszystkie serwery, które wysyłają pocztę z Państwa domeną. Jeśli raportów brakuje, najpierw zbieramy je z p=none. To trwa dłużej niż sam test.
Jak przebiega test dostarczalności
-
Dostęp i pomiar
Otrzymujemy dostęp do DNS i serwera pocztowego albo wyciągi z logów oraz przykłady wiadomości, których dotyczy problem. Mierzymy sześć punktów kontrolnych i wysyłamy wiadomości testowe na skrzynki dużych dostawców.
-
Spis nadawców
Na podstawie DNS, logów i istniejących raportów DMARC ustalamy, które systemy wysyłają pocztę w Państwa imieniu, i sprawdzamy ich wiadomości pod kątem SPF i DKIM.
-
Ocena przyczyn
Sprawdzamy reputację Państwa adresów IP i domeny, na przykład na listach blokujących, i porządkujemy ustalenia według efektu i nakładu pracy.
-
Lista poprawek i omówienie
Otrzymują Państwo pisemne ustalenia i plan wdrożenia DMARC. Omawiamy je z Państwem i z Państwa działem IT.
Co zawiera wynik testu
Poprawki wprowadza na podstawie listy Państwa dział IT albo, na życzenie, my w ramach osobnego projektu.
-
-
Lista znalezionych nadawców
Systemy, które wysyłają pocztę z Państwa domeną, każdy z wynikiem kontroli.
-
Działania według priorytetu
Z miejscem zmiany (DNS, aplikacja lub serwer pocztowy) i nakładem pracy.
-
Plan wdrożenia DMARC
Kroki od p=none do p=reject, z adresem do odbioru raportów.
Czego Gmail i Yahoo wymagają od nadawców
| Data | Zdarzenie | Źródło |
|---|---|---|
| 2024-02-01 | Gmail wymaga od wszystkich nadawców SPF lub DKIM, poprawnych rekordów DNS prostych i odwrotnych (PTR), TLS i odsetka spamu poniżej 0,3%. Przy około 5000 wiadomości dziennie do adresów Gmail wymagane są jednocześnie SPF i DKIM oraz DMARC z dopasowaniem domen (alignment). | support.google.com (otwiera się w nowym oknie) |
| 2024-02-01 | Od lutego 2024 r. Yahoo wymaga od wszystkich nadawców SPF lub DKIM, poprawnych rekordów DNS prostych i odwrotnych oraz skarg na spam poniżej 0,3%. Nadawcy masowi potrzebują obu metod, do tego DMARC i realizacji wypisów w ciągu dwóch dni. | senders.yahooinc.com (otwiera się w nowym oknie) |
| 2024-06-01 | Gmail wymaga od nadawców masowych wypisu jednym kliknięciem w wiadomościach marketingowych i reklamowych. Nadawcy, którzy mieli już link do wypisu, dostali czas do tego dnia. | support.google.com (otwiera się w nowym oknie) |
| 2025-11-01 | Od listopada 2025 r. Gmail ostrzej egzekwuje wymagania. Niezgodne wiadomości są coraz częściej odrzucane czasowo lub trwale, co widać po kodach błędów z serii 4.7.x i 5.7.x. | support.google.com (otwiera się w nowym oknie) |
Plan DMARC: od p=none do p=reject bez blokowania własnych maili
-
Obserwacja z p=none
Publikujemy DMARC z p=none i adresem do odbioru raportów. Wiadomości docierają jak dotąd, a raporty pokazują wszystkich nadawców i miejsca, w których SPF lub DKIM zawodzą.
-
Porządkowanie nadawców
Konfigurujemy SPF i DKIM dla każdego uprawnionego systemu, aż raporty przestaną wykazywać własne wiadomości jako błędne. Zależnie od liczby nadawców może to trwać tygodnie.
-
Przejście na p=quarantine
Wiadomości, które nie przechodzą DMARC, trafiają u odbiorcy do folderu spam. Nadal czytamy raporty i poprawiamy to, co się w nich pojawia.
-
Przejście na p=reject
Jeśli raporty pozostają czyste, odbiorcy odrzucają wiadomości, które podają Państwa domenę jako nadawcę, ale nie przechodzą DMARC. Obserwujemy dalej, bo dochodzą nowe systemy. BIMI, czyli wyświetlanie Państwa logo u odbiorcy, to opcjonalny dodatek, a nie warunek dostarczenia.
Gdy aplikacja sama wysyła wiadomości
Wiele aplikacji samodzielnie wysyła pocztę: ColdFusion i Lucee przez cfmail, PHP przez mail() albo przez bibliotekę. Typowe błędy:
- Aplikacja wysyła pocztę bezpośrednio z serwera WWW, zamiast logować się przez SMTP do serwera pocztowego (submission). Rekord SPF nie zna tego serwera.
- Adres nadawcy należy do innej domeny niż ta, dla której obowiązują SPF i DKIM.
- Zwrotki trafiają do skrzynki, której nikt nie czyta, a nieprawidłowe adresy zostają na liście wysyłkowej.
Jeśli wysyłka idzie przez własny serwer Postfix, sprawdzamy też jego konfigurację, kolejkę i logi. Lista poprawek wskazuje, gdzie powstaje błąd: w aplikacji, na serwerze pocztowym czy w DNS. Więcej o pracy z ColdFusion i Lucee oraz z PHP piszemy na stronach technologii.
Doświadczenie naszych inżynierów z serwerami pocztowymi i pocztą z aplikacji
- Utrzymanie poczty
- Serwery Postfix i Dovecot oraz systemy poczty transakcyjnej, dla praktycznie wszystkich klientów
- Poczta z aplikacji
- Wysyłka z ColdFusion, Lucee i PHP, łącznie ze zwrotkami i wypisami
- Uwierzytelnianie i reputacja
- SPF, DKIM i DMARC z raportami, odwrotny DNS, TLS i reputacja nadawców
- Full stack i DevOps
- Od 2012 r., od aplikacji po serwer
Jak pracujemy nad dostarczalnością poczty
- Dane dostępowe, konfiguracja i dokumentacja zostają u Państwa.
- Mówimy też wprost, gdy coś się nie opłaca.
O dostarczeniu decyduje serwer odbiorcy
Test obejmuje więc to, na co mamy wpływ: poprawność techniczną wysyłki, zgodność z wytycznymi dostawców poczty i pomiar wyniku.
A co, jeśli u nas ktoś będzie niedostępny?
Dokumentację sporządzamy na życzenie. Repozytorium z reguły znajduje się u Państwa. Zastępstwo organizujemy na życzenie. Zasady współpracy opisuje strona Współpraca.
Pierwszy krok: test dostarczalności z listą działań i planem DMARC
Test dostarczalności poczty
Dla firm, których faktury, oferty lub hasła jednorazowe trafiają do spamu albo wracają jako niedostarczone.
- Rekordy DNS Państwa domeny: SPF, DKIM, DMARC i odwrotny DNS (PTR)
- Reputacja Państwa domeny i adresów IP, z których wychodzi poczta
- Nagłówki prawdziwych wiadomości z Państwa aplikacji i pozostałych systemów
- Wysyłka testowa na skrzynki dużych dostawców poczty
- Lista poprawek według priorytetu
Zakres i cenę ustalamy w rozmowie wstępnej i potwierdzamy na piśmie przed rozpoczęciem pracy. Test nie obejmuje samych poprawek ani stałego utrzymania serwerów pocztowych. Oba zakresy uzgadniamy na życzenie później.
Co zawiera wynik
Pisemna lista działań z przyczynami i poprawkami według priorytetu oraz plan wdrożenia DMARC. Oba dokumenty należą do Państwa.
Dwa przypadki z naszej pracy
-
Dostarczalność poczty dla czterech domen firmowych
Serwer pocztowy czterech domen firmowych niczego nie podpisywał, nie publikował polityki DMARC i był odrzucany przez Microsoft. Nasi inżynierowie sprawdzili go, przetestowali zmianę na jednej domenie i wdrożyli ją partiami. Efekt: wszystkie trzy mechanizmy przechodzą sprawdzenie w Gmailu, blokada Microsoftu została zdjęta, a użytkownicy niczego nie odczuli.
-
Filtr antyspamowy, który działał, ale nie chronił
Usługi uruchomione, konfiguracja poprawna, w statusie systemu żadnych błędów. A mimo to phishing lądował w skrzynkach odbiorczych, a newslettery partnerów w folderze spam. Nasi inżynierowie zmierzyli, które mechanizmy wykrywania naprawdę działają, usunęli przyczyny, a trzy miesiące później znaleźli i naprawili regresję, którą było widać dopiero w ujęciu godzinowym.
Częste pytania o spam, SPF, DKIM i DMARC
Czy DMARC z p=reject zablokuje nasze własne faktury?
Nie, jeśli wszyscy nadawcy są wcześniej spisani i skonfigurowani. Zaczynamy od p=none i czytamy raporty DMARC: pokazują one, które systemy wysyłają pocztę w Państwa imieniu. Dla każdego uprawnionego systemu konfigurujemy SPF i DKIM. Na p=quarantine, a potem na p=reject przechodzimy dopiero wtedy, gdy raporty przestają wykazywać własne wiadomości jako błędne.
Jeśli później dojdzie nowy system, przed pierwszą wysyłką potrzebuje wpisu w SPF i klucza DKIM. Inaczej odbiorcy będą odrzucać jego wiadomości.
Czy wystarczy, że nasza usługa newslettera podpisuje wiadomości?
Nie automatycznie. Wiele usług na początku podpisuje wiadomości własną domeną. Dla DMARC podpis lub rekord SPF musi jednak pasować do Państwa domeny nadawcy (alignment). W tym celu ustawiają Państwo w usłudze swoją domenę jako domenę nadawcy i dodają we własnym DNS wpisy wskazane przez usługę.
Czy tak się stało, pokazują nagłówki wiadomości testowej (Authentication-Results) i raporty DMARC. To samo dotyczy CRM, helpdesku i innych systemów, które wysyłają pocztę w Państwa imieniu.
Dlaczego po przeprowadzce serwera maile trafiają do spamu?
Przy przeprowadzce zwykle zmieniają się adres IP, wpis odwrotnego DNS i nazwa, którą serwer się przedstawia (HELO). Rekord SPF podaje wtedy nadal stary adres, a na nowym systemie często brakuje klucza DKIM. Do tego nowy adres IP nie ma jeszcze reputacji u dużych dostawców poczty.
Dotyczy to także aplikacji, które same wysyłają pocztę, na przykład przez cfmail po przejściu z Windows/IIS na Linux. Przy planowanej przeprowadzce te punkty należą więc do listy kontrolnej, zanim serwery zostaną przełączone.
Jak szybko działają poprawki?
To zależy najpierw od tego, kiedy poprawki trafią do systemów: zmiany w DNS, na serwerze pocztowym lub w aplikacji wprowadza Państwa dział IT, dostawca hostingu albo my, po otrzymaniu dostępu. Zmiany w DNS zaczynają działać, gdy wygaśnie czas ważności dotychczasowego wpisu (TTL). Reputacja domeny lub adresu IP odbudowuje się w tempie zależnym od dostawcy poczty i od przyczyny, dlatego po poprawkach warto zmierzyć wynik ponownie.
Czy mogą Państwo zagwarantować, że nasze e-maile trafią do skrzynki odbiorczej?
Gwarancja dostarczenia nie jest technicznie możliwa, ponieważ decyduje serwer odbiorcy. Dbamy o poprawne technicznie, zgodne z wytycznymi i monitorowane dostarczanie wiadomości. SPF, DKIM i DMARC są ustawione prawidłowo, reputacja Państwa nadawców jest obserwowana, a wszystkie systemy wysyłające w Państwa imieniu są ujęte w spisie. Następnie mierzymy wynik.
Co zrobić, jeśli brakuje nam danych dostępowych?
Zwykle da się to rozwiązać. Zaczynamy od tego, czym Państwo dysponują: umową i kontem u dostawcy hostingu, dostępem do domeny oraz, jeśli istnieją, repozytorium i kopiami zapasowymi. Dostęp do serwera często można zresetować przez dostawcę hostingu, jeśli występują Państwo jako strona umowy. Dostęp do systemu uzyskujemy wyłącznie za Państwa wyraźną zgodą.
Kiedy mogą Państwo zacząć?
Pierwszą odpowiedź otrzymają Państwo w ciągu jednego dnia roboczego. Kiedy zaczniemy pracę, zależy od bieżącego obłożenia i od zakresu. Powiemy to Państwu wiążąco podczas rozmowy wstępnej. Jeśli sprawa jest pilna, Ocena awaryjna w 48 godzin rozpoczyna się z chwilą, gdy uzyskamy dostęp do systemu.
Które wiadomości trafiają u Państwa do spamu?
Wystarczy podać, których wiadomości to dotyczy, u jakich odbiorców i od kiedy. Odpowiadamy w ciągu jednego dnia roboczego i proponujemy odpowiedni pierwszy krok.