SPF Record: configurare strictă (-all) pentru anti-spoofing email
SPF e fundamentul autentificării email. Vedem cum configurați un SPF strict (-all), cum gestionați limita de 10 lookup-uri și cum evitați greșelile care invalidează policy-ul.
Pe scurt
SPF (Sender Policy Framework, RFC 7208) este o înregistrare TXT DNS care declară ce IP-uri sunt autorizate să trimită email pentru un domeniu. E fundamentul pentru DMARC — fără SPF corect, DMARC nu poate decide dacă un email e autentic. Lipsa SPF înseamnă că orice atacator poate trimite email cu MAIL FROM: <orice>@firma.ro din orice IP.
Configurarea ia 2-4 ore (incluzând inventarul surselor de trimitere) și e prima măsură anti-spoofing pe care o recomandăm oricărei organizații care primește sau trimite email.
Cum funcționează SPF
Când un mail-server destinatar primește un email cu MAIL FROM: ceo@firma.ro:
- Caută TXT-ul
firma.roîn DNS — găseștev=spf1 ip4:91.234.56.78 include:_spf.google.com -all - Verifică dacă IP-ul real al expeditorului SMTP e în lista declarată
- Dacă da → SPF Pass (probabil legitim)
- Dacă nu → SPF Fail. Cu
-all(hard fail), receiver-ul respinge sau marchează ca spam
Notă importantă: SPF verifică MAIL FROM (envelope sender), NU From: afișat utilizatorului. Pentru protecția headerului From: aveți nevoie de DMARC suplimentar.
Atacuri preventate de SPF
Spam mass de pe IP-uri compromise
Atacatorii care controlează botneturi (zeci de mii de IP-uri rezidențiale infectate) trimit milioane de emailuri spoof. Cu SPF strict, fiecare destinatar verifică IP-ul → respinge instant.
Email Business Compromise (BEC)
Atacator închiriază un VPS la 5 USD/lună, configurează postfix și trimite emailuri ca cfo@firma.ro către accounts@partener.com cu factură falsă. Fără SPF (sau cu ~all/?all permisiv), Gmail/Outlook livrează în Inbox. Cu -all, ajunge în Spam sau e respins complet.
Subdomain spoofing
Dacă SPF există pe firma.ro dar lipsește pe mail.firma.ro sau newsletter.firma.ro, atacatorul folosește subdomeniul nepotcut. Best practice: SPF explicit pe fiecare subdomeniu care trimite email.
Anatomia unui SPF corect configurat
firma.ro. IN TXT "v=spf1 ip4:91.234.56.78/32 ip4:91.234.56.79/32 include:_spf.google.com include:sendgrid.net include:mailgun.org -all"Decodare:
v=spf1— versiunea SPFip4:91.234.56.78/32— IP fix al MTA-ului propriu (Postfix/Exim self-hosted)include:_spf.google.com— Google Workspace (delegă lista IP-urilor lor)include:sendgrid.net— SendGrid pentru transactional emailsinclude:mailgun.org— Mailgun pentru notificări-all— hard fail la orice altceva (respingere la receiver)
Tipurile de fail SPF
| Mecanism | Comportament receiver |
|---|---|
-all (hard fail) | Reject sau Spam — recomandat în producție |
~all (soft fail) | Marker doar — folosit în deployment inițial |
?all (neutral) | Niciun efect — practic SPF dezactivat |
+all (pass all) | Periculos — orice IP trece SPF; nu folosiți niciodată |
Limita de 10 DNS lookup-uri (problema majoră în practică)
RFC 7208 limitează SPF la 10 lookup-uri DNS. Fiecare include:, a:, mx:, exists:, redirect: consumă un lookup. La organizații complexe (Google Workspace + SendGrid + Mailgun + Salesforce + Hubspot + 5 alte SaaS), depășirea e ușoară.
Când SPF depășește 10 lookup-uri → receivers tratează ca PermError = SPF eșuat = potențial reject.
Cum verificați
dig TXT firma.roTool: https://www.kitterman.com/spf/validate.html — vizualizator + counter de lookup-uri.
Soluție: SPF flattening
Tools dedicate (EasyDMARC, Cisco SPF flattening, dmarcian) iau lista voastră de include: și o rezolvă într-o listă de IP-uri statice — un singur lookup. Recomandat: refresh săptămânal pentru că ESP-urile (Google, SendGrid) își schimbă IP-urile periodic.
Implementare pas-cu-pas
Pas 1 — Inventarul surselor legitime
Toate sistemele care trimit email pentru domeniul vostru:
- MTA propriu (Postfix, Exim) — IP-ul fix
- Email service (Google Workspace, Microsoft 365)
- Marketing tools (Mailchimp, SendGrid, Mailgun, Postmark)
- CRM/ERP (Salesforce, Hubspot, NetSuite)
- Monitoring (PagerDuty, Datadog) — dacă trimit alertele de pe domeniul vostru
- Notification scripts (cron jobs care trimit raporturi)
Pas 2 — Construire SPF TXT record
Începeți cu ~all (softfail) ca să monitorizați:
firma.ro. IN TXT "v=spf1 ip4:91.234.56.78 include:_spf.google.com include:sendgrid.net ~all"Lăsați 14-30 zile să identificați surse uitate (apar în DMARC reports ca SPF fail).
Pas 3 — Switch la -all (hard fail)
După ce DMARC reports confirmă că nu mai sunt SPF fails false-positive:
firma.ro. IN TXT "v=spf1 ip4:91.234.56.78 include:_spf.google.com include:sendgrid.net -all"Pas 4 — Subdomenii
Pentru fiecare subdomeniu care trimite email separat:
mail.firma.ro. IN TXT "v=spf1 ip4:91.234.56.78 -all"
newsletter.firma.ro. IN TXT "v=spf1 include:sendgrid.net -all"Pentru subdomenii care NU trimit email (anti-abuse):
old.firma.ro. IN TXT "v=spf1 -all"Confuzii frecvente
“SPF e suficient — nu am nevoie de DMARC.” — Greșit. SPF nu protejează headerul From: afișat utilizatorului. DMARC verifică alignment-ul între From: și domeniul autentificat de SPF/DKIM.
“Folosesc ~all ca să fiu safe.” — Confuzie comună. ~all permite atacatorilor să exploateze ambiguitatea — multe receivers livrează în Inbox emailuri SPF softfail. -all e standardul în 2026.
“Am 11 lookup-uri și încă funcționează.” — Aleator. Unii receivers tolerează 11-12, alții fail strict la 11. Risc deliverability mare.
Verificați acum
ARTEMIS verifică automat SPF în orice audit Site (2 EUR) — plus DMARC, DKIM, MTA-STS, BIMI, DNSSEC, CAA și 30+ verificări tehnice.
🔗 Soluții complementare CAI Technology
- ARTEMIS — Audit tehnic complet email auth (SPF + DKIM + DMARC + MTA-STS + BIMI) + 30+ verificări infrastructură.
- Lexnomia — Evaluare auditor-grade NIS2 / GDPR — autentificarea email e cerință explicită NIS2 Art.21.2.j.
- BeLegal — Verificare gratuită compliance UE în 5 minute.
- Auditope — Audit holistic web (SEO + AI search + GDPR + Performance).
- AriaUnited — Consultanță fonduri europene PNRR pentru investiții în infrastructură email securizată (gateway anti-spam, DMARC reporting platform internă).
Întrebări? tehnic@caitech.ro