SPF: la prima linea di difesa contro lo spoofing
Il Sender Policy Framework (SPF) è un meccanismo di autenticazione email che permette al proprietario di un dominio di specificare quali server sono autorizzati a inviare email per suo conto. Senza SPF, chiunque può inviare email facendo apparire il proprio dominio come mittente — una tecnica chiamata spoofing che è alla base della maggior parte degli attacchi di phishing. SPF è stato standardizzato nella RFC 7208 e rappresenta il primo dei tre pilastri dell'autenticazione email moderna, insieme a DKIM e DMARC.
Quando un server riceve un'email, verifica il record SPF del dominio mittente. Se l'IP del server che ha inviato l'email è nell'elenco degli IP autorizzati dal record SPF, il controllo passa. In caso contrario, l'email viene segnalata come potenzialmente fraudolenta. La decisione finale (accettare, rifiutare o segnalare) dipende dalla policy specificata nel record e dalla configurazione DMARC del dominio.
Anatomia di un record SPF
Un record SPF è un record TXT nel DNS del dominio che inizia con v=spf1 seguito da una serie di meccanismi e qualificatori. I meccanismi definiscono chi è autorizzato a inviare, mentre il qualificatore finale (tipicamente ~all o -all) definisce cosa fare con le email che non corrispondono a nessun meccanismo autorizzato.
Il limite dei 10 DNS lookup
Uno degli aspetti più critici e meno compresi di SPF è il limite dei 10 DNS lookup. Ogni volta che il record SPF usa un meccanismo che richiede una query DNS aggiuntiva (include, a, mx, redirect, exists), conta come un lookup. Superare il limite di 10 causa un permerror: il record SPF viene considerato invalido e l'autenticazione fallisce per tutte le email.
Questo limite diventa problematico quando si utilizzano molti servizi terzi per l'invio email. Un singolo include può contenere a sua volta altri include annidati, e ciascuno conta nel limite. Ad esempio, include:_spf.google.com da solo consuma già 3-4 lookup. Aggiungi Mailchimp, SendGrid, HubSpot e il limite è rapidamente esaurito. Il nostro SPF Lookup analizza il tuo record SPF e conta automaticamente i DNS lookup, avvisandoti se sei vicino al limite.
Come risolvere i problemi SPF più comuni
Il problema più frequente è il superamento del limite di 10 lookup. Le soluzioni includono: sostituire i meccanismi include con ip4/ip6 diretti (che non contano come lookup), usare servizi di SPF flattening che risolvono gli include in IP statici, o consolidare i servizi email per ridurre il numero di include necessari. Un'altra strategia è usare sottodomini dedicati per diversi servizi: marketing@news.esempio.com può avere il proprio record SPF indipendente.
Un altro errore comune è avere più record SPF per lo stesso dominio. Le RFC specificano chiaramente che un dominio deve avere un solo record TXT che inizia con v=spf1. Record multipli causano un permerror. Se devi autorizzare più origini, combina tutto in un unico record. Verifica la presenza di record duplicati con il TXT Lookup, che elenca tutti i record TXT del dominio.
SPF da solo non basta: il trinomio SPF + DKIM + DMARC
SPF ha una limitazione importante: verifica solo l'IP del server mittente, non il contenuto dell'header From che l'utente vede. Un attaccante potrebbe usare un server autorizzato dal suo SPF per inviare email con il tuo dominio nell'header From. Per questo SPF deve essere affiancato da DKIM e DMARC. DKIM firma crittograficamente l'email, mentre DMARC verifica che il dominio nell'header From sia allineato con il dominio autenticato da SPF o DKIM.
Usa il DMARC Lookup per verificare che il tuo dominio abbia una policy DMARC attiva. Senza DMARC, anche un SPF perfetto non impedisce che email spoofate vengano consegnate. La combinazione dei tre protocolli crea una difesa a strati che rende lo spoofing del tuo dominio estremamente difficile, proteggendo la tua reputazione e i tuoi destinatari.
La configurazione ideale prevede: SPF con ~all o -all per autorizzare solo i server legittimi, DKIM con chiave a 2048 bit per firmare tutte le email in uscita, e DMARC con policy progressiva (da p=none per il monitoraggio a p=reject per il blocco totale). Questo trinomio è oggi considerato il requisito minimo per qualsiasi dominio che invii email.