Autenticazione SPF: Una panoramica e migliori pratiche
Uccello
19 dic 2016
1 min read
Punti Chiave
SPF (Sender Policy Framework) è un protocollo di autenticazione delle email basato su percorso che verifica se il server di invio è autorizzato a inviare email per un dominio.
Le politiche SPF si trovano come record TXT DNS, formattati con meccanismi che definiscono quali server, IP o reti sono autorizzati a inviare per conto di un dominio.
La convalida SPF è legata al dominio Return-Path (dominio di rimbalzo) o al nome host HELO—non all'indirizzo From visibile.
Poiché SPF controlla solo il percorso di invio, può essere convalidato presto nella transazione SMTP, rendendolo utile per rifiutare rapidamente le email non autorizzate.
SPF è efficace ma non perfetto—è soggetto a falsi negativi, specialmente con l'inoltro di email e le mailing list.
I record SPF si basano su meccanismi come
mx,a,ipv4,ipv6,include,redirect,exists, e devono terminare con un modificatoreall(-all,~all,?all,+all).Si applicano limiti alle ricerche DNS: la valutazione SPF non può superare 10 query DNS, rendendo importante la pianificazione dei record.
Il meccanismo
ptrè ora considerato “non usare”, ma i validatori devono ancora accettarlo. Alcuni mittenti lo usano ancora a causa di lacune di compatibilità.SPF da solo non garantisce che un'email sia legittima—solo che è stata inviata da un server autorizzato. Funziona meglio quando combinato con DKIM, DMARC, e altre tecniche anti-frode.
Punti salienti del Q&A
Cos'è la SPF in termini semplici?
SPF consente a un dominio di dichiarare quali server sono autorizzati a inviargli email per conto suo. I server di ricezione controllano questo per rilevare mittenti non autorizzati.
Perché si chiama SPF "basato su percorso"?
Perché l'SPF convalida il percorso che il messaggio ha seguito—specificamente, l'IP del server di invio—anziché qualsiasi cosa nel contenuto del messaggio.
Dove viene memorizzata una politica SPF?
A: Come un record TXT DNS, che inizia con
v=spf1, seguito da meccanismi che definiscono i mittenti consentiti.Quale dominio convalida SPF?
Il Return-Path (chiamato anche dominio di rimbalzo).
Se il Return-Path è vuoto (mittente NULL), i controlli SPF vengono eseguiti sul dominio HELO invece.
È possibile controllare la SPF all'inizio della transazione SMTP?
Sì. Perché dipende solo dall'indirizzo IP e dal dominio del server mittente, l'SPF può essere convalidato prima di ricevere il corpo del messaggio, rendendolo efficiente per il filtraggio.
Perché a volte il SPF non funziona anche per le email legittime?
Le cause comuni includono:
Inoltro email (l'inoltro non è nel record SPF del dominio originale)
Liste di distribuzione (i messaggi vengono reinviati da un server diverso)
Questo porta a falsi negativi, che sono intrinsecamente legati all'autenticazione basata su percorso.
Qual è il ruolo di meccanismi come include, redirect ed exists?
include— autorizza il record SPF di un altro dominio (ad esempio, il tuo ESP)redirect— riutilizza la politica SPF di un altro dominioexists— autorizza dinamicamente in base a una ricerca DNS (utile per infrastrutture complesse)
Come funzionano i modificatori "tutti"?
-all→ rifiuta tutto ciò che non è elencato (rigido)~all→ softfail (accetta ma segna)?all → neutrale+all→ passa tutto (disabilita effettivamente SPF)
Perché il meccanismo ptr è sconsigliato?
È lento, inaffidabile e deprecato nelle specifiche moderne, ma i validatori SPF devono ancora supportarlo.
È sufficiente il SPF da solo per l'autenticazione dell'email?
No. SPF verifica l'infrastruttura di invio, ma:
Non protegge l'integrità del messaggio
Non si allinea con i domini visibili del mittente
Interferisce con l'inoltro
SPF è più efficace quando abbinato a DKIM e DMARC.
Prima di immergersi nell'implementazione tecnica, vale la pena comprendere l'evoluzione e la varietà delle tecniche di convalida delle email disponibili. Dalla semplice verifica della sintassi agli approcci moderni basati sui dati, diversi metodi di convalida offrono livelli variabili di accuratezza e affidabilità.
Quando parliamo di “Autenticazione Email”, ci riferiamo a una tecnica che intende fornire al destinatario di un messaggio un certo livello di certezza che il messaggio sia effettivamente originato dalla fonte dichiarata del messaggio. L'idea è di ottenere un certo livello di difesa contro le email fraudolente, come il phishing e lo spoofing, che potrebbero erodere la fiducia di un destinatario nel ricevere email. Per le organizzazioni che richiedono la crittografia a livello di messaggio oltre all'autenticazione, S/MIME fornisce sicurezza end-to-end, con la raccolta automatizzata delle chiavi pubbliche dei destinatari che rende l'implementazione più scalabile. Detto ciò, l'atto di inviare email autenticate non implica, di per sé, che l'email sia buona o desiderata; significa solo che la posta è tale da poter stabilire e utilizzare in modo affidabile una reputazione per la parte autenticata nelle decisioni di accettazione e posizionamento delle email.
Ci sono due forme principali di autenticazione email in uso oggi—Sender Policy Framework (SPF) e DomainKeys Identified Mail (DKIM). In questo post del blog, spiegherò cos'è l'SPF e come funziona.
Prima di immergersi nell'implementazione tecnica, vale la pena comprendere l'evoluzione e la varietà delle tecniche di convalida delle email disponibili. Dalla semplice verifica della sintassi agli approcci moderni basati sui dati, diversi metodi di convalida offrono livelli variabili di accuratezza e affidabilità.
Quando parliamo di “Autenticazione Email”, ci riferiamo a una tecnica che intende fornire al destinatario di un messaggio un certo livello di certezza che il messaggio sia effettivamente originato dalla fonte dichiarata del messaggio. L'idea è di ottenere un certo livello di difesa contro le email fraudolente, come il phishing e lo spoofing, che potrebbero erodere la fiducia di un destinatario nel ricevere email. Per le organizzazioni che richiedono la crittografia a livello di messaggio oltre all'autenticazione, S/MIME fornisce sicurezza end-to-end, con la raccolta automatizzata delle chiavi pubbliche dei destinatari che rende l'implementazione più scalabile. Detto ciò, l'atto di inviare email autenticate non implica, di per sé, che l'email sia buona o desiderata; significa solo che la posta è tale da poter stabilire e utilizzare in modo affidabile una reputazione per la parte autenticata nelle decisioni di accettazione e posizionamento delle email.
Ci sono due forme principali di autenticazione email in uso oggi—Sender Policy Framework (SPF) e DomainKeys Identified Mail (DKIM). In questo post del blog, spiegherò cos'è l'SPF e come funziona.
Prima di immergersi nell'implementazione tecnica, vale la pena comprendere l'evoluzione e la varietà delle tecniche di convalida delle email disponibili. Dalla semplice verifica della sintassi agli approcci moderni basati sui dati, diversi metodi di convalida offrono livelli variabili di accuratezza e affidabilità.
Quando parliamo di “Autenticazione Email”, ci riferiamo a una tecnica che intende fornire al destinatario di un messaggio un certo livello di certezza che il messaggio sia effettivamente originato dalla fonte dichiarata del messaggio. L'idea è di ottenere un certo livello di difesa contro le email fraudolente, come il phishing e lo spoofing, che potrebbero erodere la fiducia di un destinatario nel ricevere email. Per le organizzazioni che richiedono la crittografia a livello di messaggio oltre all'autenticazione, S/MIME fornisce sicurezza end-to-end, con la raccolta automatizzata delle chiavi pubbliche dei destinatari che rende l'implementazione più scalabile. Detto ciò, l'atto di inviare email autenticate non implica, di per sé, che l'email sia buona o desiderata; significa solo che la posta è tale da poter stabilire e utilizzare in modo affidabile una reputazione per la parte autenticata nelle decisioni di accettazione e posizionamento delle email.
Ci sono due forme principali di autenticazione email in uso oggi—Sender Policy Framework (SPF) e DomainKeys Identified Mail (DKIM). In questo post del blog, spiegherò cos'è l'SPF e come funziona.
La protezione SPF non è infallibile
Sebbene sembri un modo relativamente semplice per autenticare le email, l'SPF è vulnerabile a fallimenti sotto forma di falsi negativi. Questi fallimenti possono verificarsi più frequentemente di quanto molti siano disposti ad accettare.
Qui ci sono due scenari comuni in cui email perfettamente legittime possono fallire la convalida SPF e quindi apparire fraudolente:
Inoltro automatico, dove un messaggio inviato a jsmith@alumni.university.edu, una casella di posta impostata per inoltrare automaticamente tutte le email a jsmith@isp.com
Liste di distribuzione, dove le email inviate a talk-about-stuff@listserv.foo.com vengono “esplose” e inviate a ciascun abbonato
In entrambi questi casi, se il Return-Path non viene modificato rispetto all'originale, l'email potrebbe fallire i controlli SPF (a seconda del modificatore utilizzato con il meccanismo ‘all’). Ciò accade perché arriva alla sua destinazione finale da un server intermedio, non da quello originale, e quel server intermedio è poco probabile che si trovi nel record SPF del dominio. Una tecnica chiamata “Sender Rewriting Scheme” o “SRS” può mitigare questo rischio, e alcuni siti più grandi l'hanno adottata, ma non è universale.
Sebbene sembri un modo relativamente semplice per autenticare le email, l'SPF è vulnerabile a fallimenti sotto forma di falsi negativi. Questi fallimenti possono verificarsi più frequentemente di quanto molti siano disposti ad accettare.
Qui ci sono due scenari comuni in cui email perfettamente legittime possono fallire la convalida SPF e quindi apparire fraudolente:
Inoltro automatico, dove un messaggio inviato a jsmith@alumni.university.edu, una casella di posta impostata per inoltrare automaticamente tutte le email a jsmith@isp.com
Liste di distribuzione, dove le email inviate a talk-about-stuff@listserv.foo.com vengono “esplose” e inviate a ciascun abbonato
In entrambi questi casi, se il Return-Path non viene modificato rispetto all'originale, l'email potrebbe fallire i controlli SPF (a seconda del modificatore utilizzato con il meccanismo ‘all’). Ciò accade perché arriva alla sua destinazione finale da un server intermedio, non da quello originale, e quel server intermedio è poco probabile che si trovi nel record SPF del dominio. Una tecnica chiamata “Sender Rewriting Scheme” o “SRS” può mitigare questo rischio, e alcuni siti più grandi l'hanno adottata, ma non è universale.
Sebbene sembri un modo relativamente semplice per autenticare le email, l'SPF è vulnerabile a fallimenti sotto forma di falsi negativi. Questi fallimenti possono verificarsi più frequentemente di quanto molti siano disposti ad accettare.
Qui ci sono due scenari comuni in cui email perfettamente legittime possono fallire la convalida SPF e quindi apparire fraudolente:
Inoltro automatico, dove un messaggio inviato a jsmith@alumni.university.edu, una casella di posta impostata per inoltrare automaticamente tutte le email a jsmith@isp.com
Liste di distribuzione, dove le email inviate a talk-about-stuff@listserv.foo.com vengono “esplose” e inviate a ciascun abbonato
In entrambi questi casi, se il Return-Path non viene modificato rispetto all'originale, l'email potrebbe fallire i controlli SPF (a seconda del modificatore utilizzato con il meccanismo ‘all’). Ciò accade perché arriva alla sua destinazione finale da un server intermedio, non da quello originale, e quel server intermedio è poco probabile che si trovi nel record SPF del dominio. Una tecnica chiamata “Sender Rewriting Scheme” o “SRS” può mitigare questo rischio, e alcuni siti più grandi l'hanno adottata, ma non è universale.
Panoramica SPF
Il Sender Policy Framework (SPF), per parafrasare RFC 7208, è un protocollo che non solo consente a un'organizzazione di autorizzare host e reti a utilizzare i propri nomi di dominio quando inviano email, ma fornisce anche un modo affinché un host ricevente possa controllare tale autorizzazione.
Quando avrai finito di leggere questo post, spero che tu abbia appreso quanto segue:
SPF è un sistema di autenticazione “basato sul percorso”.
Le politiche SPF sono dichiarate nei record TXT di DNS.
La convalida è collegata al dominio Return-Path (quello che qui in SparkPost chiamiamo il “dominio di rimbalzo”) o al dominio HELO.
La convalida può essere effettuata precocemente nella transazione SMTP, quindi è un buon controllo da utilizzare per rifiutare rapidamente le email non autenticate.
È soggetta a una percentuale relativamente alta di falsi negativi.
Il Sender Policy Framework (SPF), per parafrasare RFC 7208, è un protocollo che non solo consente a un'organizzazione di autorizzare host e reti a utilizzare i propri nomi di dominio quando inviano email, ma fornisce anche un modo affinché un host ricevente possa controllare tale autorizzazione.
Quando avrai finito di leggere questo post, spero che tu abbia appreso quanto segue:
SPF è un sistema di autenticazione “basato sul percorso”.
Le politiche SPF sono dichiarate nei record TXT di DNS.
La convalida è collegata al dominio Return-Path (quello che qui in SparkPost chiamiamo il “dominio di rimbalzo”) o al dominio HELO.
La convalida può essere effettuata precocemente nella transazione SMTP, quindi è un buon controllo da utilizzare per rifiutare rapidamente le email non autenticate.
È soggetta a una percentuale relativamente alta di falsi negativi.
Il Sender Policy Framework (SPF), per parafrasare RFC 7208, è un protocollo che non solo consente a un'organizzazione di autorizzare host e reti a utilizzare i propri nomi di dominio quando inviano email, ma fornisce anche un modo affinché un host ricevente possa controllare tale autorizzazione.
Quando avrai finito di leggere questo post, spero che tu abbia appreso quanto segue:
SPF è un sistema di autenticazione “basato sul percorso”.
Le politiche SPF sono dichiarate nei record TXT di DNS.
La convalida è collegata al dominio Return-Path (quello che qui in SparkPost chiamiamo il “dominio di rimbalzo”) o al dominio HELO.
La convalida può essere effettuata precocemente nella transazione SMTP, quindi è un buon controllo da utilizzare per rifiutare rapidamente le email non autenticate.
È soggetta a una percentuale relativamente alta di falsi negativi.
Autenticazione “Basata su Percorso”
SPF è considerato un sistema di autenticazione basato su percorsi perché è legato esclusivamente al percorso che il messaggio ha seguito per arrivare dalla sua origine alla sua destinazione. Quando un server di invio avvia una transazione SMTP con un server di ricezione, il server di ricezione determinerà se il server di invio è autorizzato o meno a inviare quel messaggio in base alla politica SPF del dominio. È esclusivamente una decisione basata su dove proviene il messaggio, senza alcun legame con il contenuto del messaggio.
SPF è considerato un sistema di autenticazione basato su percorsi perché è legato esclusivamente al percorso che il messaggio ha seguito per arrivare dalla sua origine alla sua destinazione. Quando un server di invio avvia una transazione SMTP con un server di ricezione, il server di ricezione determinerà se il server di invio è autorizzato o meno a inviare quel messaggio in base alla politica SPF del dominio. È esclusivamente una decisione basata su dove proviene il messaggio, senza alcun legame con il contenuto del messaggio.
SPF è considerato un sistema di autenticazione basato su percorsi perché è legato esclusivamente al percorso che il messaggio ha seguito per arrivare dalla sua origine alla sua destinazione. Quando un server di invio avvia una transazione SMTP con un server di ricezione, il server di ricezione determinerà se il server di invio è autorizzato o meno a inviare quel messaggio in base alla politica SPF del dominio. È esclusivamente una decisione basata su dove proviene il messaggio, senza alcun legame con il contenuto del messaggio.
Dichiarare una politica SPF
Il record della politica SPF di un dominio è semplicemente un record DNS TXT formattato in modo specifico, che comunemente contiene uno o più dei seguenti “meccanismi”:
v=spf1 – Token richiesto per indicare che il record TXT è un record SPF (un dominio può avere più record TXT)
ipv4, ipv6 – Utilizzato per specificare indirizzi IP e reti autorizzati a inviare posta per il dominio
a – Se il dominio mittente ha un record DNS “A” che risolve all'IP di invio, l'IP è autorizzato
mx – Se l'IP di invio è anche uno dei record MX per il dominio mittente, l'IP è autorizzato
all – Token finale richiesto, sempre modificato:
-all – Solo ciò che è elencato qui può passare; rifiuta i fallimenti.
~all – Le cose che non sono qui dovrebbero fallire dolcemente; accettale ma annotale.
?all – Non sono sicuro se le cose che non sono qui dovrebbero passare.
+all – Pensiamo che SPF sia inutile; accetta tutto.
Altri meccanismi meno comuni che sono comunque in uso diffuso sono:
include – Utilizzato quando un dominio non ha solo i propri server, ma utilizza anche i server di qualcun altro. Deve essere usato con cautela. Ogni inclusione è un'altra query DNS, e i record SPF non possono richiedere più di dieci query DNS per risolversi.
redirect – Quando il dominio A e il dominio B sono di proprietà della stessa entità e utilizzano la stessa infrastruttura. I proprietari solitamente vogliono mantenere una sola copia del record SPF per entrambi e configurare B per reindirizzare le query ad A.
exists – Se un dominio ha molti blocchi di rete non contigui e piccoli, può utilizzare questo meccanismo per specificare il proprio record SPF, invece di elencarli tutti. Utile per rimanere all'interno del limite di dimensione (512 byte) per la risposta DNS.
Una nota sul meccanismo “ptr”
Un ultimo meccanismo, “ptr” esisteva nella specifica originale per SPF, ma è stato dichiarato “non usare” nella specifica attuale. Il meccanismo ptr veniva utilizzato per dichiarare che se l'indirizzo IP di invio aveva un record PTR DNS che risolveva nel nome di dominio in questione, allora quell'indirizzo IP era autorizzato a inviare posta per il dominio.
Lo stato attuale di questo meccanismo è che non dovrebbe essere utilizzato. Tuttavia, i siti che effettuano la convalida SPF devono accettarlo come valido.
Meccanismo | Cosa Fa | Note / Indicazioni per l'uso |
|---|---|---|
v=spf1 | Dichiara che il record TXT è una politica SPF | Token primo richiesto |
ipv4 / ipv6 | Autorizza IP o blocchi CIDR specifici | Metodo di autorizzazione più esplicito e affidabile |
a | Autorizza gli IP che corrispondono al record A del dominio | Buono per infrastrutture semplici |
mx | Autorizza gli IP elencati nei record MX del dominio | Utile quando i server MX inviano anche posta |
include | Importa la politica SPF di un altro dominio | Contribuisce al limite di 10-lookup DNS; usare con parsimonia |
redirect | Delega la politica SPF a un altro dominio | Utilizzato quando più domini condividono una definizione SPF |
exists | Autorizza tramite una regola di lookup DNS personalizzata | Utile per ampie gamme IP frammentate; il validatore deve supportarlo |
ptr | Autorizza in base alla mappatura DNS inversa | Obsoleto (“non usare”) ma deve comunque essere rispettato dai validatori |
all | Definisce come trattare tutto ciò che non è esplicitamente consentito | Varianti: -all rifiuta, ~all softfail, ?all neutro, +all consenti tutti (non raccomandato) |
Il record della politica SPF di un dominio è semplicemente un record DNS TXT formattato in modo specifico, che comunemente contiene uno o più dei seguenti “meccanismi”:
v=spf1 – Token richiesto per indicare che il record TXT è un record SPF (un dominio può avere più record TXT)
ipv4, ipv6 – Utilizzato per specificare indirizzi IP e reti autorizzati a inviare posta per il dominio
a – Se il dominio mittente ha un record DNS “A” che risolve all'IP di invio, l'IP è autorizzato
mx – Se l'IP di invio è anche uno dei record MX per il dominio mittente, l'IP è autorizzato
all – Token finale richiesto, sempre modificato:
-all – Solo ciò che è elencato qui può passare; rifiuta i fallimenti.
~all – Le cose che non sono qui dovrebbero fallire dolcemente; accettale ma annotale.
?all – Non sono sicuro se le cose che non sono qui dovrebbero passare.
+all – Pensiamo che SPF sia inutile; accetta tutto.
Altri meccanismi meno comuni che sono comunque in uso diffuso sono:
include – Utilizzato quando un dominio non ha solo i propri server, ma utilizza anche i server di qualcun altro. Deve essere usato con cautela. Ogni inclusione è un'altra query DNS, e i record SPF non possono richiedere più di dieci query DNS per risolversi.
redirect – Quando il dominio A e il dominio B sono di proprietà della stessa entità e utilizzano la stessa infrastruttura. I proprietari solitamente vogliono mantenere una sola copia del record SPF per entrambi e configurare B per reindirizzare le query ad A.
exists – Se un dominio ha molti blocchi di rete non contigui e piccoli, può utilizzare questo meccanismo per specificare il proprio record SPF, invece di elencarli tutti. Utile per rimanere all'interno del limite di dimensione (512 byte) per la risposta DNS.
Una nota sul meccanismo “ptr”
Un ultimo meccanismo, “ptr” esisteva nella specifica originale per SPF, ma è stato dichiarato “non usare” nella specifica attuale. Il meccanismo ptr veniva utilizzato per dichiarare che se l'indirizzo IP di invio aveva un record PTR DNS che risolveva nel nome di dominio in questione, allora quell'indirizzo IP era autorizzato a inviare posta per il dominio.
Lo stato attuale di questo meccanismo è che non dovrebbe essere utilizzato. Tuttavia, i siti che effettuano la convalida SPF devono accettarlo come valido.
Meccanismo | Cosa Fa | Note / Indicazioni per l'uso |
|---|---|---|
v=spf1 | Dichiara che il record TXT è una politica SPF | Token primo richiesto |
ipv4 / ipv6 | Autorizza IP o blocchi CIDR specifici | Metodo di autorizzazione più esplicito e affidabile |
a | Autorizza gli IP che corrispondono al record A del dominio | Buono per infrastrutture semplici |
mx | Autorizza gli IP elencati nei record MX del dominio | Utile quando i server MX inviano anche posta |
include | Importa la politica SPF di un altro dominio | Contribuisce al limite di 10-lookup DNS; usare con parsimonia |
redirect | Delega la politica SPF a un altro dominio | Utilizzato quando più domini condividono una definizione SPF |
exists | Autorizza tramite una regola di lookup DNS personalizzata | Utile per ampie gamme IP frammentate; il validatore deve supportarlo |
ptr | Autorizza in base alla mappatura DNS inversa | Obsoleto (“non usare”) ma deve comunque essere rispettato dai validatori |
all | Definisce come trattare tutto ciò che non è esplicitamente consentito | Varianti: -all rifiuta, ~all softfail, ?all neutro, +all consenti tutti (non raccomandato) |
Il record della politica SPF di un dominio è semplicemente un record DNS TXT formattato in modo specifico, che comunemente contiene uno o più dei seguenti “meccanismi”:
v=spf1 – Token richiesto per indicare che il record TXT è un record SPF (un dominio può avere più record TXT)
ipv4, ipv6 – Utilizzato per specificare indirizzi IP e reti autorizzati a inviare posta per il dominio
a – Se il dominio mittente ha un record DNS “A” che risolve all'IP di invio, l'IP è autorizzato
mx – Se l'IP di invio è anche uno dei record MX per il dominio mittente, l'IP è autorizzato
all – Token finale richiesto, sempre modificato:
-all – Solo ciò che è elencato qui può passare; rifiuta i fallimenti.
~all – Le cose che non sono qui dovrebbero fallire dolcemente; accettale ma annotale.
?all – Non sono sicuro se le cose che non sono qui dovrebbero passare.
+all – Pensiamo che SPF sia inutile; accetta tutto.
Altri meccanismi meno comuni che sono comunque in uso diffuso sono:
include – Utilizzato quando un dominio non ha solo i propri server, ma utilizza anche i server di qualcun altro. Deve essere usato con cautela. Ogni inclusione è un'altra query DNS, e i record SPF non possono richiedere più di dieci query DNS per risolversi.
redirect – Quando il dominio A e il dominio B sono di proprietà della stessa entità e utilizzano la stessa infrastruttura. I proprietari solitamente vogliono mantenere una sola copia del record SPF per entrambi e configurare B per reindirizzare le query ad A.
exists – Se un dominio ha molti blocchi di rete non contigui e piccoli, può utilizzare questo meccanismo per specificare il proprio record SPF, invece di elencarli tutti. Utile per rimanere all'interno del limite di dimensione (512 byte) per la risposta DNS.
Una nota sul meccanismo “ptr”
Un ultimo meccanismo, “ptr” esisteva nella specifica originale per SPF, ma è stato dichiarato “non usare” nella specifica attuale. Il meccanismo ptr veniva utilizzato per dichiarare che se l'indirizzo IP di invio aveva un record PTR DNS che risolveva nel nome di dominio in questione, allora quell'indirizzo IP era autorizzato a inviare posta per il dominio.
Lo stato attuale di questo meccanismo è che non dovrebbe essere utilizzato. Tuttavia, i siti che effettuano la convalida SPF devono accettarlo come valido.
Meccanismo | Cosa Fa | Note / Indicazioni per l'uso |
|---|---|---|
v=spf1 | Dichiara che il record TXT è una politica SPF | Token primo richiesto |
ipv4 / ipv6 | Autorizza IP o blocchi CIDR specifici | Metodo di autorizzazione più esplicito e affidabile |
a | Autorizza gli IP che corrispondono al record A del dominio | Buono per infrastrutture semplici |
mx | Autorizza gli IP elencati nei record MX del dominio | Utile quando i server MX inviano anche posta |
include | Importa la politica SPF di un altro dominio | Contribuisce al limite di 10-lookup DNS; usare con parsimonia |
redirect | Delega la politica SPF a un altro dominio | Utilizzato quando più domini condividono una definizione SPF |
exists | Autorizza tramite una regola di lookup DNS personalizzata | Utile per ampie gamme IP frammentate; il validatore deve supportarlo |
ptr | Autorizza in base alla mappatura DNS inversa | Obsoleto (“non usare”) ma deve comunque essere rispettato dai validatori |
all | Definisce come trattare tutto ciò che non è esplicitamente consentito | Varianti: -all rifiuta, ~all softfail, ?all neutro, +all consenti tutti (non raccomandato) |
Alcuni esempi di record SPF
Qui ci sono alcuni record di esempio e i loro significati. Questo esempio mostra gli indirizzi RFC 1918, ma riconosco che tali indirizzi non appariranno mai in veri record SPF.
Record MX, un indirizzo IP, una rete IP, softfail tutto il resto:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Record A, due reti IP, rifiuta tutto il resto:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Non inviamo posta:
“v=spf1 -all”
Riteniamo che SPF sia stupido:
“v=spf1 +all”
Il record SPF per il dominio sparkpostmail.com (meccanismo di reindirizzamento utilizzato)
“v=spf1 redirect=_spf.sparkpostmail.com”
Il record SPF per _spf.sparkpostmail.com (meccanismi esistenti e ptr utilizzati):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
In SparkPost, attualmente stiamo utilizzando il meccanismo ptr nel nostro record SPF. Abbiamo trovato necessario farlo a causa della mancanza di supporto universale per la validazione del meccanismo exists. E fino ad oggi, non abbiamo visto alcun fallimento SPF a causa dell'uso del meccanismo ptr.
Qui ci sono alcuni record di esempio e i loro significati. Questo esempio mostra gli indirizzi RFC 1918, ma riconosco che tali indirizzi non appariranno mai in veri record SPF.
Record MX, un indirizzo IP, una rete IP, softfail tutto il resto:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Record A, due reti IP, rifiuta tutto il resto:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Non inviamo posta:
“v=spf1 -all”
Riteniamo che SPF sia stupido:
“v=spf1 +all”
Il record SPF per il dominio sparkpostmail.com (meccanismo di reindirizzamento utilizzato)
“v=spf1 redirect=_spf.sparkpostmail.com”
Il record SPF per _spf.sparkpostmail.com (meccanismi esistenti e ptr utilizzati):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
In SparkPost, attualmente stiamo utilizzando il meccanismo ptr nel nostro record SPF. Abbiamo trovato necessario farlo a causa della mancanza di supporto universale per la validazione del meccanismo exists. E fino ad oggi, non abbiamo visto alcun fallimento SPF a causa dell'uso del meccanismo ptr.
Qui ci sono alcuni record di esempio e i loro significati. Questo esempio mostra gli indirizzi RFC 1918, ma riconosco che tali indirizzi non appariranno mai in veri record SPF.
Record MX, un indirizzo IP, una rete IP, softfail tutto il resto:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Record A, due reti IP, rifiuta tutto il resto:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Non inviamo posta:
“v=spf1 -all”
Riteniamo che SPF sia stupido:
“v=spf1 +all”
Il record SPF per il dominio sparkpostmail.com (meccanismo di reindirizzamento utilizzato)
“v=spf1 redirect=_spf.sparkpostmail.com”
Il record SPF per _spf.sparkpostmail.com (meccanismi esistenti e ptr utilizzati):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
In SparkPost, attualmente stiamo utilizzando il meccanismo ptr nel nostro record SPF. Abbiamo trovato necessario farlo a causa della mancanza di supporto universale per la validazione del meccanismo exists. E fino ad oggi, non abbiamo visto alcun fallimento SPF a causa dell'uso del meccanismo ptr.
Come Funziona l'Autenticazione SPF?
Ecco come appare una tipica transazione SMTP quando è coinvolto SPF:
Il server di invio (client) si connette al server di ricezione
Il server di ricezione prende nota dell'indirizzo IP del client che si connette
Si scambiano saluti, incluso il nome host HELO del client
Il client emette il comando SMTP MAIL FROM
Il server di ricezione può ora cercare il record SPF per il dominio MAIL FROM o il nome host HELO per determinare se l'indirizzo IP che si connette è autorizzato a inviare mail per il dominio e decidere se accettare o meno il messaggio.
Ecco come appare una tipica transazione SMTP quando è coinvolto SPF:
Il server di invio (client) si connette al server di ricezione
Il server di ricezione prende nota dell'indirizzo IP del client che si connette
Si scambiano saluti, incluso il nome host HELO del client
Il client emette il comando SMTP MAIL FROM
Il server di ricezione può ora cercare il record SPF per il dominio MAIL FROM o il nome host HELO per determinare se l'indirizzo IP che si connette è autorizzato a inviare mail per il dominio e decidere se accettare o meno il messaggio.
Ecco come appare una tipica transazione SMTP quando è coinvolto SPF:
Il server di invio (client) si connette al server di ricezione
Il server di ricezione prende nota dell'indirizzo IP del client che si connette
Si scambiano saluti, incluso il nome host HELO del client
Il client emette il comando SMTP MAIL FROM
Il server di ricezione può ora cercare il record SPF per il dominio MAIL FROM o il nome host HELO per determinare se l'indirizzo IP che si connette è autorizzato a inviare mail per il dominio e decidere se accettare o meno il messaggio.
MAIL DA o HELO – Quale controllare?
La specifica SPF stabilisce che i siti riceventi DEVONO controllare SPF per il dominio MAIL FROM e si RACCOMANDA di controllarlo per il nome host HELO. In pratica, il controllo avviene solo sul dominio MAIL FROM, tranne forse nei casi in cui l'indirizzo MAIL FROM è l'inviante NULL (cioè, “<>”), nel qual caso il nome host HELO è l'unica identità disponibile.
La specifica SPF stabilisce che i siti riceventi DEVONO controllare SPF per il dominio MAIL FROM e si RACCOMANDA di controllarlo per il nome host HELO. In pratica, il controllo avviene solo sul dominio MAIL FROM, tranne forse nei casi in cui l'indirizzo MAIL FROM è l'inviante NULL (cioè, “<>”), nel qual caso il nome host HELO è l'unica identità disponibile.
La specifica SPF stabilisce che i siti riceventi DEVONO controllare SPF per il dominio MAIL FROM e si RACCOMANDA di controllarlo per il nome host HELO. In pratica, il controllo avviene solo sul dominio MAIL FROM, tranne forse nei casi in cui l'indirizzo MAIL FROM è l'inviante NULL (cioè, “<>”), nel qual caso il nome host HELO è l'unica identità disponibile.
