# Record SPF: cos’è, come si legge e come si imposta > Il record SPF dice quali server possono spedire email per il tuo dominio. Controlla il tuo gratis e scopri come si scrive, si corregge e si unisce. Fonte: https://www.infomail.it/come-impostare-lo-spf/ · Infomail, piattaforma italiana di email marketing di Hoplo S.r.l. · pubblicato il 22 ottobre 2026 (2026-10-22) Il record SPF (*Sender Policy Framework*) è una riga nel DNS del tuo dominio con l’elenco dei server autorizzati a spedire email a suo nome. Quando un’email arriva, il server di chi riceve guarda da quale indirizzo IP è partita e controlla se quell’IP è nell’elenco. Le regole le fissa la [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208), del 2014. Il controllo qui sopra legge il tuo record, conta le ricerche DNS che costa e segnala gli errori che lo rendono inutile. Se è tutto verde, puoi fermarti qui. Se no, sotto trovi come si legge una riga che sembra scritta in codice e come si sistema senza rompere quello che già funziona. ## Cosa controlla l’SPF (e cosa no) L’SPF non guarda l’indirizzo che il destinatario vede nel campo «Da». Guarda l’indirizzo di ritorno della busta, quello a cui tornano i messaggi non consegnati (nel gergo *MAIL FROM* o *Return-Path*), più il nome con cui il server si presenta, l’*HELO* ([RFC 7208, §2.3 e §2.4](https://www.rfc-editor.org/rfc/rfc7208#section-2.3)). Di solito i due indirizzi stanno sullo stesso dominio, ma non è obbligatorio: un’email può superare l’SPF e mostrare nel «Da» un nome qualsiasi. A collegare le due cose ci pensa il DMARC, come spieghiamo nella [guida al DMARC](https://www.infomail.it/come-impostare-il-dmarc-per-lemail-marketing/). C’è un secondo limite. Se un cliente inoltra la tua email, il messaggio riparte da un altro server e l’SPF fallisce anche se è tutto in regola. La firma [DKIM](https://www.infomail.it/aggiornamenti-per-il-servizio-dkim/) viaggia con il messaggio e regge l’inoltro: per questo si usano insieme. ## Come si legge un record SPF Questo, per esempio, potrebbe essere il record di uno studio di commercialisti con il server di posta in ufficio, un gestionale che manda gli avvisi di scadenza e la newsletter mensile su Infomail: ``` v=spf1 mx ip4:203.0.113.25 include:sender.infomail.it ~all ``` Si legge da sinistra a destra: | Pezzo | Cosa vuol dire | | --- | --- | | `v=spf1` | È un record SPF. Sta sempre all’inizio, scritto così | | `mx` | Sono autorizzati i server che ricevono la posta del dominio (i suoi record MX) | | `ip4:203.0.113.25` | È autorizzato questo indirizzo IP, il server del gestionale. Per IPv6 c’è `ip6:` | | `include:sender.infomail.it` | Sono autorizzati i server elencati nell’SPF di Infomail | | `~all` | Tutti gli altri probabilmente non sono autorizzati | Puoi incontrare anche `a` (l’indirizzo IP del dominio stesso), `exists`, raro, e `ptr`, che la RFC chiede di non pubblicare più ([§5.5](https://www.rfc-editor.org/rfc/rfc7208#section-5.5)). In fondo al record possono esserci due modificatori: `redirect=`, che rimanda all’SPF di un altro dominio, ed `exp=`, una spiegazione da mostrare quando un server viene respinto. `include` è il pezzo che si fraintende più spesso. Non copia il record dell’altro dominio nel tuo: chiede «questo IP passerebbe l’SPF di quel dominio?» e, se la risposta è sì, lo considera autorizzato. La RFC stessa ammette, a posteriori, che il nome è stato scelto male ([§5.2](https://www.rfc-editor.org/rfc/rfc7208#section-5.2)). ### Il finale: -all, ~all, ?all, +all L’ultimo pezzo decide cosa succede ai server che non sono nell’elenco. Il simbolo davanti ad `all` si chiama qualificatore: | Finale | Risultato | Cosa succede di solito | | --- | --- | --- | | `-all` | *fail* | Il server non è autorizzato: chi riceve può rifiutare l’email ([§8.4](https://www.rfc-editor.org/rfc/rfc7208#section-8.4)) | | `~all` | *softfail* | Probabilmente non è autorizzato: l’email non va rifiutata solo per questo, ma viene guardata con sospetto ([§8.5](https://www.rfc-editor.org/rfc/rfc7208#section-8.5)) | | `?all` | *neutral* | Il record non si pronuncia, e per chi riceve non cambia niente | | `+all` | *pass* | Chiunque è autorizzato. Da non usare mai | Senza nessun `all`, per i server non in elenco il risultato è *neutral* ([§4.7](https://www.rfc-editor.org/rfc/rfc7208#section-4.7)). Meglio `-all` o `~all`? La nostra opinione: comincia con `~all` e passa a `-all` quando sei sicuro che l’elenco sia completo, cioè quando i rapporti DMARC ti hanno mostrato tutte le fonti della tua posta. Con `-all` e un servizio dimenticato, le email di quel servizio rischiano il rifiuto. Per Gmail e Yahoo vanno bene tutti e due. ## Come si imposta un record SPF Il record si aggiunge nel pannello DNS del dominio, dal registrar o da chi ti gestisce il sito. Prima di aprirlo, però, ti serve un elenco. 1. **Scrivi chi spedisce con il tuo dominio.** La casella di posta aziendale, la piattaforma per le newsletter, il gestionale che manda fatture e promemoria, il negozio online con le conferme d’ordine, il CRM. Ogni servizio ti dice cosa aggiungere: di solito un `include:`, a volte un indirizzo IP. 2. **Guarda se un record c’è già.** Il controllo in testa alla pagina te lo mostra. Se c’è, lo modifichi; non ne aggiungi un secondo. 3. **Crea o modifica il record TXT.** Il nome (in alcuni pannelli «host») è il dominio stesso: si scrive `@` oppure si lascia vuoto, dipende dal pannello. Il valore è la riga che comincia con `v=spf1`. 4. **Metti in fila i servizi e chiudi con un solo `all`.** Quello che scrivi dopo `all` viene ignorato ([§5.1](https://www.rfc-editor.org/rfc/rfc7208#section-5.1)). 5. **Salva e rifai il controllo** finché non vedi il record nuovo. I sottodomini che spediscono, per esempio `news.tuodominio.it`, hanno bisogno di un record loro: quello del dominio principale non vale per loro. ### Il limite delle dieci ricerche Nei domini delle aziende che usano tanti servizi è il problema che troviamo più spesso. Ogni `include`, `a`, `mx`, `ptr`, `exists` e `redirect` costa una ricerca DNS al server che riceve, e contano anche quelle dentro gli include degli altri. Il massimo è dieci ([§4.6.4](https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4)): all’undicesima il controllo finisce in errore permanente e l’SPF non vale più. `ip4`, `ip6` e `all` sono gratis. A occhio non si vede. Un record con quattro include può costarne dodici, perché uno dei servizi ne ha altri dentro. Lo strumento le conta tutte e, sotto «Gli include, uno per uno», ti mostra quanto pesa ciascuno. Per rientrare: - togli gli include dei servizi che non usi più (il vecchio fornitore di newsletter, la prova di un CRM di due anni fa, mai disdetta nel DNS); - togli `mx` e `a` se i server di posta sono già coperti da un include; - solo come ultima risorsa, sostituisci un include con gli indirizzi `ip4`/`ip6` del servizio, sapendo che andranno aggiornati a mano quando il servizio li cambia. La stessa sezione della RFC fissa un secondo tetto: al massimo due ricerche a vuoto, cioè nomi che non esistono o non hanno record. Capita con gli include di servizi chiusi. ## Quando l’SPF non funziona: gli errori tipici ### Due record SPF sullo stesso dominio Succede quando si aggiunge un servizio e il pannello crea un secondo TXT invece di modificare il primo. Con più record `v=spf1` il controllo va in errore ([§4.5](https://www.rfc-editor.org/rfc/rfc7208#section-4.5)) e nessuno dei due conta. Vanno uniti in uno, con gli include in fila e un solo `all`: ``` prima: v=spf1 mx ~all v=spf1 include:sender.infomail.it ~all dopo: v=spf1 mx include:sender.infomail.it ~all ``` ### Il record chiuso con +all Autorizza qualsiasi server del mondo a spedire con il tuo dominio, quindi le email false superano il controllo. Si sostituisce con `~all`. ### Un include che punta nel vuoto Se il dominio incluso non ha un record SPF, per la RFC è un errore permanente ([§5.2](https://www.rfc-editor.org/rfc/rfc7208#section-5.2)). Di solito è una lettera sbagliata nel nome o un servizio che ha cambiato indirizzo. ### Il record spezzato male Un singolo pezzo di testo in un record TXT non supera i 255 caratteri, e i record lunghi vengono divisi in più stringhe tra virgolette. Chi riceve le riunisce senza aggiungere spazi ([§3.3](https://www.rfc-editor.org/rfc/rfc7208#section-3.3)): se il taglio cade tra due meccanismi, lo spazio va lasciato in fondo alla prima stringa, altrimenti `include:a.it` e `include:b.it` diventano una parola sola. Ancora meglio, accorcia il record. ### Il meccanismo ptr È lento, inaffidabile, e la RFC chiede di non usarlo. Si sostituisce con l’include del servizio o con i suoi indirizzi IP. ### Il dominio che non spedisce, lasciato scoperto Il dominio che usi solo per il sito, o quello vecchio che tieni per non perderlo, fa gola a chi vuole spacciarsi per te. Pubblica `v=spf1 -all`: dice che nessun server è autorizzato. ## L’SPF con Infomail Per Infomail ti basta un pezzo: `include:sender.infomail.it`. Quando aggiungi il dominio tra i **Domini di invio**, la piattaforma legge il record che hai già e ti propone la versione da pubblicare, con l’include inserito prima di `all`. Se il dominio non ha ancora un SPF, ti propone questo: ``` v=spf1 include:sender.infomail.it ~all ``` Lo copi nel pannello DNS, torni in Infomail e premi **Verifica DNS**. Se il DNS lo gestisce il fornitore del sito o il reparto IT, le istruzioni gliele mandi dalla pagina del dominio, e noi ti assistiamo per la configurazione del mittente se qualcosa non torna. Il percorso completo, con DKIM e DMARC, è nella guida [Inserire un nuovo mittente](https://www.infomail.it/help/inserire-un-nuovo-mittente/). Le email transazionali che il tuo gestionale manda dai nostri SMTP (`smtp.infomail.ai`, porta 587) escono dalla stessa infrastruttura, nell’Unione europea: l’include è lo stesso. ## Cosa chiedono Gmail e Yahoo sull’SPF [Google](https://support.google.com/a/answer/81126) e [Yahoo](https://senders.yahooinc.com/best-practices/) chiedono a tutti i mittenti, da febbraio 2024, SPF o DKIM; a chi spedisce molto, tutti e due, insieme al DMARC. Google aggiunge che il record SPF deve comprendere tutti i servizi che spediscono per il dominio. Se Gmail rifiuta un messaggio per colpa dell’SPF, nell’errore trovi il codice 4.7.27 o 5.7.27 ([domande frequenti di Google](https://support.google.com/a/answer/14229414)). Chi conta come «chi spedisce molto», e cosa succede da novembre 2025 a chi non rispetta le regole, è spiegato nella [guida al DMARC](https://www.infomail.it/come-impostare-il-dmarc-per-lemail-marketing/#cosa-chiedono-gmail-e-yahoo). ## Domande frequenti ### Ho già il DKIM: mi serve anche l’SPF? Se spedisci poco, a Gmail e Yahoo basta uno dei due. Una newsletter però supera in fretta la soglia dei mittenti massivi, e lì li vogliono entrambi. E l’SPF costa una riga nel DNS. ### Quanto ci mette a funzionare? Dipende da quanto a lungo i server tengono in memoria il record vecchio. Spesso pochi minuti, a volte ore: le modifiche al DNS possono richiedere fino a 48 ore per propagarsi. ### Ho superato le dieci ricerche: cosa tolgo? Apri «Gli include, uno per uno» nella scheda SPF e guarda quanto pesa ogni servizio. Togli prima quelli che non usi più, poi `mx` e `a` se non servono. Se ancora non basta, scrivici: va fatto con calma, un servizio alla volta. ### Ho tre domini che spediscono dagli stessi server. Devo scrivere tre record uguali? Puoi scriverne uno completo sul dominio principale e, sugli altri due, solo `v=spf1 redirect=tuodominio.it`. Il redirect fa valere il record di quel dominio ([§6.1](https://www.rfc-editor.org/rfc/rfc7208#section-6.1)) e, quando cambia un servizio, lo aggiorni in un posto solo. Conta come una ricerca DNS.