Creare un record SPF: organizzare i mittenti e controllare le query

Se devi creare un record SPF per un dominio, l'obiettivo è semplice: autorizzare i mittenti corretti senza trasformare il DNS in un groviglio destinato a creare problemi dopo qualche mese. Molte difficoltà iniziano allo stesso modo. Aggiungi un fornitore, poi un altro. Microsoft restituisce un 550 5.7.515, Google un 550 5.7.26, e ti ritrovi a esaminare record TXT alle 11 di sera.

Il problema è proprio questo. SPF sembra facile finché non smette di esserlo. Il record del dominio radice diventa un contenitore di tutto, gli include ricorsivi si accumulano e una valutazione aggiuntiva può produrre PermError. Se gestisci un dominio aziendale, l'infrastruttura di un cliente o più marchi, non è un dettaglio: può compromettere la consegna, anche se PermError non comporta necessariamente un rifiuto automatico. Per capire meglio la configurazione del dominio, parti dalla guida sull'e-mail aziendale per le piccole imprese.

Questa guida propone un'architettura più sostenibile: mantenere la posta aziendale sul dominio radice, separare gli invii massivi e applicativi con sottodomini effettivamente usati per l'invio e trattare il budget delle interrogazioni come una risorsa limitata. In questo modo i record SPF diventano più facili da mantenere, pur richiedendo verifiche quando cambiano i mittenti.

Perché tanti record SPF non funzionano

SPF può fallire perché i destinatari limitano i termini che attivano interrogazioni DNS durante la valutazione. Accumulare troppi include su un dominio può superare il limite, produrre PermError e compromettere la consegna o causare un rifiuto secondo la politica del destinatario, anche se la sintassi sembra corretta.

L'RFC 7208 è esplicito. I termini che attivano interrogazioni DNS comprendono include, a, mx, ptr, exists e redirect. I destinatari devono limitare a 10 i termini di questo tipo valutati, compresi quelli ricorsivi; non si tratta di contare tutti i pacchetti DNS. Superare il limite produce un errore permanente, non un avviso. L'RFC stabilisce inoltre che più record SPF sullo stesso nome di dominio causano PermError. Altri record TXT, non relativi a SPF, possono coesistere.

Ecco perché il consiglio abituale non basta. Le guide generiche suggeriscono di creare un record SPF inserendo tutti i mittenti in un valore TXT su @. Sembra ordinato, ma trasforma il dominio radice in un'infrastruttura condivisa tra newsletter, sistemi di assistenza, avvisi applicativi, strumenti di prospezione commerciale e caselle dei collaboratori. Se un fornitore amplia la catena di include, tutti gli invii che dipendono da quella politica possono risentirne.

Un modello sbagliato: un solo record SPF sul dominio radice che tenta di autorizzare tutti gli strumenti mai usati dall'azienda.

Anche le indicazioni di Google per i mittenti sottolineano l'importanza di un'autenticazione corretta e di un allineamento coerente, soprattutto per gli invii massivi. SPF è solo una parte del quadro, ma un suo errore è spesso il primo sintomo evidente.

Il vero vincolo: il budget di 10 interrogazioni

La regola è questa: una politica SPF ha un budget fisso di 10 termini valutati che attivano interrogazioni DNS. Il conteggio è ricorsivo. Se un include porta ad altri termini di questo tipo e vengono valutati, anche questi contano. Il tuo provider DNS non corregge una politica SPF dimensionata male.

Cosa rientra nel budget:

• include
• a
• mx
• ptr (da evitare)
• exists
• redirect

Cosa non rientra nel budget:

• ip4
• ip6
• all

Contano anche le interrogazioni senza risultato. L'RFC 7208 raccomanda ai destinatari di limitarle a due. Un errore nel nome di destinazione di un include può consumare parte di quel margine. Superare il limite raccomandato, non semplicemente raggiungerlo, può produrre un altro PermError.

Se il dominio invia tramite più fornitori, calcola il budget reale prima di pubblicare il record SPF. Il rischio non dipende soltanto dal numero dei fornitori, ma dai termini valutati nelle loro politiche e dalla tua architettura.

Creare un record SPF con un'architettura separata

