"550 5.7.23 The message was rejected because of Sender Policy Framework violation" (SPF fail): come risolvere

Cosa significa

Il server di destinazione ha controllato il record SPF del tuo dominio e ha scoperto che il server che ha inviato l'email non è autorizzato a inviare per il tuo dominio. Con Microsoft 365 ed Exchange, il messaggio di errore è simile a questo:

550 5.7.23 The message was rejected because of Sender Policy Framework violation

Altri server usano formulazioni più brevi. Il messaggio di solito è simile a uno di questi:

550 5.7.1 SPF fail - not authorized
550 5.7.1 Rejected by SPF

SPF (Sender Policy Framework) è un record TXT nel DNS del tuo dominio che elenca i server autorizzati a inviare email per suo conto. Quando invia un server che non è nella lista, SPF "fallisce". Se il record termina con -all ("rifiuta tutto il resto"), molti destinatari rifiutano subito l'email.

Perché succede

• Manca un mittente nell'SPF. Hai iniziato a usare uno strumento di newsletter, un CRM, un negozio online, uno strumento di fatturazione o un nuovo provider email e non l'hai aggiunto.
• L'IP del tuo server è cambiato (nuovo hosting, nuovo VPS) e l'SPF elenca ancora quello vecchio.
• Esistono due record SPF per il dominio. Non è valido, e SPF fallisce per tutti i mittenti.
• Troppe query. SPF consente solo 10 query DNS (contano ogni include:, a, mx). Oltre questo limite SPF restituisce un errore che alcuni destinatari trattano come un fallimento.
• Inoltro. L'email è stata inviata a un indirizzo che la inoltra a Microsoft 365 o a un'altra casella. Il server che inoltra non è nel tuo SPF, quindi lì il controllo fallisce.
• Qualcun altro sta falsificando il tuo dominio. In questo caso il rifiuto significa che SPF sta facendo il suo lavoro.

Come verificare

1. Fai un test Delivmail. Dalla stessa app o dallo stesso server che ha ricevuto il rifiuto, invia un'email all'indirizzo unico nella home page (/). Il report mostra l'IP di invio, il dominio verificato da SPF (il mittente della busta, o Return-Path) e il risultato SPF con il motivo.
2. Analizza il tuo dominio. Usa /domain-scanner per leggere il tuo record SPF. Ti mostra se ci sono due record, un errore di sintassi o troppe query.
3. Leggi le intestazioni del messaggio di errore. Spesso contengono una riga come Received-SPF: Fail con l'IP che è stato verificato.

Come risolvere

1. Individua il servizio di invio. Il report Delivmail mostra l'IP. La documentazione del servizio indica il suo include SPF, per esempio include:spf.protection.outlook.com per Microsoft 365 o include:_spf.google.com per Google Workspace.
2. Aggiungilo al tuo unico record SPF. Modifica il record esistente, non crearne un secondo:

   v=spf1 include:spf.protection.outlook.com include:spf.newsletter-example.com ip4:203.0.113.10 -all

3. Unisci i doppioni. Se hai due record v=spf1, riuniscili in uno solo.
4. Resta sotto le 10 query. Togli i servizi che non usi più. Sostituisci a e mx con ip4: quando conosci l'IP.
5. Valuta ~all durante i test. Segna i mittenti sconosciuti come sospetti invece di rifiutarli. Torna a -all quando tutto passa.
6. Configura anche DKIM. DKIM firma l'email e resiste agli inoltri. Con DKIM e DMARC attivi, i destinatari si affidano meno al solo SPF.

Se la causa è un inoltro

Chiedi alla persona di inoltrare in un altro modo (una regola della casella che reindirizza con SRS, o il recupero diretto della posta), oppure assicurati che le tue email siano firmate con DKIM, così DMARC può comunque passare.

Verifica che sia risolto

Aspetta che la modifica DNS si propaghi (spesso pochi minuti, fino al TTL del record, a volte qualche ora). Avvia lo Scanner di dominio per confermare che c'è un solo record SPF valido, poi invia un nuovo test Delivmail dallo stesso servizio: SPF deve mostrare pass. Infine invia di nuovo l'email all'indirizzo che l'aveva rifiutata.