Tutto sui record SPF

On Maggio 29, 2023
9min read
Zakhar Yung Technical Content Writer @Mailtrap

Un record SPF è un record DNS indispensabile per una consegna affidabile delle e-mail. Si tratta di un tipo di autenticazione delle e-mail che protegge le tue e-mail dalla contraffazione. In questo modo la tua reputazione viene protetta da phisher e spoofers. Scopri di più sul Sender Policy Framework per aumentare la credibilità del tuo prodotto.

Cos’è un record SPF?

Uno dei record di risorse DNS è di tipo TXT. Viene utilizzato principalmente per indicare fatti relativi al dominio e fornire informazioni a fonti esterne. È indispensabile per l’autenticazione delle e-mail. Ad esempio, un’e-mail arriva da un server al tuo provider di servizi Internet (ISP). L’ISP può autenticare l’e-mail utilizzando un record TXT dedicato, il record SPF. Questo record contiene i dati relativi ai server affidabili autorizzati dal tuo dominio, in modo che l’ISP possa identificare la fonte da cui proviene un’e-mail e individuare un’e-mail contraffatta. SPF o Sender Policy Framework è il metodo principale (ma non l’unico) per autenticare le tue e-mail.

Gli standard di autenticazione delle e-mail: a cosa servono?

L’SMTP non è in grado di proteggere la tua applicazione da frodi come spoofing, phishing e spam. Non dispone di una funzione per identificare l’origine di un messaggio e-mail e convalidare il dominio. Al contrario, l’autenticazione via e-mail può fare il suo lavoro.

Esistono tre standard ampiamente adottati per l’autenticazione delle e-mail: SPF, DKIM e DMARC. In breve, ognuno di essi svolge le seguenti funzioni:

  • SPF controlla che l’indirizzo IP da cui proviene l’e-mail sia autorizzato.
  • DKIM verifica che il messaggio non sia stato modificato durante il transito utilizzando le chiavi per la verifica della firma.
  • Il DMARC racchiude entrambi gli approcci in un’unica soluzione.

SPF, DKIM e DMARC differiscono nell’implementazione tecnica, ma si basano tutti su record DNS. Puoi trovare anche altri metodi di autenticazione come ADSP, Sender ID, iprev e così via. Alcuni di questi metodi non sono stati reclamati o sono stati deprecati.

Sender Policy Framework o SPF

Il Sender Policy Framework è apparso ufficialmente come standard sperimentale nel 2006. Otto anni dopo, SPF è stato approvato come standard proposto per l’autenticazione delle e-mail.

In parole povere, SPF è un protocollo in base al quale i server di posta decidono se ricevere o rifiutare un’e-mail in arrivo. La decisione viene presa utilizzando le informazioni SPF contenute nei record TXT come per l’elenco degli indirizzi IP autorizzati all’interno di un particolare dominio. Se l’e-mail è stata inviata da uno di questi indirizzi, non è contraffatta e può essere accettata.

Quando hai bisogno di SPF

Se il tuo prodotto digitale invia messaggi transazionali o commerciali, assicurati di implementare il Sender Policy Framework. Infatti, l’SPF è attualmente richiesto dai provider di servizi internet. Se non hai un record SPF valido o se hai una configurazione sbagliata, il tuo ISP potrebbe eseguire un filtraggio secondario delle e-mail. Una mancata autenticazione SPF significa che la tua e-mail verrà riconosciuta come spam o addirittura bloccata.

L’SPF è un problema per gli spammer e i phisher. perché permette di riconoscere le e-mail contraffatte. In questo modo è possibili distinguere e-mail vera da e-mail falsa e far rimanere la reputazione dei prodotti reali rimane. Ma per completare il quadro, è meglio implementare un’autenticazione delle e-mail su con tutti i meccanismi possibili (i.e., SPF + DKIM + DMARC).

Contro dell’autenticazione SPF delle e-mail

  • È problematico mantenere aggiornati i record SPF se si cambia ISP o si aggiungono flussi di posta
  • L’SPF da solo non garantisce che il tuo messaggio passi l’autenticazione
  • I record SPF interrompono l’inoltro di messaggi semplici

Idee sbagliate comuni sull’SPF

L’SPF è una misura necessaria ma non la soluzione definitiva contro lo spoofing e il phishing. Assicurati di essere consapevole delle seguenti convinzioni sbagliate in modo da poter utilizzare correttamente il framework.

  • Protezione completa del dominio dallo spoofing