Un modo per ridurre il rischio è separare la posta tra persone dagli invii massivi o applicativi. Mantieni il provider principale delle caselle sul dominio radice e configura i mittenti specializzati con sottodomini realmente usati nel MAIL FROM o return-path. Modificare solo il From visibile non separa il budget SPF. L'allineamento DMARC resta necessario tramite SPF o DKIM, secondo la modalità rigorosa o rilassata.

Il modello è questo:

1. Dominio radice @ per gli scambi tra persone.
2. Sottodomini di MAIL FROM o return-path per newsletter, assistenza, avvisi transazionali e altri mittenti specializzati.
3. Un record SPF per nome host, senza duplicati né vecchie politiche dimenticate. Altri TXT non relativi a SPF possono coesistere.

Esempio di record sul dominio radice per l'invio gestito da TrekMail, da verificare con la configurazione attuale:

v=spf1 include:spf.trekmail.net -all

La politica è facile da esaminare: un include e una terminazione esplicita. L'include può però avere dipendenze ricorsive; controllane il costo effettivo.

Esempio indicativo per un sottodominio di marketing, da confrontare con le istruzioni ufficiali attuali di ciascun fornitore:

v=spf1 include:servers.mcsv.net include:hubspot.com -all

Mailchimp e HubSpot consumano il budget di marketing.example.com soltanto se questo è il dominio effettivamente usato nel MAIL FROM o return-path e se la loro configurazione supporta tale modello. In quel caso, le modifiche alle loro politiche SPF non incidono direttamente sulla politica di example.com. L'allineamento DMARC richiede comunque una configurazione adeguata.

Anche TrekMail si inserisce in questa organizzazione. La documentazione dei domini presenta include:spf.trekmail.net come include di base per l'invio gestito. Il controllo DNS può aiutare a individuare conflitti, senza sostituire una verifica completa. Per configurare caselle e DNS, consulta Aggiungere un dominio a TrekMail e Verificare lo stato del DNS.

Passo dopo passo: creare valori SPF senza improvvisare

Per creare record SPF facili da mantenere, inventaria prima tutti i mittenti, assegna a ciascuno il nome host corretto e solo dopo costruisci il TXT. Non partire dal DNS: identifica chi invia e quale dominio di busta utilizza. Così eviti di accumulare include arbitrari sul dominio radice.

Segui questo processo:

1. Elenca tutti i servizi che inviano posta usando il tuo dominio.
2. Classifica ogni mittente come aziendale, transazionale, di assistenza o di marketing.
3. Decidi il nome host di MAIL FROM per ciascun mittente e verifica l'allineamento DMARC.
4. Usa la politica SPF minima che autorizzi tutti gli invii legittimi di quell'host.
5. Pubblica un TXT SPF per host; altri TXT non relativi a SPF possono coesistere.

Costruisci poi il record reale seguendo le istruzioni ufficiali attuali del fornitore, comprese quelle per il MAIL FROM personalizzato.

Esempio di SMTP gestito da TrekMail:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net -all
TTL: 3600

Esempio combinato di TrekMail e SMTP proprio per Nano o configurazioni ibride, non una ricetta universale:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com -all
TTL: 3600

Con TrekMail Nano, il modello descritto richiede un tuo provider SMTP per inviare. Autorizza il fornitore che consegna effettivamente il messaggio e il relativo dominio di busta; ospitare le caselle su TrekMail non richiede automaticamente di includere TrekMail e SES insieme. L'esempio combinato vale solo quando entrambi sono necessari, e per SES occorre seguire le istruzioni sul MAIL FROM personalizzato. Secondo le condizioni riportate nell'articolo, i piani a pagamento partono da $3.50/mese e includono SMTP gestito. Nano è descritto come gratuito, soggetto alle condizioni vigenti. I piani a pagamento offrono inoltre una prova gratuita di 14 giorni che richiede una carta di credito. Verifica le condizioni attuali e consulta SMTP personalizzato (BYO) e SMTP gestito da TrekMail.

Pubblicare e verificare il record

Dopo aver creato il record SPF, pubblicalo come TXT e controlla cosa restituisce il DNS pubblico. Non fidarti soltanto dell'interfaccia del registrar, di un pannello con dati in cache o dell'indicatore verde di uno strumento. Interroga il dominio e verifica che ci sia un solo record SPF valido. Questi comandi normalmente consultano un resolver con cache: non garantiscono una risposta diretta dai server autoritativi né un tempo esatto di propagazione.

