I 6 errori SPF più comuni e come risolverli

Le tue email sono autenticare, il tuo DNS è pulito e la deliverability è solida. Poi un giorno, una nuova piattaforma di marketing viene messa online, qualcuno modifica un record DNS e improvvisamente metà delle tue email finiscono nello spam. Ti suona familiare?

Le anomalie SPF (Sender Policy Framework) sono tra i problemi di autenticazione più comuni che vediamo nelle oltre 1.200 organizzazioni che utilizzano Red Sift OnDMARC. E nel 2026, con Google, Yahoo e Microsoft che richiedono l'autenticazione obbligatoria per i bulk sender, un record SPF errato non danneggia solo la deliverability. Taglia completamente ogni forma di comunicazione con i tuoi clienti.

SPF è uno dei tre protocolli fondamentali di autenticazione email, insieme a DKIM (DomainKeys Identified Mail) e DMARC (Domain-based Message Authentication, Reporting, and Conformance). Funziona tramite la pubblicazione di un record DNS TXT che elenca quali indirizzi IP e server sono autorizzati a inviare email per il tuo dominio. Quando un server di posta ricevente riceve un messaggio, controlla l’IP del mittente rispetto al tuo record SPF. Se non c’è corrispondenza, l’email fallisce l’autenticazione.

Ecco perché conta oggi. Nel febbraio 2024, Google e Yahoo hanno iniziato a richiedere a tutti i bulk sender (oltre 5.000 email al giorno) di autenticare le email con SPF e DKIM e pubblicare un record DMARC [1]. Microsoft li ha seguiti a maggio 2025, applicando gli stessi requisiti per Outlook.com, Hotmail.com e Live.com [2]. Questi tre provider gestiscono insieme circa il 90% di una tipica lista email B2C. Un record SPF errato può bloccare la consegna alla stragrande maggioranza della tua audience da un giorno all’altro.

La posta in gioco va oltre la deliverability. Il rapporto FBI sulle cybercrime del 2024 registra 193.407 segnalazioni per phishing e spoofing, che rappresentano la categoria più segnalata, con perdite internet complessive di 16,6 miliardi di dollari (+33% rispetto al 2023) [3]. Il solo Business Email Compromise (BEC) ha causato perdite per 2,77 miliardi di dollari in 21.442 casi [4]. Un’autenticazione email correttamente configurata, a partire da SPF, è la prima difesa contro l’impersonificazione del dominio.

E non sono solo i provider di posta a spingere per l’adozione. PCI DSS v4.0.1 da marzo 2025 impone DMARC almeno a quarantena o reject per chi processa pagamenti con carta [5]. CISA BOD 18-01 richiede p=reject per i domini federali statunitensi. L’NCSC del Regno Unito, ASD australiana e CCCS canadese impongono DMARC per i domini governativi. Anche le polizze cyber assicurative richiedono sempre più spesso enforcement DMARC come prerequisito. Tutti i dettagli nella nostra analisi globale sui requisiti DMARC.

La sintesi: gli errori SPF nel 2026 non sono un piccolo fastidio. Sono un problema serio per deliverability, compliance e sicurezza.

Vediamo allora i sei errori SPF più comuni e come risolverli.

Come si presenta: Email inviate tramite un servizio legittimo (CRM, helpdesk, sistema HRP/ERP) falliscono lo SPF perché i loro IP non sono elencati nel record SPF.

Perché accade: È l’errore SPF più comune e di solito è semplicemente perché qualcuno ha attivato un nuovo servizio di invio senza aggiornare il DNS. Il supporto inizia a usare Zendesk per le email clienti, l’ingegneria integra un ERP per le notifiche transazionali, ecc. Ognuno usa il dominio aziendale e ciascuno va esplicitamente autorizzato nel record SPF.

Il problema si aggrava nel tempo. Le aziende acquisiscono società con sistemi diversi, i fornitori cambiano IP senza preavviso, un account di prova diventa produttivo ma nessuno aggiorna il DNS. Le aziende che usano Salesforce, SAP o Zendesk accanto alle infrastrutture principali sono particolarmente esposte a queste lacune.

Come risolvere:

