Chiedi che cosa autorizza il tuo record SPF e ti daranno un aggettivo. Largo. Permissivo. Una superficie d’attacco più ampia. Chiedi un numero e di solito la conversazione si ferma lì.

Il numero si può ottenere. È solo più difficile da ottenere giusto di quanto sembri, e quasi tutti i modi di sbagliarlo lo fanno crescere — cioè vanno nella direzione che vende allarme.

Partiamo dall’include più diffuso che esista:

google.com        v=spf1 include:_spf.google.com ~all

_spf.google.com   v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17
                  ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56
                  ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56
                  ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all

Risolti ad agosto 2026. I fornitori cambiano i propri range senza preavviso: risolvi i tuoi, invece di fidarti di un numero stampato in un articolo — compreso questo.

La metà IPv4 è aritmetica da scuola media. Un /16 sono 2¹⁶ = 65.536 indirizzi, un /17 sono 32.768. In tutto: 98.304 indirizzi abilitati a spedire posta a nome di quel dominio.

Poi c’è la metà IPv6, ed è lì che un conteggio che sembrava facile comincia a mentire. Sei blocchi. Ci torniamo.

E quello era un record semplice: un include, due letterali IPv4, nessun meccanismo dinamico. Ecco i quattro modi in cui il conto sbaglia su tutti gli altri.

Regola 1: ip4: e ip6: non sono tutto il record

Alcuni meccanismi non contengono indirizzi. Contengono istruzioni per trovare degli indirizzi, eseguite nell’istante in cui un messaggio arriva.

_spf.salesforce.com   v=spf1 exists:%{i}._spf.mta.salesforce.com -all

Conta i meccanismi ip4: in quel record: zero. Uno strumento che conta i letterali dirà che quel fornitore non autorizza niente — un numero che non è impreciso, è rovesciato.

Quello che il record dice davvero è questo. exists: costruisce un nome di dominio a partire dall’indirizzo IP che si sta connettendo (%{i} è la macro che lo rappresenta), cerca un record A a quel nome, e autorizza il mittente se ne trova uno (RFC 7208 §5.7). L’autorizzazione è una domanda che si pone un indirizzo alla volta, e la risposta sta in una zona DNS che non hai modo di elencare. Ho provato con un indirizzo di documentazione — 192.0.2.1._spf.mta.salesforce.com risponde NXDOMAIN, quindi quello non è autorizzato — ma per ricostruire l’insieme completo bisognerebbe fare la stessa domanda 4,3 miliardi di volte.

a, mx e ptr hanno la stessa forma: si risolvono al momento della valutazione, contro record che possono cambiare da un messaggio all’altro. (ptr è un caso a parte: la §5.5 di RFC 7208 si intitola letteralmente “ptr” (do not use) e dice che il meccanismo non andrebbe pubblicato. Se ne trovi uno nel tuo record, quello è già un risultato.)

Un conteggio onesto fa quindi due cose insieme: somma i letterali e dichiara i meccanismi che non ha potuto enumerare. Quello che ne esce è un minimo, mai un totale. Un numero che tace sul terzo tipo non è una misura.

Regola 2: IPv4 e IPv6 non si sommano

Torniamo a quei sei blocchi IPv6. Prendiamo un esempio più grosso — l’infrastruttura di invio di Microsoft 365, che pubblica entrambe le famiglie:

spf.protection.outlook.com
  v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/15
         ip4:52.102.0.0/16 ip4:52.103.0.0/17 ip4:104.47.0.0/17
         ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49
         ip6:2a01:111:f403:8000::/51 ip6:2a01:111:f403:c000::/51
         ip6:2a01:111:f403:f000::/52 -all

Il lato IPv4 fa 458.752 indirizzi. Adesso il lato IPv6: un singolo /48 contiene 2⁸⁰ indirizzi, e i cinque blocchi insieme fanno circa 2,19 × 10²⁴.

Somma le due metà e ottieni 2,19 × 10²⁴, cioè la stessa cifra di prima. I 458.752 indirizzi IPv4 non sopravvivono all’arrotondamento: sono diciotto ordini di grandezza troppo piccoli per comparire. Un totale unico non è un numero grande, è il numero dell’IPv6 travestito — e per produrlo si è cancellata l’unica parte su cui un sistemista può davvero ragionare.

Quindi: gli IPv4 si contano a indirizzi, gli IPv6 a blocchi, e non si pubblica mai una cifra sola per entrambi. Chi ti dice che il tuo SPF autorizza settantanove miliardi di miliardi di indirizzi ha sommato le due famiglie e ti sta citando la dimensione di IPv6.

