Jak zabezpieczyć adres e-mail firmy przed scrapingiem

Firmowy adres e-mail opublikowany w zwykłej postaci — na stronie kontaktowej, w stopce albo przy nazwisku pracownika — może trafić do bazy spamerów w ciągu kilku godzin. Nie musi go kopiować człowiek. Automatyczny skrypt pobiera kod strony, wyszukuje ciągi pasujące do schematu nazwa@domena.pl, zapisuje wynik, a następnie przechodzi do kolejnego adresu URL.

Całkowite ukrycie skrzynki nie jest jednak rozsądnym rozwiązaniem. Adres ma przecież umożliwiać klientom kontakt, pojawia się w dokumentach, katalogach branżowych, rejestrach i profilach firmy. Celem nie powinno więc być stworzenie „niewidzialnego” e-maila, lecz ograniczenie masowego zbierania adresu, odseparowanie korespondencji publicznej od ważnych procesów oraz szybkie wykrywanie nadużyć.

Najpierw ogranicz miejsca, z których bot może skopiować adres

Najczęstszy błąd jest banalny: ten sam adres, na przykład biuro@firma.pl, obsługuje stronę internetową, faktury, reklamacje, rekrutację, zamówienia i logowanie do zewnętrznych usług. Gdy trafi do publicznej bazy, firma nie może go łatwo wyłączyć, ponieważ odcięłaby sobie jednocześnie kilka ważnych kanałów komunikacji.

Lepszym rozwiązaniem jest podział skrzynek według funkcji:

• kontakt@firma.pl — publiczne zapytania ze strony;
• zamowienia@firma.pl — komunikacja z klientami po zakupie;
• faktury@firma.pl — dokumenty księgowe;
• rekrutacja@firma.pl — ogłoszenia i aplikacje;
• imienne adresy pracowników — wyłącznie tam, gdzie są rzeczywiście potrzebne;
• osobny, niepublikowany adres — do logowania w banku, panelu domeny, hostingu i systemach administracyjnych.

Adres używany do resetowania haseł nigdy nie powinien być publicznym adresem kontaktowym. Scraping sam w sobie nie daje napastnikowi dostępu do skrzynki, ale ujawnia identyfikator logowania i ułatwia phishing, próby przejęcia konta oraz automatyczne testowanie wyciekłych haseł.

Następnie trzeba sprawdzić, gdzie adres faktycznie występuje. Samo usunięcie go ze strony „Kontakt” zwykle niewiele zmienia. E-maile pozostają w:

• stopce serwisu i polityce prywatności;
• plikach PDF dostępnych w wyszukiwarce;
• starych ofertach, regulaminach i cennikach;
• opisach zdjęć oraz danych strukturalnych;
• kodzie HTML, nawet jeżeli nie są widoczne na ekranie;
• mapach XML, kopiach podstron i wersjach językowych;
• profilach pracowników;
• wpisach katalogowych i wizytówkach firmy;
• archiwalnych komunikatach prasowych.

Praktyczny audyt można zacząć od wyszukania w Google frazy:

"kontakt@firma.pl"

oraz zapytania:

site:firma.pl "@firma.pl"

Trzeba też pobrać kod źródłowy najważniejszych podstron i wyszukać znak @. Bot analizuje przede wszystkim HTML, więc adres niewidoczny dla użytkownika, ale pozostawiony w atrybucie, komentarzu albo skrypcie JavaScript, nadal jest łatwy do przejęcia.

Największy priorytet ma usunięcie imiennych adresów pracowników ze stron dostępnych publicznie. Schemat imie.nazwisko@firma.pl pozwala odtworzyć adresy kolejnych osób na podstawie listy zespołu, LinkedIna albo informacji prasowych. W takim przypadku nawet ukrycie kilku adresów nie rozwiązuje problemu — przewidywalny format domeny wystarcza do automatycznego wygenerowania całej listy.

Zastąp publiczny e-mail formularzem, ale zabezpiecz również formularz

Najprostsza technicznie ochrona polega na usunięciu adresu z kodu strony i udostępnieniu formularza kontaktowego. Wiadomość jest wtedy przekazywana przez serwer, a odwiedzający nie poznaje adresu skrzynki docelowej.

To działa tylko wtedy, gdy e-mail rzeczywiście nie trafia do przeglądarki. Częsty błąd wygląda tak:

<form action="mailto:kontakt@firma.pl">

Taki formularz niczego nie chroni. Adres znajduje się w kodzie strony i może zostać odczytany bez otwierania formularza.

Poprawny mechanizm powinien działać następująco:

1. Użytkownik wypełnia formularz.
2. Przeglądarka wysyła dane do aplikacji lub skryptu po stronie serwera.
3. Serwer sprawdza zabezpieczenia antyspamowe.
4. Dopiero serwer przekazuje wiadomość na niepubliczny adres.
5. Odpowiedź do klienta jest wysyłana z kontrolowanego adresu kontaktowego.

