Definizione
Un record SPF (record Sender Policy Framework) è un record DNS TXT pubblicato nella zona DNS pubblica di un dominio che elenca gli indirizzi IP, i prefissi IPv6 e gli hostname dei server di posta autorizzati a inviare email per conto del dominio. Quando un server di posta ricevente accetta un messaggio in arrivo, interroga il DNS del mittente per il record SPF e confronta l’IP che si connette con la policy. Se l’IP non è elencato, il server può marcare il messaggio come softfail, rifiutarlo del tutto o segnalarlo per ulteriore valutazione, a seconda del qualificatore di policy impostato dal proprietario del dominio.
SPF è stato formalizzato per la prima volta come standard IETF in RFC 4408 (2006) e successivamente aggiornato alla specifica autorevole attuale, RFC 7208, pubblicata da IETF ad aprile 2014. È uno dei tre standard complementari di autenticazione email accanto a DKIM (DomainKeys Identified Mail) e DMARC (Domain-based Message Authentication, Reporting, and Conformance).
Come funziona
Il processo di valutazione SPF prevede vari passaggi sequenziali eseguiti dal motore SMTP del server ricevente durante la fase MAIL FROM dell’handshake.
Il proprietario del dominio pubblica un record TXT SPF nel DNS. Un record tipico segue la sintassi: v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all. I componenti sono: v=spf1 (identificatore di versione), uno o più meccanismi (include, ip4, ip6, a, mx, exists) e un qualificatore finale (+all, -all, ~all, ?all). Il qualificatore -all indica hard fail — qualsiasi server non esplicitamente elencato non è autorizzato. Il qualificatore ~all (softfail) lascia passare il messaggio segnalando però la discrepanza, e si usa spesso nei periodi di migrazione.
All’arrivo di un messaggio, l’MTA ricevente estrae il dominio del mittente di busta (l’indirizzo MAIL FROM, detto anche RFC5321.MailFrom) ed esegue una lookup TXT su _spf.<dominio> o direttamente sul dominio root. La libreria SPF valuta ogni meccanismo nell’ordine finché uno corrisponde o si raggiunge il limite di dieci lookup DNS (limite “SPF PermError” definito in RFC 7208 sezione 4.6.4). Il risultato — Pass, Fail, SoftFail, Neutral, TempError o PermError — viene inserito nell’header Received-SPF del messaggio e passato al filtro antispam e a qualsiasi motore di policy DMARC.
È fondamentale capire che SPF autentica il mittente di busta (MAIL FROM) e non l’header From visibile nel corpo del messaggio. Questa distinzione fa sì che SPF da solo non impedisca lo spoofing del display name nei client email, motivo per cui l’allineamento DMARC — che richiede che almeno uno tra SPF e DKIM si allinei al dominio dell’header RFC5322.From — è necessario per una protezione completa.
Dove lo incontri
I record SPF compaiono in qualsiasi contesto in cui contano deliverability ed reputazione di mittente. L’infrastruttura email transazionale gestita da servizi come Amazon SES, SendGrid, Mailgun, Postmark e SparkPost richiede ai proprietari di aggiungere meccanismi include SPF che puntino all’infrastruttura di invio del provider prima che i messaggi superino i controlli.
Le piattaforme di concorso che inviano email di conferma del voto — tra cui Woobox, ShortStack e sistemi custom con Mailchimp Transactional (Mandrill) — fanno affidamento su un record SPF valido. I mailbox provider come Google (Gmail), Microsoft (Outlook / Exchange Online Protection) e Yahoo Mail valutano SPF come input nei loro algoritmi di deliverability. Un SPF mancante o mal configurato aumenta in modo sostanziale la probabilità che l’email di conferma finisca silenziosamente nello spam o venga rifiutata, lasciando voti non confermati.
Pannelli DNS di provider come Cloudflare, AWS Route 53, GoDaddy e Namecheap espongono l’editing dei record SPF TXT tramite l’interfaccia di gestione. Strumenti diagnostici come MXToolbox SPF Lookup, Google Admin Toolbox e SPF Surveyor di DMARCIAN permettono di ispezionare e validare i record pubblicati.
Esempi pratici
Una piattaforma di concorso invia email di conferma da [email protected]. Il dominio votes.example.com ha il record SPF v=spf1 include:sendgrid.net -all. Quando Gmail riceve un messaggio di conferma, il server SMTP in entrata interroga il DNS per l’SPF di votes.example.com, espande il meccanismo sendgrid.net e confronta l’IP che si connette con l’elenco dei server autorizzati di SendGrid. Se l’IP corrisponde, il risultato SPF è Pass e il messaggio prosegue verso l’inbox. Se il dominio non avesse record SPF, il filtro Gmail tratterebbe il messaggio come non autenticato, riducendone le probabilità di arrivare in inbox.
Un concorso di una testata regionale cambia provider transazionale da Mailchimp ad Amazon SES senza aggiornare il record SPF. Le email di conferma iniziano a fallire i controlli SPF su Microsoft Outlook e finiscono in massa in spam, facendo perdere ai votanti la finestra di conferma. L’amministratore diagnostica il problema con MXToolbox, aggiunge include:amazonses.com al record SPF e la deliverability si riprende entro la finestra di propagazione DNS (di solito 0–48 ore a seconda del TTL).
Concetti correlati
SPF è uno dei pilastri dello stack di autenticazione email a tre standard: vedi DKIM per la verifica della firma crittografica e DMARC per il livello di policy che agisce sui risultati di SPF e DKIM. L’impatto pratico sulle operazioni di concorso è descritto in Email Confirmation Vote, dove la deliverability del messaggio di conferma è la dipendenza operativa più critica. BIMI (Brand Indicators for Message Identification), uno standard più recente costruito su DMARC, consente ai mittenti verificati di mostrare il logo del brand nei mailbox provider che lo supportano — un segnale di fiducia emergente che qui non trattiamo.
