Verifica SPF in Exchange: come verificare, pubblicare e correggere i record SPF in Exchange

Nel maggio 2025, Microsoft ha iniziato a respingere le e-mail provenienti da mittenti ad alto volume privi di SPF, DKIM e DMARC validi. Se il tuo dominio invia più di 5.000 messaggi al giorno a Outlook.com o Hotmail.com senza un'autenticazione adeguata, tali messaggi non raggiungeranno mai la casella di posta in arrivo.

Google e Yahoo hanno introdotto requisiti simili nel febbraio 2024. Secondo il team di sicurezza e-mail di Google, quella prima fase di applicazione delle norme ha ridotto i messaggi non autenticati ricevuti dagli utenti Gmail di circa il 75%.

Secondo il FBI IC3 Internet Crime Report, 2023. 

Il problema negli ambienti Exchange è che gli errori SPF non vengono segnalati. Exchange Online non invia alcuna notifica quando il record non è più valido. Non esiste una dashboard integrata che mostri i tassi di superamento del test. La maggior parte dei team se ne accorge solo settimane dopo, quando gli utenti segnalano che le e-mail vengono respinte o quando il reparto marketing segnala un crollo dei tassi di apertura.

Questa guida spiega come verificare il record SPF di Exchange utilizzando quattro metodi diversi, come pubblicare il record corretto per Exchange Online, le configurazioni on-premise e quelle ibride, e come correggere gli errori SPF più comuni errori SPF (incluso il limite di 10 look-up che compromette l'SPF nella maggior parte delle organizzazioni di medie dimensioni), come Exchange Online valuta effettivamente l'SPF sotto il cofano e come monitorare l'SPF in modo continuo invece di controllarlo una volta sola e poi dimenticarsene.

Come verificare il record SPF del proprio provider di posta elettronica (passo dopo passo)

Esistono quattro metodi affidabili per verificare il proprio record SPF, dal più veloce al più completo. Usa il Metodo 1 per una verifica rapida, il Metodo 4 per una visibilità operativa continua.

Metodo 1: Utilizzare uno strumento di ricerca SPF (il più veloce)

1. Apri un qualsiasi strumento di verifica SPF (il PowerDMARC SPF Checker è gratuito e non richiede registrazione)
2. Inserisci il tuo dominio (ad es. tuodominio.com, senza il prefisso http://) e 
3. Controlla il risultato

La ricerca restituisce diversi risultati di convalida SPF. Ecco il significato di ciascun campo dell'output e a cosa prestare attenzione durante la lettura: 

Un record può essere analizzato correttamente e il numero di risultati può essere pari a sei, ma potrebbe comunque mancare una fonte di invio legittima. Lo strumento di verifica SPF convalida i dati presenti nel DNS, ma non sa quali IP dovrebbero essere autorizzati.

Metodo 2: Verifica tramite il Centro di amministrazione di Microsoft 365

Accedi al Centro di amministrazione di Microsoft 365. Vai su Impostazioni → Domini → seleziona il tuo dominio → Record DNS. Nella sezione Microsoft Exchange, verifica che lo stato del record TXT sia OK.

Se lo stato indica "Inserimento non valido", significa che il tuo record SPF è mancante oppure non include la dichiarazione obbligatoria include:spf.protection.outlook.com. Questo è il modo più veloce per verificare l'SPF senza uscire dal portale di amministrazione.

Metodo 3: Verifica tramite riga di comando (nslookup / dig)

Per la risoluzione dei problemi lato server o nei casi in cui non si disponga di accesso tramite browser, è possibile interrogare il record TXT SPF del proprio dominio direttamente dalla riga di comando.

Esegui uno dei seguenti comandi: 

# Windows

nslookup -type=txt tuodominio.com

# Linux 

/ macOSdig txt iltuodominio.com +short

L'output restituisce il record TXT grezzo. Cerca la riga che inizia con v=spf1. Se vedi due righe di questo tipo, significa che sono presenti più record SPF, il che comporta un errore PermError immediato. Risolvi il problema prima di procedere con qualsiasi altra operazione.

Metodo 4: Verifica tramite i rapporti aggregati DMARC (il metodo di riferimento)

I rapporti aggregati forniti dai provider di posta elettronica, come Gmail, Yahoo, Microsoft, Mail.ru e gli ISP regionali, mostrano i tassi di superamento/fallimento del controllo SPF per ogni e-mail inviata dal tuo dominio, non solo per un singolo messaggio di prova. Questo è l'unico modo per ottenere un quadro completo e aggiornato dello stato di salute dell'SPF.

Se state implementando DMARC con un tag `rua=`, state già raccogliendo questi report. La maggior parte delle organizzazioni li riceve, ma solo poche li analizzano, poiché il codice XML grezzo è illeggibile senza una piattaforma che lo analizzi.

PowerDMARC acquisisce quotidianamente questi rapporti e presenta analisi specifiche relative all'SPF in una dashboard dedicata, con percentuali di superamento/fallimento per ogni fonte di invio, monitoraggio delle ricerche DNS e avvisi quando compare un nuovo mittente non autorizzato.

Metodo 5: Verifica tramite le intestazioni dei messaggi di Exchange (convalida nel mondo reale)

Per verificare come viene valutato l'SPF da parte di un destinatario reale:

• Invia un messaggio di prova dal tuo dominio a un indirizzo esterno (va bene anche un account Gmail personale).
• Apri il messaggio e recupera tutte le intestazioni. In Outlook: File → Proprietà → Intestazioni Internet. In OWA o Gmail: Visualizza sorgente / Mostra originale.
• Individua l'intestazione "Authentication-Results" e cerca il campo "spf=".

Ecco come appare l'intestazione in questione con le annotazioni:

Risultati dell'autenticazione: 

spf=pass (l'IP del mittente è 40.107.22.83)  

smtp.mailfrom=tuodominio.com;  

dkim=pass (la firma è stata verificata)  

header.d=tuodominio.com;  

dmarc=passato action=nessuna  

header.from=tuodominio.com;  

compauth=pass motivo=100

Il messaggio "spf=pass" conferma che l'IP mittente è stato autorizzato dal tuo record SPF. Se visualizzi "spf=fail", "spf=softfail" o "spf=permerror", il risultato specifico ti indica quale è il problema:

• spf=fail: L'IP mittente non è presente nel tuo record SPF.
• spf=softfail: L'indirizzo IP non è autorizzato, ma il tuo record utilizza ~all invece di -all.
• spf=permerror: Il tuo record SPF presenta un problema strutturale (più di 10 ricerche, record multipli, errore di sintassi).

Come si presenta un record SPF di scambio valido

Come pubblicare un record SPF per Exchange Online (M365)

Pubblicare un record SPF per Exchange Online è semplice. Tuttavia, è proprio nel fornire i dati corretti che la maggior parte dei team commette errori.

Fase 1: Identifica tutte le tue fonti di invio autorizzate

Prima di intervenire sul DNS, controlla tutti i sistemi che inviano e-mail per conto del tuo dominio. La maggior parte delle organizzazioni sottostima tale elenco del 30–50%.

• Microsoft 365 / Exchange Online → includere:spf.protection.outlook.com
• Automazione del marketing (HubSpot, Mailchimp, Marketo, Pardot) → ognuna ha il proprio codice di inclusione
• CRM (Salesforce, Microsoft Dynamics) → consultare la documentazione SPF del fornitore
• Email transazionali (SendGrid, Amazon SES, Postmark, Mailgun) → file di inclusione specifici per fornitore
• Assistenza tecnica / gestione dei ticket (Zendesk, Freshdesk, ServiceNow) → integrazioni specifiche per fornitore
• Risorse umane / paghe (BambooHR, Gusto, Workday) → verificare se inviano notifiche dal proprio dominio
• Server on-premise legacy → IPv4: con indirizzi IP pubblici

Il modo più affidabile per individuare mittenti che non conoscevi è i report aggregati DMARC. Ogni fonte legittima (e illegittima) che invia messaggi dal tuo dominio viene visualizzata lì.

Fase 2: Creare il record SPF

Inizia con il tag della versione, aggiungi le fonti autorizzate e termina con il qualificatore.

Esempio di base di M365:

v=spf1 

include:spf.protection.outlook.com -all

Tipica azienda di medie dimensioni che utilizza HubSpot e SendGrid:

v=spf1 

includere: spf.protection.outlook.com 

includere:_spf.hubspot.com 

include:sendgrid.net -tutto

Conta le ricerche DNS man mano che procedi con la configurazione. Ogni meccanismo include:, a:, mx:, ptr: ed exists: genera una ricerca. I meccanismi ip4: e ip6: non vengono conteggiati. Anche gli include annidati vengono conteggiati, poiché include:spf.protection.outlook.com richiede internamente da 2 a 4 ricerche aggiuntive mentre si propaga attraverso l'infrastruttura di Microsoft.

Passaggio 3: Pubblicare il record nel DNS

Il processo di pubblicazione varia leggermente a seconda del provider DNS, ma segue lo stesso schema:

Impostazioni da utilizzare in modo coerente:

• Tipo di record: TXT
• Host / Nome: @ (o vuoto, a seconda del provider)
• TTL: 3600 (1 ora) durante la fase di test, poi 86400 (24 ore) una volta raggiunta la stabilità

Importante: Solo un record SPF per dominio. Un secondo record TXT v=spf1 è un errore permanente (PermError) in attesa di essere rilevato. Se il processo di configurazione del tuo provider DNS crea automaticamente un record quando aggiungi un servizio, verifica immediatamente la presenza di duplicati.

Passaggio 4: Verifica del record pubblicato

• Attendere 5–60 minuti affinché il DNS si propaghi (a seconda del TTL e del provider).
• Esegui nuovamente la ricerca SPF descritta nel Metodo 1 per verificare che il record venga risolto correttamente.
• Controlla il Centro di amministrazione di M365 (Metodo 2). Lo stato del record TXT dovrebbe ora essere "OK".
• Invia un messaggio di prova a un indirizzo esterno e verifica che nelle intestazioni sia presente la riga "spf=pass".
• Verifica che il numero di ricerche DNS sia inferiore a 10.

Se preferisci non creare il record manualmente, il Generatore SPF di PowerDMARC genera un record correttamente formattato una volta che hai elencato le tue fonti di invio.

SPF per ambienti di Exchange ibridi: on-premise + cloud

Gli ambienti Exchange ibridi rendono l'SPF notevolmente più complesso, poiché le e-mail possono provenire contemporaneamente sia da Microsoft 365 che dall'infrastruttura locale. Soprattutto durante le migrazioni, i percorsi del flusso di posta spesso si sovrappongono in modi tali da causare errori SPF non rilevati, a meno che ogni percorso in uscita non venga gestito correttamente.

La sfida dell'ibrido: due percorsi di posta, un unico record SPF

In un ambiente ibrido, la posta in uscita può essere inviata attraverso tre diversi percorsi:

• Direttamente tramite Exchange Online: per le caselle di posta ospitate in M365
• Server Exchange o Edge Transport in locale: per le caselle di posta ancora in locale
• Host intelligenti o relay di terze parti: quando la posta viene instradata esternamente prima di raggiungere la rete Internet pubblica

Ciascun percorso presenta al server destinatario un indirizzo IP di origine diverso. L'SPF non tiene conto del percorso previsto, poiché verifica solo se l'indirizzo IP effettivamente rilevato è autorizzato. Entrambi i percorsi devono essere inclusi in un unico record SPF, poiché è consentito un solo record SPF per dominio.

Come configurare l'SPF per Exchange Hybrid

Includere entrambi i percorsi di autorizzazione:

v=spf1 include:spf.protection.outlook.com ipv4:203.0.113.10 ipv4:203.0.113.11 -all

Gli indirizzi IP locali sono gli indirizzi pubblici utilizzati dal server di posta quando invia messaggi su Internet, non gli indirizzi interni RFC 1918. Controlla i connettori di invio del server Edge Transport e tutte le regole NAT o del firewall che determinano l'indirizzo IP pubblico. Se disponi di ridondanza geografica o di più percorsi in uscita, ogni indirizzo IP pubblico da cui potrebbero essere inviati messaggi di posta deve essere presente nel record.

SPF durante la migrazione (stato transitorio)

La migrazione graduale o con passaggio graduale comporta un periodo in cui le caselle di posta sono presenti in entrambe le posizioni e la posta può essere inviata da entrambe le vie. L'SPF deve garantire la copertura di entrambe le vie per l'intera durata del processo.

• Prima di avviare la migrazione: Assicurati che il tuo record SPF copra sia gli indirizzi IPv4 locali che includa: spf.protection.outlook.com.
• Durante la migrazione: Lascia attive entrambe le autorizzazioni. Monitora i tassi di superamento dell'SPF tramite i report aggregati DMARC. Se le modifiche al routing deviano la posta attraverso percorsi inattesi, i report lo segnalano prima che se ne accorgano gli utenti.
• Una volta completata la migrazione: Rimuovi le voci ip4: locali. Lasciare IP obsoleti nell'SPF rappresenta un rischio per la sicurezza. Se quei vecchi IP vengono riassegnati dal tuo ISP o dal tuo provider cloud, il nuovo tenant potrebbe inviare email autenticate come se provenissero dal tuo dominio.

Un errore comune è quello di rimuovere gli indirizzi IP locali durante la migrazione solo perché il passaggio è «quasi completato». Basta che una sola casella di posta continui a passare attraverso il vecchio percorso per compromettere l'autenticazione della posta di quell'utente.

Sottodomini in Exchange: l'SPF non viene ereditato

Un aspetto fondamentale che spesso sfugge a molte organizzazioni ibride: i sottodomini non ereditano il record SPF del dominio principale. Se marketing.tuodominio.com invia e-mail tramite un ESP separato, deve disporre di un proprio record TXT SPF. I record SPF con caratteri jolly non sono supportati dal protocollo. Ogni sottodominio che invia posta deve avere un proprio record v=spf1 pubblicato nella radice del proprio DNS.

Ciò significa anche che l'uso dei sottodomini rappresenta una strategia efficace per distribuire il carico SPF. Indirizzate le e-mail di marketing tramite marketing.vostro-dominio.com e quelle transazionali tramite mail.vostro-dominio.com, in modo che ogni sottodominio disponga di un proprio budget di 10 query. Si tratta di una pratica conforme alle RFC, ampiamente supportata dagli ESP e ampiamente utilizzata negli ambienti aziendali.

Exchange Online verifica l'SPF per la posta interna al tenant?

No. Exchange Online considera i messaggi all'interno dello stesso tenant come posta interna e non esegue la verifica SPF. I messaggi tra tenant diversi, anche se si tratta di organizzazioni partner di fiducia, sono soggetti ai controlli SPF, poiché tale posta attraversa il percorso di instradamento pubblico.

Per le organizzazioni che dispongono di più domini all'interno di un unico tenant di M365, ogni dominio deve avere un proprio record SPF. La condivisione di un record tra domini tramite CNAME non è una pratica standard e non garantisce un funzionamento affidabile.

Errori SPF più comuni in Exchange e come risolverli

Ogni scenario di risoluzione dei problemi riportato di seguito segue lo stesso schema diagnostico: sintomo → causa → soluzione.

Errore permanente: numero eccessivo di ricerche DNS

• • Sintomo: SPF restituisce PermError. I destinatari potrebbero contrassegnare come spam o rifiutare la tua email. L'allineamento DMARC non va a buon fine.
  • Causa: Più di 10 ricerche DNS nel record SPF, inclusi gli include nidificati. Questo è l'errore SPF più comune nelle organizzazioni che utilizzano più servizi SaaS.

• Soluzione (procedura in 5 passaggi):

• • Passaggio 1: Verifica il tuo attuale numero di lookup utilizzando uno strumento di controllo SPF che conta in modo ricorsivo gli include annidati.
  • Passaggio 2: Rimuovi gli include obsoleti relativi ai servizi che non utilizzi più.
  • Passaggio 3: Sostituire "include:" con "ip4:" nei casi in cui gli indirizzi IP del fornitore siano stabili e documentati.
  • Passaggio 4: Spostare i mittenti non aziendali con volumi elevati (marketing, transazioni) su sottodomini con i propri record SPF.
  • Passaggio 5: Se il valore è ancora superiore a 10, implementa l'appiattimento SPF o le macro utilizzando uno strumento come PowerSPF per risolvere automaticamente gli include in voci ip4 e mantenere aggiornato il record quando i fornitori cambiano gli IP.

Esempio prima/dopo:

Prima (14 ricerche: PermError):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com include:zendesk.com include:spf.freshdesk.com a mx -all

Dopo (7 ricerche: al di sotto del limite):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net ip4:198.2.128.0/24 ip4:192.254.113.0/24 -all# Salesforce e Zendesk sono stati spostati su mail.tuodominio.com# Freshdesk sostituito con voci ip4 appiattite# meccanismi a e mx rimossi (ridondanti con include espliciti)

Sono stati rilevati più record SPF

• Sintomo: Lo strumento di verifica SPF restituisce un errore relativo a "record SPF multipli". Tutte le valutazioni SPF falliscono.
• Causa: Esistono due o più record TXT che iniziano con v=spf1 per lo stesso dominio. Ciò accade comunemente quando il processo di provisioning di un fornitore SaaS crea un secondo record senza che l'amministratore se ne accorga.
• Correzione: Unire in un unico record. È possibile avere più meccanismi include: e ip4: all'interno di un unico record, ma solo un record TXT v=spf1 per dominio. Eliminare la voce ridondante.

L'SPF smette di funzionare dopo l'aggiunta di un nuovo strumento SaaS

• Sintomo: Le e-mail provenienti dal nuovo strumento aggiunto non superano il controllo SPF. Anche altri mittenti potrebbero non funzionare correttamente se il nuovo strumento fa superare il numero totale di lookups a 10.
• Causa: Il nuovo servizio non è stato aggiunto all'SPF oppure la sua aggiunta ha superato il limite di ricerca.
• Soluzione: Aggiungi l'include, quindi esegui nuovamente la verifica delle ricerche totali. Se ora superi il numero 10, il problema è il conteggio delle ricerche, non l'include in sé. Applica la procedura in 5 passaggi sopra indicata.

Errore SPF in Hybrid Exchange (IP locale mancante)

• Sintomo: Le e-mail inviate da Exchange on-premise non superano il controllo SPF, mentre quelle provenienti da M365 lo superano.
• Causa: L'IP pubblico del server locale non è presente nel record SPF. Ciò è particolarmente comune dopo una migrazione parziale in cui l'amministratore ha aggiornato l'SPF per Exchange Online ma ha dimenticato che il percorso locale continua a instradare la posta.
• Risoluzione: Aggiungere ip4:x.x.x.x per ogni IP di uscita in locale. Se la posta viene instradata tramite un server Edge Transport, uno smart host o un relay di terze parti, è necessario includere anche l'IP pubblico di tale relay.

L'SPF non funziona dopo la migrazione a Exchange Online

• Sintomo: Le email inviate dopo la migrazione falliscono il controllo SPF su tutta la linea.
• Causa: Il DNS punta ancora ai vecchi indirizzi IP locali, tra cui: spf.protection.outlook.com non è stato aggiunto, oppure la posta viene instradata attraverso percorsi imprevisti durante la transizione.
• Risoluzione: Verificare che il record SPF includa sia i percorsi di autorizzazione precedenti (on-premise) che quelli nuovi (Exchange Online) durante la finestra di migrazione. Rimuovere le vecchie voci solo dopo aver verificato che il 100% delle caselle di posta sia stato migrato. Monitorare l'intero processo tramite i report aggregati DMARC. Questi mostrano esattamente quali percorsi seguono le e-mail dal punto di vista dei destinatari.

L'SPF viene accettato, ma l'e-mail finisce nella cartella dello spam

• Sintomo: Le intestazioni mostrano spf=pass, ma il messaggio finisce nella cartella della posta indesiderata del destinatario.
• Causa: L'SPF è solo uno dei tanti segnali. La reputazione del mittente, il contenuto, il DKIM o il DMARC potrebbero non essere validi. Ognuno di questi fattori può prevalere su un SPF valido.
• Soluzione: Verifica l'allineamento DKIM, la politica DMARC, la reputazione del mittente (stato nella blacklist, età del dominio, recenti variazioni di volume) e la reputazione dei contenuti/link. L'Analizzatore di dominio di PowerDMARC restituisce un punteggio relativo a tutti questi aspetti in un'unica scansione.

L'SPF non funziona per le e-mail inoltrate

• Sintomo: I messaggi inoltrati automaticamente, le e-mail delle mailing list o i messaggi instradati tramite regole di trasporto non superano il controllo SPF.
• Causa: L'IP del server di inoltro non è presente nel record SPF del mittente originale. Si tratta di una limitazione architettonica dell'SPF piuttosto che di un errore di configurazione.
• Risoluzione: Considerare l'errore SPF sulla posta inoltrata come un comportamento previsto. Assicurarsi che DKIM sia configurato correttamente per il proprio dominio. Le firme DKIM sopravvivono all'inoltro, il che consente a DMARC di superare il controllo tramite l'allineamento DKIM anche quando SPF fallisce. ARC (Authenticated Received Chain) in Exchange Online preserva ulteriormente i risultati dell'autenticazione attraverso le catene di inoltro attendibili.

Come Exchange Online elabora effettivamente i risultati SPF (spiegazione del "black box")

La maggior parte degli amministratori di Exchange si trova di fronte allo stesso dubbio: in che modo Exchange Online Protection (EOP) gestisce effettivamente gli errori SPF? Alcune fonti sostengono che un errore grave comporti il rifiuto automatico. Altre suggeriscono invece che l'SPF sia solo un indicatore secondario di spam. Ecco come funziona realmente.

La pipeline multisegnale (SPF è solo uno degli ingressi)

Exchange Online Protection non basa le decisioni relative alla consegna esclusivamente sull'SPF. L'SPF è uno dei fattori che concorrono a una valutazione di autenticazione complessiva che include:

• Risultato SPF: superato, fallito, fallito parzialmente, neutro, PermError o TempError
• Risultato DKIM: superato, fallito o assente
• Risultato DMARC: derivato dall'allineamento di SPF o DKIM con il dominio From dell'intestazione
• Reputazione del mittente: reputazione dell'IP, reputazione del dominio, modelli storici di invio
• Punteggio SCL (Spam Confidence Level): punteggio interno di Microsoft compreso tra -1 (mittente sicuro) e 9 (spam altamente probabile)
• Filtraggio dei contenuti: parole chiave, reputazione degli URL, analisi degli allegati

È il risultato complessivo dell'autenticazione, e non un singolo protocollo, che EOP utilizza per determinare la destinazione finale del messaggio.

Come EOP gestisce i diversi esiti dell'SPF

PermError è un errore grave che EOP tratta in modo quasi identico a un errore SPF vero e proprio, e si ripercuote su DMARC, compromettendo completamente l'autenticazione. Ecco perché il limite di 10 ricerche rappresenta un punto di fallimento strutturale.

Dove visualizzare i risultati SPF all'interno di Exchange

Tre luoghi, in ordine crescente di completezza:

• Intestazioni dei messaggi (Authentication-Results): Ogni messaggio elaborato da EOP viene contrassegnato con spf=pass/fail/softfail/permerror/temperror, insieme al dominio di invio e all'IP valutati.
• Tracciamento dei messaggi di Exchange: Mostra lo stato di consegna, l'IP di origine, il destinatario e la destinazione finale, ma non mette in evidenza la valutazione SPF. Se ti affidi esclusivamente alla traccia del messaggio per la visibilità SPF, stai procedendo alla cieca.
• Rapporti aggregati DMARC (RUA): L'unica fonte di dati che mostra come i destinatari in tutto il mondo valutano il tuo SPF. I rapporti RUA riportano i tassi di superamento e fallimento dell'SPF per IP e per origine su ogni server di ricezione che elabora la tua posta.

Configurazione dell'applicazione rigida delle regole SPF in EOP

Per impostazione predefinita, Exchange Online tiene conto dei risultati SPF nel punteggio composito, ma non rifiuta i messaggi basandosi esclusivamente sull'SPF. Per configurare esplicitamente EOP in modo che contrassegni i messaggi con errore grave SPF come spam:

Nel Centro di amministrazione di Exchange Online: accedere a Protezione → Filtro antispam → Opzioni avanzate e impostare l'opzione "Record SPF: errore irreversibile" su On. In alternativa, eseguire il seguente cmdlet di PowerShell:

Get-HostedContentFilterPolicy | Where-Object {$_.IsDefault -eq $true} | Set-HostedContentFilterPolicy -MarkAsSpamSpfRecordHardFail On

Migliori pratiche SPF per gli ambienti Exchange nel 2026

• Utilizza -all (hard fail) come impostazione predefinita. In combinazione con DMARC, -all rappresenta lo standard. L'unica eccezione è la fase iniziale di implementazione, prima che DMARC sia pienamente operativo.
• Non usare mai +all. Consente a chiunque su Internet di inviare messaggi a nome del tuo dominio. Se trovi +all nel tuo record, consideralo come un incidente di sicurezza in corso.
• Per M365, includere sempre spf.protection.outlook.com, anche se la posta in uscita passa attraverso un gateway di terze parti. Exchange Online genera inviti di calendario, risposte automatiche, NDR e conferme di lettura che vengono inviati direttamente dall'infrastruttura di Microsoft.
• Controlla il tuo record SPF almeno una volta ogni tre mesi. I fornitori di servizi SaaS modificano gli intervalli di indirizzi IP. I team di marketing adottano nuovi strumenti senza avvisare il reparto IT. I controlli trimestrali individuano eventuali discrepanze prima che causino un errore permanente (PermError). Il monitoraggio continuo tramite i report DMARC rileva le discrepanze in tempo reale.
• Implementa SPF insieme a DKIM e DMARC. SPF da solo non impedisce la falsificazione del campo "From" dell'intestazione. DKIM da solo non convalida il mittente dell'involucro. Solo l'applicazione di DMARC, che verifica la corrispondenza tra SPF o DKIM e il dominio del campo "From" dell'intestazione, garantisce una protezione completa.
• Rispettare i requisiti imposti dai principali destinatari. Nel 2026, Google, Yahoo, Microsoft e Apple richiederanno tutti l'implementazione di SPF, DKIM e DMARC per i mittenti di messaggi in massa. Lo standard PCI DSS v4.0, obbligatorio a partire da marzo 2025, richiede espressamente l'adozione di tutti e tre questi protocolli come misure di protezione contro il phishing.

Come monitorare costantemente l'SPF 

Il divario più significativo tra le organizzazioni che hanno "configurato l'SPF" e quelle effettivamente protette dall'SPF riguarda il monitoraggio. La configurazione iniziale è la parte più semplice, ma individuare i malfunzionamenti silenziosi nei mesi successivi è ciò che distingue l'autenticazione della posta elettronica effettivamente funzionante da quella puramente teorica.

Perché i controlli SPF una tantum creano un falso senso di sicurezza

I record SPF subiscono continue variazioni perché i fornitori modificano i propri intervalli IP autorizzati, le catene "include:" puntano a indirizzi IP diversi e uno di questi potrebbe farti superare il limite di query. I team aggiungono nuovi strumenti SaaS senza aggiornare l'SPF. Le migrazioni modificano l'instradamento della posta in uscita in modi che il tuo DNS non riflette. Rimangono vecchie voci relative a servizi che l'organizzazione ha smesso di utilizzare anni fa.

Come funziona il monitoraggio continuo dell'SPF

Quattro componenti, ciascuno dei quali è destinato a una specifica modalità di guasto:

• Rapporti aggregati DMARC acquisiti quotidianamente dai destinatari di tutto il mondo. Questi riportano i risultati SPF per IP e per origine su ogni server ricevente che ha elaborato la tua posta. PowerDMARC li acquisisce automaticamente e li visualizza in una dashboard dedicata all'analisi SPF, con percentuali di superamento/fallimento per origine, monitoraggio del numero di ricerche DNS e andamenti storici.
• Avvisi automatici non appena gli errori SPF superano una soglia prestabilita, quando compare una nuova fonte di invio non autorizzata o quando una modifica al DNS influisce sul tuo record. PowerAlerts di PowerDMARC li inoltra tramite e-mail, Slack o Discord in modo che il team giusto possa vedere il problema durante l'orario di lavoro.
• Appiattimento SPF automatizzato che si aggiorna quando i provider di terze parti cambiano gli IP. PowerSPF risolve le catene di include in voci ip4: e mantiene il tuo record permanentemente al di sotto dei 10 lookups senza modifiche manuali al DNS.
• Monitoraggio delle blacklist e della reputazione. Se i tuoi IP di invio finiscono in una lista di blocco, l'SPF potrebbe superare il controllo ma la deliverability risulterà comunque compromessa. Il monitoraggio integrato della reputazione rileva i casi di errore che l'SPF da solo non è in grado di individuare.

In particolare per gli MSP: quando il fornitore di un cliente modifica il proprio intervallo di indirizzi IP, ne venite a conoscenza prima che il servizio di posta elettronica del cliente smetta di funzionare. 

La dashboard MSP di PowerDMARC offre un monitoraggio centralizzato dell'SPF su tutti i domini dei clienti da un'unica schermata, con la possibilità di approfondire i dati per singolo cliente. Ciò trasforma la gestione dell'SPF da un'attività reattiva di risoluzione dei problemi a una linea di servizi strutturata.

Inizia una prova gratuita di 15 giorni per provarlo tu stesso. 

Domande frequenti

Come posso controllare i record SPF in Exchange Online?

Utilizza uno strumento di verifica SPF come PowerDMARC SPF Checker, inserisci il tuo dominio e controlla il record, la sintassi e il numero di query. Puoi anche verificare la configurazione nel Centro di amministrazione di Microsoft 365, alla voce Impostazioni → Domini → Record DNS. Per la verifica dal lato del destinatario, controlla l'intestazione Authentication-Results in un messaggio di prova inviato dall'esterno.

Di quale record SPF ho bisogno per Microsoft 365?

Come minimo: v=spf1 include:spf.protection.outlook.com -all. Se utilizzi altri servizi di invio (HubSpot, SendGrid, Salesforce, Zendesk), aggiungi i relativi include prima di -all. Assicurati che il numero totale di ricerche DNS rimanga inferiore a 10, comprese le ricerche annidate all'interno di ciascun include:.

Perché l'SPF non funziona anche se il mio record sembra corretto?

Cause comuni: superamento del limite di 10 ricerche DNS (PermError), presenza di più record SPF sullo stesso dominio, e-mail inoltrate (per impostazione predefinita, l'SPF non funziona in caso di inoltro) o modifica degli intervalli IP autorizzati da parte di un fornitore senza previa notifica. Controlla l'intestazione "Authentication-Results" per verificare il risultato specifico di "spf=".

Qual è la differenza tra -all e ~all?

-all (hard fail) indica ai destinatari di respingere o rifiutare i messaggi provenienti da indirizzi IP non autorizzati. ~all (soft fail) è più permissivo. Nel 2026, con l'implementazione di DMARC, sarà la politica DMARC a determinare l'applicazione delle regole, indipendentemente dal qualificatore. Se non si dispone ancora di DMARC, l'opzione -all offre una protezione notevolmente più efficace.

Quante ricerche DNS effettua il dominio include:spf.protection.outlook.com?

L'inclusione di Microsoft conta come una sola ricerca, ma si collega a inclusioni annidate che comportano circa 2-4 ricerche aggiuntive. Il numero esatto varia a seconda degli aggiornamenti apportati da Microsoft alla propria infrastruttura. Verificare sempre utilizzando uno strumento di controllo che conti in modo ricorsivo le ricerche annidate.

L'SPF è sufficiente a impedire lo spoofing delle e-mail?

No. Il protocollo SPF da solo non impedisce la falsificazione dell'indirizzo "Da" visibile (intestazione "From"). Si limita a verificare l'autenticità del mittente dell'involucro (Return-Path). Per una protezione completa sono necessari il protocollo DKIM per la firma a livello di messaggio e il protocollo DMARC per garantire la conformità. L'utilizzo congiunto di tutti e tre i protocolli, monitorati costantemente, costituirà lo standard nel 2026.