L’SPF funziona con l’indirizzo di envelope-from (passaggio di ritorno) delle e-mail. È invisibile all’utente a differenza dell’indirizzo header-from, che si riferisce al contenuto del messaggio. Pertanto, un record SPF non può proteggere l’indirizzo visibile del mittente.

  • Con l’SPF, ottieni una protezione diretta contro lo spam

Il framework sfrutta i sistemi di filtraggio dello spam per controllare le e-mail. Inoltre, protegge dai messaggi contraffatti provenienti da un dominio specifico. Tuttavia, non offre miglioramenti significativi in termini di lotta allo spam.

  • SPF autorizza il mittente dell’e-mail

In realtà, il server di posta che invia un messaggio viene autorizzato in base al record SPF. Quindi, il framework funziona a livello di dominio.

  • Un record SPF per ogni dominio autorizzato

Ricorda che puoi avere un solo record SPF. In caso contrario, otterrai “permerror”, un errore che indica che il record SPF recuperato non può essere interpretato.

  • L’autenticazione delle e-mail con il solo DKIM è sufficiente

Anche se tutti i messaggi sono autorizzati secondo DKIM, hai bisogno di un record SPF per identificare il dominio. Inoltre, il Sender Policy Framework è necessario nei servizi cloud e nelle reti IPv6. Quindi, il modo migliore per combattere lo spoofing e proteggere le tue e-mail è implementare SPF, DKIM e DMARC.

Come funziona l’SPF?

In generale, l’SPF in azione consiste nelle seguenti fasi:

  • Creare un record SPF. Questo stabilisce una policy di autenticazione e definisce i server di posta autorizzati a inviare e-mail da un determinato dominio.
  • Ricerca DNS. Un messaggio in arrivo viene verificato nel DNS. Il nome del dominio dovrebbe essere elencato come indirizzo “envelope from”. Poi, il server in entrata controlla se l’indirizzo IP da cui viene inviata l’e-mail è autorizzato nel record SPF. L’e-mail non supera l’autenticazione SPF se uno qualsiasi dei controlli non ha esito positivo.
  • Risultato dell’autenticazione. Il server di posta consegna, segnala o rifiuta il messaggio in base alle regole specificate nel record SPF.

Ad esempio, un server con indirizzo IP ‘234.213.42.2’ ha inviato un’e-mail da ‘home@apple.com’. Durante il controllo SPF, il server in entrata chiederà al dominio ‘apple.com’ se questo indirizzo IP è autorizzato a inviare l’e-mail. In caso affermativo “benvenuto” e il messaggio passa, in caso contrario il messaggio verrà smistato in base al meccanismo specificato nel record SPF.

Sintassi del record SPF

Per prima cosa, analizziamo un semplice esempio di record SPF.

"v=spf1 +a +mx redirect=esempio.com -all"

v = spf1 è il numero di versione del record corrente, mentre gli altri sono Meccanismi, Qualificatori e Modificatori per specificare le diverse regole del controllo SPF. Ecco cosa puoi impostare nel tuo record SPF.

QualificatoScopoImplementazione
+Accetta. L’host è autorizzato a inviare un messaggio+
Rifiuta. L’host non è autorizzato a inviare un messaggio
~Accetta ma segna. L’host non è autorizzato a inviare un messaggio ma è in transizione (il meccanismo è a scopo di test).~
?Accetta. La validità dell’host non è specificata?
MeccanismoScopoImplementazione
aDefinisce il record DNS A del dominio come autorizzato. Se non specificato, viene utilizzato il dominio corrente.a
a/<lunghezza del prefisso>
a:<dominio>
a:<dominio>/<lunghezza del prefisso>
tuttiDefinisce la politica per tutte le altre fontitutti
esisteControlla la validità di un record A per un dominio fornitoesiste:<dominio>
includereInclude il dominio specificato come autorizzato. Se il dominio non ha un record valido, otterrai “permerror”.include:<dominio>
ip4Definisce l’intervallo di rete IPv6. Può essere utilizzato con il prefisso, che indica la lunghezza dell’intervallo. Se non viene specificato alcun prefisso, /32 è il valore predefinito.ip4:<indirizzo IP4>
ip4:<rete IP4>/<lunghezza prefisso>
ip6Definisce l’intervallo di rete IPv6. Può essere utilizzato con il prefisso, che indica la lunghezza dell’intervallo. Se non viene specificato alcun prefisso, /128 è il valore predefinito.ip6:<indirizzo IP6>
ip6:<rete IP6>/<lunghezza prefisso>
mxDefinisce il record DNS MX del dominio come autorizzato. Cioè, il messaggio deve essere inviato da uno dei server di posta in entrata del dominio.mx
mx/<lunghezza del prefisso>
mx:<dominio>
mx:<dominio>/<lunghezza del prefisso>
ptr [deprecato]Definisce il nome host inverso e il sottodominio dell’indirizzo IP di invio.ptr
ptr:<dominio>
ModificatoreScopoImplementazione
esp.Specifica la spiegazione che un mittente vedrà se il messaggio è stato respintoexp=<dominio>
reindirizzareSostituisce il dominio con il record correnteredirect=<dominio>

