I punti chiave da prendere in considerazione
- Un record SPF indica ai server di posta in ricezione quali indirizzi IP sono autorizzati a inviare e-mail per conto del tuo dominio.
- Per aggiungere un indirizzo IP, usa il meccanismo "ip4:" o "ip6:" all'interno del tuo record TXT SPF esistente; non creare mai un secondo record SPF. Un dominio può averne solo uno.
- Per i servizi di terze parti (Google Workspace, Microsoft 365, Mailchimp, SendGrid, ecc.), usa il meccanismo "include:" invece degli indirizzi IP grezzi. È un sistema che si aggiorna automaticamente.
- Il tuo record SPF non può superare le 10 ricerche DNS. Vengono conteggiati tutti i meccanismi include:, a, mx e redirect. I meccanismi ip4, ip6 e all non vengono conteggiati.
- Verifica sempre il tuo record SPF dopo aver apportato delle modifiche. Un solo errore di sintassi può compromettere silenziosamente la consegna delle e-mail per l'intero dominio.
- Google, Yahoo e Microsoft richiedono ora l'allineamento DMARC per i mittenti che inviano messaggi in massa. Se disponi solo di SPF, non sei pienamente conforme ai requisiti previsti per il 2026.
Per aggiungere un indirizzo IP al tuo record SPF, modifica il record TXT SPF esistente del tuo dominio nel DNS e inserisci un meccanismo "ip4:" (o "ip6:") prima del meccanismo "all". Ad esempio:
v=spf1 ip4:192.0.2.1 include:_spf.google.com -all
Importante: NON creare un secondo record SPF. È necessario modificare quello esistente e, prima di aggiungere un IP grezzo, verificare se il servizio di invio fornisce invece un valore "include:", che di solito rappresenta la scelta migliore a lungo termine.
Questa guida ti accompagna passo dopo passo attraverso l'intero processo, dalla ricerca del tuo record attuale alla scelta tra iPR4 e include, dalla modifica dei tuoi DNS presso i principali provider alla verifica del risultato, fino a come evitare gli errori che ogni anno compromettono silenziosamente la funzionalità della posta elettronica per migliaia di domini.
Che cos'è un record SPF e perché è importante nel 2026?
L'SPF (Sender Policy Framework) è un record TXT del DNS che elenca gli indirizzi IP e i servizi autorizzati a inviare e-mail dal proprio dominio. Se l'IP di un server non è presente nell'elenco, i server di posta in ricezione possono rifiutare o contrassegnare il messaggio.
Google ha iniziato ad applicare i requisiti di autenticazione per i mittenti di messaggi in massa nel febbraio 2024, richiedendo SPF o DKIM più DMARC a chiunque invii più di 5.000 messaggi al giorno.
A partire da novembre 2025, le e-mail non conformi saranno soggette a respingimenti permanenti, non a rinvii temporanei, ma a respingimenti definitivi. Yahoo ha adottato requisiti identici con le stesse tempistiche. Microsoft ha seguito l'esempio a maggio 2025, rifiutando immediatamente le email di massa non autenticate con errori 550.
Senza un record SPF corretto, il tuo dominio è esposto al rischio di spoofing e persino le tue e-mail legittime potrebbero essere respinte da Gmail, Yahoo e Outlook. Se il tuo record SPF è errato, le tue e-mail smettono semplicemente di arrivare senza alcun avviso. Il problema si verifica in modo silenzioso dal lato del destinatario, e te ne accorgi solo quando un cliente o un collega ti comunica di non aver mai ricevuto il tuo messaggio.
Spiegazione della sintassi dei record SPF (con esempi)
Prima di aggiungere qualsiasi dato al tuo record, devi capire a cosa serve ogni parte. Ecco la struttura di un tipico record SPF:
v=spf1 ip4:192.0.2.1 ip4:203.0.113.0/24 include:_spf.google.com -all
| Componente | Cosa fa |
|---|---|
| v=spf1 | Tag versione. Obbligatorio. Deve essere il primo. |
| ip4:192.0.2.1 | Autorizza un singolo indirizzo IPv4. Non richiede una ricerca DNS. |
| ip4:203.0.113.0/24 | Autorizza un intervallo CIDR (256 indirizzi IP). Non richiede una ricerca DNS. |
| ip6:2001:db8::1 | Autorizza un indirizzo IPv6. Non richiede una ricerca DNS. |
| include:_spf.google.com | Indirizza al record SPF di un altro dominio. Richiede almeno una ricerca DNS. |
| a | Autorizza gli indirizzi IP indicati nel record A del dominio. Consuma 1 ricerca. |
| mx | Autorizza gli indirizzi IP dei server MX del dominio. Consuma 1 ricerca. |
| -tutti | Hardfail. Rifiuta tutto ciò che non è elencato sopra. |
| ~tutto | Softfail. Segnalare ma non respingere le e-mail non autorizzate. |
Ecco tre esempi concreti che coprono diversi livelli di complessità:
Semplice (singolo server di posta):
v=spf1 ip4:198.51.100.25 -tutto
Tipica PMI (Microsoft 365 + uno strumento di marketing):
v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all
Impresa complessa (servizi multipli):
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.brevo.com -all
| Regola fondamentale: Un dominio può avere solo UN record SPF. Se ne hai già uno, DEVI modificarlo. Non aggiungere un secondo record TXT che inizi con v=spf1. Due record SPF sullo stesso dominio genereranno un PermError e interromperanno TUTTA l'autenticazione delle email. |
Devi creare un record da zero?
Utilizzo del generatore gratuito di record SPF di PowerDmarc per creare immediatamente un record sintatticamente corretto.
Come aggiungere un indirizzo IP al proprio record SPF (passo dopo passo)
Aggiungere un indirizzo IP al proprio record SPF è uno dei modi più diretti per autorizzare una fonte di invio. Di solito è necessario quando si utilizza un server dedicato, un sistema di posta elettronica transazionale o qualsiasi infrastruttura di cui si ha il controllo.
Sebbene la modifica in sé sia semplice, è fondamentale prestare attenzione alla precisione, poiché inserimenti errati o problemi di formattazione possono compromettere l'autenticazione e la recapitabilità. I passaggi riportati di seguito illustrano come aggiungere correttamente un indirizzo IP al proprio record SPF, senza interferire con la configurazione esistente.
Passaggio 1: Individua il tuo record SPF attuale
Molti domini dispongono già di un record SPF derivante da una configurazione precedente. Se ne crei uno nuovo senza controllare, ne avrai due e questo causerà un malfunzionamento generale.
Puoi consultare la tua scheda attuale in due modi.
Utilizza lo strumento gratuito di verifica SPF di PowerDMARC per ottenere un risultato visivo immediato oppure esegui una query da riga di comando:
nslookup -type=TXT yourdomain.com
dig TXT tuodominio.com