Regola 3: i range sovrapposti vanno fusi prima

Qui i trabocchetti sono tre, e tutti e tre gonfiano.

Range scritti separati che sono un range solo. Riguarda il record Microsoft qui sopra. Pubblica sei letterali IPv4, ma 52.100.0.0/15, 52.102.0.0/16 e 52.103.0.0/17 stanno attaccati uno all’altro: insieme sono un’unica corsa ininterrotta da 52.100.0.0 a 52.103.127.255, 229.376 indirizzi. I letterali sono sei, i blocchi contigui sono quattro. Chi dice «sei range» ha contato la punteggiatura, non la superficie.

Lo stesso fornitore contato due volte. Il record di sendgrid.net finisce già con include:ab.sendgrid.net. Un dominio che pubblica entrambi gli include — cosa in cui è facile ritrovarsi seguendo due guide di configurazione a un anno di distanza — eredita quel secondo record lungo tutte e due le strade. Sommando i letterali alla cieca vengono 238.592 indirizzi. Fondendo prima gli intervalli il numero vero è 237.056: la differenza, 1.536, è esattamente il sotto-record contato una seconda volta.

Host-bit che non stanno dove pensi. La §5.6 di RFC 7208 dice che si confrontano solo i bit alti del prefisso, quindi i bit sotto la lunghezza del prefisso, nel letterale pubblicato, sono semplicemente irrilevanti. Il record di _spf-b.microsoft.com contiene ip4:207.46.22.98/29. Non autorizza otto indirizzi a partire da .98: autorizza da 207.46.22.96 a 207.46.22.103, quindi anche .96 e .97, e non .104. Prendi il letterale alla lettera e ogni intervallo ti si sfasa da entrambi i lati — il che manda in pezzi, silenziosamente, la fusione del paragrafo precedente.

Qui in ballo ci sono due cifre diverse, e conviene tenerle separate. I range che stanno soltanto uno accanto all’altro gonfiano il conteggio dei blocchi lasciando corretto il totale degli indirizzi — è il caso Microsoft. Un fornitore ereditato due volte gonfia gli indirizzi stessi — è il caso SendGrid. Gli host-bit letti male rovinano entrambi.

Quello che i tre errori hanno in comune è la direzione. Tutti e tre fanno la cifra più grande: un conteggio che salta la fusione non è approssimativo in modo neutro, è sistematicamente sbilanciato verso l’allarme.

Regola 4: zero e «non lo so» sono numeri diversi

example.com   v=spf1 -all

Quel record autorizza esattamente zero indirizzi, ed è un fatto vero, utile e difendibile: è quello che dovrebbe pubblicare un dominio che non spedisce posta.

Adesso considera un include: che non si è risolto, o un ramo abbandonato perché il record aveva già esaurito i dieci lookup consentiti (RFC 7208 §4.6.4). Gli indirizzi che ci stanno dietro non sono zero. Sono ignoti, e la risposta onesta è una casella vuota, non una cifra.

La distinzione sembra pedanteria finché non guardi da che parte cade l’errore. Scritto 0, un dato ignoto si legge come una buona notizia: il record più permissivo del tuo parco, mostrato come il più stretto. E uno strumento che non sa dirti quando non è riuscito a guardare ha zeri che non valgono niente nemmeno altrove.

La domanda migliore: quanti di quegli indirizzi hanno mai spedito?

La superficie autorizzata è un elenco di permessi, e da sola non dice nulla su che cosa sia effettivamente in uso. La cifra interessante è la sovrapposizione con la realtà, e i report aggregati DMARC forniscono l’altra metà: ogni report elenca le sorgenti che hanno spedito posta a nome del tuo dominio (RFC 9990 §3.1).

Incrocia i due insiemi e ottieni due numeri utili:

  • autorizzati ∩ osservati — gli indirizzi che spediscono davvero la tua posta;
  • autorizzati − osservati — il peso morto: indirizzi per cui garantisci e che non spediscono un messaggio da mesi.

Il peso morto è quasi sempre archeologia. L’ESP da cui sei migrato e che nessuno ha tolto. Un server di posta dismesso due traslochi fa. Un apparato di monitoraggio che ha smesso di mandare email quando qualcuno ne ha spento gli avvisi. Nessuno di questi si annuncia: l’include: continua a risolversi, il record continua a essere valido, e gli indirizzi continuano a essere autorizzati.

