Controllo SPF gratuito

Cos'è SPF e perché conta nel 2026

Sender Policy Framework (SPF) è uno dei tre pilastri dell'autenticazione email moderna, insieme a DKIM e DMARC. Definito nell'RFC 7208, permette al proprietario di un dominio di pubblicare nel DNS una lista di server di invio autorizzati, così i provider di posta riceventi possono verificare che i messaggi in arrivo provengano davvero da dove dichiarano. Senza SPF, chiunque può inviare email fingendosi il tuo dominio — e provider moderni come Gmail e Yahoo silenziosamente fanno cadere la posta non autenticata direttamente nello spam.

Nel 2026 SPF non è più opzionale. I requisiti per i bulk sender di Gmail e Yahoo (introdotti nel 2024 e via via stretti) impongono SPF e DKIM a ogni dominio che invia oltre 5.000 messaggi al giorno. Microsoft 365 e Apple Mail applicano standard simili. Un record SPF mancante o configurato male si traduce ora direttamente in posizionamento nello spam, ricavi persi e danno al brand. La buona notizia: SPF è una delle vittorie di deliverability più economiche e veloci disponibili — un singolo record TXT configurato bene può aumentare il posizionamento in inbox del 20–40% da un giorno all'altro.

Anatomia di un record SPF

Ogni record SPF è un singolo record DNS TXT che contiene meccanismi separati da spazio. Ecco un esempio tipico per un dominio che usa Google Workspace e Mailgun:

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.10 ~all

• v=spf1 — il tag versione. Ogni record SPF deve iniziare così. Non esiste v=spf2; il protocollo non cambia da oltre un decennio.
• ip4: / ip6: — ip4: e ip6: — indirizzi IP o range CIDR esplicitamente consentiti. ip4:203.0.113.0/24 autorizza un'intera subnet. Sono i meccanismi più economici perché non innescano alcun lookup DNS.
• include: — incorpora il record SPF di un altro dominio. include:_spf.google.com dice ai receiver di accettare anche posta da qualsiasi server che Google autorizza per i suoi tenant. Ogni include conta come un lookup DNS, e anche gli include annidati contano.
• a / mx — a e mx — autorizzano gli IP del record A del dominio (il server del sito) o dei record MX (i server di posta in entrata). Usali con parsimonia: molti domini hanno web server che non dovrebbero inviare posta.
• I qualifier controllano il risultato. ~all (soft fail) marca la posta non corrispondente come sospetta ma la accetta — utile in fase di test. -all (hard fail) rifiuta direttamente la posta non corrispondente — l'impostazione di produzione raccomandata. ?all (neutral) non fa nulla ed è inutile. +all autorizza esplicitamente ogni IP di internet — non usarlo mai; equivale a lasciare aperta la porta di casa con un cartello che dice "per favore, impersonami".

5 errori comuni di SPF e come risolverli

Troppi lookup DNS (limite RFC 7208: 10)

SPF consente al massimo 10 lookup DNS per valutazione. Ogni include:, a:, mx:, exists: e redirect= conta. Anche gli include annidati contano — se include:_spf.google.com contiene quattro include, sono cinque lookup per quel singolo meccanismo. Superare il limite innesca un PermError e la maggior parte dei receiver lo tratta come hard fail. Risolvi: audita ogni include con il nostro SPF checker qui sopra, rimuovi i vendor inutilizzati, sostituisci include: con blocchi ip4: dove il vendor pubblica range statici, oppure usa un servizio di flattening.

PermError: sintassi del record SPF non valida

Errori di sintassi comuni: prefisso v=spf1 mancante, uso di punti e virgola invece degli spazi, caratteri rimasti dal copia-incolla o qualifier (~all) messo in mezzo al record invece che alla fine. I receiver lo vedono come un fallimento di configurazione e bocciano SPF a priori. Risolvi: incolla il record esatto in un validator, cerca caratteri Unicode nascosti e assicurati che i meccanismi siano separati da spazi con il qualifier all in coda.

