Sender policy
SPF
SPF publica in DNS ce servere sunt autorizate sa trimita email folosind domeniul tau in envelope sender, adica identitatea SMTP MAIL FROM.
Ce este SPF
SPF inseamna Sender Policy Framework. Domeniul publica un TXT care spune ce servere au voie sa trimita email pentru el. Cand un server primeste email, verifica IP-ul clientului SMTP si domeniul din envelope sender. Daca IP-ul este autorizat de recordul SPF, rezultatul poate fi PASS. Daca nu este autorizat, rezultatul poate fi FAIL, SOFTFAIL, NEUTRAL sau alt rezultat definit de standard.
Este important sa nu confunzi envelope sender cu header From. Utilizatorul vede de obicei header From in clientul de mail, dar SPF se aplica pe MAIL FROM sau HELO. De aceea SPF singur nu este suficient pentru anti-spoofing vizibil. Un atacator poate folosi un envelope sender aliniat cu infrastructura lui si un From vizibil diferit. DMARC rezolva aceasta problema cerand aliniere.
Structura unui record SPF
Un record SPF incepe cu v=spf1 si continua cu mecanisme si calificatori. Mecanismele comune sunt ip4, ip6, a, mx, include, exists si all. Calificatorul de la final stabileste politica pentru sursele care nu se potrivesc.
example.com. TXT "v=spf1 ip4:203.0.113.10 include:_spf.provider.example -all"
- -all - hardfail: sursele neautorizate trebuie tratate ca nepermise.
- ~all - softfail: sursele neautorizate sunt suspecte, dar nu respinse strict.
- ?all - neutral: domeniul nu da o decizie clara.
- +all - permite orice sursa si este o configuratie periculoasa.
include si redirect
include: inseamna ca domeniul accepta si sursele autorizate de alt record SPF. Este folosit pentru platforme de newsletter, CRM, servicii cloud sau relay-uri externe. redirect= muta evaluarea SPF catre alt domeniu. Diferenta operationala este importanta: include este un mecanism din lista, iar redirect devine politica finala daca niciun mecanism anterior nu a dat match.
Un checker corect trebuie sa evalueze recursiv include si redirect. De exemplu, daca un record are doar redirect=_spf.google.com, lipsa lui all in recordul initial nu este o problema. Politica finala este in recordul redirectat. De aceea Mailcheck nu marcheaza WARN doar pentru ca recordul initial nu are all, daca exista redirect valid care defineste politica.
Limita de 10 lookup-uri DNS
SPF limiteaza la 10 numarul de mecanisme si modificatori care produc lookup-uri DNS. Mecanisme precum include, a, mx, ptr, exists si redirect conteaza. Mecanismele ip4, ip6 si all nu consuma lookup-uri. Daca depasesti limita, rezultatul poate fi permerror, iar deliverability-ul poate fi afectat.
Configuratiile mutate de pe multe platforme ajung usor la 10 lookup-uri: un include pentru newsletter, unul pentru helpdesk, unul pentru facturare, unul pentru cloud, plus MX si A. O practica buna este sa pastrezi SPF cat mai scurt, sa elimini include-uri vechi si sa folosesti subdomenii separate pentru sisteme diferite.
Legatura cu DMARC
SPF ajuta DMARC doar daca domeniul SPF se aliniaza cu domeniul din header From. In aliniere relaxed, subdomeniile pot fi acceptate ca parte a aceleiasi organizatii; in aliniere stricta, domeniul trebuie sa fie identic. Un SPF PASS pe un domeniu complet diferit nu inseamna DMARC PASS pentru domeniul afisat utilizatorului.
Ce verifica Mailcheck
Mailcheck verifica existenta recordului SPF, sintaxa, mecanismele folosite, politica finala, include/redirect recursiv si numarul de lookup-uri. Statusul MISSING apare cand domeniul nu are SPF. WARN apare pentru protectie slaba, de exemplu ~all, ?all sau lookup-uri aproape de limita. FAIL apare la sintaxa defecta, mai multe recorduri SPF sau depasirea limitei.