Fai un audit di tutti i servizi che inviano email per conto del tuo dominio. Verifica i report aggregati DMARC: indicano esattamente quali IP stanno inviando e se stanno passando o fallendo SPF. Se usi Red Sift OnDMARC, la piattaforma individua e segnala automaticamente i mittenti non autorizzati.

Una volta individuati tutti i servizi legittimi, aggiungi i loro meccanismi SPF nel record. Ogni servizio mail pubblica il suo meccanismo include, ad esempio include:spf.protection.outlook.com per Microsoft 365 o include:_spf.google.com per Google Workspace.

Un esempio pratico: Se usi Google Workspace e Zendesk, il tuo record SPF dovrebbe essere simile a:

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

Consiglio: Pianifica un audit SPF trimestrale. Ogni volta che aggiungi o rimuovi un servizio, aggiorna il DNS. I report DMARC semplificano il processo: mostrano tutti gli invii e i relativi fallimenti, così non vai a tentativi. Inoltre, rimuovi record SPF superflui rispetto all’allineamento SPF (approfondiremo poi).

Come si presenta: Il record SPF produce un PermError (errore permanente) e tutte le email dal tuo dominio falliscono l'autenticazione SPF. Tutti i messaggi, non solo alcuni.

Perché accade: RFC 7208 (lo standard SPF) impone un limite di 10 lookup DNS per ogni verifica SPF [6]. I meccanismi include, a, mx e exists, più il modificatore redirect, contano tutti nel computo. I meccanismi ip4 e ip6 no, poiché contengono direttamente l'IP e non richiedono ulteriori risoluzioni DNS.

La matematica diventa critica in fretta. Un tipico Microsoft 365 consuma 2 lookup. Google Workspace ne usa 4. Se aggiungi SendGrid (1), Salesforce (2) e qualche altro servizio, sei già fuori budget. Ogni include può includere a sua volta altri include: anche quelli contano. Sono 10 query DNS totali, considerando tutte le chiamate ricorsive dovute alle catene di include.

Quando superi quota 10 e l’IP autorizzato non è stato ancora trovato, il server ricevente restituisce un PermError e smette di valutare. DMARC interpreta questo come fallimento SPF [7]. Le tue email vengono rifiutate o indirizzate nello spam e resti appeso solo al DKIM, che però non aiuta se il servizio di invio particolare non lo ha attivato.

Received-SPF: permerror (yourdomain.com: too many DNS lookups)
  client-ip=203.0.113.45;
  envelope-from=noreply@yourdomain.com;
  helo=mail.yourdomain.com;

Come leggerlo: permerror conferma che il server ricevente ha raggiunto il limite di 10 lookup prima di risolvere il mittente autorizzato, e non che il mittente sia effettivamente non autorizzato. La stringa reason riporta la motivazione in inglese chiaro. client-ip ed envelope-from sono i due campi da incrociare col tuo SPF per individuare qual è la catena include che ti porta fuori soglia.

C’è anche un altro limite poco noto: la regola dei 2 void lookup. Se due query DNS durante la valutazione danno NXDOMAIN (dominio inesistente) o una risposta vuota, una terza void lookup genera un PermError [8]. Questo accade spesso quando un include punta a un dominio che non pubblica più un record SPF, come un vendor dismesso.

Come risolvere:

Innanzitutto conta gli attuali lookup. Usa Red Sift Investigate per interrogare il tuo SPF e vedere quante chiamate DNS richiede.

Poi riduci il numero di lookup:

• Rimuovi servizi non più attivi. Se hai disdetto Mailchimp mesi fa ma l’include è ancora lì, eliminalo. Vecchi CRM, tool di email in trial e include aggiunti da ex dipendenti sono cause frequenti.
• Elimina meccanismi ptr.ptr. Lo standard SPF ne sconsiglia fortemente l’uso (ora deprecati) e consumano lookup inutili.
• Delegare ai sottodomini. Ogni sottodominio può avere il suo SPF e budget di 10 lookup. Invia le mail marketing da info.iltuodominio.com con un record SPF dedicato, mantenendo il dominio principale snello.