Più record SPF (vanno fusi)

L'RFC 7208 vieta esplicitamente più di un record TXT v=spf1 sullo stesso dominio. Capita di solito quando un team aggiunge Google Workspace e un altro aggiunge SendGrid senza coordinarsi. I receiver che vedono due record lanciano un PermError. Risolvi: combinali in un singolo record. v=spf1 include:_spf.google.com include:sendgrid.net ~all sostituisce entrambi i record individuali.

v=spf1 include:_spf.google.com include:sendgrid.net ~all

L'inoltro rompe SPF

Quando un destinatario inoltra il tuo messaggio a un altro indirizzo, l'IP che si connette cambia ma il Return-Path resta il tuo — e SPF fallisce all'hop di forwarding. È by design ma causa falsi negativi. Risolvi: appoggiati a DKIM per l'allineamento (DKIM sopravvive all'inoltro), implementa SRS sui forwarder in uscita che controlli e accetta che SPF da solo non basta — è esattamente perché DMARC richiede SPF o DKIM, non entrambi.

Confusione sull'ereditarietà dei sottodomini

SPF non è ereditato. mail.example.com e example.com sono host distinti e hanno bisogno di record SPF separati. Bug comune: l'azienda pubblica SPF sull'apex ma uno strumento di marketing invia da updates.example.com — i receiver non vedono nessun record SPF sul sottodominio e la tua posta fallisce l'allineamento. Risolvi: pubblica v=spf1 -all su ogni sottodominio che non deve mai inviare posta, e una policy reale su ogni sottodominio che invia.

Setup SPF passo-passo

1. Inventario di tutti i servizi di invio

Elenca ogni sistema che invia posta usando il tuo dominio: piattaforme di marketing (Mailchimp, HubSpot), provider transazionali (SendGrid, Postmark, Resend), CRM, support desk (Zendesk, Intercom), payroll, payment processor e i tuoi server applicativi. Anche solo dimenticarne uno significa che la posta legittima sarà rifiutata dopo che pubblichi il record.

2. Scegli una fail policy (~all vs -all)

Inizia con ~all (soft fail) per le prime 1–2 settimane mentre monitori i report DMARC per fonti inattese. Una volta confermato che ogni mittente legittimo è nel record e che i report DMARC mostrano tassi di pass del 100%, passa a -all per la massima protezione.

3. Costruisci il record

Usa i meccanismi include: pubblicati dal vendor ovunque possibile (es. include:_spf.google.com). Per i servizi senza include, usa ip4: con i loro range IP pubblicati. Tieni il record sotto il limite di 10 lookup contando ogni include e i suoi lookup annidati. Termina con un singolo qualifier — ~all o -all — mai entrambi.

4. Aggiungi il record TXT al DNS

