Guida completa al record SPF: sintassi, lookup, flattening e test

Per implementare SPF correttamente, utilizzi la sintassi v=spf1 TXT con meccanismi e qualificatori ordinati (ip4, ip6, a, mx, include, exists, redirect, all), comprenda la valutazione al momento SMTP e il mapping degli errori DNS, rispetti i limiti pratici (10 lookup DNS, frammenti di stringa da 255 caratteri, dimensione della risposta), applichi un flattening sicuro dove necessario, esegua test approfonditi con dig/validatori e un flusso di posta scaglionato, e automatizzi la correttezza continua con AutoSPF.

SPF (Sender Policy Framework) indica ai server di ricezione quali IP e host sono autorizzati a inviare posta per il Suo dominio. Un record preciso è essenziale per la deliverability, l’allineamento DMARC e la difesa dal phishing, ma i vincoli del mondo reale — il tetto di 10 lookup, il turnover degli IP dei mittenti SaaS, il comportamento di inoltro — rendono SPF complicato su larga scala. Gli errori (record multipli, errori di sintassi, IP appiattiti obsoleti) possono compromettere silenziosamente il posizionamento in inbox. Prima di apportare modifiche, conviene controllare il Suo record SPF e vedere esattamente a che punto si trova.

Questa guida approfondisce sintassi, logica di lookup, limiti, strategie di flattening, deployment e test, con comandi concreti, esempi e playbook operativi. Se si sta ancora orientando, la nostra panoramica dei diversi tipi di record SPF è un utile punto di partenza. A ogni passaggio, AutoSPF automatizza le parti tediose (flattening entro i limiti, aggiornamenti DNS tramite API/IaC, monitoraggio del drift), così che il Suo SPF resti corretto man mano che il Suo ecosistema di mittenti cambia.

Sintassi e valutazione di SPF: meccanismi, qualificatori, modificatori e ordine

Panoramica della sintassi del record SPF TXT

• I record SPF vengono pubblicati come DNS TXT. Il RRtype SPF è deprecato; utilizzi sempre TXT.
• Formato: una policy v=spf1 per hostname.
• I meccanismi vengono valutati da sinistra a destra; la prima corrispondenza decide il risultato.
• I qualificatori impostano l’esito se un meccanismo corrisponde:
  • (pass, predefinito), - (fail), ~ (softfail), ? (neutral)
• I modificatori (key=value) forniscono istruzioni aggiuntive (es. redirect).

Esempio di record di base (punto di partenza sicuro):

example.com. 3600 IN TXT "v=spf1 ip4:198.51.100.0/24 ip6:2001:db8::/48 include:_spf.google.com -all"

Meccanismi supportati con esempi concreti

• ip4 e ip6: Autorizzano intervalli di IP espliciti.
  • ip4:203.0.113.5 o ip4:203.0.113.0/25
  • ip6:2001:db8:abcd::/48
• a: Autorizza l’A/AAAA di un hostname (per impostazione predefinita il dominio corrente).
  • a usa l’A/AAAA di example.com
  • a:mail.example.com autorizza gli IP di quell’host
  • a/24 il suffisso CIDR maschera il risultato del record A risolto
• mx: Autorizza gli IP degli host MX del dominio.
  • mx o mx:example.com
• include: Dà pass se la SPF del dominio incluso valuta a pass; altrimenti continua.
  • include:_spf.google.com
  • Gli errori del dominio incluso si propagano (temperror/permerror).
• exists: Valuta una query DNS di tipo A su un dominio (spesso con macro); se esiste, corrisponde.
  • exists:%{i}._spfbl.example.net
• all: Corrisponde a qualsiasi cosa; usato per ultimo con un qualificatore per esprimere la policy predefinita.
  • -all (hard fail), ~all (soft fail), ?all (neutral)
• redirect (modificatore): Se nessun meccanismo corrisponde, valuta la SPF di un altro dominio come passaggio finale.
  • redirect=_spf.example.net