Se non riesci a stare sotto i 10 lookup in modo manuale, Dynamic SPF di Red Sift OnDMARC lo risolve automaticamente. Dynamic SPF sostituisce il record SPF complesso con un solo smart include che si risolve solo sugli IP realmente attivi. Gestisci i mittenti direttamente da OnDMARC e il DNS rimane in regola.

Come si presenta: L'autenticazione SPF fallisce su tutte le email, o il record non viene riconosciuto come SPF. Potresti vedere PermError o None nei report DMARC.

Perché accade: I record SPF seguono regole di sintassi molto rigide (RFC 7208). Basta un errore per invalidare tutto. Gli errori più comuni sono:

• Version tag mancante o errato. Ogni record deve iniziare con v=spf1. Errori come v=spf2, v=spf11 o uno spazio di troppo lo invalidano.
• Spazi mancanti tra i meccanismi. Ogni meccanismo deve essere separato da uno spazio. Ad esempio include:_spf.google.cominclude:mail.zendesk.com (senza spazio) blocca tutto.
• Formattazione meccanismi errata. I meccanismi ip4 e ip6 richiedono i due punti (ip4:192.168.1.1), non uguali o slash.
• Meccanismi con errori di battitura. Scrivere incldue per include o ipv4 per ip4 li rende inutilizzabili.
• Uso del meccanismo deprecato ptr.ptr. Anche se ancora interpretato, ptr è deprecato secondo RFC 7208 e crea carico DNS inutile.

Questi errori impattano ogni email. Il server ricevente blocca tutto il record e restituisce PermError (se riesce a leggerlo parzialmente) o None (se non lo riconosce affatto come SPF).

Come risolvere:

Convalida sempre il record SPF prima della pubblicazione. Red Sift Investigate controlla in pochi secondi sintassi, numero di lookup e altre anomalie.

Ecco una struttura SPF corretta da usare come riferimento:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all

Nota: v=spf1 all’inizio, spazi tra meccanismi, i due punti dopo ip4 e un solo qualificatore ~all alla fine. Valida sempre dopo ogni modifica, attendi fino a 24h per la propagazione DNS e consulta i report DMARC per eventuali anomalie.

Come si presenta: SPF restituisce PermError e l’autenticazione SPF fallisce su tutte le email. È una casistica di blocco totale.

Perché accade: Lo standard SPF impone un solo record TXT SPF per dominio [6]. Se ci sono due o più record, i server riceventi non sanno quale applicare e restituiscono PermError.

Accade solitamente quando team diversi gestiscono parti diverse dell’infrastruttura email. L’IT pubblica il record per Microsoft 365. Il marketing ne aggiunge un altro per la piattaforma mail. Un consulente ne crea un terzo per un progetto di deliverability. Nessuno verifica se ci fosse già un record, così ne hai tre — e nessuno funziona.

$ dig yourdomain.com TXT +short

"v=spf1 include:spf.protection.outlook.com ~all"
"v=spf1 include:_spf.google.com ~all"

Come leggerlo: due stringhe distinte che iniziano entrambe con v=spf1. Il server non ha alcuna regola per scegliere, li scarta tutti e restituisce PermError, come nel caso limite dei lookup ma per eccesso di record. La correzione è unire tutto in un solo record e poi verificare con lo stesso comando dig che resti solo un v=spf1.

Può anche capitare durante le migrazioni. Passi da Google Workspace a Microsoft 365? Se non rimuovi il vecchio record Google quando aggiungi quello Microsoft, rimani con due record e una configurazione inutilizzabile.

Come risolvere:

Interroga i record TXT del dominio e cerca quelli che iniziano con v=spf1. Ne deve risultare uno solo. Se sono multipli, unisci tutti i mittenti autorizzati in un unico record.

Ad esempio, se hai:

Record 1: v=spf1 include:spf.protection.outlook.com ~all Record 2: v=spf1 include:_spf.google.com ~all

Uniscili così:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all

Poi elimina il record duplicato. Dopo la fusione, valida che il record risultante non superi i 10 lookup. Centralizzare la gestione DNS e richiedere approvazione alle modifiche previene ricadute. Se più team devono gestire i mittenti, usa una piattaforma come Red Sift OnDMARC da cui gestirli tramite un’unica interfaccia.

