Defaults.Exposed › Naprawy › Guides
E-maile z formularza kontaktowego trafiają do spamu — naprawa nadawcy serwera WWW (2026)
Opublikowano 2026-07-08
Dane z 2026-06-29 · metodologia v7. Zagregowane dane ze spisu 261 milionów ocenianych domen. Zobacz jak oceniamy.
E-maile z formularza kontaktowego i strony trafiają do spamu, ponieważ Twój serwer WWW wysyła je bez uwierzytelniania — bez autoryzacji SPF, bez podpisu DKIM. Niezawodną naprawą jest kierowanie tej poczty przez uwierzytelniony SMTP, a nie umieszczanie serwera na białej liście. 46,4% z 261 086 232 domen ocenionych w spisie Defaults.Exposed (dane z 2026-06-29) nie publikuje w ogóle rekordu SPF.
Kolejność naprawy ma znaczenie i większość poradników odwraca ją. Uruchom bezpłatne skanowanie, żeby zobaczyć, co faktycznie publikuje Twoja domena; kieruj pocztę strony przez uwierzytelniony SMTP (Twój dostawca skrzynki lub usługa poczty transakcyjnej), żeby uzyskał prawdziwy podpis DKIM; napraw adres From formularza; i tylko jako ostatnią deskę ratunku dodaj IP serwera do SPF.
Dlaczego e-maile z mojej strony trafiają do spamu?
Z powodu kto faktycznie je wysyła. Gdy odwiedzający wypełnia formularz kontaktowy, e-mail nie jest wysyłany przez Twojego dostawcę poczty — serwer WWW generuje go samodzielnie, zazwyczaj przez mail() PHP. Z perspektywy odbiorcy ta wiadomość:
- pochodzi z IP, którego Twój rekord SPF nie autoryzuje (Twoje SPF obejmuje dostawcę poczty, nie host WWW);
- nie niesie żadnego podpisu DKIM, więc nic kryptograficznie nie łączy jej z Twoją domeną;
- często wysyłana jest z IP współdzielonego hostingu, którego reputację ustawia setki stron obcych ludzi.
Nieuwierzytelniona poczta z IP o mieszanej reputacji to dokładnie to, do przechwytywania czego istnieją filtry spamu — Gmail i Outlook widzą losowy serwer twierdzący, że jest Tobą. Szersza podstawa jest ponura: 46,4% domen nie publikuje w ogóle SPF, a tylko 10,59% (27 640 987 z 261 086 232 ocenianych domen, spis z 2026-06-29) wymusza politykę DMARC.
Dlaczego ten problem dotyczy szczególnie stron WordPress?
WordPress wysyła całą swoją pocztę — powiadomienia z formularzy, resetowania haseł, potwierdzenia zamówień — przez jedną funkcję, wp_mail(), która domyślnie owija mail() PHP na serwerze WWW. Każda strona WordPress, która nie została celowo przerekonfigurowana, jest od razu nieuwierzytelnionym nadawcą. Wtyczki formularzy (Contact Form 7, WPForms, Gravity Forms) wszystkie przekazują pocztę tej samej funkcji: wygląda to jak problem z wtyczką, ale jest to problem z transportem.
Naprawą nie jest inna wtyczka formularza, ale wtyczka SMTP (WP Mail SMTP i jej odpowiedniki), która przekierowuje wszystko, co wysyła wp_mail(), przez prawdziwe, uwierzytelnione konto pocztowe — infrastrukturę, którą Twoje SPF już autoryzuje, z dołączonym podpisem DKIM.
Której metody wysyłania powinna używać strona?
| Metoda wysyłania | SPF | DKIM | Przeżywa migrację hosta? | Werdykt |
|---|---|---|---|---|
PHP mail() / domyślne wp_mail() z serwera WWW | nie przechodzi | brak | n/a — zepsute wszędzie | problem, nie opcja |
| Uwierzytelniony SMTP przez dostawcę skrzynki (Google Workspace, Microsoft 365 itp.) | przechodzi | podpisany | tak — niezależny od hostingu | naprawa dla większości stron |
| Usługa poczty transakcyjnej (SES, Postmark, Brevo itp.) z zweryfikowaną domeną | przechodzi | podpisany | tak | naprawa przy wolumenie (e-commerce, duże formularze) |
| IP serwera WWW dodane do rekordu SPF | przechodzi (tylko SPF) | brak | nie — psuje się cicho, gdy IP się zmienia | tylko jako awaryjne — patrz poniżej |
Na kilka powiadomień dziennie, SMTP przez skrzynkę, za którą już płacisz, to najkrótsza droga; przy prawdziwym wolumenie usługa transakcyjna jest do tego stworzona. Oba dają DKIM — skrót przez umieszczanie IP na białej liście nigdy tego nie robi.
Jak naprawić dostarczalność poczty z formularza kontaktowego?
- Uruchom bezpłatne skanowanie na defaults.exposed przed dotknięciem czegokolwiek. Pokazuje, co faktycznie publikuje Twoja domena w SPF, DKIM i DMARC — czy naprawiasz transport formularza, brakujący rekord, czy oba. Brak SPF w ogóle? Zacznij od jak naprawić SPF.
- Utwórz dedykowaną tożsamość SMTP dla strony — np.
[email protected]u dostawcy skrzynki, lub zweryfikowaną domenę wysyłkową w usłudze transakcyjnej. Użyj hasła aplikacji lub klucza API, który możesz unieważnić, nie hasła osobistej skrzynki. - Kieruj pocztę strony przez nią. WordPress: zainstaluj wtyczkę SMTP i wskaż ją na to konto. Inne stosy: skonfiguruj mailer frameworka zamiast lokalnego
mail(). - Napraw adres From (antywzorzec poniżej): From musi być z Twojej własnej domeny; adres odwiedzającego trafia do Reply-To.
- Jeśli nadawcą jest usługa transakcyjna, dodaj jej rekordy DKIM (zazwyczaj para CNAME), żeby poczta była podpisana Twoją domeną — kroki DNS odzwierciedlają opisy konfiguracji SPF.
- Wyślij testowe zgłoszenie i przeskanuj ponownie. Nagłówki powinny pokazywać
spf=passidkim=passdla Twojej domeny; następnie usuń wszystko inne zaznaczone przez skanowanie przez naprawę SPF i naprawę DKIM.
Dlaczego formularz wysyła „od” adresu e-mail odwiedzającego?
Najczęstszy samozadany błąd w konfiguracji formularza, a wiele wtyczek robiło to domyślnie: powiadomienie dociera From: adres odwiedzającego, żebyś mógł nacisnąć odpowiedz. To wygodne i jest sfałszowaniem. Twój serwer nie ma prawa wysyłać poczty jako [email protected] — nie przechodzi SPF i DKIM dla gmail.com, a polityka DMARC Gmaila mówi odbiorcom, żeby to wyrzucili lub odrzucili. Naprawa nic nie kosztuje:
- From: adres z Twojej własnej domeny (tożsamość SMTP z kroku 2)
- Reply-To: adres odwiedzającego — odpowiedź nadal trafia prosto do nich
Każda główna wtyczka formularzy to obsługuje; to dwa pola w ustawieniach powiadomień.
Dlaczego nie po prostu dodać IP serwera do rekordu SPF?
To naprawa, po którą większość wątków na forach sięga jako pierwszą, i jest awaryjną z powodu. Dodanie ip4:<serwer> (lub mechanizmu a dla hosta WWW) do SPF sprawia, że surowe sprawdzenie przechodzi — ale:
- Na współdzielonym hostingu autoryzuje obcych. IP należy do maszyny, nie do Ciebie; każda inna strona na tym serwerze może teraz wysyłać pocztę zaliczającą SPF jako Twoja domena.
- Psuje się cicho. Hosty migrują serwery i rotują IP bez informowania Cię; Twoje SPF nadal autoryzuje adres, który opuściłeś miesiące temu.
- Nie daje DKIM. Samo SPF psuje się przy przekazywaniu i nie może prowadzić Cię ku egzekwowaniu DMARC tak jak podpis.
Zachowaj tę drogę dla naprawdę ograniczonego przypadku: dedykowany serwer ze statycznym IP, który kontrolujesz, i aplikacja, która nie może używać SMTP — i połącz z podpisywaniem DKIM na serwerze, jeśli możesz.
Czy SPF w ogóle sprawdza adres, który formularz umieszcza w „From”?
Nie — i to potknięcie połowy samodzielnych diagnoz. Odbiorcy oceniają SPF względem domeny Return-Path (RFC5321.MailFrom), nie nagłówka From. Serwery WWW często nadają własną nazwę hosta Return-Path, więc Twój rekord SPF nigdy nie był konsultowany — odbiorca sprawdził SPF dla srv0421.examplehost.com. Uwierzytelniony SMTP naprawia też to: Return-Path staje się Twoją domeną, więc zaliczenie SPF w końcu liczy się dla Ciebie. Dlatego DKIM ma też znaczenie — wyrównanie DMARC potrzebuje zaliczenia powiązanego z domeną w From, a podpis DKIM podróżuje z wiadomością.
Często zadawane pytania
Czy wtyczka SMTP naprawi też e-maile resetowania hasła i WooCommerce?
Tak. Na WordPressie wszystko przepływa przez wp_mail(), więc przekierowanie go naprawia powiadomienia z formularzy, resetowania haseł i e-maile zamówień jednym ruchem.
Czy nadal potrzebuję rekordów SPF i DKIM, jeśli używam wtyczki SMTP? Tak — wtyczka zmienia którą infrastrukturę wysyła Twoją pocztę; rekordy to co ją autoryzuje. Jeśli Twoja domena należy do 46,4% z 261 086 232 ocenianych domen bez rekordu SPF (spis, 2026-06-29), sam uwierzytelniony SMTP Cię nie uratuje. Lista kontrolna poczty nowej domeny obejmuje pełny zestaw rekordów.
E-maile z formularza zaliczają SPF, ale nadal nie przechodzą DMARC — dlaczego? Prawie zawsze antywzorzec From-spoofing powyżej, lub SPF zaliczające dla domeny Return-Path hosta, a nie Twojej. Najpierw napraw From/Reply-To; jeśli nadal nie przechodzi, brakującym elementem jest wyrównany podpis DKIM — patrz „DKIM signature not valid”. Jeśli narzędzia SaaS poza stroną też nie przechodzą, przewodnik SPF-dla-SaaS obejmuje kolejność naprawy.
Czy warto przez to przechodzić dla formularza o niskim ruchu? Formularz to zazwyczaj miejsce, gdzie wchodzą pieniądze — przegapione zapytanie to klient, którego nigdy nie wiedziałeś, że straciłeś. A naprawa jest bezpłatna; barierą jest wiedza, że serwer WWW był przez cały czas nieuwierzytelnionym nadawcą.
Wyślij właścicielowi raport
Jeśli jesteś deweloperem lub wykonawcą to naprawiającym: gdy testowe zgłoszenie przejdzie, ponów bezpłatne skanowanie i prześlij oceniony raport właścicielowi strony — datowany, prosty zapis, że domena właściwie uwierzytelnia, i artefakt, którego będą potrzebować przy kolejnym odnowieniu ubezpieczenia cybernetycznego lub kwestionariuszu bezpieczeństwa klienta. Jeśli jesteś właścicielem czytającym to, bo zapytania przestały przychodzić: wyślij tę stronę i raport skanowania temu, kto prowadzi Twoją stronę — praca na jedno popołudnie z wynikiem przed i po, który możesz pokazać.
Sprawdź swoją domenę → · SPF nie działa dla narzędzi SaaS? → · Napraw SPF → · Jak oceniamy → · Tylko dane zagregowane. Dane przechowywane i przetwarzane w UE.