Ghid de securitate · România

Cum securizez serverul de e-mail cu SPF, DKIM și DMARC?

Fără SPF, DKIM și DMARC, oricine poate trimite e-mailuri „de la” domeniul tău, iar mesajele tale legitime ajung în spam. Cele trei înregistrări DNS sunt gratuite, se configurează într-o după-amiază și sunt cerute de marile servicii de e-mail pentru expeditorii în volum.

Actualizat la

Răspuns scurt

  1. Securizezi serverul de e-mail publicând în DNS o înregistrare SPF care listează exact serverele autorizate: terminația -all pentru domeniile care nu trimit, ~all plus DMARC p=reject pentru cele care trimit.
  2. Semnezi fiecare mesaj cu DKIM, folosind o cheie de 2048 de biți pe care o rotești periodic, cu selectorul publicat în DNS.
  3. Publici DMARC, pornind cu p=none și rapoarte rua ca să vezi cine trimite în numele tău, apoi treci la p=quarantine și p=reject.
  4. Serverul are PTR corect, TLS pe porturile 25, 587 și 465, nu e open relay și limitează rata de trimitere; mailul tranzacțional pleacă printr-un relay separat.
SPF
v=spf1 … ~all cu DMARC p=reject (-all fără trimitere), max. 10 lookup-uri DNS
DKIM
cheie RSA 2048, selector rotit cel puțin anual
DMARC
p=none → p=quarantine → p=reject, cu rua=
Porturi cu TLS
25 STARTTLS, 587 STARTTLS, 465 TLS implicit

Ce face fiecare dintre cele trei înregistrări

SPF spune destinatarului care adrese IP pot trimite pentru domeniul tău; -all înseamnă că orice altă sursă e refuzată, iar ~all doar marcată. DKIM adaugă o semnătură criptografică în antetul mesajului, verificabilă cu cheia publică din DNS: dacă conținutul a fost modificat sau expeditorul nu are cheia, verificarea eșuează. DMARC leagă cele două de domeniul vizibil în câmpul From și îi spune destinatarului ce să facă la eșec și unde să trimită rapoartele. Fără DMARC, SPF și DKIM sunt indicii; cu DMARC devin politică.

Serverul în sine: PTR, TLS, relay și separare

Marile servicii verifică întâi dacă adresa IP are o înregistrare PTR care se rezolvă înapoi la numele serverului; fără ea, mesajul e respins înainte de SPF. TLS trebuie activ pe toate porturile de trimitere, cu certificat valid, ca parolele să nu circule în clar. Serverul acceptă trimiterea doar de la utilizatori autentificați sau din rețelele proprii; un open relay ajunge pe liste negre în ore. Limitezi rata per cont, ca un cont cu parola furată să nu trimită zece mii de mesaje. Mailul tranzacțional pleacă printr-un relay separat, pe subdomeniu propriu.

  • Rapoartele DMARC le citești câteva săptămâni în p=none înainte să înăsprești politica
  • MTA-STS și TLS-RPT sunt pasul următor, opțional, pentru a impune TLS la primire
  • Un domeniu care nu trimite e-mail primește SPF v=spf1 -all și DMARC p=reject

Ce spune legislația din România

E-mailul de pe domeniul firmei conține aproape întotdeauna date personale, deci intră sub art. 32 GDPR; un cont compromis care trimite phishing clienților e un incident pe care trebuie să îl evaluezi și, dacă datele au fost accesate, să îl notifici ANSPDCP în 72 de ore. Pentru entitățile de sub OUG 155/2024, protecția comunicațiilor și autentificarea multi-factor sunt măsuri minime explicite. Facturile trimise prin e-mail sunt documente contabile: un IBAN înlocuit într-o factură falsificată în numele tău e scenariul pe care DMARC p=reject îl oprește.

Înregistrările DNS și setările de server pentru un e-mail de încredere
MecanismUnde se configureazăValoare recomandatăCe previne
SPFTXT pe domeniuv=spf1 ip4:… include:… ~all, cu DMARC p=rejectTrimitere de pe servere neautorizate
DKIMTXT pe selector._domainkey + semnare în MTARSA 2048, rotație anualăModificarea conținutului, falsificarea expeditorului
DMARCTXT pe _dmarcp=reject după perioada p=none cu ruaFalsificarea adresei From vizibile
PTR (rDNS)La furnizorul IP-uluimail.exemplu.ro → IP → mail.exemplu.roRespingere înainte de orice verificare
TLSPostfix / MailuCertificat valid pe 25, 587, 465Interceptarea parolelor și a mesajelor
Relaysmtpd_relay_restrictionsDoar autentificat sau rețele propriiOpen relay, liste negre

Comenzi și configurări

