Record SPF: configurazione, esempi ed errori comuni

Quando prepari un'infrastruttura email nel 2026, il record SPF è una parte importante dell'autenticazione. Una configurazione errata può contribuire a spam o rifiuti, ma SPF non decide da solo se un messaggio arriva nella posta in arrivo.

Da febbraio 2024 Google e Yahoo applicano requisiti di autenticazione più esigenti al traffico interessato. Un SPF assente o errato può contribuire a rifiuti come SMTP 550, secondo le altre verifiche e le politiche, senza causare necessariamente questa risposta per ogni invio.

Per un'azienda con un solo dominio, l'errore può compromettere una presentazione agli investitori. Per un fornitore che gestisce 500 domini clienti, può trasformare il lunedì mattina in una serie di richieste sugli invii a Gmail. Verificare prima riduce i rischi, senza evitare ogni incidente.

Questa guida spiega il ruolo di SPF, come costruire il record, quali errori possono influire sulla posta e come mantenere la configurazione quando gestisci molti domini.

Cosa fa SPF e cosa non fa

Sender Policy Framework (SPF) è un protocollo di autorizzazione basato sul DNS, definito nella RFC 7208. Pubblica una politica che permette al server ricevente di verificare quali server siano autorizzati per un'identità SMTP. Non è una protezione generale e non autentica tutto il contenuto.

Come funziona la verifica

Quando Gmail riceve un messaggio da alice@yourcompany.com, SPF non verifica direttamente il From visibile nell'interfaccia. Valuta il dominio del mittente della busta SMTP, riflesso nel Return-Path alla consegna, oppure HELO nei casi applicabili. Consulta la sua politica DNS e confronta l'IP della connessione con le autorizzazioni.

Una regola di autorizzazione corrispondente può dare pass. Se la valutazione raggiunge SoftFail (~all) o HardFail (-all), restituisce quel risultato. Non sono ordini automatici di accettazione o rifiuto; esistono altri risultati e il ricevente decide il trattamento.

La differenza fra From e Return-Path

Il 90% citato nel testo di origine è un valore illustrativo, non una statistica misurata. La distinzione essenziale è che SPF non verifica direttamente il From visibile in Outlook o Apple Mail, ma l'identità SMTP pertinente.

Il punto critico: Mailchimp può usare un Return-Path proprio per gestire gli errori di consegna, come bounce-mc.us1.mailchimp.com. Il ricevente consulta quindi SPF di Mailchimp, non necessariamente quello del tuo dominio. Il tuo record può essere valido senza partecipare a quell'invio.

Per questo SPF da solo non basta a verificare l'identità visibile. Leggi come SPF, DKIM e DMARC interagiscono nella guida alla configurazione dell'autenticazione email.

Perché SPF serve ancora

SPF completa DKIM e DMARC. La sua assenza può violare requisiti applicabili; Microsoft può restituire 550 5.7.515 Access Denied per determinati flussi soggetti alle proprie regole di autenticazione. Non attribuire universalmente quel codice a SPF e non trascurare la verifica tecnica.

Configurazione di base con un fornitore

Una piccola azienda che invia con TrekMail, Google Workspace o Microsoft 365, magari con uno strumento marketing, ha bisogno di una politica SPF coerente per ogni dominio SMTP usato. Con pochi servizi la configurazione può essere semplice, ma c'è un errore frequente da evitare.

Regola di base: al massimo un record SPF applicabile per nome di dominio; se pubblichi SPF, deve essere unico.

Quando aggiungi un servizio, non creare un secondo TXT SPF allo stesso nome. Più politiche SPF applicabili producono PermError; il ricevente non le unisce. Altri TXT estranei a SPF possono invece coesistere.

Componenti di un record

Consulta la guida alla configurazione SPF per esempi passo passo. Verifica i modelli con le istruzioni attuali dei fornitori prima di pubblicarli.

TrekMail per le piccole imprese