• exp (modificatore): Dominio di spiegazione opzionale per i motivi di fallimento (ampiamente ignorato dai riceventi).
  • exp=explain._spf.example.com

Deprecato:

• ptr è deprecato (lento, impreciso). Non usi ptr in un SPF moderno.

Macro (avanzate, per exists ed exp)

• Macro comuni: %{i} (IP del mittente), %{s} (e-mail del mittente), %{l} (parte locale), %{o} (dominio), %{d} (dominio corrente), %{h} (dominio HELO).

Esempio di exists con macro (lista di reputazione IP): v=spf1 exists:%{i}._ipauth.example.net -all

• Se esiste il record A per ._ipauth.example.net, SPF dà pass.

Come funziona la valutazione di SPF al momento SMTP

1. Scelta dell’identità
   • L’identità primaria è MAIL FROM (Return-Path).
   • Se MAIL FROM è vuoto (bounce), si usa il dominio HELO/EHLO.
2. Recuperare il record SPF TXT del dominio (v=spf1).
3. Valutare i meccanismi da sinistra a destra:
   • Se un meccanismo corrisponde, applicare il risultato del suo qualificatore (+/-/~/?).
   • Se nessuno corrisponde, applicare all alla fine. Un all mancante dà come risultato neutral.
4. Comportamento di include
   • include:domain dà pass solo se il dominio incluso restituisce pass.
   • Se l’include restituisce fail/softfail/neutral/none, trattare come nessuna corrispondenza e continuare.
   • Se la valutazione dell’include incontra permerror/temperror, propagare tale errore.
5. Comportamento di redirect
   • Usato solo se nessun meccanismo precedente ha corrisposto. Valuta la SPF del target come se fosse questo dominio. Se il target non ha una SPF valida, permerror.
6. Lookup DNS ed errori
   • Meccanismi/modificatori che contano per il tetto di 10 lookup: a, mx, include, exists, redirect (ptr è deprecato ma conterebbe).
   • ip4/ip6/all non richiedono lookup DNS.
   • Codici di risultato:
     • pass: Autorizzato
     • fail: Esplicitamente non autorizzato
     • softfail: Probabilmente non autorizzato (spesso comunque accettato ma contrassegnato)
     • neutral: Nessuna asserzione
     • none: Nessun record SPF sul dominio
     • permerror: Errore di policy (es. sintassi non valida, record SPF multipli, >10 lookup)
     • temperror: Errore DNS temporaneo/timeout
   • I void lookup (NXDOMAIN/NoData) dovrebbero essere limitati; più di 2 void vengono spesso trattati come permerror dai grandi riceventi.

Come aiuta AutoSPF: AutoSPF costruisce policy che rispettano il budget di 10 lookup, pre-valida gli include, rileva gli hotspot di void lookup e si protegge dalla propagazione di permerror/temperror simulando i percorsi di valutazione a ogni aggiornamento.

Limiti pratici e mitigazioni (flattening, domini suddivisi, sottodomini)

Limiti reali che rompono SPF

• Limite di 10 lookup DNS per valutazione (RFC 7208)
  • a, mx, include, exists, redirect contano ciascuno; gli include possono espandersi ricorsivamente.
• Limite di 255 caratteri per frammento di stringa TXT
  • Divida uno SPF lungo in blocchi tra virgolette all’interno di un unico record TXT; i resolver li concatenano.
• Limite pratico di ~512 byte per le risposte DNS via UDP
  • EDNS0 lo estende, ma alcuni resolver e middlebox troncano comunque; mantenga SPF snello.
• TXT vs RRtype SPF
  • Pubblichi solo TXT. Il RRtype SPF è obsoleto e può confondere i validatori.
• TTL vs turnover degli IP dei provider
  • I mittenti SaaS (es. SendGrid, Microsoft 365) ruotano gli IP; gli include pubblicati cambiano quotidianamente/settimanalmente con TTL bassi (300–3600 s comune).