Due discipline rendono onesto quel numero, e contano più dell’aritmetica:

«Nessun report» non è «zero mittenti». Se nella finestra di osservazione non è arrivato niente, non hai imparato nulla sull’uso. Dire a chi ha configurato il reporting la settimana scorsa che nessuno dei suoi 98.304 indirizzi autorizzati spedisce posta sarebbe assurdo, e uno strumento che lo fa sta sottraendo da dati che non ha. L’esito corretto è tacere sull’uso, non esibire un numero grande e preoccupante.

Si contano le sorgenti distinte, non i messaggi. La domanda è quanti indirizzi autorizzati siano vivi, quindi un server che ha spedito un milione di messaggi vale uno. Pesare per volume produce una cifra grossa e senza alcun rapporto con la superficie che dovrebbe descrivere.

Un SPF largo non è, di per sé, un errore

Va detto chiaramente, perché il genere a cui questo articolo appartiene di solito chiude lasciando intendere il contrario.

I 98.304 indirizzi di Google non sono sciatteria. Sono la dimensione di una piattaforma di posta che recapita per moltissime organizzazioni, e qualunque fornitore che operi a quella scala autorizzerà un intervallo paragonabile. Non è successo niente di male.

E quella cifra non è nemmeno un voto. Non esiste una soglia oltre la quale un record diventa cattivo, non c’è un valore di riferimento sotto cui stare, e il numero non va messo dietro un semaforo rosso. È una misura — la stessa categoria del numero di host sulla tua rete: utile da sapere, priva di senso come pagella.

Vale anche la pena essere precisi su che cosa quella superficie esponga. Un indirizzo autorizzato non è una porta aperta: è una macchina per la cui posta il tuo dominio si fa garante. Il rischio che rappresenta è condizionato — conta se una di quelle macchine viene compromessa, o se un range torna al fornitore cloud e viene riaffittato a qualcun altro. È una preoccupazione reale, ed è esattamente il motivo per cui la provenienza conta più della dimensione. Un record che autorizza 98.304 indirizzi di un solo fornitore che usi attivamente sta meglio di uno che ne autorizza 3.000 distribuiti su sei fornitori, quattro dei quali hai smesso di pagare due anni fa.

Che cosa farsene, di quel numero

Togli i fornitori che non usi più. È l’unico intervento sempre giusto, non costa niente e riduce insieme la superficie e il conteggio dei lookup. Non richiede alcuna valutazione: serve solo l’elenco, e qualcuno disposto a dire quali voci sono ancora vere. Comincia dal peso morto.

Dai un sottodominio ai mittenti pesanti. La posta di marketing e quella transazionale spedite da mail.example.com, con un proprio record SPF, tengono piccolo e verificabile a parte il record del dominio aziendale. I range del tuo ESP finiscono così dietro a un nome il cui unico mestiere è la posta massiva, e la compromissione di quella superficie non si porta dietro il peso del tuo dominio principale.

Non ricorrere al flattening. Sostituire include:_spf.google.com con i range letterali in cui si risolve oggi riduce davvero il conteggio dei lookup, ed è il consiglio standard per i record che hanno sbattuto contro il tetto dei dieci. Ma trasforma un riferimento vivo in un’istantanea, e il fornitore continua a cambiare i range alle tue spalle. Quando ne aggiunge uno, la posta che parte da lì comincia a fallire. Quando ne rilascia uno — restituito al pool del cloud, riassegnato a un altro cliente — il tuo record continua ad autorizzare indirizzi che ormai appartengono a un estraneo. È precisamente il rischio che l’espressione «superficie d’attacco» era stata coniata per descrivere, e il flattening lo fabbrica. Merita un articolo a sé, ma la versione breve è che baratta un limite misurabile con un’esposizione che non si vede.

Contare la superficie richiede un pomeriggio e un resolver. Sapere quanta ne sia ancora viva richiede i report DMARC su una finestra abbastanza lunga da intercettare anche i mittenti trimestrali, ed è la metà che nessuna ispezione del record può darti. Sentinely fa entrambe le cose: misura la superficie autorizzata, dichiara le parti che non ha potuto enumerare invece di arrotondarle a zero, e incrocia il risultato con le sorgenti che i tuoi report mostrano davvero — che è dove il peso morto diventa visibile. Se sei arrivato qui per il taglio sicurezza, quel lato sta qui.