Il testo di origine confronta Google Workspace a $6-$18 per utente al mese. Per dieci utenti, indica $720-$2,160 all'anno. Cita inoltre Starter di TrekMail a $3.50 al mese, fino a 100 utenti. Sono riferimenti illustrativi, non preventivi attuali. Aggiungere include:spf.trekmail.net può rientrare nello SPF se corrisponde al trasporto usato, ma occorre verificare tutti i mittenti e il resto dell'autenticazione. Il modello a prezzo fisso dipende da limiti e condizioni vigenti, senza garantire una posta funzionante con una sola riga.

Più fornitori: il caso delle agenzie

Un'agenzia con decine di domini può trovare HubSpot per le vendite, Zendesk per l'assistenza, Klaviyo per il marketing e TrekMail per la posta aziendale. Inventaria i flussi: non tutti devono comparire nello SPF principale se usano altri domini della busta.

Unisci in una politica i servizi che usano davvero la stessa identità SMTP, rispettando il limite di 10 consultazioni dei termini valutati.

Il limite di 10 consultazioni

La RFC 7208 §4.6.4 limita a 10 i meccanismi e modificatori valutati che richiedono consultazioni DNS, compresi quelli annidati. Non conta singoli pacchetti DNS. La restrizione limita lavoro e abusi possibili, ma può coinvolgere anche configurazioni legittime.

Termini che consumano il budget: include:, a, mx, exists, redirect. L'elenco non è completo: anche ptr rientra nel budget.

Termini che non consumano questo budget: ip4:, ip6:, all

Il problema degli include annidati

Aggiungere include:bluehost.com sembra consumare 1 termine. Come esempio ipotetico, se quella politica valuta anche spf.protection.outlook.com e mail.bluehost.com, potrebbero essere valutati tre termini. Inoltre spf.protection.outlook.com può avere una propria catena. L'esempio non descrive necessariamente i record attuali né un percorso obbligato di tutte le dipendenze.

Se la valutazione supera 10 termini pertinenti, restituisce PermError, distinto da fail. Il ricevente può rifiutare o filtrare secondo la propria politica; non significa perdita silenziosa garantita di tutta la posta.

Come verificare il budget

Non tirare a indovinare. Usa la riga di comando o un visualizzatore affidabile. Su Mac o Linux:

dig +short txt yourdomain.com

Consulta poi i domini di ogni include: e segui la valutazione pertinente, includendo meccanismi DNS e modificatori, non soltanto include. La guida alle consultazioni e ai limiti SPF spiega come verificare dipendenze e correggere superamenti.

Flattening o separazione per sottodomini

Se la configurazione si avvicina al limite di 10 o lo supera, valuta queste due opzioni. Non tutte le agenzie raggiungono necessariamente il limite.

Opzione 1: flattening SPF, con manutenzione

Il flattening risolve le dipendenze include: e le sostituisce con autorizzazioni IP esplicite, come ip4:. I termini ip4: non consumano questo budget; centinaia di IP possono comunque porre limiti di dimensione e manutenzione. Non è una sostituzione meccanica valida per ogni politica, anche secondo le famiglie di indirizzi e le macro.

Il rischio: HubSpot, Klaviyo e altri servizi possono cambiare IP. Dopo qualche mese una lista fissa potrebbe diventare obsoleta, non autorizzare nuovi server o mantenere indirizzi che non dovrebbero più essere consentiti.

Se scegli questa strada, prevedi rilevamento affidabile delle modifiche, revisione delle autorizzazioni, aggiornamento DNS, test e ripristino. L'automazione aiuta, ma non elimina rischi e supervisione.

Opzione 2: separazione per sottodomini

Un'altra soluzione distribuisce le identità di invio fra sottodomini. SPF valuta il dominio della busta SMTP, riflesso nel Return-Path: deve cambiare realmente perché la separazione abbia effetto.

