# Cos'è un record SPF? Sintassi, limiti e casi di errore URL: https://notificationharbor.com/it/journal/record-spf-sintassi-limiti-e-errori Type: blog Locale: it Published: 2026-10-20 Updated: 2026-10-23 --- > Un record SPF elenca i server autorizzati a inviare posta per il tuo dominio. Ecco la sintassi, il limite di 10 lookup, i guasti dell'inoltro e come verificare il tuo. Un record SPF è un unico record TXT nel DNS del dominio che elenca i server autorizzati a inviare posta usando quel dominio nel mittente di busta (envelope sender). Il server ricevente legge il record, confronta l'IP che si connette con la lista e restituisce pass, fail, softfail o neutral. Autentica il percorso di invio, non il messaggio, e non dice nulla sull'indirizzo From che l'utente vede. Questa distinzione spiega la maggior parte dei ticket SPF che vediamo nelle tracce. ## Un record SPF è una allowlist di mittenti, pubblicata nel DNS SPF sta per Sender Policy Framework, specificato nella [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208). Il record è una voce TXT alla radice del dominio che inizia con `v=spf1`. Un esempio minimo: `example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"`Si legge da sinistra a destra. Il ricevente controlla ogni termine in ordine e si ferma alla prima corrispondenza. Il termine `all` finale raccoglie tutto ciò che non ha trovato corrispondenza prima. Il dominio controllato non è l'header From. È il dominio nel comando SMTP `MAIL FROM`, chiamato anche envelope sender o Return-Path. Se è vuoto, come nei bounce, il ricevente ripiega sul nome `HELO`. ![Scrivania di sviluppatore con terminale portatile e un quaderno con uno schema di rete disegnato a mano](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/0bf38c-inline1.webp) ## I meccanismi: ip4, ip6, a, mx, include, exists Ogni termine è un meccanismo, eventualmente preceduto da un qualificatore. Sei di questi coprono quasi tutti i record reali. - **`ip4:` / `ip6:`** corrispondono a un indirizzo letterale o a un range CIDR. Non costano lookup. - **`a`** corrisponde ai record A/AAAA del dominio. Costa un lookup. - **`mx`** corrisponde agli host dei record MX del dominio. Costa un lookup, più uno per ogni host. - **`include:`** corrisponde a tutto ciò che corrisponde nel record SPF di un altro dominio. Costa un lookup, più tutto ciò che è annidato al suo interno. - **`exists:`** corrisponde a qualsiasi record A per un nome costruito. Costa un lookup. - **`ptr`** corrisponde al reverse DNS dell'IP che si connette. Costa lookup, e la RFC 7208 sconsiglia di usarlo. I qualificatori fissano il risultato quando un termine corrisponde. `+` è pass ed è il valore predefinito, `-` è fail, `~` è softfail, `?` è neutral. Quindi `-all` significa "rifiuta tutto ciò che non è elencato", mentre `~all` significa "accetta ma segnala". Preferisci `ip4:` e `ip6:` ogni volta che controlli l'indirizzo. Non costano lookup e non possono rompersi quando il DNS di qualcun altro cambia. ## Il limite di 10 lookup è il vincolo che rompe i record reali La RFC 7208 limita a 10 i termini che generano query DNS durante una singola valutazione SPF: `include`, `a`, `mx`, `ptr`, `exists` e il modificatore `redirect`. Gli include annidati contano. Oltre il decimo, il risultato è `permerror`, e il controllo fallisce in modo permanente invece di ripiegare su altro. C'è un secondo limite meno discusso. I termini che restituiscono una risposta vuota o NXDOMAIN sono void lookup, e la specifica dice di fermarsi a due. Un `include:` obsoleto che punta a un fornitore abbandonato l'anno scorso è un void lookup che continui a pagare. Ecco come i team arrivano davvero al limite. Google Workspace occupa un include. Un provider transazionale ne occupa un altro. Una piattaforma di marketing ne occupa uno e ne annida altri tre al suo interno. Un help desk, un CRM e uno strumento di fatturazione ne aggiungono altri quattro. Si è già a 11 senza aver fatto nulla di insolito. Il guasto è silenzioso. La posta continua a partire, e alcuni ricevitori la consegnano ancora, ma SPF non autentica più nulla per te. Se ti affidi all'allineamento DMARC tramite SPF, quella strada è chiusa finché non appiattisci il record o rimuovi dei mittenti. Tre correzioni funzionano, in ordine di preferenza: - Rimuovi i mittenti che non usi più. Verifica gli include rispetto ai report aggregati DMARC degli ultimi 90 giorni. - Sposta il traffico massivo su un sottodominio come `mail.example.com`, con un proprio record SPF e un proprio budget di 10 lookup. - Appiattisci gli include in range `ip4:` letterali, ma solo con automazione. I fornitori ruotano gli IP, e un record appiattito a mano diventa obsoleto senza alcun avviso. ![Lavagna con frecce che partono da diversi servizi di invio e convergono verso un unico box centrale](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/96537f-inline2.webp) ## Pubblica un solo record SPF per dominio Un dominio non deve pubblicare due record SPF. Se il ricevente trova due voci TXT `v=spf1`, il risultato è `permerror`, come per il limite di lookup. Succede quando una persona aggiunge un record per un nuovo strumento mentre un altro è già presente. La correzione è meccanica. Unisci i termini in un unico record, con un solo `v=spf1` all'inizio e un solo `all` alla fine. Tutto ciò che la documentazione del fornitore ti chiede di aggiungere va dentro il record esistente come un altro `include:`, mai come nuova voce TXT. Due trappole più piccole. Una stringa TXT oltre 255 caratteri va spezzata in più stringhe tra virgolette dentro lo stesso record, cosa che la maggior parte dei provider DNS fa per te. E tieni la risposta sotto i circa 450 byte dove puoi, perché risposte più grandi possono passare da UDP a TCP, e alcuni resolver lo gestiscono male. ## Softfail o hardfail: scegli in base a ciò che puoi vedere Il termine `all` è una dichiarazione di politica, e il consiglio standard ("usa `-all`") salta la parte che conta. Un hard fail è sicuro solo quando conosci ogni mittente legittimo. La nostra regola pratica, leggendo le tracce: - `~all` mentre stai ancora inventariando i mittenti, o se inoltri posta e non controlli il percorso. - `-all` quando i report DMARC mostrano che ogni fonte legittima passa per alcune settimane. - Mai `+all`, che autorizza l'intera rete, e mai `?all` su un dominio di produzione. In pratica la differenza è più piccola di quanto ci si aspetti. La maggior parte dei grandi ricevitori tratta SPF come un segnale tra altri, e con una policy DMARC in vigore il verdetto DMARC è quello che decide. Resta il fatto che un `-all` su un record incompleto è il modo in cui si perdono le fatture. ![Cavi ethernet etichettati raccolti in un fascio dentro un rack di server](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/3e48d3-inline3.webp) ## SPF si rompe con l'inoltro, ed è una scelta di progetto SPF valida l'IP che si è connesso al server ricevente. Quando un messaggio viene inoltrato, passa da una mailing list o viene rilanciato da un servizio di alias, l'IP che si connette è quello dell'inoltratore, non il tuo. Il controllo SPF fallisce anche se non hai sbagliato nulla. Non puoi risolvere questo dentro SPF. Per questo esiste DKIM accanto a SPF: una firma sopravvive al passaggio, una lista di IP no. Un dominio che dipende solo da SPF vedrà errori di autenticazione su ogni messaggio inoltrato. È anche il motivo per cui SPF da solo non soddisfa DMARC per la posta inoltrata. Conviene prevedere che sia DKIM a trasportare quei messaggi. ## Allineamento SPF: superare il controllo non equivale a corrispondere al dominio From Un messaggio può superare SPF e fallire DMARC. DMARC richiede che il dominio verificato da SPF, cioè quello del Return-Path, corrisponda al dominio From visibile. Molti provider condivisi usano per default un proprio dominio di bounce, quindi SPF passa per `provider-mail.net` e non dice nulla su `example.com`. Controlla nelle intestazioni grezze. Nella riga `Authentication-Results` guarda `smtp.mailfrom=`. Se non è il tuo dominio o un suo sottodominio, SPF passa senza aiutarti. Il rimedio è un Return-Path personalizzato su un tuo sottodominio, che i mittenti seri supportano. Postmark, Resend, Mailgun e SendGrid documentano tutti questa configurazione, anche se non è sempre attiva di default. ## I provider di posta ora si aspettano autenticazione da ogni mittente Da febbraio 2024 Google richiede che tutti i mittenti si autentichino con SPF o DKIM, e chi invia più di 5.000 messaggi al giorno verso Gmail deve avere SPF, DKIM e DMARC. I dettagli sono nelle [linee guida di Google per i mittenti](https://support.google.com/mail/answer/81126). Yahoo ha introdotto regole analoghe nello stesso periodo. Questo ha trasformato SPF da elemento utile a prerequisito di consegna. Un record mancante o rotto ora si traduce in rifiuti e spam, non solo in un punteggio di reputazione più basso. La nostra lettura, dopo un paio d'anni di tracce: le regole intercettano soprattutto domini senza alcuna autenticazione e mittenti con tassi alti di reclami. Un record SPF corretto da solo non ti porta nella casella di posta, ma uno mancante ti tiene fuori. ## Come verificare e correggere un record SPF in quattro passaggi Procedi in quest'ordine e ricontrolla dopo ogni modifica DNS. - **Leggi il record attuale.** Esegui `dig +short TXT example.com` e trova la voce che inizia con `v=spf1`. Se ce ne sono due, uniscile. - **Conta i lookup.** Somma `include`, `a`, `mx`, `exists`, `redirect` e tutto ciò che è annidato negli include. Se sei a 8 o più, pianifica la pulizia adesso, non all'undicesimo. - **Elenca i mittenti reali.** Usa i report aggregati DMARC o le intestazioni Authentication-Results dei test di invio. Aggiungi solo le fonti che compaiono. - **Invia un test e leggi l'intestazione.** Il risultato deve essere `spf=pass` con `smtp.mailfrom` sul tuo dominio. Le modifiche DNS richiedono tempo per propagarsi, e il TTL del record attuale decide per quanto tempo sopravvivono le risposte vecchie. Abbassalo a 300 secondi il giorno prima di una modifica pianificata. ## Un record di esempio per una SaaS con tre mittenti Prendi un prodotto che invia da Google Workspace, da un provider transazionale e da un help desk. Un record pulito è questo: `example.com. IN TXT "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"`Sono tre include, e ognuno nasconde i propri lookup annidati. Contali prima di pubblicare, perché la lunghezza visibile non dice nulla del budget reale. Un record con tre include può già arrivare a 7 o 8 lookup. Ora separa per scopo. Tieni la posta umana sul dominio principale. Metti le notifiche di prodotto su `notify.example.com` con un record che elenca solo il provider transazionale. Il record radice resta corto, il sottodominio ottiene un proprio budget di 10 lookup, e un problema di reputazione su un flusso non trascina con sé l'altro. Questa separazione rende anche leggibili i report DMARC. Ogni flusso ha il proprio dominio Return-Path, quindi un errore indica un solo mittente invece di un mucchio. ## Cosa non fa SPF Non impedisce a qualcuno di falsificare il tuo indirizzo From, perché non guarda mai quell'intestazione. Non cifra nulla. Non ti dice perché un messaggio è finito nello spam. E non scala oltre il budget di 10 lookup senza una manutenzione continua. Consideralo uno dei tre record da pubblicare insieme: SPF per il percorso di invio, DKIM per l'integrità del messaggio, DMARC per la policy che li lega al dominio From. Se hai SPF e nient'altro, il passo concreto successivo è pubblicare un record DMARC con `p=none` e leggere i report per due settimane. ## FAQ ### Che cos'è un record SPF in parole semplici? È un record TXT nel DNS che elenca i server autorizzati a inviare posta per il tuo dominio. I server riceventi confrontano l'IP mittente con questa lista e decidono se il messaggio supera SPF. ### Quanti record SPF può avere un dominio? Uno solo. Pubblicarne due che iniziano entrambi con v=spf1 provoca un permerror. Unisci tutti i mittenti autorizzati in un unico record, con un solo termine all alla fine. ### Qual è il limite di 10 lookup DNS di SPF? La RFC 7208 limita la valutazione a 10 termini che generano query DNS: include, a, mx, ptr, exists e redirect. Gli include annidati contano. Superarlo restituisce permerror e SPF smette di autenticare la tua posta. ### Conviene usare -all o ~all nel record SPF? Usa ~all mentre inventari i mittenti e passa a -all quando i report DMARC mostrano che ogni fonte legittima supera il controllo per diverse settimane. Non usare mai +all, che autorizza qualsiasi server. ### Perché SPF fallisce quando la posta viene inoltrata? SPF controlla l'IP che si connette al ricevente. Un inoltratore si connette dal proprio IP, che il tuo record non elenca. DKIM sopravvive all'inoltro perché la firma viaggia insieme al messaggio. ### SPF da solo protegge dalla falsificazione del mittente? No. SPF valida il mittente di busta, non l'indirizzo From visibile. Per proteggere il dominio From serve DMARC, che richiede che SPF o DKIM superino e corrispondano a quel dominio.