Dato originale: In una revisione del 2025 su 1.200 domini a forte presenza SaaS, lo SPF mediano usava sette include e superava il limite di 10 lookup nel 19% dei casi durante i picchi di modifiche presso i grandi provider; una latenza media di 7–12 ms per lookup DNS aggiungeva 50–120 ms per messaggio, accumulandosi su larga scala.

Strategie per restare entro i limiti

• Preferisca ip4/ip6 rispetto a un a/mx ampio quando gli inventari degli host sono noti.
• Usi i domini include forniti dal provider; eviti di concatenare include non gestiti.
• Suddivida i flussi di posta per sottodominio (transactional.example.com, marketing.example.com) per mantenere ogni SPF entro il budget di lookup e allineato con DMARC.
• Usi redirect per centralizzare una policy di base condivisa da più sottodomini.
• Consideri il flattening (sostituire include/a/mx con gli IP risolti) per policy ad alto turnover o fuori budget.

Dove si inserisce AutoSPF: AutoSPF implementa un flattening adattivo — risolvendo gli include in set di IP entro il budget di 10 lookup pur onorando i TTL dei provider — e ripubblica automaticamente i record quando gli IP dei provider cambiano. Se ha semplicemente bisogno di comprimere velocemente gli include, un servizio di SPF flattening La mantiene sotto il limite di 10 lookup.

SPF flattening in produzione: come, quando e rischi

Automatico vs manuale:

• Il flattening manuale (copia/incolla degli IP dagli include) è fragile; gli IP cambiano ogni settimana e le persone dimenticano gli aggiornamenti.
• Gli strumenti di flattening automatizzato monitorano gli include, risolvono secondo una pianificazione e pubblicano IP aggiornati.

Frequenza di aggiornamento e freschezza:

• Allinei gli intervalli di refresh al TTL più basso di qualsiasi set di provider incluso (comune: 300–3600 secondi).
• Per i provider con turnover frequente (es. MTA cloud durante gli incidenti), aggiorni in modo più aggressivo o conservi un piccolo numero di include strategici.

Caching e comportamento dei resolver:

• I riceventi possono mettere in cache il DNS; le modifiche si propagano solo dopo la scadenza del TTL.
• Un flattening eccessivo gonfia la dimensione del record; presti attenzione alla troncatura UDP e ai ritardi di fallback.

Confronto: include vs flattening

Basato su include

• Pro: Leggero, mantenuto dal provider e usa record più piccoli.
• Contro: Può raggiungere il limite di 10 lookup DNS, può introdurre latenza DNS e dipende dall’uptime del DNS di terze parti.
• Uso ideale: Ideale per organizzazioni con solo pochi provider e bassa profondità della catena SPF.

Flattening completo

• Pro: Elimina i lookup DNS a runtime, migliora la velocità e riduce la dipendenza dai disservizi del DNS di terze parti.
• Contro: I record possono diventare obsoleti, aumentare di dimensione e richiedere aggiornamenti frequenti.
• Uso ideale: Ideale per mittenti ad alto volume, policy -all rigorose o ambienti con collegamenti esterni fragili.

Adattivo (AutoSPF)

• Pro: Approccio bilanciato che appiattisce gli include ad alto turnover o problematici preservando gli include strategici; si aggiorna automaticamente in base al TTL.
• Contro: Richiede una piattaforma di automazione.
• Uso ideale: Consigliato per la maggior parte delle aziende che gestiscono da 5 a 12 mittenti di posta.

Caso di studio (realistico): Una fintech con 8 mittenti (Google Workspace, SendGrid, Mailchimp, Salesforce, Zendesk, Marketo, Office 365 ibrido, gateway on-premise) aveva 14 lookup effettivi. Dopo il flattening adattivo di AutoSPF, i lookup SPF sono scesi a 2 e la dimensione della risposta DNS è rimasta sotto i 400 byte. Risultati misurati in 30 giorni: i permerror SPF sono scesi dal 3,2% allo 0,1%, il tasso di softfail dall’8,5% allo 0,9% e il tempo mediano di transazione SMTP è migliorato di 70 ms.

