SPF PermError indica che il record SPF non può essere valutato correttamente. Una causa frequente è il superamento del limite di 10 meccanismi o modificatori che richiedono interrogazioni DNS durante una singola verifica.
Questa guida approfondisce SPF PermError con una procedura progressiva e reversibile. Non inviare password, codici 2FA, token, chiavi private o file di configurazione completi nei ticket.
Che cosa significa
Il limite riguarda la valutazione completa, compresi gli include richiamati e i loro eventuali include. Non basta contare le parole presenti nel record principale.
I meccanismi `include`, `a`, `mx`, `exists` e il modificatore `redirect` possono generare lookup. `ip4` e `ip6` non richiedono la stessa interrogazione.
Come riconoscere il problema
- I test mostrano too many DNS lookups.
- DMARC fallisce perché SPF è permerror.
- Il problema nasce aggiungendo un nuovo provider.
- Il record contiene molti include.
- Invii legittimi hanno esiti diversi tra destinatari.
Cause più frequenti
1. Troppi provider
Ogni piattaforma aggiunge include e sottodipendenze. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
2. Include annidati
Un solo include può espandersi in molti lookup. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
3. Uso eccessivo di a e mx
Ogni meccanismo può richiedere ulteriori query. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
4. Provider dismessi
Autorizzazioni vecchie restano nel record. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
5. Più record SPF
Due TXT v=spf1 causano permerror indipendentemente dal conteggio. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
6. Flattening non mantenuto
IP statici copiati diventano obsoleti quando il provider cambia infrastruttura. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
Diagnosi passo per passo
- Recupera l’unico SPF. Interroga TXT sul nome mittente. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Espandi gli include. Conta ricorsivamente i meccanismi DNS. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Inventaria i servizi. Associa ogni include a una piattaforma reale. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Controlla più record. Deve esistere una sola policy v=spf1 per nome. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Verifica il Return-Path. SPF usa il dominio dell’envelope sender, non necessariamente il From. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Controlla DMARC. Valuta anche allineamento. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Rimuovi servizi dismessi in ambiente controllato. Conferma prima che non inviino più. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
Metodo sicuro di intervento
Prima di modificare la configurazione, registra lo stato iniziale: indirizzo o funzione coinvolta, messaggio completo, data e ora, ultima modifica nota e risultato da un secondo dispositivo, rete o strumento. Una diagnosi ripetibile è più utile di molti tentativi eseguiti contemporaneamente.
Applica una sola correzione alla volta e conserva una copia dei file, dei record o dei valori precedenti. Dopo ogni intervento ripeti esattamente il test originale e controlla i log relativi allo stesso intervallo temporale. Se il risultato cambia, annota quale modifica lo ha prodotto.
Evita disattivazioni globali di firewall, WAF, TLS, cache o sistemi di sicurezza. Quando serve una eccezione, deve essere limitata all’URL, al parametro, al processo o al servizio realmente interessato.
Procedura di risoluzione
- Elimina include inutili. Riduci provider non più usati. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Usa sottodomini dedicati. Separa newsletter, transazionali e posta ordinaria quando appropriato. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Sostituisci meccanismi ridondanti. Evita a o mx non necessari. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Chiedi configurazione ottimizzata al provider. Alcuni offrono include specifici o domain delegation. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Valuta DKIM come percorso DMARC. Mantieni comunque SPF valido. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Evita flattening manuale non gestito. Gli IP possono cambiare. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Ritesta dopo il TTL. Verifica conteggio ed esito su messaggi reali. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
Controlli finali
- Un solo SPF.
- Valutazione entro 10 lookup.
- Invii legittimi passano.
- Provider dismessi rimossi.
- DMARC allineato.
Prevenzione
- Inventaria mittenti.
- Rivedi SPF periodicamente.
- Usa sottodomini.
- Documenta include.
- Non aggiungere provider senza rimuovere vecchi.
Errori da evitare
- Non creare un secondo SPF.
- Non usare `+all`.
- Non flatten manualmente senza manutenzione.
- Non contare solo include visibili.
- Non eliminare un provider ancora attivo.
Come documentare la verifica
Conserva una breve nota con configurazione iniziale, risultato di ogni controllo e modifica applicata. Inserisci sempre data e ora, perché cache, log, code, rate limit e processi pianificati possono cambiare nel tempo. Questa documentazione facilita il rollback e permette all’assistenza di evitare verifiche già eseguite.
Quando confronti due test, usa le stesse condizioni: stesso URL o destinatario, stesso file, stesso client e stessa rete quando possibile. Se cambi più variabili, il risultato non permette di individuare con certezza la causa.
Controllo incrociato
Dopo la correzione esegui almeno un controllo indipendente. Per un sito confronta browser, risposta HTTP e log; per DNS interroga autoritativo e resolver pubblico; per la posta confronta Webmail, intestazioni e Track Delivery; per PHP verifica il valore effettivamente applicato al dominio. Un solo indicatore può essere influenzato da cache o configurazioni locali.
Se il problema ricompare, evita ulteriori modifiche e raccogli nuovamente i dati. La ricorrenza può indicare un processo pianificato, un limite raggiunto, una dipendenza esterna o una configurazione che viene rigenerata automaticamente.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:
- dominio envelope sender
- record SPF
- servizi di invio
- risultato del test
- header Authentication-Results
Non inviare credenziali. Per iniziare la diagnosi sono sufficienti dati tecnici, orari, URL, codici e messaggi di errore.
Fonti tecniche ufficiali
Domande frequenti su SPF PermError
Il limite conta soltanto gli include?
No. Include, a, mx, exists e redirect possono contribuire, compresi quelli annidati.
ip4 conta come lookup?
No, un meccanismo ip4 contiene direttamente l’indirizzo.
Posso creare due record SPF?
No. Più TXT che iniziano con v=spf1 producono PermError.
Che cos’è SPF flattening?
La sostituzione degli include con IP; richiede aggiornamento continuo e può diventare obsoleta.
DKIM risolve il PermError SPF?
Può permettere a DMARC di passare se è valido e allineato, ma SPF deve comunque essere corretto.