Înregistrările DNS (TXT) pentru exemplu.ro
exemplu.ro.                     TXT  "v=spf1 ip4:203.0.113.25 include:relay.exemplu.net ~all"
s2026._domainkey.exemplu.ro.    TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq...cheia publică...IDAQAB"
_dmarc.exemplu.ro.              TXT  "v=DMARC1; p=none; rua=mailto:dmarc@exemplu.ro; adkim=s; aspf=s; pct=100"
Postfix: TLS oportunist pe 25, TLS obligatoriu pe submission, fără open relay
# /etc/postfix/main.cf (fragment) — portul 25, între servere: TLS oportunist
smtpd_tls_security_level = may
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.exemplu.ro/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.exemplu.ro/privkey.pem
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_client_connection_rate_limit = 30

# /etc/postfix/master.cf — submission (587): TLS OBLIGATORIU și doar autentificat
submission inet n - y - - smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
Verifici din exterior
dig +short TXT exemplu.ro
dig +short TXT _dmarc.exemplu.ro
dig +short -x 203.0.113.25
openssl s_client -starttls smtp -connect mail.exemplu.ro:587 -servername mail.exemplu.ro </dev/null | grep -E "Verify|subject="

Exemple practice

Firmă de contabilitate din Sibiu cu domeniul folosit pentru phishing

Clienții primeau facturi false „de la” firmă, cu alt IBAN, iar domeniul nu avea DMARC. SPF, DKIM și DMARC p=none cu rapoarte au arătat trei surse neautorizate în prima săptămână; la p=reject, mesajele false au dispărut din inbox-urile clienților.

SaaS din Iași cu notificări tranzacționale

Aplicația trimitea e-mailurile de resetare a parolei prin același server ca oamenii. O campanie de marketing marcată ca spam a scăzut reputația și resetările au ajuns în spam. Mutarea aplicației pe un relay separat, cu subdomeniu și DKIM propriu, a izolat cele două fluxuri.

Greșeli frecvente

  • Te oprești la SPF, cu ~all sau -all, și nu publici DMARC: fără o politică p=reject, ambele variante lasă mesajul falsificat să ajungă la destinatar.
  • Depășești zece lookup-uri DNS în SPF prin include-uri înlănțuite și SPF devine invalid.
  • Publici DMARC p=reject din prima zi, fără rapoarte, și blochezi propriul sistem de facturare.
  • Nu ai PTR pentru IP-ul serverului sau PTR-ul arată numele generic al furnizorului.

Cum te ajută 4hosting

  • Serviciul Mailu & SMTP Relay instalează Mailu self-hosted pe domeniul tău, cu SPF, DKIM și DMARC configurate, și un relay separat pentru mailul tranzacțional; ghidul e la /documentatie/mailu-smtp-relay.
  • Același serviciu acoperă migrarea de la cPanel sau Google Workspace, în orele incluse: 1–8 lunar la VPS, 10 la dedicate și GPU, cerute din panoul de client, secțiunea „Servicii DevOps”; orele se consumă în luna calendaristică și nu se reportează.
  • Pe planurile cPanel, e-mailul e inclus, cu SPF și DKIM generate din panou; DMARC îl adaugi tu în DNS.

Întrebări conexe

  • Cât timp stau în p=none înainte să trec la reject?

    Până când rapoartele DMARC arată că toate sursele legitime — serverul propriu, aplicația, newsletterul, facturarea — trec SPF sau DKIM aliniat. De obicei două–patru săptămâni. Treci întâi la p=quarantine, eventual cu pct=25, apoi la p=reject.

  • Merită să-mi țin propriul server de e-mail?

    Da, dacă vrei control asupra datelor și un cost fix, și dacă cineva îl întreține: actualizări, reputație, rapoarte DMARC. Mailu împachetează Postfix, Dovecot, antispam și webmail într-o instalare Docker administrabilă. Dacă nimeni nu-l poate întreține, un serviciu găzduit e alegerea mai sigură.

  • De ce mailul tranzacțional trebuie separat de cel al oamenilor?

    Pentru că reputația se calculează per domeniu și per IP. O campanie prost primită sau un cont compromis afectează livrarea tuturor mesajelor de pe aceeași sursă. Cu un subdomeniu și un relay dedicat, resetările de parolă și facturile ajung în inbox indiferent ce se întâmplă cu newsletterul.

Cere o verificare de securitate

Un server de producție e atacat automat din primele minute după ce primește IP public, indiferent cât de mic e proiectul. Ghidul ordonează controalele după impact, de la accesul SSH până la răspunsul la incident, cu legislația din România care se aplică. Fiecare temă are o pagină dedicată, cu răspuns scurt, exemple și configurări.