Cos'è un record SPF? Sintassi, limiti e casi di errore

Un record SPF è un unico record TXT nel DNS del dominio che elenca i server autorizzati a inviare posta usando quel dominio nel mittente di busta (envelope sender). Il server ricevente legge il record, confronta l'IP che si connette con la lista e restituisce pass, fail, softfail o neutral. Autentica il percorso di invio, non il messaggio, e non dice nulla sull'indirizzo From che l'utente vede.

Questa distinzione spiega la maggior parte dei ticket SPF che vediamo nelle tracce.

Un record SPF è una allowlist di mittenti, pubblicata nel DNS

SPF sta per Sender Policy Framework, specificato nella RFC 7208. Il record è una voce TXT alla radice del dominio che inizia con v=spf1. Un esempio minimo:

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"

Si legge da sinistra a destra. Il ricevente controlla ogni termine in ordine e si ferma alla prima corrispondenza. Il termine all finale raccoglie tutto ciò che non ha trovato corrispondenza prima.

Il dominio controllato non è l'header From. È il dominio nel comando SMTP MAIL FROM, chiamato anche envelope sender o Return-Path. Se è vuoto, come nei bounce, il ricevente ripiega sul nome HELO.

I meccanismi: ip4, ip6, a, mx, include, exists

Ogni termine è un meccanismo, eventualmente preceduto da un qualificatore. Sei di questi coprono quasi tutti i record reali.

• ip4: / ip6: corrispondono a un indirizzo letterale o a un range CIDR. Non costano lookup.

• a corrisponde ai record A/AAAA del dominio. Costa un lookup.

• mx corrisponde agli host dei record MX del dominio. Costa un lookup, più uno per ogni host.

• include: corrisponde a tutto ciò che corrisponde nel record SPF di un altro dominio. Costa un lookup, più tutto ciò che è annidato al suo interno.

• exists: corrisponde a qualsiasi record A per un nome costruito. Costa un lookup.

• ptr corrisponde al reverse DNS dell'IP che si connette. Costa lookup, e la RFC 7208 sconsiglia di usarlo.

I qualificatori fissano il risultato quando un termine corrisponde. + è pass ed è il valore predefinito, - è fail, ~ è softfail, ? è neutral. Quindi -all significa "rifiuta tutto ciò che non è elencato", mentre ~all significa "accetta ma segnala".

Preferisci ip4: e ip6: ogni volta che controlli l'indirizzo. Non costano lookup e non possono rompersi quando il DNS di qualcun altro cambia.

Il limite di 10 lookup è il vincolo che rompe i record reali

La RFC 7208 limita a 10 i termini che generano query DNS durante una singola valutazione SPF: include, a, mx, ptr, exists e il modificatore redirect. Gli include annidati contano. Oltre il decimo, il risultato è permerror, e il controllo fallisce in modo permanente invece di ripiegare su altro.

C'è un secondo limite meno discusso. I termini che restituiscono una risposta vuota o NXDOMAIN sono void lookup, e la specifica dice di fermarsi a due. Un include: obsoleto che punta a un fornitore abbandonato l'anno scorso è un void lookup che continui a pagare.

Ecco come i team arrivano davvero al limite. Google Workspace occupa un include. Un provider transazionale ne occupa un altro. Una piattaforma di marketing ne occupa uno e ne annida altri tre al suo interno. Un help desk, un CRM e uno strumento di fatturazione ne aggiungono altri quattro. Si è già a 11 senza aver fatto nulla di insolito.

Il guasto è silenzioso. La posta continua a partire, e alcuni ricevitori la consegnano ancora, ma SPF non autentica più nulla per te. Se ti affidi all'allineamento DMARC tramite SPF, quella strada è chiusa finché non appiattisci il record o rimuovi dei mittenti.

Tre correzioni funzionano, in ordine di preferenza:

1. Rimuovi i mittenti che non usi più. Verifica gli include rispetto ai report aggregati DMARC degli ultimi 90 giorni.

2. Sposta il traffico massivo su un sottodominio come mail.example.com, con un proprio record SPF e un proprio budget di 10 lookup.

3. Appiattisci gli include in range ip4: letterali, ma solo con automazione. I fornitori ruotano gli IP, e un record appiattito a mano diventa obsoleto senza alcun avviso.

Pubblica un solo record SPF per dominio

Un dominio non deve pubblicare due record SPF. Se il ricevente trova due voci TXT v=spf1, il risultato è permerror, come per il limite di lookup. Succede quando una persona aggiunge un record per un nuovo strumento mentre un altro è già presente.

La correzione è meccanica. Unisci i termini in un unico record, con un solo v=spf1 all'inizio e un solo all alla fine. Tutto ciò che la documentazione del fornitore ti chiede di aggiungere va dentro il record esistente come un altro include:, mai come nuova voce TXT.

Due trappole più piccole. Una stringa TXT oltre 255 caratteri va spezzata in più stringhe tra virgolette dentro lo stesso record, cosa che la maggior parte dei provider DNS fa per te. E tieni la risposta sotto i circa 450 byte dove puoi, perché risposte più grandi possono passare da UDP a TCP, e alcuni resolver lo gestiscono male.

Softfail o hardfail: scegli in base a ciò che puoi vedere

Il termine all è una dichiarazione di politica, e il consiglio standard ("usa -all") salta la parte che conta. Un hard fail è sicuro solo quando conosci ogni mittente legittimo.

La nostra regola pratica, leggendo le tracce:

• ~all mentre stai ancora inventariando i mittenti, o se inoltri posta e non controlli il percorso.

• -all quando i report DMARC mostrano che ogni fonte legittima passa per alcune settimane.

• Mai +all, che autorizza l'intera rete, e mai ?all su un dominio di produzione.

In pratica la differenza è più piccola di quanto ci si aspetti. La maggior parte dei grandi ricevitori tratta SPF come un segnale tra altri, e con una policy DMARC in vigore il verdetto DMARC è quello che decide. Resta il fatto che un -all su un record incompleto è il modo in cui si perdono le fatture.

SPF si rompe con l'inoltro, ed è una scelta di progetto

SPF valida l'IP che si è connesso al server ricevente. Quando un messaggio viene inoltrato, passa da una mailing list o viene rilanciato da un servizio di alias, l'IP che si connette è quello dell'inoltratore, non il tuo. Il controllo SPF fallisce anche se non hai sbagliato nulla.

Non puoi risolvere questo dentro SPF. Per questo esiste DKIM accanto a SPF: una firma sopravvive al passaggio, una lista di IP no. Un dominio che dipende solo da SPF vedrà errori di autenticazione su ogni messaggio inoltrato.

È anche il motivo per cui SPF da solo non soddisfa DMARC per la posta inoltrata. Conviene prevedere che sia DKIM a trasportare quei messaggi.

Allineamento SPF: superare il controllo non equivale a corrispondere al dominio From

Un messaggio può superare SPF e fallire DMARC. DMARC richiede che il dominio verificato da SPF, cioè quello del Return-Path, corrisponda al dominio From visibile. Molti provider condivisi usano per default un proprio dominio di bounce, quindi SPF passa per provider-mail.net e non dice nulla su example.com.

Controlla nelle intestazioni grezze. Nella riga Authentication-Results guarda smtp.mailfrom=. Se non è il tuo dominio o un suo sottodominio, SPF passa senza aiutarti.

Il rimedio è un Return-Path personalizzato su un tuo sottodominio, che i mittenti seri supportano. Postmark, Resend, Mailgun e SendGrid documentano tutti questa configurazione, anche se non è sempre attiva di default.

I provider di posta ora si aspettano autenticazione da ogni mittente

Da febbraio 2024 Google richiede che tutti i mittenti si autentichino con SPF o DKIM, e chi invia più di 5.000 messaggi al giorno verso Gmail deve avere SPF, DKIM e DMARC. I dettagli sono nelle linee guida di Google per i mittenti. Yahoo ha introdotto regole analoghe nello stesso periodo.

Questo ha trasformato SPF da elemento utile a prerequisito di consegna. Un record mancante o rotto ora si traduce in rifiuti e spam, non solo in un punteggio di reputazione più basso.

La nostra lettura, dopo un paio d'anni di tracce: le regole intercettano soprattutto domini senza alcuna autenticazione e mittenti con tassi alti di reclami. Un record SPF corretto da solo non ti porta nella casella di posta, ma uno mancante ti tiene fuori.

Come verificare e correggere un record SPF in quattro passaggi

Procedi in quest'ordine e ricontrolla dopo ogni modifica DNS.

1. Leggi il record attuale. Esegui dig +short TXT example.com e trova la voce che inizia con v=spf1. Se ce ne sono due, uniscile.

2. Conta i lookup. Somma include, a, mx, exists, redirect e tutto ciò che è annidato negli include. Se sei a 8 o più, pianifica la pulizia adesso, non all'undicesimo.

3. Elenca i mittenti reali. Usa i report aggregati DMARC o le intestazioni Authentication-Results dei test di invio. Aggiungi solo le fonti che compaiono.

4. Invia un test e leggi l'intestazione. Il risultato deve essere spf=pass con smtp.mailfrom sul tuo dominio.

Le modifiche DNS richiedono tempo per propagarsi, e il TTL del record attuale decide per quanto tempo sopravvivono le risposte vecchie. Abbassalo a 300 secondi il giorno prima di una modifica pianificata.

Un record di esempio per una SaaS con tre mittenti

Prendi un prodotto che invia da Google Workspace, da un provider transazionale e da un help desk. Un record pulito è questo:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"

Sono tre include, e ognuno nasconde i propri lookup annidati. Contali prima di pubblicare, perché la lunghezza visibile non dice nulla del budget reale. Un record con tre include può già arrivare a 7 o 8 lookup.

Ora separa per scopo. Tieni la posta umana sul dominio principale. Metti le notifiche di prodotto su notify.example.com con un record che elenca solo il provider transazionale. Il record radice resta corto, il sottodominio ottiene un proprio budget di 10 lookup, e un problema di reputazione su un flusso non trascina con sé l'altro.

Questa separazione rende anche leggibili i report DMARC. Ogni flusso ha il proprio dominio Return-Path, quindi un errore indica un solo mittente invece di un mucchio.

Cosa non fa SPF

Non impedisce a qualcuno di falsificare il tuo indirizzo From, perché non guarda mai quell'intestazione. Non cifra nulla. Non ti dice perché un messaggio è finito nello spam. E non scala oltre il budget di 10 lookup senza una manutenzione continua.

Consideralo uno dei tre record da pubblicare insieme: SPF per il percorso di invio, DKIM per l'integrità del messaggio, DMARC per la policy che li lega al dominio From. Se hai SPF e nient'altro, il passo concreto successivo è pubblicare un record DMARC con p=none e leggere i report per due settimane.