Wdrożenie prostego formularza przez programistę zazwyczaj zajmuje od 2 do 6 godzin, jeżeli strona ma już działający backend i system wysyłki poczty. Przy WordPressie można użyć między innymi Gravity Forms, Fluent Forms albo Contact Form 7, ale sama instalacja wtyczki nie kończy pracy. Trzeba skonfigurować walidację, zabezpieczenie antybotowe, wysyłkę przez SMTP, retencję zgłoszeń oraz komunikat dotyczący przetwarzania danych.

Formularz powinien zawierać co najmniej cztery warstwy ochrony:

• pole typu honeypot, niewidoczne dla zwykłego użytkownika, ale często wypełniane przez proste boty;
• limit liczby zgłoszeń, na przykład maksymalnie 3–5 wysłań z jednego adresu IP w ciągu 10 minut;
• minimalny czas wypełnienia, ponieważ zgłoszenie przesłane 200 milisekund po załadowaniu strony niemal na pewno pochodzi z automatu;
• weryfikację po stronie serwera, a nie wyłącznie w JavaScript.

Przy większej liczbie nadużyć należy dodać Cloudflare Turnstile albo reCAPTCHA. Turnstile można osadzić niezależnie od hostowania strony w Cloudflare; bezpłatny plan pozwala obecnie utworzyć do 20 widżetów na konto. Mechanizm generuje token w przeglądarce, ale jego poprawność musi zostać sprawdzona na serwerze — pominięcie tego etapu sprawia, że zabezpieczenie jest dekoracją.

reCAPTCHA v3 przyznaje zgłoszeniom ocenę ryzyka. Domyślny próg 0,5 jest punktem wyjścia, nie uniwersalną wartością. Na stronie o niewielkim ruchu ustawienie zbyt wysokiego progu potrafi odrzucać prawdziwych klientów, zwłaszcza korzystających z VPN, firmowych sieci albo przeglądarek ograniczających śledzenie. Google udostępnia obecnie do 10 000 ocen miesięcznie bez opłat w reCAPTCHA Enterprise, ale limit i zasady rozliczeń trzeba sprawdzić przed wdrożeniem w serwisie o większym ruchu.

Najbardziej irytującą wadą zabezpieczeń antybotowych są fałszywe blokady. Formularz może wyglądać na sprawny, lecz wiadomości części klientów nie docierają. Dlatego po wdrożeniu należy przez co najmniej 7–14 dni rejestrować liczbę zaakceptowanych i odrzuconych zgłoszeń. W logach nie trzeba przechowywać pełnej treści wiadomości; wystarczą czas, wynik oceny, skrócony identyfikator IP, przyczyna blokady i status wysyłki.

Nie należy też pozwalać formularzowi na dowolne ustawianie nagłówka From. Adres wpisany przez użytkownika powinien znaleźć się w polu Reply-To, natomiast wiadomość musi wychodzić z adresu należącego do domeny firmy. Inaczej mechanizmy SPF, DKIM i DMARC mogą uznać ją za próbę podszycia się pod nadawcę.

Utrudnij automatyczne zbieranie, nie psując kontaktu z klientem

Gdy publiczny adres musi pozostać na stronie, można zastosować obfuskację, czyli zapis utrudniający jego automatyczne rozpoznanie. Najprostszy wariant to:

kontakt [małpa] firma [kropka] pl

Taki zapis zatrzymuje część prymitywnych skryptów, ale nie stanowi mocnej ochrony. Współczesne scrapery potrafią rozpoznawać słowa „małpa”, „at”, „kropka” i „dot”, a następnie odtwarzać właściwy adres. Dodatkowo rozwiązanie pogarsza wygodę użytkownika: adresu nie można łatwo kliknąć ani skopiować.

Nieco lepiej działa składanie adresu w JavaScript dopiero po załadowaniu strony, na przykład z oddzielnych fragmentów nazwy i domeny. Nadal nie jest to zabezpieczenie przed scraperem korzystającym z pełnej przeglądarki, takiej jak Playwright lub Selenium. Taki bot wykona skrypt i odczyta gotową treść dokładnie tak samo jak użytkownik.

Rozsądniejszym rozwiązaniem jest przycisk „Pokaż adres e-mail”, który pobiera adres z serwera dopiero po wykonaniu działania przez użytkownika. Punkt końcowy API można objąć limitem zapytań, analizą zachowania oraz mechanizmem antybotowym. To nie daje pełnej gwarancji, ale podnosi koszt automatycznego zbierania — scraper musi uruchamiać interakcję, obsługiwać tokeny i respektować limity.

Przy konfiguracji serwera warto wprowadzić trzy poziomy reakcji:

1. Rejestrowanie nietypowej liczby wejść na stronę kontaktową.
2. Ograniczenie szybkości po przekroczeniu ustalonego progu.
3. Wyzwanie lub blokada dopiero dla ruchu o wyraźnie automatycznym charakterze.