Come si presenta: Le email passano SPF nella consegna diretta ma falliscono quando vengono inoltrate o ridistribuite tramite una mailing list. I report DMARC mostrano fallimenti SPF da IP associati a server forwarder noti (università, ISP, mail server aziendali).

Perché accade: È una limitazione intrinseca di SPF, ed è l’unico errore qui non dovuto a una configurazione errata.

SPF verifica se l’IP del server inviante è autorizzato per il dominio mittente. Quando una mail viene inoltrata, il server di inoltro (Server B) la invia al destinatario finale (Server C) usando il proprio IP. Server C lo confronta con il record SPF originale e non trova corrispondenza: l’IP del forwarder non è autorizzato. SPF fallisce.

Le mailing list peggiorano la situazione: spesso modificano il corpo messaggio (footer, header, link unsubscribe), invalidando la firma DKIM. Se falliscono sia SPF che DKIM, fallisce anche DMARC.

Questo è proprio il design di SPF, pensato per consegna diretta e senza gestire server intermediari.

Come risolvere:

Non puoi "aggiustare" SPF per l’inoltro in senso stretto, ma puoi rafforzare la struttura di autenticazione:

• Fai di DKIM il tuo principale backup. DKIM si basa sui contenuti, non sul percorso. Finché il corpo non viene alterato, la firma resta valida e DMARC passa. Assicurati che ogni servizio firmi con DKIM usando il tuo dominio. Vedi la nostra guida completa alla configurazione SPF, DKIM e DMARC. La nostra guida spiega anche gestione delle chiavi DKIM, setup dei selector e troubleshooting avanzato.
• Usa ~all (soft fail), non -all (hard fail). Alcuni server valutano SPF prima di DMARC. Con -all potrebbero rifiutare direttamente la mail a livello SMTP senza che DKIM o DMARC la valutino. Il soft fail la fa arrivare a DMARC, dove una firma DKIM valida può salvarla. Nel 2026 il consiglio per i domini attivi è ~all [9]. In combinazione con DMARC impostato su p=reject, ottieni la stessa protezione senza blocchi anticipati indesiderati.
• Conosci ARC (Authenticated Received Chain). ARC consente ai server intermedi di "sigillare" i risultati originali SPF e DKIM, cosicché il server finale possa considerarli anche se SPF fallisce sull’ultimo hop. ARC viene applicato automaticamente da provider principali, non va configurato lato mittente [10].

Nota: L’IETF ha appena approvato la dismissione ufficiale di ARC. DKIM2 dovrebbe sostituirlo.DKIM2 dovrebbe sostituirlo.

• Monitora i fallimenti di inoltro nei report DMARC. Distingui il forwarding dagli attacchi di spoofing veri. Il traffico di inoltro viene da IP riconoscibili (mail.university.edu, relay corporate) e mostra SPF fail ma DKIM pass. Gli attacchi provengono invece da IP ignoti con fallimento sia SPF che DKIM.

Come si presenta: SPF passa (l’IP inviante è autorizzato), ma DMARC fallisce comunque. Questo confonde molti, perché si pensa che se SPF passa allora DMARC passerà per forza. Non è così. Se vuoi approfondire come lavorano insieme SPF, DKIM e DMARC, questo punto è fondamentale.

Perché accade: DMARC richiede l’allineamento tra il dominio che supera l’autenticazione e il dominio visibile nel From. Per SPF, significa che il dominio nel Return-Path (detto anche bounce address, envelope from o MAIL FROM) deve coincidere, o essere un sottodominio, col dominio del From che vede il destinatario.

Molti servizi di invio usano di default un loro dominio come Return-Path. Salesforce, ad esempio, gestisce i bounce col suo dominio a meno che tu non lo configuri diversamente. SPF esamina Return-Path, trova l’IP in regola sullo SPF Salesforce, quindi SPF passa. Ma DMARC verifica l’allineamento: "Il dominio di Return-Path corrisponde a quello visibile nel From?" Se il From è @yourdomain.com e il Return-Path è @bounce.salesforce.com, fallisce l’allineamento. SPF passa l’autenticazione ma fallisce l’allineamento. Se non puoi allineare SPF, DKIM diventa ancora più cruciale.