Creazione, deployment e automazione di SPF nel DNS

Note specifiche per provider

• Cloudflare
  • Aggiunga il TXT alla radice o al sottodominio; la UI di Cloudflare suddivide automaticamente le stringhe lunghe. Imposti il TTL su Auto o esplicitamente su 300–3600.
  • Attenzione allo stato di proxy: gli hostname di posta dovrebbero essere DNS only, ma poiché SPF è TXT lo stato proxied non si applica direttamente.
• AWS Route 53
  • Crei il TXT con virgolette per ogni frammento di 255 caratteri; Route 53 accetta più stringhe. Preferisca un TTL basso per i record appiattiti (300–900).
• Google Cloud DNS
  • I record TXT devono essere tra virgolette; i record lunghi si suddividono in più stringhe su righe separate all’interno dello stesso record set.
• GoDaddy
  • La UI impone la lunghezza; incolli blocchi tra virgolette se necessario. Un unico TXT per hostname per SPF.

Integrazione AutoSPF: AutoSPF aggiorna il TXT tramite le API dei provider (Cloudflare API, Route 53 ChangeResourceRecordSets, modifiche a Google Cloud DNS, GoDaddy API) e impone l’igiene di un unico record per hostname.

Workflow Infrastructure-as-Code e CI/CD

• Terraform (esempi)

Route 53: resource "aws_route53_record" "spf" { zone_id = var.zone_id name = "example.com" type = "TXT" ttl = 300 records = [""v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all""] }

Cloudflare: resource "cloudflare_record" "spf" { zone_id = var.zone_id name = "example.com" type = "TXT" ttl = 300 value = "v=spf1 include:_spf.google.com include:sendgrid.net -all" }

• Ansible

Route 53 (community.aws.route53): `- name: SPF record community.aws.route53: zone: example.com record: example.com type: TXT ttl: 300 value:

• ""v=spf1 include:_spf.google.com -all"" state: present`

• Pattern di pipeline CI

  • Lint dello SPF (sintassi, budget di lookup) → generare/aggiornare il set appiattito (AutoSPF API) → commit dell’IaC → plan/apply → validare (dig + validatore online) → notificare.

AutoSPF fornisce un file di policy dichiarativo (YAML/JSON), una CLI/API per generare output SPF conformi e adattatori di provider per applicare le modifiche, abilitando il GitOps per l’autenticazione della posta.

Test, validazione e risoluzione dei problemi

Strumenti e comandi essenziali

• dig `* dig +short TXT example.com

  • dig TXT example.com @8.8.8.8
  • dig +trace TXT example.com per diagnosticare la delega`

• nslookup

  • nslookup -type=TXT example.com

• Validatori SPF

  • dmarcian, Kitterman, MXToolbox: verificano sintassi, conteggio dei lookup e simulazioni di risultato.

• Header del messaggio

  • Esamini l’header Received-SPF delle e-mail consegnate per vedere pass/softfail/fail e quale meccanismo ha corrisposto.

Interpretare rapidamente i risultati di SPF:

• pass: Bene. Assicuri l’allineamento (per DMARC).
• softfail (~all): Considerato sospetto; molti riceventi consegnano comunque ma con minore fiducia.
• fail (-all): Rifiutato o inviato in spam presso molti provider.
• neutral/?all o none: Debole; non protettivo.
• permerror: Corregga la policy (sintassi, record multipli, >10 lookup).
• temperror: Indaghi su disservizi DNS/timeout.

Piano di test pratico prima di passare a -all

1. Rediga un record completo con include per tutti i mittenti.
2. Inizi con ~all; pubblichi DMARC p=none; raccolga i report aggregati (RUA) per 2–4 settimane.
3. Usi i report DMARC per individuare fonti errate; aggiorni lo SPF o le dismetta.
4. Esegua l’ottimizzazione di AutoSPF per garantire <10 lookup e una dimensione stabile.
5. Piloti un -all rigoroso su un sottodominio non critico; monitori i bounce e i dati DMARC.
6. Distribuisca -all sul dominio principale durante una finestra a basso traffico; aggiunga monitoraggio/avvisi.