Nel pannello del tuo provider DNS, crea un nuovo record TXT con host = @ (o l'apex del tuo dominio) e valore = la stringa SPF completa tra virgolette. Un TTL di 3600 (1 ora) è un buon default. Se il provider DNS auto-quota, non doppiare le virgolette.

5. Valida e monitora

Usa il checker qui sopra per verificare che il record si analizzi senza errori, che il conteggio dei lookup sia sotto 10 e che la policy sia impostata correttamente. Poi invia email di test a mail-tester.com e ai tuoi account Gmail/Outlook. Configura DMARC con report rua= per intercettare fonti che ti sei perso. Monitora in continuo — gli IP dei vendor cambiano, vengono aggiunti include e un record SPF pulito sei mesi fa può rompersi silenziosamente.

Come restare sotto il limite di 10 lookup DNS

Il limite di 10 lookup è di gran lunga la causa più comune dei fallimenti SPF su scala. Ogni include: innesca una query DNS, e qualsiasi include che a sua volta contiene include ne innesca altri — l'SPF di Salesforce, per esempio, può risolversi a 8+ lookup da solo. Tre strategie ti tengono sotto il limite. Primo, fai audit senza pietà: ogni vendor che non usi più deve uscire dal record. Esegui mensilmente il nostro checker e rimuovi gli include morti.

Secondo, sostituisci include: con ip4: dove i vendor pubblicano range IP stabili. SendGrid, Mailgun e Amazon SES pubblicano tutti blocchi statici; usare ip4:198.61.254.0/24 invece di include:sendgrid.net costa zero lookup invece di due. Il trade-off è la manutenzione — quando il vendor aggiunge nuovi IP devi aggiornare a mano.

Terzo, usa servizi di flattening SPF (es. easydmarc.com, dmarcian) per gli include annidati inevitabili. Questi servizi risolvono tutti i tuoi include in una lista piatta di blocchi ip4: e li ripubblicano come un singolo record SPF hosted che richiami con un solo include. Lo svantaggio è la dipendenza operativa da una terza parte — vagliali con attenzione e monitora gli outage.

SPF, DKIM e DMARC: come lavorano insieme

SPF da solo non basta. I tre protocolli formano una difesa stratificata: SPF autentica l'IP del server di invio, DKIM firma crittograficamente i contenuti del messaggio e DMARC lega i due all'indirizzo From visibile e dice ai receiver cosa fare quando l'autenticazione fallisce. SPF si rompe con l'inoltro; DKIM sopravvive all'inoltro ma è più difficile da implementare perché richiede di generare una coppia di chiavi e aggiungere la chiave pubblica al DNS. Insieme, l'allineamento DMARC passa se passa SPF o DKIM — quindi distribuire entrambi ti dà ridondanza e copertura completa negli scenari di consegna reali, dove inoltro, mailing list e catene di trust ARC sono comuni. Senza DMARC, SPF e DKIM sono solo strumenti diagnostici; i receiver possono usare i risultati con larghezza o ignorarli. Con DMARC a p=reject, dichiari pubblicamente la tua policy di autenticazione e dici a ogni receiver del pianeta di scartare a priori la posta falsificata. Questo è lo standard moderno di sicurezza email, e parte da un record SPF pulito. L'ordine di deploy raccomandato è: prima SPF (un record TXT, impatto immediato), poi DKIM (generazione chiavi più DNS), poi DMARC a p=none con report rua= per due settimane di monitoraggio, poi stringi progressivamente a p=quarantine e infine p=reject. Saltare il monitoraggio è la causa più comune di posta legittima persa durante il rollout DMARC.

Requisiti Gmail e Yahoo 2026

Da febbraio 2024, Gmail e Yahoo richiedono a tutti i bulk sender (oltre 5.000 messaggi al giorno verso i loro utenti) di pubblicare SPF, DKIM e DMARC, di mantenere un header di unsubscribe one-click (List-Unsubscribe con Post URL) e di tenere il tasso di reclami spam sotto lo 0,3% misurato in Postmaster Tools. Microsoft 365 applica regole simili tramite SmartScreen e Apple Mail segue DMARC alla lettera su iCloud e gli Apple ID gestiti. Nel 2026 questi standard si sono ulteriormente stretti: DMARC deve essere a p=quarantine o più stringente per il traffico bulk non autenticato, il trust ARC è stato aggiunto alla catena di valutazione per la posta inoltrata e i tassi di reclamo sopra lo 0,1% innescano già una consegna ridotta, ben prima del cap duro dello 0,3%. Il fallimento non è un soft warning — la tua posta finisce nello spam o viene rifiutata a priori a livello SMTP. Anche i mittenti non bulk sono sempre più toccati perché i filtri generalizzano: un mittente B2B con 200 email al giorno trae comunque beneficio da SPF, DKIM e DMARC puliti, perché i classificatori machine-learning di Gmail riusano gli stessi segnali di autenticazione per dare un punteggio a ogni messaggio. Il succo: SPF non è più una best-practice — è un prerequisito di deliverability. Esegui il checker qui sopra oggi per confermare che il tuo SPF passi, poi passa a DKIM e DMARC per completare lo stack.

Guide correlate

• DMARC Policy Setup Guide — How SPF fits into the full email authentication stack