Un domeniu .md fără SPF, DKIM și DMARC poate fi folosit de oricine ca expeditor, iar facturile false „de la contabilitate” ajung la clienții tăi cu numele tău. Serverul de e-mail al firmei cere trei înregistrări DNS și câteva setări.
SPF spune ce servere au voie să trimită pentru domeniul tău: -all cere respingerea, ~all doar marcarea, iar decizia o ia DMARC. DKIM adaugă fiecărui mesaj o semnătură verificabilă prin cheia publică din DNS, deci destinatarul știe că nu a fost modificat. DMARC leagă cele două de domeniul vizibil în From, spune ce să facă la eșec și îți trimite rapoarte. Fără DMARC, SPF și DKIM sunt informații; cu DMARC devin politică.
Începi cu p=none și adresa rua pentru rapoarte agregate. O lună vezi de unde pleacă de fapt mesaje cu domeniul tău: serverul principal, aplicația de facturare, programările, un CRM conectat de contabilitate. Adaugi fiecare sursă legitimă în SPF sau o pui să semneze DKIM. Când rapoartele arată doar surse cunoscute, treci pe p=quarantine, apoi pe p=reject. Sari direct la reject și facturile pleacă în neant.
Un server care trimite fără PTR corect ajunge în spam, indiferent de SPF. Cere furnizorului să seteze PTR-ul adresei la numele serverului de mail. Postfix sau Mailu acceptă mesaje de la utilizatori doar după autentificare SASL, pe 587 sau 465 cu certificat valid; pe 25 primește doar corespondența pentru domeniile tale. Un relay deschis e găsit în ore și duce adresa pe liste negre.
Aplicația de facturare trimite mii de mesaje cu atașamente; un client care le marchează ca spam scade reputația domeniului, deci suferă și corespondența angajaților. Soluția e un relay separat pentru tranzacțional, cu subdomeniu sau selector DKIM propriu. Pentru clienții din UE, notificările plecate dintr-un datacenter din UE răspund la o întrebare din chestionarele de securitate.
| Înregistrare | Unde | Valoare recomandată | Ce previne |
|---|---|---|---|
| SPF | TXT pe exemplu.md | v=spf1 mx include:relay.exemplu.md ~all, cu DMARC p=reject | trimiteri de pe servere neautorizate |
| DKIM | TXT pe 2026a._domainkey.exemplu.md | v=DKIM1; k=rsa; p=<cheie 2048> | modificarea mesajului, falsificarea sursei |
| DMARC | TXT pe _dmarc.exemplu.md | v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s | mesaje cu From falsificat acceptate |
| PTR | reverse DNS la furnizor | 203.0.113.25 → mail.exemplu.md | clasificarea ca spam la primire |
| MTA-STS și TLS-RPT | TXT pe _mta-sts și _smtp._tls | v=STSv1; id=2026090901, plus fișierul de politică pe https://mta-sts.exemplu.md/.well-known/mta-sts.txt / v=TLSRPTv1; rua=… | degradarea TLS la livrare către tine |
opendkim-genkey -b 2048 -d exemplu.md -s 2026a -D /etc/opendkim/keys/exemplu.md
cat /etc/opendkim/keys/exemplu.md/2026a.txt # conținutul TXT pentru 2026a._domainkey
chown opendkim:opendkim /etc/opendkim/keys/exemplu.md/2026a.private# /etc/postfix/main.cf (fragment)
mynetworks = 127.0.0.0/8 [::1]/128
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_tls_security_level = may
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.exemplu.md/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.exemplu.md/privkey.pem
# /etc/postfix/master.cf: submission pe 587 doar cu TLS și SASL
submission inet n - y - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,rejectdig +short TXT exemplu.md | grep spf1
dig +short TXT 2026a._domainkey.exemplu.md
dig +short TXT _dmarc.exemplu.md
dig +short -x 203.0.113.25
# test de relay: trebuie să răspundă 554 Relay access denied
swaks --to test@alt-domeniu.md --from x@exemplu.md --server mail.exemplu.mdClienții primeau „facturi” cu alt IBAN, de la o adresă cu domeniul firmei, care nu avea nici SPF, nici DMARC. După SPF, DKIM și DMARC pe reject în șase săptămâni, rapoartele au arătat că peste 90 % din mesajele cu acel domeniu veneau din surse străine.
Confirmările plecau de pe același server ca e-mailurile angajaților, fără DKIM și fără PTR. Mutarea lor pe un relay separat, cu selector propriu și PTR corect, a dus livrarea în inbox de la jumătate la aproape 100 %.
Clientul german a cerut ca proiectul să nu treacă printr-un furnizor american. Echipa a instalat Mailu pe un VPS în Frankfurt, cu DMARC pe reject și TLS impus, iar chestionarul de securitate a primit răspunsuri verificabile.
Da. Furnizorul semnează DKIM și îți dă valorile SPF, dar politica DMARC o publici tu, iar fără ea oricine poate falsifica From-ul. Marii destinatari cer deja DMARC, deci lipsa ei afectează livrarea, nu doar securitatea.
Cel puțin anual sau imediat după un incident. Publici cheia nouă pe un selector nou, treci semnarea pe el, aștepți câteva zile pentru mesajele în tranzit, apoi ștergi selectorul vechi.
Acest ghid adună într-un singur loc măsurile care contează pentru un server de producție al unei firme din Moldova: de la cheia SSH până la copia de backup pe care nimeni nu o poate șterge. Fiecare capitol trimite la o pagină de întrebare cu pași, comenzi și exemple. Este scris pentru echipe care livrează clienților din UE, raportează la instituții locale sau vând online și nu își permit o zi de indisponibilitate.