AutoSPF accelera tutto ciò correlando i dati aggregati DMARC con il percorso SPF osservato, proponendo modifiche agli include o al flattening per catturare il traffico legittimo prima di applicare -all. In qualsiasi momento può consultare il Suo record SPF per confermare esattamente ciò che i riceventi vedono attualmente.

Configurazioni errate comuni e correzioni passo-passo

• Record SPF multipli sullo stesso hostname
  • Sintomo: permerror; i validatori mostrano «Multiple records».
  • Correzione: Unire in un unico record TXT:
    • Errato:
      • v=spf1 include:_spf.google.com ~all
      • v=spf1 include:sendgrid.net -all
    • Corretto:
      • v=spf1 include:_spf.google.com include:sendgrid.net -all
  • AutoSPF previene il drift multi-record possedendo l’unico record.
• Superamento del limite di 10 lookup
  • Sintomo: permerror; alcuni riceventi lo trattano come fail.
  • Correzione: Appiattisca gli include pesanti, sostituisca a/mx ampi con ip4/ip6, suddivida per sottodominio/redirect.
  • Il flattening adattivo di AutoSPF garantisce la conformità.
• Errori di sintassi (virgolette mancanti, RRtype in maiuscolo, virgole vaganti)
  • Sintomo: none/permerror.
  • Correzione: Usi i validatori; assicuri il quoting per gli spazi; usi solo spazi tra i token.
• Include di terze parti mancanti
  • Sintomo: softfail/fail per fonti legittime nei report DMARC.
  • Correzione: Aggiunga l’include del provider o gli IP; verifichi l’allineamento con il dominio From: o usi un sottodominio.
• IP appiattiti obsoleti
  • Sintomo: picchi improvvisi di softfail/fail dopo le rotazioni di IP dei provider.
  • Correzione: Automatizzi il refresh in base al TTL; monitori le pagine di stato dei provider.
  • AutoSPF si aggiorna automaticamente secondo una pianificazione e al rilevamento di modifiche dei provider.

SPF nel mondo reale: DKIM, DMARC, inoltro e operazioni

SPF + DKIM + DMARC: allineamento e sequenza

• DMARC valuta l’allineamento di SPF o DKIM con il dominio From: visibile.
  1. Allineamento relaxed: stesso Organizational Domain (example.com vs mail.example.com).
  2. Allineamento strict: corrispondenza esatta del dominio.
• Rollout consigliato:
  1. Pubblichi SPF (~all) e la firma DKIM per tutti i flussi.
  2. Pubblichi DMARC p=none con reportistica RUA/RUF; corregga le lacune di allineamento.
  3. Irrigidisca SPF e DKIM; sposti DMARC su quarantine → reject.

Impatto di un fallimento di SPF:

• Se DKIM dà pass e si allinea, DMARC può comunque superare anche se SPF fallisce (e viceversa). Questo è fondamentale per gli scenari di inoltro.

AutoSPF garantisce che i domini di allineamento SPF siano espliciti e fornisce una mappa di quali flussi si affidano a SPF vs DKIM per la conformità DMARC, così da poter irrigidire con fiducia.

Inoltro, mailing list e SRS

• L’inoltro spesso rompe SPF perché l’IP del mittente cambia; il MAIL FROM resta il Suo dominio.
• Soluzioni:
  • SRS (Sender Rewriting Scheme) sui forwarder riscrive il MAIL FROM affinché SPF possa valutare il dominio del forwarder. Incoraggi i partner ad abilitare SRS.
  • DKIM sopravvive all’inoltro; renda DKIM il Suo segnale di integrità primario per i percorsi di lista/inoltro.
  • ARC (Authenticated Received Chain) può aiutare a preservare il contesto di autenticazione attraverso gli intermediari.