Cosa devi tenere a mente:

  • La stringa di un record SPF non può superare i 255 caratteri. Usa più record se necessario.
  • Alcuni provider DNS potrebbero non richiedere di allegare i dati del record. Controlla in anticipo.
  • I record per i sottodomini dovrebbero essere denominati rispettivamente (best per best.example.com)
  • Per evitare un carico irragionevole sul DNS, il numero totale di meccanismi, compresi i modificatori, dovrebbe essere limitato a 10.

Ora mettiamo in pratica queste conoscenze.

Crea un record SPF per il tuo dominio

Fase 1 – Preparazione

  • Raccogli tutti i server di posta e gli indirizzi IP che verranno specificati come autorizzati nel record SPF

Passo 2 – Pannello di controllo DNS

  • Accedi al pannello di controllo DNS del tuo ISP e trova la sezione del record di tipo TXT.

Passo 3 – Record SPF

  • Inizia con il tag version: v=spf1. Le versioni successive saranno v=spf2, v=spf3, ecc.
  • Inserisci tutti gli indirizzi IP che hai raccolto per specificarli come autorizzati:

ip4:35.167.41.421 ip6:2a13:c025:e4:7a01:bc72:dcb5:7a13

  • Aggiungi il tag include per ogni servizio e-mail di terze parti per designarlo come mittente affidabile:

include:sendgrid.net o include:mandrillapp.com

  • Sfrutta altri meccanismi, qualificatori o modificatori per impostare il record SPF.
  • Il tag all viene solitamente utilizzato per finalizzare il record.
    • -all – tutti i server non specificati non sono autorizzati (le e-mail saranno rifiutate).
    • ~all – tutti i server non specificati non sono autorizzati, ma le e-mail saranno contrassegnate e accettate.
    • +all – qualsiasi server è autorizzato (opzione piuttosto indesiderata).

Ecco come si presenta il record SPF più comune:

"v=spf1 a mx -all"

Qui, tutti i record A e MX di questo dominio sono autorizzati a inviare e-mail. Le e-mail provenienti da qualsiasi altro record verranno rifiutate.

Record SPF per più domini

Supponiamo che tu abbia un dominio primario – alpha.net con un record come questo v=spf1 a mx -all. e che tu debba creare un record SPF per più domini come beta.net e gamma.net?

Il meccanismo “include” ti permette di designare altri domini indipendenti da quello principale. Ad esempio, alpha.net potrebbe inviare la posta utilizzando beta.net e gamma.net.

v=spf1 include:beta.net include:gamma.net -all

Inoltre, puoi puntare al tuo dominio principale aggiungendo include:alpha.net nei record SPF dei tuoi domini secondari:

v=spf1 include:primary-domain.com -all

In questo modo si applicheranno le regole del dominio primario a quelli secondari.

Tieni presente che non puoi avere più di un record TXT per SPF per un dominio.\

Posso dividere un record SPF di grandi dimensioni?

E se il tuo record SPF avesse questo aspetto?

v=spf1 a mx a:mail.alpha.com a:first.alpha.net a:second.alpha.org mx:third.domain.net ip4:34.243.61.237 ip6:2a05:d018:e3:8c00:bb71:dea8:8b83:851e include:sendgrid.net include:mandrill.com -all

Corrisponde al requisito di 255 caratteri per stringa, ma è comunque molto lungo. Per questo motivo, puoi dividerlo in diversi record che saranno inclusi nel record SPF principale. Ecco come potrebbe andare:

  • Per prima cosa, crea dei record separati. I loro nomi dovrebbero riferirsi al dominio corrente in questo modo:

spf1.alpha.com TXT

v=spf1 a mx a:mail.alpha.com a:first.alpha.net a:second.alpha.org mx:third.domain.net -all