Il marketing deve usare team@company.com, oppure può inviare da news@marketing.company.com? Cambiare solo il From visibile non basta: configura anche l'identità tecnica appropriata.

Dominio principale (company.com) - Mantieni una politica adatta alla posta aziendale e ai servizi essenziali. Esempio illustrativo da verificare:

v=spf1 include:spf.trekmail.net -all

Sottodominio marketing (marketing.company.com) - Configura qui i servizi che usano davvero quel dominio della busta. Esempio, non record pronto per la pubblicazione:

v=spf1 include:servers.mcsv.net include:hubspot.com -all

Ogni valutazione di un dominio della busta distinto ha un budget di 10 termini; un include annidato non ne apre uno nuovo. Verifica l'allineamento DMARC rilassato o rigoroso. Separare marketing.company.com facilita la gestione, ma non protegge in modo assoluto l'indirizzo del direttore: i riceventi possono aggregare reputazione per dominio organizzativo o IP.

Consulta i modelli di configurazione SPF e la configurazione per più mittenti. Adatta gli esempi all'inventario e alle istruzioni attuali dei fornitori.

Verifiche dopo la pubblicazione

Salvare il record nell'editor DNS non conclude il lavoro. Questi controlli aiutano a verificare pubblicazione e invii reali.

1. Verificare l'aggiornamento DNS

Le modifiche possono richiedere minuti o ore, secondo pubblicazione e cache TTL. Oltre alla cache locale, consulta un resolver pubblico e i server autoritativi quando necessario:

nslookup -type=txt yourdomain.com 8.8.8.8

8.8.8.8 seleziona il DNS pubblico Google, che può avere a sua volta una cache. Vedere il record conferma quella risposta, non l'aggiornamento immediato di tutti i resolver o riceventi.

2. Validare la sintassi

Controlla errori di sintassi e regole che possono modificare la valutazione:

• Uno spazio prima di v=spf1 può impedire l'identificazione corretta della politica.
• ip4: 192.1.1.1 - Lo spazio dopo i due punti è errato.
• Più meccanismi all: il primo corrisponde sempre e i termini successivi non vengono valutati.
• Voci include: duplicate possono sprecare budget sul percorso valutato, senza essere sempre un errore sintattico.

Usa un validatore. La procedura DNS guidata di TrekMail può aiutare secondo i controlli disponibili; verifica anche il risultato pubblicato.

3. Il limite delle consultazioni senza risultato

La RFC 7208 raccomanda al massimo 2 consultazioni senza risultato, come NXDOMAIN o risposte prive dei dati pertinenti. Il limite può dipendere dall'implementazione; superarlo, non semplicemente raggiungerlo, può generare PermError.

Ad esempio, include:spf.trekmaill.net contiene una lettera aggiuntiva. Se il nome non esiste, la consultazione potrebbe rappresentare 1 risultato vuoto; tuttavia un include senza politica SPF può produrre PermError da solo. Due refusi non dimostrano universalmente il superamento del limite delle consultazioni vuote.

Verifica le risposte DNS, non soltanto il testo: una politica può avere sintassi corretta e dipendenze inesistenti.

4. Analizzare le intestazioni di un invio reale

Invia a un account Gmail che controlli. Nel menu con tre puntini scegli «Mostra originale» e cerca Authentication-Results aggiunto dal server ricevente attendibile. Esempio illustrativo:

spf=pass (google.com: domain of user@yourdomain.com designates 192.0.2.1 as permitted sender)

spf=neutral o spf=softfail richiede un controllo se attendevi pass, ma può riflettere una politica intenzionale o un inoltro. Verifica IP, dominio valutato e percorso; non prova un fallimento DMARC se DKIM è valido e allineato. Consulta la verifica dello stato DNS.

Errori che influiscono sulla posta

Questi casi compaiono negli incidenti SPF. Conoscerli aiuta a indagare, senza attribuire loro una proporzione misurata di tutte le richieste di assistenza.