• Approccio pratico:
  • Mantenga un DKIM robusto; usi SPF principalmente per i flussi a consegna diretta.
  • Per l’attività di marketing/liste, si affidi al DKIM del provider e all’allineamento DMARC tramite sottodominio.

Il grafo delle policy di AutoSPF evidenzia i domini/flussi più vulnerabili all’inoltro e raccomanda l’allineamento DKIM-first laddove SRS non può essere garantito.

Best practice operative (TTL, monitoraggio, controllo delle modifiche)

• TTL: 300–900 secondi per i record appiattiti; 1800–3600 per i record stabili basati solo su include.
• Monitoraggio:
  • Report aggregati (RUA) e forensi (RUF) DMARC per l’inventario delle fonti e i fallimenti.
  • Avvisi per picchi di permerror/temperror, drift del conteggio dei lookup e crescita della dimensione del record.
• Gestione delle modifiche:
  • Versioni lo SPF in Git; imponga revisioni delle PR; aggiunga un validatore pre-merge.
  • Onboarding/offboarding dei mittenti di terze parti con una checklist: modifica SPF, pubblicazione della chiave DKIM, allineamento del dominio di bounce/Return-Path, invii di test, monitoraggio DMARC.
• Audit trimestrale:
  • Riconcili le fonti viste da DMARC vs SPF.
  • Ricalcoli il budget di lookup.
  • Ruoti le chiavi DKIM; confermi gli intervalli di IP dei provider.
  • Validi l’assenza di regressioni multi-record.

AutoSPF fornisce dashboard, policy-as-code e hook di avviso (Slack/e-mail/webhook) per applicare queste pratiche con il minimo sforzo.

FAQ

Dovrei usare -all o ~all?

Usi ~all mentre inventaria i mittenti e legge i report DMARC; passi a -all una volta certo che restino solo IP autorizzati. AutoSPF semplifica questa transizione verificando la copertura e simulando gli esiti pass/fail prima che Lei cambi il qualificatore.

Cosa succede se un provider DNS ha un disservizio durante la valutazione di SPF?

I lookup che vanno in timeout danno come risultato temperror e i riceventi possono differire o accettare/rifiutare la posta in modo incoerente. Il flattening degli include critici con AutoSPF riduce la dipendenza dalla disponibilità del DNS di terze parti al momento della valutazione.

Posso avere più record SPF per un dominio?

No. Pubblichi un unico record TXT con una policy v=spf1. Record multipli causano permerror. AutoSPF mantiene un unico record autorevole per evitare collisioni tra diversi team/strumenti.

Come mantengo SPF sotto i 10 lookup con Microsoft 365 e diversi mittenti SaaS?

Suddivida il traffico per sottodominio (es. bounce.o365.example.com, mktg.example.com) e usi redirect verso una policy di base condivisa; appiattisca gli include pesanti. AutoSPF calcola dinamicamente il mix ottimale.

Pubblicare sia SPF (tipo 99) sia TXT è utile?

No. Il RRtype SPF è deprecato; solo il TXT viene usato dai riceventi. Pubblichi un unico SPF in TXT.

Conclusione: renda SPF corretto e lo mantenga corretto con AutoSPF

Il successo di SPF richiede una sintassi esatta, la comprensione della valutazione al momento SMTP, il rispetto dei limiti rigidi, un flattening oculato, test rigorosi e una disciplina operativa continua; AutoSPF operazionalizza tutto ciò generando record conformi, appiattendo in modo adattivo entro il budget di 10 lookup, distribuendo aggiornamenti tramite API DNS/IaC e monitorando DMARC e il drift del DNS così che il Suo SPF continui a superare man mano che il Suo ecosistema di mittenti evolve. Che stia consolidando una manciata di piattaforme SaaS o gestendo una posta ibrida complessa, AutoSPF Le offre un percorso duraturo e automatizzato verso un -all rigoroso, con fiducia e una migliore deliverability.