spf2.alpha.com TXT

v=spf1 ip4:34.243.61.237 ip6:2a05:d018:e3:8c00:bb71:dea8:8b83:851e -all

spf3.alpha.com TXT

v=spf1 include:sendgrid.net include:mandrill.com -all

  • Ora, puoi modificare il tuo record SPF iniziale in questo modo:

alpha.com TXT

v=spf1 include:spf1.alpha.com include:spf2.alpha.com include:spf3.alpha.com -all

Tutto qui. Tutti questi record verranno visti come un unico record dopo l’aggiornamento del DNS.

Verifica che il tuo record SPF si corretto

L’ultima cosa che ti consigliamo di fare è di verificare che il tuo record SPF sia corretto. Fortunatamente, esistono molti strumenti utili come SPF Record Check o SPF Syntax Validator. In questo modo potrai trovare e risolvere eventuali problemi del tuo record e essere sicuro che tutto funzioni.

Come creare un record SPF utilizzando il mio provider DNS?

Puoi creare e gestire i tuoi record SPF utilizzando la console o il pannello di controllo del tuo provider DNS. Alcuni servizi forniscono istruzioni o guide dettagliate su come creare i record TXT. Di seguito troverai i link alle guide di alcuni dei migliori provider.

Inoltre, abbiamo raccolto un elenco di specifiche SPF per i provider di posta elettronica più diffusi, in modo che tu possa copiarle e incollarle nel tuo record TXT.

Provider di servizi e-mailRecord SPF
Gmailv=spf1 include:_spf.google.com ~all
Sendgridv=spf1 include:sendgrid.net ~all
MailChimpv=spf1 include:servers.mcsv.net ?all
Mandrillv=spf1 include:spf.mandrillapp.com ?all
Pistola postalev=spf1 include:mailgun.org ~all

Dai un’occhiata a Mailtrap Email API se cerchi una soluzione che abbia un processo di configurazione semplice e che ti aiuti a monitorare la tua deliverability attraverso una dashboard con preziose informazioni, che ti fornisca un indirizzo IP dedicato e il suo riscaldamento automatico.

Record SPF: v=spf1 include:_spf.smtp.mailtrap.live -all

Leggi la nostra guida per istruzioni passo-passo su come configurare E-mail API.

Risoluzione dei problemi SPF: Il record SPF non viene convalidato

Ecco un breve elenco di problemi comuni (e relative soluzioni di base) che si possono incontrare quando si cerca di convalidare i record SPF.

  • Superamento del limite di ricerche DNS. Tieni presente che ci sono solo 10 query DNS. Il problema più comune è l’utilizzo di molti “include” nei record. Esistono diverse soluzioni a questo problema, la più popolare delle quali è la creazione di un sottodominio dedicato alle e-mail (es: mail.tuodominio.com). In primo luogo, puoi creare un nuovo record SPF per il sottodominio. In secondo luogo, quando un verificatore esegue un controllo SPF, guarda solo il dominio come estratto dalla RFC 5321 Mail From. Ciò significa che esamina direttamente il record DNS di un dominio figlio, non di un dominio genitore. Se hai bisogno di altri modi per risolvere il problema della rottura del limite di 10 ricerche DNS, consulta la guida dettagliata di DMARCian.
  • Deprecazione del tipo 99 (record di tipo SPF). Ciò significa che il tuo record SPF non è più aggiornato. Nel 2014 è terminata la fase sperimentale dell’utilizzo dei record DNS di tipo RR. Ora i record SPF devono essere pubblicati solo come DNS TXT (tipo 16). Per risolvere i problemi di “Tipo 99”, assicurati di utilizzare record DNS di tipo TXT per l’autenticazione SPF.
  • Record SPF multipli. Se utilizzi un grande provider di posta elettronica come Microsoft Exchange o Gmail, il problema dei record SPF duplicati dovrebbe essere corretto automaticamente. I provider di posta elettronica più piccoli di solito non offrono funzioni così intelligenti; quindi, è probabile che tu debba occuparti di questo problema da solo. La soluzione migliore è quella di unire entrambe le voci DNS TXT in una versione consolidata. Per maggiori informazioni su come affrontare questo problema, consulta la nostra sezione SPF da fare e da non fare.

Una volta impostato il tuo record SPF, puoi procedere con i protocolli DKIM e DMARC per rendere la tua sicurezza e le tue campagne di marketing superiori al resto.

Article by Zakhar Yung Technical Content Writer @Mailtrap