Jeśli maile z Twojej domeny lądują w spamie, znikają bez śladu albo wracają z błędami typu „unauthorized sender”, to w 80% przypadków nie jest „pech”. Najczęściej problem da się sprowadzić do trzech rzeczy: kto faktycznie wysyła (hosting, CMS, zewnętrzny SMTP), czy DNS potwierdza, że to dozwolone (SPF/DKIM), i czy odbiorca ma jasną politykę weryfikacji (DMARC).
Kłopot w tym, że „poczta na hostingu” bywa pojęciem zbiorczym. Jedna domena potrafi wysyłać z kilku miejsc naraz: formularze kontaktowe z WordPressa, powiadomienia sklepu, ręczne maile z klienta pocztowego, a do tego newsletter z narzędzia marketingowego. Każde z tych źródeł musi być ujęte w SPF albo podpisane DKIM — inaczej filtr uzna, że ktoś podszywa się pod Twoją domenę.
Drugi częsty powód to mylenie celu. SPF/DKIM/DMARC nie „wymuszają”, że mail trafi do skrzynki głównej. One sprawiają, że odbiorca może Ci zaufać i nie musi się domyślać. Dostarczalność to też reputacja IP, spójność nagłówków, jakość listy, tempo wysyłki i stabilność serwera. Dlatego poprawna konfiguracja to nie jeden rekord TXT i „gotowe”, tylko proces: ustaw → przetestuj → monitoruj → zaostrzaj politykę.
W tym artykule przejdziemy przez SPF, DKIM i DMARC od zera, ale praktycznie: jak rozpoznać źródła wysyłki, jak napisać rekord bez pułapek, jak testować i jak czytać symptomy. Będą też szybkie checklisty wdrożeniowe i sekcja o najczęstszych błędach z gotowymi sposobami naprawy.
Jeśli jesteś na etapie wyboru usług i chcesz uniknąć problemów „z natury” (np. z powodu współdzielonej reputacji), potraktuj to jako jeden z elementów decyzji o hostingu — podobnie jak w poradniku jak wybrać hosting albo przy porównywaniu opcji w rankingu hostingów.
Na koniec: nie musisz zgadywać. Da się dość precyzyjnie sprawdzić, dlaczego dany odbiorca odrzuca lub „przytłumia” Twoje maile. Trzeba tylko wiedzieć, gdzie patrzeć i co jest sygnałem, a co szumem.
Co realnie wpływa na dostarczalność: objawy, przyczyny i szybka diagnostyka
Dostarczalność to nie tylko „czy mail doszedł”, ale gdzie wylądował i czy był opóźniony. Typowe objawy to: lądowanie w spamie w Gmailu, brak dostarczenia do firmowych skrzynek (często bez odbicia), odbicia z komunikatami o SPF/DKIM, albo sytuacja, w której do jednych domen dochodzi, a do innych nie — mimo identycznej treści.
W praktyce filtr antyspamowy podejmuje decyzję na podstawie dwóch warstw. Pierwsza to zaufanie techniczne (SPF/DKIM/DMARC, zgodność domen w nagłówkach, TLS, reputacja IP, poprawny reverse DNS). Druga to sygnały „behawioralne” i treściowe: skargi na spam, współczynnik odbić, czytelność maila, linki, tempo wysyłki, a nawet to, czy Twoje maile są otwierane i przenoszone do „Odebranych”.
Szybka diagnostyka w 15 minut wygląda tak: wyślij test na kilka skrzynek (Gmail + Outlook/Hotmail + firmowa domena), sprawdź nagłówki wiadomości i zobacz trzy rzeczy: wynik SPF, wynik DKIM, wynik DMARC. Jeśli DMARC jest „fail”, to nawet poprawny SPF lub DKIM może nie wystarczyć, bo liczy się jeszcze zgodność (o tym niżej). Jeśli SPF „permerror”, to rekord jest zbyt złożony albo ma błąd składni. Jeśli DKIM „none”, to nic nie podpisuje wiadomości.
Równolegle sprawdź, czy wiesz, co wysyła. W szczególności WordPress i sklepy (PrestaShop) potrafią wysyłać zarówno przez PHP mail(), jak i przez SMTP. Te dwa tryby mają inne „ślady” w nagłówkach i często inne serwery wyjściowe. Jeżeli nie rozpoznasz źródeł, będziesz poprawiać SPF „na ślepo” i co chwilę psuć wysyłkę z innego miejsca.
Na koniec zrób jeden test „reputacyjny”: czy IP serwera pocztowego nie jest na blacklistach i czy reverse DNS jest poprawnie ustawiony. To nie zastępuje SPF/DKIM/DMARC, ale tłumaczy, czemu maile potrafią przechodzić technicznie, a i tak wpadać do spamu.
Poczta z hostingu czy zewnętrzny SMTP: jak wybrać model wysyłki
Najpierw rozdziel dwie rzeczy: pocztę do odbierania (skrzynki, IMAP/POP3) i pocztę do wysyłania (serwer SMTP / MTA). To, że masz skrzynki na hostingu, nie oznacza, że wysyłka z formularzy czy sklepu powinna iść tym samym kanałem. Wysyłka transakcyjna (powiadomienia, reset hasła, potwierdzenie zamówienia) jest bezlitośnie oceniana przez filtry, więc „byle jak” zwykle szybko wychodzi.
W modelu „wszystko na hostingu” wysyłka idzie z serwera współdzielonego. Plusy: prosto, tanio, mniej integracji. Minusy: reputacja IP bywa wspólna, a jeśli ktoś na serwerze „przepali” reputację spamem, oberwą też uczciwi. Dodatkowo część hostingów ogranicza tempo wysyłki lub liczbę wiadomości na godzinę, co objawia się opóźnieniami i kolejkami.
W modelu „zewnętrzny SMTP” (np. dostawca poczty firmowej lub usługa transakcyjna) przenosisz reputację i mechanikę wysyłki poza hosting. To często najlepsza droga dla sklepów i serwisów, bo dostajesz DKIM „z pudełka”, raporty i stabilność, a hosting zajmuje się stroną. W praktyce dla stron na CMS warto rozumieć różnice w środowisku — dlatego dobrze mieć jasność, czym się różni Hosting www vs hosting WordPress i jakie ma to skutki dla wysyłki z aplikacji.
Jest też trzeci wariant, bardzo częsty: skrzynki są na hostingu, ale CMS wysyła przez SMTP (wtyczka, konfiguracja w aplikacji). Wtedy SPF musi dopuszczać serwer SMTP, a DKIM powinien podpisywać domeną, z której wysyłasz. To usuwa problem „PHP mail() bez podpisu” i zwykle natychmiast poprawia wyniki testów.
SPF bez wpadek: jak zbudować rekord, który przejdzie weryfikację
SPF to lista „kto ma prawo wysyłać maile w imieniu tej domeny”. Technicznie to rekord TXT w DNS, który odbiorca sprawdza, porównując IP serwera wysyłającego z Twoją deklaracją. Najważniejsze: SPF dotyczy domeny użytej w Return-Path (adres koperty), a nie zawsze tej widocznej w polu „From”. To kluczowe, bo możesz mieć poprawny SPF, który i tak nie pomaga DMARC-owi, jeśli domeny nie są wyrównane (zgodne).
Pierwszy krok to inwentaryzacja źródeł wysyłki. Zbierz: serwer poczty na hostingu (jeśli wysyłasz z niego), narzędzie do newslettera, CRM, system faktur, sklep, formularze z CMS, oraz ewentualne integracje (np. system zgłoszeń). Najprościej: weź 3–5 typów maili (transakcyjny, ręczny, marketingowy) i z nagłówków odczytaj: „Received” (skąd wyszło), „Return-Path”, czasem „X-Mailer” albo „Authentication-Results”. To pozwala rozróżnić, czy wysyłka idzie z hostingu, czy zewnętrznym kanałem.
Potem budujesz rekord SPF możliwie prosty. Typowy przykład dla poczty na hostingu + dodatkowego dostawcy wygląda tak:
v=spf1 mx include:_spf.example-smtp.com -all
mx mówi „pozwól serwerom wskazanym w moich rekordach MX”. include: dodaje reguły dostawcy (to on publikuje własny SPF). Na końcu jest polityka: -all to twarde odrzucenie wszystkich innych źródeł; ~all to miękkie (często dobry etap przejściowy, gdy dopiero stabilizujesz konfigurację i nie masz pewności, że spisałeś wszystkie źródła).
Dwie pułapki SPF, które psują wdrożenia najczęściej: limit zapytań DNS (10 lookupów) i „duplikowanie” rekordów. SPF może być tylko jeden dla danej domeny. Jeśli masz dwa rekordy TXT zaczynające się od v=spf1, część odbiorców uzna to za błąd (permerror). Druga rzecz: nadmiar include: potrafi przekroczyć limit 10 i wtedy SPF też wpada w permerror — paradoksalnie pogarszając dostarczalność.
Na koniec pamiętaj o subdomenach. Jeśli wysyłasz newsletter z news.twojadomena.pl, zrób SPF dla tej subdomeny osobno. To ułatwia porządek, zmniejsza ryzyko przekroczenia limitów i pomaga zarządzać reputacją (zwłaszcza gdy marketing i transakcje nie powinny „dzielić losu”).
DKIM w praktyce: klucze, selektory, testy i rotacja
DKIM to podpis kryptograficzny dodawany do wiadomości. Odbiorca weryfikuje go na podstawie publicznego klucza w DNS. W praktyce DKIM rozwiązuje problem „ktoś wysyła z Twojej domeny, ale nie masz jak potwierdzić, że to legalne” — szczególnie gdy wysyłka idzie przez zewnętrznych dostawców, gdzie SPF bywa trudniejszy do utrzymania.
Konfiguracja DKIM zależy od tego, skąd wysyłasz. Jeśli wysyłka jest z hostingu (serwer pocztowy), klucz generujesz w panelu hostingu albo na serwerze pocztowym, a potem wklejasz rekord TXT do DNS. Jeśli wysyłka jest z zewnętrznego SMTP, to dostawca zwykle generuje klucz i daje Ci gotowy rekord do dodania. Zawsze składa się to z: selektora (np. s1, default, 2026) oraz domeny. Rekord ląduje pod adresem typu:
selector._domainkey.twojadomena.pl TXT "v=DKIM1; k=rsa; p=MIIBI... "
Ważny szczegół: DKIM musi podpisywać domeną, którą chcesz chronić DMARC-iem. W nagłówku zobaczysz parametr d= — to domena podpisu. Jeśli wysyłasz „From: @twojadomena.pl”, a DKIM ma d=provider.com, to sam DKIM może przejść, ale DMARC niekoniecznie, bo nie ma zgodności. Dlatego przy dostawcach newsletterów i usług transakcyjnych szukaj opcji typu „domain authentication”, „custom DKIM” i „custom return-path”.
Testowanie DKIM jest proste: wyślij mail na Gmail, otwórz „pokaż oryginał” i sprawdź „DKIM: PASS”. Jeśli jest „none”, to podpis nie jest dodawany. Jeśli „fail”, to zwykle: zły rekord w DNS (błąd wklejenia, cudzysłowy, cięcie linii), nie ten selektor, albo serwer podpisuje inną domeną. Dodatkowy trik: sprawdź, czy wiadomość nie jest modyfikowana po podpisaniu (niektóre bramki/stopki potrafią zepsuć DKIM).
Rotacja kluczy to temat, który prawie zawsze jest pomijany, dopóki nie wydarzy się incydent. Praktyczna metoda bez przestojów: dodajesz drugi selektor (np. s2), włączasz podpisywanie nowym, zostawiasz stary rekord jeszcze przez kilka tygodni, a dopiero potem usuwasz stary. Dzięki temu maile „w drodze” i różne kolejki nie zaczną nagle failować.
DMARC krok po kroku: polityka, zgodność i raporty
DMARC to „polityka domeny”: mówisz odbiorcy, co ma zrobić, jeśli mail nie przejdzie SPF/DKIM w sposób zgodny z domeną From. I tu jest sedno: DMARC nie pyta tylko „czy SPF przeszedł” albo „czy DKIM przeszedł”, ale czy przynajmniej jeden z nich przeszedł z wyrównaniem względem domeny widocznej dla użytkownika.
Wyrównanie w praktyce:
- dla SPF: domena w Return-Path powinna być taka sama (lub zgodna w trybie relaxed) jak domena w From,
- dla DKIM: domena
d=w podpisie powinna być taka sama (lub zgodna) jak domena w From.
Dlatego DMARC często „wywraca” konfiguracje, które wyglądały na poprawne. Klasyczny przypadek: CMS wysyła przez zewnętrzny SMTP, ale Return-Path jest z domeny dostawcy, a DKIM też podpisuje domeną dostawcy. Odbiorca widzi From: Twoja domena, ale technicznie nie ma dowodu, że to Twoja domena autoryzowała wysyłkę — więc DMARC fail.
Wdrożenie DMARC warto robić etapami. Startujesz od p=none, żeby tylko zbierać sygnały i raporty, bez wpływu na dostarczanie. Przykład rekordu:
_dmarc.twojadomena.pl TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1; adkim=r; aspf=r; pct=100"
rua to raporty zbiorcze (agregate), które przychodzą zazwyczaj raz dziennie od większych odbiorców. One pokazują, kto wysyłał w imieniu domeny i z jakim wynikiem SPF/DKIM/DMARC. Po 1–2 tygodniach wiesz już, czy odkryłeś wszystkie źródła wysyłki, i możesz przechodzić do p=quarantine (sugeruj spam/kwarantanna), a finalnie p=reject (odrzucaj nieautoryzowane).
DMARC ma też parametr sp, który dotyczy subdomen. To ważne, jeśli chcesz, żeby subdomeny były traktowane inaczej (np. newsletter z subdomeny z inną polityką). Dla wielu wdrożeń dobrym modelem jest: domena główna pod transakcje, subdomena pod marketing — i osobne, świadome DMARC-y.
Na koniec: DMARC to nie tylko „ochrona przed podszyciem”. To też narzędzie porządkujące ekosystem wysyłki. Jeśli prowadzisz serwis na WordPressie, sprawdź też, czy konfiguracja wysyłki (wtyczki SMTP, formularze) pasuje do tego, jak rozumiesz hosting WordPress — bo często to właśnie „detale wdrożenia” robią różnicę między PASS a losowym spamem.
Ustawienia „około-DNS”, które robią różnicę: PTR, HELO, TLS i spójność nagłówków
Nawet przy poprawnym SPF/DKIM/DMARC możesz mieć problem, jeśli serwer wysyłający wygląda dla odbiorcy „podejrzanie”. Najważniejszy element to reverse DNS (PTR). Odbiorcy lubią, gdy IP serwera ma PTR wskazujący na sensowną nazwę hosta, a ta nazwa rozwiązuje się z powrotem do tego IP (forward-confirmed reverse DNS). W praktyce: IP → PTR → hostname → A/AAAA → to samo IP. Jeśli wysyłasz z hostingu i nie masz wpływu na PTR, to kolejny argument, żeby rozważyć zewnętrzny SMTP dla krytycznej wysyłki.
Kolejny detal to HELO/EHLO (nazwa przedstawiana przez serwer SMTP). W idealnym świecie pasuje do PTR i ma sensowną domenę/hosta. „localhost” albo losowy ciąg znaków potrafi obniżyć zaufanie filtrów, zwłaszcza w zestawie z młodą domeną i małą historią wysyłki.
TLS w połączeniu SMTP to dziś w zasadzie standard. Brak TLS nie zawsze blokuje dostarczenie, ale pogarsza „score” w wielu filtrach. Jeśli wysyłasz przez zewnętrzny SMTP, to temat zwykle znika, bo dostawca ma to domyślnie. Jeśli wysyłasz z hostingu, sprawdź w dokumentacji/panelu, czy serwer negocjuje TLS i jakie protokoły wspiera.
Spójność nagłówków to niby drobiazg, ale filtry lubią porządek: From, Reply-To, Return-Path i domeny w linkach powinny mieć sens. Jeśli wysyłasz transakcje z domeny A, a linki w mailu prowadzą do domeny B, a Return-Path jest z domeny C, to nawet przy PASS-ach zwiększasz ryzyko folderu „Inne”/„Oferty”/spam — bo sygnał „to nie wygląda jak normalna, stabilna konfiguracja”.
Jeśli jesteś na etapie wyboru usług, te elementy warto dopisać do checklisty „jakości” — obok rzeczy, które porusza hosting a SEO (bo stabilność i reputacja usług często idą w parze, nawet jeśli dotyczą różnych kanałów: WWW i e-mail).
Jak testować i monitorować dostarczalność na bieżąco
Jednorazowy test po wdrożeniu to za mało, bo wysyłka potrafi się zmienić bez Twojej wiedzy: ktoś dołoży wtyczkę do formularzy, zmieni narzędzie newsletterowe, uruchomi CRM albo przeniesie sklep na inny moduł mailowy. Dlatego monitoring powinien mieć dwa poziomy: szybkie testy „tu i teraz” oraz cykliczny podgląd trendów.
Do szybkich testów używaj: wysyłki na Gmail i podglądu „oryginału” (wyniki SPF/DKIM/DMARC), narzędzi typu mail-tester (dają punktację i wskazówki), oraz prostych checkerów DNS (czy rekordy się publikują, czy nie ma literówek). Gdy coś nie działa, nagłówki są Twoim logiem — szczególnie pola Authentication-Results i Received.
Do trendów przydaje się obserwacja reputacji domeny/IP. Jeśli wysyłasz dużo do Gmail, warto podpiąć narzędzia typu Postmaster (jeśli masz odpowiedni wolumen). W ekosystemie Microsoftu podobnie: są panele, które pokazują skargi i problemy z dostarczaniem. Dla mniejszych wolumenów ważniejsze jest DMARC rua, bo raporty pokażą, czy nagle pojawił się nowy nadawca (np. integracja) albo czy rośnie odsetek faili.
W samych aplikacjach (WordPress, sklepy) monitoruj też kolejki i błędy SMTP. Objaw „maile dochodzą z opóźnieniem” bardzo często wynika z tego, że aplikacja wysyła synchronicznie, hosting ogranicza zasoby, a wiadomości czekają w kolejce. To rzadziej jest SPF/DKIM, a częściej mechanika wysyłki i limity.
Dobry nawyk: po każdej zmianie w DNS ustaw sobie przypomnienie na kolejny dzień i za tydzień, żeby sprawdzić DMARC raporty. Zmiany w rekordach są szybkie, ale „konsekwencje” w filtrach i reputacji potrafią ujawniać się z opóźnieniem.
Najczęstsze błędy i jak je naprawić
Dwa rekordy SPF dla jednej domeny (permerror). To jeden z najbardziej podstępnych błędów, bo „na oko” wszystko wygląda dobrze: są dwa TXT-y, każdy sensowny. Problem w tym, że odbiorca nie ma obowiązku ich scalać. Naprawa: zostaw jeden rekord zaczynający się od v=spf1 i połącz w nim wszystkie źródła (include/mx/ip4). Po zmianie przetestuj SPF z kilku miejsc i upewnij się, że nie przekraczasz limitu lookupów.
SPF przekracza limit 10 zapytań DNS. Zbyt wiele include: (często od newsletterów i CRM) powoduje, że SPF kończy się permerror, a wtedy realnie tracisz ochronę. Naprawa: ogranicz liczbę źródeł wysyłki (konsolidacja), przenieś część wysyłki na subdomenę z osobnym SPF, albo użyj dostawcy, który wspiera DKIM + aligned Return-Path (wtedy SPF może być prostszy). Po zmianie testuj „SPF lookup count” w checkerach.
DKIM podpisuje „nie tę” domenę (brak zgodności z From). To klasyka przy usługach zewnętrznych: DKIM PASS, ale d= jest np. domeną dostawcy. DMARC wtedy fail, mimo że „DKIM działa”. Naprawa: włącz u dostawcy opcję podpisu Twoją domeną (custom DKIM), dodaj rekordy do DNS i sprawdź w nagłówkach, czy d= jest zgodne z domeną From.
DMARC ustawione od razu na p=reject bez etapu obserwacji. Efekt: nagle część maili znika, bo okazało się, że formularze wysyłają z innego kanału albo jakiś system faktur nie był uwzględniony. Naprawa: wróć na chwilę do p=none lub p=quarantine z pct=20–50, zbierz raporty rua, popraw SPF/DKIM dla wszystkich źródeł i dopiero zaostrzaj politykę etapami.
Brak spójności między From/Reply-To/Return-Path. Czasem aplikacja ustawia From na domenę, ale Return-Path jest losowy, a Reply-To idzie na darmową skrzynkę. Dla filtrów to wygląda jak nadużycie. Naprawa: uporządkuj konfigurację wysyłki w aplikacji (SMTP, stały nadawca z domeny), dopilnuj aligned Return-Path (jeśli dostawca wspiera) i trzymaj się jednego modelu dla danego typu maili.
Wysyłka z PHP mail() bez autentykacji i bez kontroli błędów. Maile „czasem dochodzą”, ale wyniki SPF/DKIM są niestabilne, a odbiorcy traktują to gorzej niż SMTP. Naprawa: przełącz wysyłkę aplikacji na SMTP (hostingowy lub zewnętrzny), włącz DKIM, a w logach aplikacji zapisuj błędy SMTP. W WordPressie to zwykle wtyczka SMTP + poprawna autoryzacja domeny u dostawcy.
Brak PTR/reverse DNS przy wysyłce z własnego serwera. Nawet poprawny DMARC nie zawsze uratuje reputację, gdy serwer wygląda „jak bot”. Naprawa: ustaw PTR po stronie operatora IP (hosting/VPS), dopilnuj zgodności HELO i forward-confirmed reverse DNS. Jeśli nie masz wpływu na PTR — rozważ przeniesienie wysyłki na zewnętrzny SMTP.
FAQ – Najczęściej zadawane pytania
W praktyce najlepiej mieć oba. DMARC wymaga, aby przynajmniej SPF albo DKIM przeszedł i był zgodny z domeną From. Jeśli masz tylko SPF, łatwo go „zgubić” przy zmianie dostawcy lub gdy aplikacja zmieni Return-Path. Jeśli masz tylko DKIM, czasem po drodze wiadomość może zostać zmodyfikowana (stopki, bramki), a wtedy DKIM potrafi failować. Podwójna autentykacja daje stabilność i zmniejsza ryzyko, że pojedyncza zmiana w ekosystemie wysyłki wywróci dostarczalność.
Alignment to zgodność domen: DMARC patrzy na domenę widoczną w From (tę, którą widzi odbiorca) i porównuje ją z domeną używaną w SPF (Return-Path) oraz domeną podpisu DKIM (d=). Jeśli domeny nie są zgodne, odbiorca może uznać, że ktoś podszywa się pod Twoją domenę, nawet jeśli technicznie SPF/DKIM „gdzieś” przeszły. Dlatego tak ważne są ustawienia „custom DKIM” i „custom return-path” u zewnętrznych dostawców.
SPF to tylko jeden sygnał zaufania technicznego. Jeśli domena jest świeża, wysyłasz nagle dużo, IP ma słabą reputację, nie masz DKIM/DMARC, albo treść wygląda jak typowa kampania, filtr może nadal kierować do spamu. SPF pomaga głównie w tym, żeby odbiorca nie uznał Cię za „podszywacza”. Żeby poprawić miejsce lądowania, potrzebujesz też DKIM/DMARC, stabilnego tempa wysyłki, dobrej higieny listy i spójnych nagłówków.
~all w SPF jest „gorsze” niż -all? -all jest ostrzejsze: mówi „odrzuć wszystko, co nie pasuje”. ~all to softfail: sygnał „to raczej nie powinno wysyłać, ale nie każę odrzucać”. Na etapie wdrożenia ~all bywa rozsądne, bo pozwala wykryć brakujące źródła bez natychmiastowego psucia dostarczania. Docelowo, gdy masz pewność, że wszystkie źródła są ujęte, -all jest zwykle lepsze dla bezpieczeństwa i spójności.
Może przestać działać. DKIM podpisuje określone nagłówki i część treści. Jeśli po podpisaniu ktoś modyfikuje wiadomość (np. dokleja stopkę, zmienia kodowanie), podpis może przestać się zgadzać. Dlatego integracje, które „przerabiają” treść po drodze, powinny być świadomie skonfigurowane, a testy DKIM warto robić na rzeczywistych ścieżkach dostarczania, nie tylko „na sucho”.
Technicznie możesz dodać rekord DMARC, ale niewiele z tego wyniknie. DMARC opiera się na wynikach SPF/DKIM, więc bez nich będzie masowo failować, a jeśli ustawisz ostrą politykę, sam sobie odetniesz wysyłkę. Minimalny sensowny start to: DKIM albo SPF działające i aligned dla większości wiadomości, a dopiero potem DMARC (najpierw p=none).
30-letnia pasjonatka informatyki, która świat serwerów i hostingów zna od podszewki. Wierzy, że technologia powinna ułatwiać życie, a nie je komplikować. Żyje w ciągłym ruchu – jeśli akurat nie konfiguruje nowej usługi, prawdopodobnie pakuje plecak na kolejną wyprawę w nieznane.
Dodaj komentarz