Mac o Linux:

dig txt example.com +short

Windows:

nslookup -type=txt example.com

Devi trovare un solo valore SPF che inizi con v=spf1, senza una seconda politica SPF duplicata o un vecchio record dimenticato dopo una migrazione. Altri valori TXT non relativi a SPF sono compatibili.

Controlli rapidi:

• Inizia con v=spf1
• Termina con -all dopo aver completato l'inventario dei mittenti e i test
• Contiene solo i mittenti che usi davvero
• Esiste una sola politica SPF per host, non più di una

Quando cambi fornitore, esamina i record precedenti: possono rimanere MX e SPF non più coerenti con la configurazione desiderata. La documentazione DNS di TrekMail affronta questi casi. Per una migrazione più ampia, possono aiutarti queste guide: come creare un'e-mail con il proprio dominio e hosting e-mail per più domini.

Errori SPF comuni e prime soluzioni

Molte anomalie SPF dipendono da troppi termini valutati che attivano interrogazioni, record SPF duplicati, domini di invio sbagliati o errori negli include. Una mappa chiara dei mittenti rende questi problemi più facili da individuare. Improvvisare rende rapidamente più costosa la diagnosi.

Queste regole pratiche evitano molti problemi:

1. Usa ip4 per mittenti statici sotto il tuo controllo. Non consuma termini del budget di interrogazioni.
2. Separa il MAIL FROM degli invii di marketing da quello della posta della dirigenza quando il fornitore lo consente, mantenendo l'allineamento DMARC.

La documentazione di Google è utile perché definisce l'obiettivo completo: autenticazione e allineamento, non SPF isolatamente. SPF può passare e DMARC fallire se il dominio del From visibile non è allineato al dominio di busta autenticato, secondo la modalità rigorosa o rilassata, e non c'è una firma DKIM allineata che passi. Consulta le domande frequenti di Google sulle linee guida per i mittenti se stai analizzando la consegna di invii massivi.

Quando TrekMail può semplificare il lavoro

TrekMail può aiutare a mantenere una configurazione uniforme su più domini. Il modello descritto combina un include per l'invio gestito, spazio condiviso, fatturazione senza tariffa per utente, migrazione IMAP integrata e SMTP proprio o gestito in base al piano. Verifica disponibilità, limiti e condizioni attuali; un unico include non garantisce un costo ricorsivo basso.

Per chi avvia un'attività da solo, il vantaggio può essere la semplicità: ospitare le caselle su TrekMail, mantenere ordinata la politica radice ed evitare la tariffazione per postazione secondo il piano. Per i team, una configurazione standardizzata può facilitare l'inserimento delle persone e ridurre gli errori DNS. Per agenzie e MSP, offre un modello riutilizzabile su molti domini, purché ogni mittente e migrazione siano verificati.

Passare da configurazioni SPF fragili e diverse per ogni cliente a un'architettura ripetibile, un pannello comune e una politica radice verificata migliora la gestione. Non si tratta soltanto di accorciare una stringa TXT.

Come riferimento dell'articolo, Nano offre 10 domini, 5GB di spazio condiviso e SMTP proprio senza carta obbligatoria. Per invio gestito e limiti superiori, i piani a pagamento descritti partono da $3.50/mese, con una prova gratuita di 14 giorni che richiede una carta di credito. Consulta i prezzi di TrekMail per confermare piani, limiti e condizioni attuali.

Conclusione: creare un record SPF più facile da mantenere

Per creare record SPF duraturi, smetti di pensare a un'enorme lista di autorizzazioni sul dominio radice e pensa all'architettura. Dominio radice per gli scambi tra persone. Sottodomini di MAIL FROM per i mittenti specializzati. Include minimi. -all esplicito quando l'inventario è completo. Verifica DNS dopo la pubblicazione, considerando cache e allineamento DMARC.

Questo approccio aiuta a controllare il budget di interrogazioni e a ridurre guasti inattesi. Non elimina le revisioni quando cambiano i fornitori, ma le semplifica. Se stai rinnovando l'infrastruttura e-mail, esplora TrekMail e verifica se il modello e le condizioni attuali sono adatti alla tua crescita.