1. SPF e inoltro

SPF confronta l'IP della connessione con la politica dell'identità SMTP. Questa dipendenza può complicare l'inoltro.

Alice scrive a Bob, che inoltra a Charlie. Se viene mantenuto il mittente della busta di Alice, Charlie confronta l'IP di Bob con quella politica. SPF può fallire per un messaggio legittimo, secondo autorizzazioni e configurazione dell'inoltro.

SPF da solo non risolve ogni caso. DKIM firma dati specifici del corpo e delle intestazioni; la firma può sopravvivere se non cambiano in modo incompatibile. Deve restare valida e allineata per DMARC. SRS può consentire SPF per il dominio dell'intermediario senza ripristinare l'allineamento con il From originale.

Leggi l'interazione fra SPF, DKIM e SRS nell'inoltro della posta di dominio, senza presumere un recapito garantito.

2. Il meccanismo ptr

All'inizio degli anni 2000 si usava il meccanismo ptr, basato sul DNS inverso:

v=spf1 ptr -all

La RFC sconsiglia ptr per costi e limiti, ma resta definito nel protocollo. Non significa che Gmail ignori ogni politica che lo contiene. Se erediti ptr, inventaria le autorizzazioni e prova la sostituzione; non confonderlo con il PTR del server, che ha un altro ruolo.

3. Il rischio di +all

Questo esempio illustra una configurazione pericolosa; non pubblicarlo:

v=spf1 include:spf.google.com +all

I qualificatori significano:

• -all = HardFail per gli IP la cui valutazione raggiunge il termine; il ricevente decide se rifiutare.
• ~all = SoftFail per quegli IP; non impone accettazione con marcatura.
• +all = Pass per qualsiasi IP la cui valutazione raggiunga il termine.

+all può autorizzare IP arbitrari per l'identità SPF valutata e indebolisce la politica. Errori o regole negative precedenti possono ancora intervenire; non garantisce una falsificazione riuscita, ma un'autorizzazione tanto ampia può facilitare abusi. Una politica con +all richiede una revisione. Sostituisci +all con autorizzazioni limitate, come -all, dopo inventario e test dei mittenti legittimi.

4. Return-Path dei servizi esterni

Uno strumento marketing può usare il proprio dominio per i mancati recapiti senza che Return-Path sia assente. Il dominio di tracciamento non è necessariamente quello personalizzato della busta. Per SPF allineato, il dominio valutato deve allinearsi a From, sul dominio organizzativo nel modo rilassato o esattamente in quello rigoroso. DMARC può anche passare con una firma DKIM valida e allineata.

Alcuni fornitori consentono un sottodominio di ritorno come bounce.yourcompany.com. Verifica supporto, istruzioni e modalità di allineamento; non è sempre necessario se DKIM offre già un percorso allineato. Consulta allineamento DMARC e reputazione del dominio.

Generatori: utilità e precauzioni

I generatori SPF variano per qualità e portata. Possono aiutare, ma devi verificare cosa controllano e le informazioni fornite.

Strumenti utili

I visualizzatori di catene include: aiutano a verificare dipendenze e termini valutati. Alcuni strumenti per il recapito delle email offrono questa funzione; conferma che coprano il percorso pertinente.

I validatori di sintassi rilevano alcuni errori nei separatori e nei caratteri. Dipendenze assenti e consultazioni vuote richiedono anche verifiche DNS, non soltanto l'analisi del testo.

Punti da controllare

Una procedura guidata con un clic può generare ?all, che restituisce Neutral per gli IP che raggiungono quel termine. Non equivale a pass né dimostra universalmente sfiducia. Scegli -all o ~all secondo inventario, test e obiettivi, senza presumere che il valore predefinito sia adatto.

Divisione delle stringhe TXT: ogni stringa ammette fino a 255 ottetti. Uno SPF lungo può occupare più stringhe fra virgolette in un solo record. Vengono concatenate senza inserire spazi, perciò devono conservare i separatori necessari:

• Struttura corretta: "v=spf1 include:a..." "include:b... -all" rappresenta due stringhe in un record, ma l'esempio abbreviato richiede un separatore appropriato nella concatenazione.
• Errato: due TXT SPF indipendenti causano PermError.

Verifica come il DNS pubblica le stringhe e valida il testo concatenato. Un generatore può dividerle in modo errato e produrre sintassi non valida.

Consulta la guida agli strumenti e alla configurazione SPF per orientare i controlli, senza presumere che ogni strumento citato sia validato per il tuo caso.

Configurazione e centralizzazione con TrekMail

Le grandi suite offrono funzionalità utili per alcuni clienti, meno per altri. Certi piani addebitano ogni utente; confronta funzioni, contratti e necessità senza presumere che ogni servizio aggiuntivo sia inutile.

Se TrekMail è l'unico trasporto autorizzato, questo modello può servire da esempio dopo la verifica delle istruzioni attuali:

v=spf1 include:spf.trekmail.net -all

Ospitare un dominio su TrekMail non rende automaticamente completa questa politica: possono esistere altri mittenti o SMTP esterno. L'infrastruttura gestita può occuparsi di IP, PTR e risorse di feedback nel proprio ambito. Non elimina la preparazione graduale dei flussi e l'analisi degli abusi, né garantisce il recapito.

Un fornitore con 50 domini che usano esclusivamente lo stesso trasporto potrebbe pubblicare 50 politiche equivalenti. Ripetere una configurazione cento volte facilita la standardizzazione, ma ogni cliente richiede inventario e verifiche propri. Il modello senza addebito per utente dipende dal piano e non elimina differenze legittime fra domini.

Per una migrazione, consulta la panoramica sulla migrazione IMAP e i record DNS richiesti. IMAP copia i dati accessibili delle caselle; MX, SPF, DKIM e DMARC si preparano separatamente, con test e piano di transizione. L'importazione in blocco dei domini può essere disponibile secondo pannello e piano: consulta l'importazione dei domini.

Buone pratiche SPF

I requisiti di autenticazione sono diventati più esigenti nel 2024 per determinati servizi e volumi. Un record SPF adeguato aiuta a rispettarli, ma la sua assenza o validità non decide da sola il destino di ogni email legittima.

Riepilogo dei controlli:

1. Verifica la pubblicazione. Esegui dig +short txt yourdomain.com e distingui SPF dagli altri TXT. Più SPF applicabili, non semplicemente più TXT, causano PermError.
2. Unisci le autorizzazioni pertinenti. Una politica per nome per i servizi che usano quel dominio della busta, con stringhe TXT concatenate correttamente.
3. Conta i termini valutati. Usa un visualizzatore. Oltre 10, valuta meno dipendenze o identità separate per sottodominio; il flattening richiede manutenzione.
4. Valuta -all. Considera il passaggio da ~all dopo inventario e test. Sostituisci +all con autorizzazioni limitate senza interrompere mittenti legittimi.
5. Verifica Return-Path e allineamento. Per Mailchimp o HubSpot, valuta un dominio personalizzato dei mancati recapiti quando serve. DMARC richiede SPF riuscito e allineato oppure una firma DKIM valida e allineata.
6. Non fermarti a SPF. L'inoltro può influire su SPF e anche su DKIM se modifica dati firmati. Configura tutti e tre: SPF, DKIM e DMARC.

Un record illustrativo di 50 byte merita la stessa cura di uno lungo. Verifica la configurazione iniziale e dopo le modifiche; un controllo annuale può integrare il monitoraggio, non sostituirlo.

Centralizza il DNS quando è utile. Consulta l'opzione gratuita TrekMail e le condizioni attuali dell'hosting a prezzo fisso e degli strumenti SPF, DKIM e DMARC.