SPF PermError: superato il limite di 10 lookup DNS

In breve: SPF PermError: indica che il record SPF non può essere valutato correttamente.

SPF PermError

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.

3. Uso eccessivo di a e mx

Ogni meccanismo può richiedere ulteriori query.

4. Provider dismessi

Autorizzazioni vecchie restano nel record.

5. Più record SPF

Due TXT v=spf1 causano permerror indipendentemente dal conteggio.

6. Flattening non mantenuto

IP statici copiati diventano obsoleti quando il provider cambia infrastruttura.

Diagnosi passo per passo

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.

Procedura di risoluzione

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.

Domande frequenti

Guide Xlogic correlate

• SPF PermError: record troppo complesso
• SPF PermError: too many DNS lookups
• Errori SMTP 421, 450 e 451: problemi temporanei