Un server de e-mail pe un VPS: ce te ține de fapt departe de spam

Serverul tău de e-mail merge. Postfix pornește, logurile arată curat, trimiți un mesaj de test pe Gmail — și ajunge în spam. Sau pur și simplu dispare. Nimic din configurația ta nu e stricat. Software-ul a făcut exact ce i-ai spus.

Problema e că serverul de la celălalt capăt nu are încă încredere în IP-ul tău, iar e-mailul ascunde un întreg șir de mici verificări de încredere care trebuie toate să se alinieze înainte ca inboxul unui necunoscut să te lase să intri. Configurează-le corect și livrarea se rezolvă în mare parte singură. Ratează una și strigi într-un folder de spam.

Trei lucruri duc cea mai mare parte din greutate: reverse DNS-ul, autentificarea expeditorului și dacă hostul tău te lasă măcar să vorbești pe portul 25. Niciunul nu e greu. Sunt doar ușor de uitat, iar fiecare e un veto tăcut.

Cel pe care îl uită toată lumea: reverse DNS

DNS-ul direct e partea pe care o știi — un nume indică spre un IP. Reverse DNS e oglinda: un IP indică înapoi spre un nume. Înregistrarea se numește PTR și stă la cel care controlează IP-ul, nu în zona domeniului tău.

Iată de ce contează. Când serverul tău deschide o conexiune spre SMTP-ul Gmail, unul dintre primele lucruri pe care le face partea care primește e o căutare inversă pe IP-ul tău — cine e ăsta? Rulează-o chiar tu:

dig -x 203.0.113.19 +short

Dacă primești înapoi ceva de felul static.203-0-113-19.rev.example-isp.net sau nu primești nimic, ai pierdut deja puncte. Numele generic spune „un VPS oarecare” și, mai rău, nu se potrivește cu numele de host cu care se prezintă serverul tău în salutul HELO. Serverele care primesc penalizează dur nepotrivirea. Unele resping direct.

Ce vor să vadă e un PTR care se potrivește cu numele de host al serverului de e-mail. Dacă serverul tău spune HELO mail.example.com, căutarea inversă pe IP-ul lui ar trebui să returneze mail.example.com. Direct și invers sunt de acord, povestea e coerentă și arăți ca un server de e-mail real, nu ca o mașină deturnată.

Setarea unui PTR însemna în mod tradițional să deschizi un tichet de suport la cel care deține blocul de IP-uri și să aștepți. Pe planurile EQVPS cu IP dedicat e un câmp în panou — scrii numele de host, se scrie direct în registru și e activ în câteva secunde. Ăsta e tot rostul variantei self-service: reverse DNS e pasul pe care oamenii îl sar pentru că înainte era enervant.

Autentificarea: SPF, DKIM, DMARC

Aceste trei înregistrări DNS le spun serverelor care primesc că e-mailul care pretinde că vine de pe domeniul tău chiar vine de acolo. Sări peste ele și ești un necunoscut neverificat.

• SPF e o înregistrare TXT care listează ce servere au voie să trimită pentru domeniul tău. Gmail o verifică și întreabă: a venit mesajul ăsta de pe un IP autorizat de tine?
• DKIM semnează criptografic fiecare mesaj trimis. Cel care primește ia cheia ta publică din DNS și verifică dacă semnătura n-a fost falsificată pe drum.
• DMARC le leagă pe cele două și le spune celor care primesc ce să facă atunci când o verificare eșuează — nimic, carantină sau respingere — și unde să trimită rapoartele.

Le vrei pe toate trei. SPF și DKIM dovedesc că e-mailul e legitim al tău; DMARC transformă dovada într-o politică. Sunt poate douăzeci de minute de editări DNS și fac diferența dintre „expeditor verificat” și „cine?”.

Portul 25 și de ce e închis

Ăsta îi surprinde pe oameni. Portul 25 spre exterior — portul prin care serverele de e-mail vorbesc între ele — e blocat implicit la practic fiecare host VPS. Și la noi.

E intenționat. Portul 25 e tunul clasic de spam, așa că rămâne închis până îl ceri și spui ce trimiți de fapt. Îl deschidem la cerere, nu îl lăsăm deschis oricui pornește un server.

Și aici e o precizare cinstită care merită spusă direct: odată cu portul 25 deschis vine și responsabilitatea. Un script compromis sau un relay configurat greșit care trimite spam și reputația IP-ului tău s-a dus — uneori pentru săptămâni. Într-o subrețea folosită de mai mulți clienți, mizeria se varsă și asupra celorlalți, exact de aceea hosturile sunt prudente. Dacă ne ceri să deschidem 25, ține-ți serverul curat, pentru că reputația pe care o protejezi e în parte și a noastră.

De ce IP-ul dedicat nu e opțional

Totul se întoarce la o singură cerință: IP-ul trebuie să fie al tău. Pe o configurare NAT sau pe o adresă folosită de mai mulți nu-ți poți seta propriul PTR, pentru că adresa nu e exclusiv a ta. Moștenești și reputația pe care o are deja IP-ul — și n-ai idee ce a făcut cu el ultimul chiriaș.

Un IP dedicat îți dă un PTR pe care îl controlezi, o reputație pe care o construiești tu și un punct de plecare curat. Pentru e-mailul trimis nu e un lux; e minimul.

Concluzia cinstită

Găzduirea propriului e-mail în 2026 e muncă reală și continuă. Nu e „configurezi și uiți” — vei urmări listele negre, vei roti cheile DKIM și, din când în când, vei afla de ce un anumit serviciu a început să te pună pe greylist. Dacă e un proiect secundar cu miză mică, sincer, redirecționarea printr-un serviciu de e-mail existent te scutește de bătăi de cap.

Dar dacă vrei control real — datele tale, domeniul tău, nimeni altcineva care să-ți citească antetele —, e foarte realizabil pe un VPS mic. Instalațiile de încredere de mai sus sunt cam 90% din bătălie și nimic din ele nu e exotic. Ia un IP dedicat, setează PTR-ul să se potrivească cu numele de host, publică SPF/DKIM/DMARC, cere-ne să deschidem portul 25, apoi trimite un test printr-o unealtă ca mail-tester.com și repară ce semnalează. Fă asta și nu mai strigi într-un folder de spam — ești un server de e-mail în care inboxurile oamenilor chiar au încredere.