Próg musi wynikać z rzeczywistego ruchu. Dla lokalnej firmy 60 żądań strony kontaktowej w ciągu minuty z jednego IP jest zwykle anomalią. Dla platformy z tysiącami użytkowników ten sam limit może blokować firmowe sieci, operatorów komórkowych albo ruch przechodzący przez wspólną bramę. Najpierw należy zebrać dane z 7–30 dni, a dopiero później ustawić twarde reguły.

Plik robots.txt nie chroni adresu przed scrapingiem. Informuje prawidłowo działające roboty, których zasobów nie powinny pobierać, ale złośliwy skrypt może go po prostu zignorować. Co gorsza, wpisanie w nim ścieżki do „ukrytego” katalogu wskazuje potencjalnemu napastnikowi, gdzie warto zajrzeć.

Blokowanie wszystkich robotów również jest złym pomysłem. Może utrudnić indeksowanie strony przez wyszukiwarki, działanie narzędzi monitorujących i dostęp do serwisu osobom korzystającym z technologii wspomagających. Ochrona powinna koncentrować się na konkretnych punktach: stronie kontaktowej, endpointach formularza, funkcji ujawniającej adres i powtarzalnych wzorcach zapytań.

Osobna sprawa to publikowanie danych firmy poza własną stroną. Spójny adres, telefon i nazwa przedsiębiorstwa są potrzebne w katalogach, mapach oraz lokalnych profilach, ale nie oznacza to konieczności podawania wszędzie tej samej skrzynki. Do publicznych wpisów można przeznaczyć alias, na przykład lokalizacje@firma.pl, i przekierować go do właściwego zespołu. Gdy alias zacznie generować głównie spam, da się go zmienić bez naruszania księgowości, obsługi zamówień czy kont administracyjnych.

Publiczny adres przypisany do konkretnej osoby może być daną osobową, a jego masowe pobieranie i dalsze wykorzystywanie nie staje się automatycznie legalne tylko dlatego, że był dostępny w internecie. W europejskich realiach dalsze przetwarzanie wymaga podstawy prawnej, określonego celu, ograniczenia zakresu danych oraz realizacji obowiązków informacyjnych. Marketing bezpośredni może w określonych warunkach opierać się na prawnie uzasadnionym interesie, ale nie jest to zgoda na dowolne zbieranie i używanie adresów.

Więcej informacji na: wizytówki NAP – sourco.pl.

FAQ: firmowy e-mail a scraping

Czy zapisanie adresu jako obrazu zatrzyma boty?
Zatrzyma najprostsze skrypty analizujące wyłącznie tekst HTML, ale nie boty korzystające z OCR ani operatorów przepisujących dane ręcznie. Obraz pogarsza też dostępność strony, skalowanie tekstu i możliwość szybkiego skopiowania adresu.

Czy Cloudflare całkowicie uniemożliwi scraping?
Nie. WAF, Turnstile, limity zapytań i analiza botów zwiększają koszt automatycznego zbierania, lecz nie zatrzymają każdej przeglądarki sterowanej automatycznie. Ochronę trzeba łączyć z aliasami i oddzieleniem publicznej skrzynki od kont krytycznych.

Czy można bezpiecznie zostawić link mailto:?
Link mailto: ujawnia pełny adres w kodzie HTML. Jest wygodny dla użytkownika, ale bardzo łatwy do odczytania przez scraper. Powinien prowadzić najwyżej do adresu przeznaczonego wyłącznie do publicznego kontaktu.

Czy zmiana @ na „małpa” wystarczy?
Nie. Jest to filtr przeciwko prostym skryptom, nie realna bariera dla nowoczesnego scrapera. Może być dodatkiem, ale nie powinien zastępować formularza, limitowania zapytań i podziału adresów.

Czy adres ogólny, taki jak biuro@firma.pl, podlega RODO?
Adres odnoszący się wyłącznie do organizacji nie zawsze pozwala zidentyfikować osobę fizyczną. Inaczej wygląda sytuacja z adresem imiennym albo skrzynką, z której treści i kontekstu można ustalić konkretną osobę. Ocena zależy od sposobu użycia adresu i danych przetwarzanych razem z nim.

Co zrobić, gdy adres już trafił do baz spamerskich?
Najpierw utworzyć nowy alias publiczny i pozostawić stary adres aktywny na okres przejściowy, zwykle 30–90 dni. Następnie trzeba przenieść ważne kontakty, zaostrzyć filtrowanie, sprawdzić reguły przekierowań i usunąć stary adres z publicznych materiałów. Nagłe wyłączenie skrzynki bez okresu przejściowego zwykle kończy się utratą prawdziwych wiadomości.

Pierwszą czynnością powinno być wyszukanie wszystkich adresów w domenie firmy i oznaczenie tych, które jednocześnie są publiczne oraz używane do logowania, faktur, odzyskiwania haseł albo obsługi kluczowych klientów. To najgroźniejszy błąd. Takie skrzynki trzeba rozdzielić przed wdrażaniem CAPTCHA, obfuskacji czy kolejnych filtrów, ponieważ żadna techniczna osłona strony nie cofnie skutków ujawnienia adresu pełniącego kilka krytycznych funkcji.