Qui si bloccano in molti, specie durante la messa in produzione di DMARC: configuri SPF correttamente ma non capisci perché DMARC continua a fallire o SPF appare come non allineato.

Come risolvere:

Per ogni servizio, configura il Return-Path (bounce address) in modo che usi il tuo dominio o un suo sottodominio. Le istruzioni variano in base alla piattaforma:

• Salesforce: Disabilita la bounce management affinché Salesforce usi il tuo dominio come Return-Path.
• Microsoft 365: L’allineamento Return-Path viene gestito automaticamente se usi il tuo dominio personalizzato.
• Piattaforme marketing (HubSpot, Marketo, Mailchimp): Quasi tutte offrono la possibilità di impostare Return-Path personalizzato o envelope-from. Verifica la documentazione ufficiale.

DMARC supporta due modalità di allineamento:

• Allineamento rigido (aspf=s):aspf=s): Il dominio nel Return-Path deve essere esattamente identico al dominio nel From.
• Allineamento rilassato (aspf=r):aspf=r): Il Return-Path può essere un sottodominio del From. È la modalità predefinita, consigliata per la maggior parte delle aziende.

Con allineamento rilassato, se il tuo From è @yourdomain.com e il Return-Path è @mail.yourdomain.com, l’allineamento passa. Così puoi usare sottodomini sui vari servizi email mantenendo la compliance DMARC.

Il principale strumento diagnostico sono i report aggregati DMARC, che mostrano se c’è fallimento in SPF (autorizzazione) o in allineamento (mancata corrispondenza tra Return-Path e From).

Red Sift OnDMARC visualizza tutto in modo intuitivo: vedi subito quali mittenti passano SPF ma falliscono in allineamento e su quali coppie di domini avviene la difformità. Avvia la procedura step-by-step di implementazione DMARC e controlla ogni mittente in modo sistematico.

I report aggregati DMARC contengono tutto ciò che ti serve per individuare e risolvere i problemi SPF. Ecco cosa osservare:

Se stai analizzando manualmente i report DMARC (elaborando file XML), stai impiegando ore per un lavoro che una piattaforma può svolgere in pochi secondi. Red Sift OnDMARC trasforma i dati grezzi dei report aggregati in dashboard chiare e operative che mostrano esattamente quali mittenti stanno fallendo, perché stanno fallendo e come risolvere i problemi. Per una panoramica dei migliori strumenti da utilizzare in ogni fase, consulta la nostra guida ai principali strumenti di autenticazione email.

I fallimenti SPF sono risolvibili. Ognuno dei sei casi di fallimento trattati in questa guida ha un percorso diagnostico chiaro e una soluzione concreta. La vera sfida non è la complessità, ma la visibilità.

Senza i report DMARC, navighi alla cieca. Non sai quali servizi stanno inviando email come il tuo dominio, quali stanno fallendo l’autenticazione o perché. Con i report, ogni fallimento diventa una voce che puoi esaminare e risolvere.

Se stai gestendo problemi SPF proprio ora, inizia con una scansione gratuita utilizzando Red Sift Investigate per vedere lo stato attuale del tuo record. Per monitoraggio continuo, gestione automatica dei mittenti e un percorso chiaro verso l’applicazione DMARC, attiva una prova gratuita di Red Sift OnDMARC.

[1] Una novità sui requisiti per mittenti massivi - Google

[2] Rafforzare l’ecosistema email - Microsoft Community Hub

[3] FBI pubblica il Rapporto annuale sui crimini informatici

[4] Rapporto annuale IC3 2024

[5] PCI DSS v4.0.1 Riepilogo delle modifiche

[6] RFC 7208 - Sender Policy Framework (SPF)

[7] Il limite delle query SPF spiegato - Mailhardener

[8] RFC 7208 Sezione 4.6.4 - Limiti delle query DNS

[9] SPF failure: hard fail contro soft fail - Red Sift

[10] ARC: risolvere il problema DMARC con l’inoltro email - Mailflow Authority