Scopri come verificare immediatamente il tuo record SPF e individuare eventuali problemi di configurazione che potrebbero compromettere la consegna delle e-mail
Cerca un record TXT che inizi con v=spf1. Se ne trovi uno, quello è il tuo record SPF e lo modificherai nel passaggio 3. Se trovi due record che iniziano entrambi con v=spf1, c'è già un problema: uniscili in uno solo prima di fare qualsiasi altra cosa.
Passaggio 2: Individua l'indirizzo IP o il valore "Include" che devi aggiungere
Ci sono due possibilità, e la scelta giusta dipende da ciò che si sta autorizzando:
Scenario A: Stai aggiungendo un indirizzo IP specifico. Questo vale quando gestisci il tuo server di posta su un IP statico o disponi di un IP di invio dedicato che controlli. Ti serve l'indirizzo IPv4 o IPv6 esatto del server.
Scenario B: Stai autorizzando un servizio di terze parti. Questo vale per servizi come Mailchimp, SendGrid, HubSpot, Google Workspace o Microsoft 365. In questo caso, devi inserire il valore "include:" riportato nella documentazione di quel servizio, non i loro indirizzi IP.
Prima di aggiungere un indirizzo IP grezzo, leggi la sezione sottostante dedicata al confronto tra "ip4" e "include". Per la maggior parte dei servizi di terze parti, "include:" rappresenta la scelta migliore nel lungo periodo.
Passaggio 3: Modifica il tuo record SPF nel DNS
Accedi al tuo provider DNS (il tuo registrar di domini o il tuo provider di hosting), individua i record TXT relativi al tuo dominio e modifica il record SPF esistente. Aggiungi il nuovo meccanismo "ip4:" o "include:" PRIMA del meccanismo "all".
Ecco come procedere con i provider più diffusi:
- Cloudflare: Vai su DNS → Record. Trova il record TXT esistente per il tuo dominio (@ o root) che inizia con v=spf1. Fai clic su Modifica. Aggiungi il nuovo meccanismo prima del tag all. Fai clic su Salva.
- GoDaddy: Vai su I miei prodotti → DNS → Record DNS. Trova il record TXT contenente v=spf1. Fai clic su Modifica. Modifica il campo Valore per includere il nuovo meccanismo prima di all. Salva.
- Namecheap: Vai su Elenco domini → Gestisci → DNS avanzato. In Registrazioni TXT, individua la voce SPF. Modificala per aggiungere il nuovo meccanismo. Salva.
- AWS Route 53: Apri Zone ospitate → seleziona il tuo dominio → individua il record TXT con v=spf1. Fai clic su Modifica. Aggiorna il valore (mantieni le virgolette). Salva.
- cPanel: Vai su Consegna e-mail → clicca su Gestisci accanto al tuo dominio → scorri fino a Record SPF suggerito → clicca su Personalizza. Aggiungi il nuovo IP nella sezione Indirizzo IP. Clicca su Installa.
| Consiglio da esperto: Riduci il TTL a 300 secondi (5 minuti) PRIMA di apportare modifiche all'SPF. Questo accelera la propagazione del DNS e ti consente di correggere gli errori più rapidamente. Attendi che il vecchio TTL scada, quindi apporta la modifica. Ripristina il TTL ai valori normali dopo aver verificato che il record funzioni correttamente. |
Passaggio 4: Verifica il tuo record SPF aggiornato
Basta un solo spazio fuori posto, un punto e virgola mancante o un record duplicato per compromettere silenziosamente il funzionamento della posta elettronica dell'intero dominio. La verifica richiede 30 secondi e ti evita ore di ricerca dei guasti.
Controlla questa lista di controllo dopo ogni modifica dell'SPF:
- Verifica il tuo dominio tramite uno strumento di controllo SPF e assicurati che il record venga interpretato correttamente.
- Verifica di vedere solo UN record SPF (non due record TXT che iniziano con v=spf1).
- Controlla il numero totale di ricerche DNS. Deve essere pari o inferiore a 10.
- Verificare che l'intero meccanismo si trovi all'estremità del disco.
- Invia un'e-mail di prova a un account Gmail o Yahoo, apri il messaggio, visualizza le intestazioni originali e verifica che sia presente la riga "spf=pass".
Per un controllo completo della sicurezza che vada oltre l'SPF, sottoponi il tuo dominio all'analisi con PowerDMARC. Questo strumento verifica SPF, DKIM, DMARC, MTA-STS e BIMI in un unico passaggio.
Passaggio 5: Monitorare l'andamento dei risultati dell'autenticazione SPF nel tempo
Il primo passo è aggiungere l'IP. Il secondo passo è verificare che funzioni davvero e individuare eventuali malfunzionamenti in seguito.
I rapporti aggregati DMARC rappresentano il principale strumento per ottenere una visibilità costante sui tassi di superamento/fallimento dell'SPF per ciascuna fonte di invio. Senza un monitoraggio adeguato, si procede alla cieca. Molti amministratori si accorgono di un record SPF non funzionante solo dopo che i clienti iniziano a contrassegnare come spam e-mail legittime o dopo che uno strumento di fatturazione ha inviato messaggi da un IP non autorizzato per settimane senza che nessuno se ne accorgesse.
| Vuoi avere una visione costante di tutti gli indirizzi IP che inviano e-mail dal tuo dominio?
La dashboard di PowerDMARC per i report DMARC mostra i tassi di superamento/fallimento SPF per fonte su tutti i tuoi domini, in dashboard di facile lettura, non in formato XML grezzo. Inizia la tua prova gratuita di 15 giorni → powerdmarc.com/free-dmarc-trial/ |
ip4 o include: quale scegliere? (Guida alla scelta)
Quando utilizzare IPv4 (indirizzi IP non formattati):
- Gestisci il tuo server di posta elettronica su un indirizzo IP statico di cui hai il controllo.
- Disponi di un indirizzo IP di invio dedicato fornito da un ESP di tua proprietà (non condiviso).
- Stai autorizzando un relay SMTP locale con un indirizzo fisso.
La regola: usa ip4: solo quando SEI TU a controllare l'IP e questo non cambierà.
Quando utilizzare include: (SPF delegato):
- Stai autorizzando qualsiasi servizio SaaS di terze parti, come Google Workspace, Microsoft 365, Mailchimp, SendGrid, HubSpot, Salesforce, Zendesk o qualsiasi strumento di posta elettronica basato su cloud.
- Il servizio utilizza indirizzi IP condivisi o a rotazione.
- Il servizio pubblica il proprio record SPF, di cui si occupa direttamente.
Perché includere: è quasi sempre preferibile per i servizi di terze parti:
I servizi cloud cambiano regolarmente gli indirizzi IP. Se si inseriscono gli indirizzi IP attuali in modo statico con il prefisso "ip4:", il record SPF diventa obsoleto quando l'infrastruttura viene migrata e la posta elettronica smette di funzionare senza preavviso.
Il meccanismo "include:" rimanda al record SPF del servizio stesso, gestito dinamicamente. Quando aggiornano i propri indirizzi IP, il tuo record SPF riflette automaticamente le modifiche senza che tu debba occuparti di nulla.
[Immagine: Diagramma di flusso ad albero decisionale — «Si tratta di un server/IP di tua proprietà e sotto il tuo controllo?» → SÌ → Usa IPv4 / NO → «Il servizio fornisce un valore "include:"?» → SÌ → Usa "include" (preferibile) / NO → Usa IPv4 + imposta un promemoria per la revisione trimestrale]
[Testo alternativo: Diagramma di flusso che illustra quando utilizzare il meccanismo IPv4 rispetto a quello "include" nei record SPF]
Per approfondire la sintassi degli include e le migliori pratiche, consulta la guida completa agli include SPF.
Valori comuni inclusi negli SPF di terze parti (tabella di riferimento rapido)
Questa tabella evita di dover cercare separatamente la documentazione SPF di ogni singolo servizio. Aggiungila ai preferiti per la prossima volta che il reparto marketing si registrerà su un nuovo strumento.
| Servizio e-mail | Valore SPF | Note |
|---|---|---|
| Spazio di lavoro Google | include:_spf.google.com | Copre tutte le operazioni di invio in Google Workspace |
| Microsoft 365 | includere: spf.protection.outlook.com | Standard per tutti i tenant M365 |
| Mailchimp | include:servers.mcsv.net | La versione standard di Mailchimp include |
| SendGrid | includere:sendgrid.net | Copre tutte le operazioni di invio tramite SendGrid |
| Salesforce | includere:_spf.salesforce.com | Riguarda l'invio di e-mail tramite Salesforce |
| Zendesk | tra cui: mail.zendesk.com | Per l'assistenza via e-mail di Zendesk |
| Freshdesk | tra cui: email.freshdesk.com | Per l'assistenza via e-mail di Freshdesk |
| Amazon SES | tra cui: amazonses.com | Copre l'invio SES |
| Brevo | includere: spf.brevo.com | Aggiornato da Sendinblue |
| Zoho Mail | tra cui: zoho.com | Riguarda Zoho Mail |
| Timbro postale | include:spf.mtasv.net | Per le e-mail transazionali di Postmark |
| Klaviyo | include:spf.klaviyo.com | Per l'email marketing con Klaviyo |
Tabella: Riepilogo dei valori SPF per i principali servizi di posta elettronica. Verificate sempre i valori aggiornati nella documentazione ufficiale di ciascun servizio, poiché i provider li aggiornano periodicamente.
Importante: Ogni include: conta come almeno una ricerca DNS, e molti record SPF di terze parti contengono include annidati che ne aggiungono altri. Se utilizzi cinque o più servizi, probabilmente ti stai avvicinando al limite di 10 ricerche. Consulta la sezione successiva per sapere come gestire questa situazione.
Il limite di 10 ricerche DNS e cosa fare quando lo si raggiunge
La RFC 7208 limita la valutazione SPF a 10 meccanismi di interrogazione DNS. I meccanismi che vengono conteggiati sono: include, a, mx, redirect ed exists. I meccanismi che NON vengono conteggiati sono: ip4, ip6 e all. Questi vengono valutati localmente senza una query DNS.
Quando il numero di consultazioni supera le 10, SPF restituisce un PermError. Molti server di ricezione interpretano un PermError come un errore SPF. La deliverability delle tue e-mail diminuisce e non ricevi alcuna notifica dell'accaduto.
Esiste anche un vincolo meno noto: il limite di due ricerche a vuoto. Se durante la valutazione SPF più di due query DNS restituiscono NXDOMAIN (dominio non trovato), anche l'SPF fallisce.
Ecco tre modi per risolvere il problema, ordinati in base alla praticità:
Opzione 1: Rimuovere i meccanismi inutilizzati
Inizia con una verifica. Elimina le istruzioni `include:` relative ai servizi che non utilizzi più. Rimuovi i record A e MX se non invii e-mail dagli indirizzi IP associati ai record A o MX del tuo dominio. Questa è la soluzione più rapida e spesso libera immediatamente 2-3 ricerche.
Opzione 2: Appiattimento manuale dell'SPF
Identifica i meccanismi di inclusione fino agli indirizzi IP sottostanti e inseriscili come voci IPv4. In questo modo si evitano le ricerche DNS che tali inclusioni avrebbero altrimenti richiesto.
Questo comporta un onere di manutenzione costante. I provider di servizi di posta elettronica modificano o ampliano i propri intervalli IP senza avvisarti. Quando lo fanno, il tuo record SPF semplificato diventa obsoleto e le email legittime iniziano a non arrivare a destinazione. La semplificazione manuale dell'SPF è come falciare il prato: funziona, ma bisogna rifarlo ogni poche settimane.
Opzione 3: Macro SPF o appiattimento automatico
L'approccio moderno utilizza le macro SPF (definite nella RFC 7208, paragrafo 7), che si espandono dinamicamente al momento della valutazione per mantenere il record entro il limite massimo consentito senza dover gestire manualmente gli indirizzi IP.
Gli strumenti di appiattimento automatizzato gestiscono questa operazione in modo continuo, ricalcolando gli indirizzi IP dei provider secondo una pianificazione prestabilita e aggiornando il record pubblicato.
| Hai raggiunto il limite di 10 ricerche?
PowerSPF utilizza le macro SPF per mantenere automaticamente il tuo record al di sotto del limite di lookup. Nessun appiattimento manuale, nessun IP obsoleto, nessuna manutenzione. PowerDMARC supporta anche l'appiattimento SPF tradizionale per configurazioni più semplici. Inizia la tua prova gratuita di 15 giorni |
Il solo SPF non basta: perché DKIM e DMARC completano il quadro
SPF verifica se l'indirizzo IP del mittente dell'intestazione (MAIL FROM) è presente nell'elenco autorizzato. Funziona quando l'e-mail viaggia direttamente dal mittente al destinatario, ma quando l'e-mail viene inoltrata, tramite mailing list, regole di inoltro automatico, caselle di posta condivise o qualsiasi server di inoltro, l'IP di invio cambia. SPF smette di funzionare, poiché l'IP del server di inoltro non è presente nel record SPF e non dovrebbe esserci.
Il DKIM (DomainKeys Identified Mail) funziona in modo diverso. Aggiunge una firma crittografica al corpo dell'e-mail. Tale firma accompagna il messaggio indipendentemente dal server che lo inoltra. Il DKIM resiste all'inoltro, mentre l'SPF no.
Il protocollo DMARC (Domain-based Message Authentication, Reporting, and Conformance) funge da collante. È sufficiente che UNO solo tra SPF e DKIM superi il controllo e sia allineato con il dominio del mittente affinché il messaggio superi il controllo DMARC.
In pratica, DKIM è il meccanismo di autenticazione più affidabile poiché non risente dell'inoltro.
Ecco perché è importante avere entrambe le cose:
- Google richiede l'autenticazione SPF o DKIM per tutti i mittenti, oltre a DMARC per i mittenti che inviano grandi volumi di messaggi (oltre 5.000 messaggi al giorno). A partire da novembre 2025, i messaggi non conformi saranno respinti in modo definitivo.
- A partire dal maggio 2025, Microsoft ha iniziato a respingere le e-mail di massa non autenticate.
- Yahoo applica gli stessi requisiti e segue le stesse tempistiche di Google.
Se l'SPF è il tuo unico meccanismo di autenticazione, il tuo dominio rimane vulnerabile all'usurpazione di identità su qualsiasi percorso di inoltro delle e-mail e non sei pienamente conforme ai requisiti dei provider di posta elettronica previsti per il 2026.
Cosa fare ora:
- Configura DKIM per ogni servizio che invia e-mail dal tuo dominio.
- Pubblica un record DMARC (inizia con p=none per il monitoraggio, poi passa a p=reject).
- Controlla i rapporti aggregati DMARC per verificare quali fonti superano o non superano i controlli SPF e DKIM.
| Sei pronto a scoprire tutti i dettagli sull'autenticazione delle e-mail?
PowerDMARC monitora DMARC, SPF e DKIM su tutti i tuoi domini tramite dashboard intuitive che mostrano esattamente quali messaggi vengono accettati, quali vengono respinti e perché. |
Record SPF per domini che non inviano e-mail
Se possiedi domini parcheggiati, inattivi o utilizzati solo per siti web, questi necessitano comunque della protezione SPF. Gli hacker si dedicano attivamente alla falsificazione dei domini inutilizzati proprio perché spesso questi ultimi vengono lasciati senza protezione.
La soluzione è semplice. Pubblica questo record SPF:
v=spf1 -all
Questo indica ai server destinatari che nessuno è autorizzato a inviare e-mail da questo dominio. Qualsiasi messaggio che dichiari di provenire da esso deve essere respinto.
Per garantire la massima protezione, pubblica anche un record DMARC con una politica di rifiuto:
v=DMARC1; p=rifiuto; rua=mailto:[email protected]
Questa combinazione impedisce lo spoofing per tutti i domini di cui sei titolare, indipendentemente dal fatto che inviino o meno e-mail.
Errori comuni relativi all'SPF e come correggerli
Gli errori di sintassi in SPF sono molto diffusi e, cosa peggiore, non generano alcun messaggio di errore. Ecco gli otto errori più comuni, cosa succede quando li si commette e come risolverli:
| Errore | Cosa succede | Come risolvere il problema |
|---|---|---|
| Due record SPF su un unico dominio | PermError. Errore SPF per TUTTE le e-mail | Unire entrambi i record in un unico record TXT |
| Manca "v=spf1" all'inizio | Il record viene completamente ignorato | Assicurarsi che il record inizi esattamente con v=spf1 |
| I meccanismi sono stati installati, dopotutto | Tutto ciò che segue -all o ~all viene ignorato | Sposta tutto alla fine del record |
| Superamento del limite di 10 ricerche DNS | PermError. L'autenticazione SPF fallisce senza generare alcun messaggio di errore | Rimuovere i file di inclusione inutilizzati, appiattire il codice o utilizzare le macro SPF |
| Utilizzo di +all | Autorizza tutti gli utenti di Internet a inviare messaggi come se provenissero dal tuo dominio | Passa subito a -all o ~all |
| Spazi o errori di battitura negli indirizzi IP | Il meccanismo non è valido e potrebbe causare un errore PermError | Controlla attentamente tutti gli indirizzi IP; utilizza uno strumento per la generazione di SPF |
| Incluso il meccanismo ptr obsoleto | La RFC 7208 sconsiglia l'uso di ptr; alcuni destinatari lo ignorano | Sostituisci con ip4: oppure includi: |
| Indirizzi IP obsoleti provenienti da server dismessi | Potrebbe essere riassegnato. Potenziale rischio per la sicurezza | Verificare l'SPF ogni tre mesi; rimuovere gli indirizzi IP dismessi |
Tabella: gli errori più comuni nei record SPF, le loro conseguenze e come risolverli.
Per approfondire la risoluzione degli errori di convalida SPF, consulta la nostra guida sugli errori di convalida SPF e su come risolverli.
Conclusione
Aggiungere un indirizzo IP al proprio record SPF è una semplice modifica al DNS, ma per farlo correttamente è necessario comprendere la sintassi, scegliere tra "ip4:" e "include:", non superare il limite di 10 ricerche DNS e verificare il risultato dopo ogni modifica.
SPF è uno dei livelli che compongono un sistema completo di autenticazione delle e-mail. Nel 2026, con Google, Yahoo e Microsoft che applicano attivamente i requisiti di autenticazione del mittente, l’SPF da solo non è sufficiente. DKIM e DMARC sono altrettanto essenziali per una protezione e una conformità complete.
Man mano che la vostra organizzazione aggiunge nuovi servizi di invio, il vostro record SPF diventerà sempre più complesso. La gestione manuale non è scalabile e un solo errore può compromettere silenziosamente la consegna delle e-mail su tutto il vostro dominio. La gestione automatizzata dell'SPF non è più un lusso. È una questione di igiene operativa.
Smetti di gestire manualmente i record SPF. PowerDMARC ti offre l'uniformazione automatizzata degli SPF (PowerSPF), il monitoraggio DMARC, la gestione DKIM e report chiari su tutti i tuoi domini, il tutto in un'unica piattaforma. Inizia la tua prova gratuita di 15 giorni
Domande frequenti
1) È possibile avere due record SPF sullo stesso dominio?
No. La RFC 7208 richiede esattamente un record TXT SPF per dominio. Se un dominio presenta due record che iniziano con v=spf1, i server di ricezione restituiscono un PermError e considerano l'SPF non valido per ogni messaggio. Se è necessario autorizzare ulteriori fonti, modificare il record esistente per aggiungerle, senza crearne uno nuovo.
2) Qual è la differenza tra -all e ~all?
-all è un "hard fail": indica ai server destinatari di rifiutare le e-mail provenienti da indirizzi IP non autorizzati. ~all è un "soft fail": contrassegna le e-mail non autorizzate ma non impone il loro rifiuto. In pratica, quando DMARC viene applicato con p=quarantine o p=reject, la differenza è minima poiché la politica DMARC ha la precedenza sul qualificatore SPF. Se DMARC è già in fase di applicazione, entrambe le opzioni funzionano. Se non si dispone ancora di DMARC, -all offre una protezione maggiore.
3) Quanti indirizzi IP posso aggiungere a un record SPF?
Non esiste un limite rigido al numero di meccanismi "ip4:" o "ip6:". Questi non vengono conteggiati ai fini del limite di 10 ricerche DNS. Tuttavia, il record SPF complessivo deve rientrare nei limiti di dimensione dei record TXT del DNS (255 caratteri per stringa, con più stringhe concatenate fino a circa 4.096 caratteri). Per elenchi IP di grandi dimensioni, utilizzare la notazione CIDR (ad es. ip4:192.0.2.0/24) per coprire gli intervalli in modo efficiente.
4) Quanto tempo occorre perché la protezione solare faccia effetto?
Dipende dal valore TTL (Time to Live) del tuo record DNS. Se il TTL è impostato su 3600 (1 ora), la maggior parte dei resolver rileverà la modifica entro un'ora. Per accelerare il processo: riduci il TTL a 300 (5 minuti) prima di apportare le modifiche, attendi che il periodo del vecchio TTL scada, quindi effettua la modifica. In questo modo si riduce notevolmente il tempo di propagazione.
5) Come faccio a sapere quali indirizzi IP stanno attualmente inviando e-mail dal mio dominio?
Il metodo più affidabile è la reportistica DMARC. Quando si pubblica un record DMARC con un tag rua, i server di ricezione inviano report aggregati giornalieri che elencano tutti gli indirizzi IP che hanno tentato di inviare e-mail dal proprio dominio, insieme ai risultati di superamento o fallimento dei controlli SPF e DKIM. Senza DMARC, si può solo tirare a indovinare. PowerDMARC elabora questi report trasformandoli in dashboard chiare e di facile comprensione, in modo da poter vedere esattamente chi sta inviando messaggi dal proprio dominio.
6) I meccanismi IPv4 e IPv6 vengono conteggiati ai fini del limite di 10 ricerche DNS?
No. Solo i meccanismi che richiedono una query DNS vengono conteggiati ai fini del limite: include, a, mx, redirect ed exists. I meccanismi ip4, ip6 e all vengono valutati localmente e non comportano alcuna ricerca DNS.


