Errore 550 5.7.1: cause e soluzioni

Perché le email vengono rifiutate con un errore 550 5.7.1?

Una risposta 550 5.7.1 significa che un server di posta ha rifiutato un messaggio per motivi legati a una policy. Il codice, da solo, non identifica la policy specifica: un server può segnalare un problema di autenticazione, mentre un altro può bloccare il mittente, l’indirizzo o il contenuto del messaggio. Il testo diagnostico associato alla risposta e il server che l’ha emessa sono i punti di partenza per la risoluzione del problema.

Se ti stai chiedendo cosa significa errore 550 5.7.1, considera il codice come un’indicazione generale di un rifiuto permanente per motivi di sicurezza o policy, non come una diagnosi completa. Se un rapporto di mancata consegna dice soltanto «messaggio rifiutato», cerca la risposta SMTP completa nel registro eventi del servizio di invio o nella notifica di mancato recapito. Per indagare in modo efficace, parti da queste informazioni, anziché modificare le impostazioni DNS o chiedere al destinatario di controllare la cartella dello spam.

Che cosa significa un rifiuto 550 5.7.1 nello scambio SMTP?

I server SMTP si scambiano codici di stato mentre elaborano un messaggio. La prima cifra di 550 indica un errore permanente: non ci si aspetta che un nuovo tentativo con lo stesso messaggio vada a buon fine. Il codice esteso 5.7.1 segnala un problema di sicurezza o di policy, ma non specifica quale regola sia scattata.

Il testo che segue il codice è importante. Per esempio, «mittente non autorizzato» suggerisce un problema diverso da «messaggio rifiutato in base alla policy locale». Queste espressioni sono esempi, non definizioni universali: ogni provider di posta scrive i propri messaggi diagnostici e la stessa formulazione può avere significati diversi a seconda del sistema.

Considera 550 5.7.1 come una categoria, non come una diagnosi. Se ti chiedi perché le email vengono rifiutate con errore 550 5.7.1, la risposta pratica è che il sistema ricevente ha applicato una decisione basata su una policy; per capire quale, ti serve la risposta completa.

Come capire se il messaggio è stato rifiutato dal server del destinatario o da un gateway intermedio?

Controlla la trascrizione SMTP o i dettagli della notifica di mancato recapito per individuare l’host che ha restituito la risposta 550. Di solito l’host che ha rifiutato il messaggio compare accanto al testo diagnostico, talvolta sotto forma di nome del server o indirizzo IP. Confrontalo con il dominio del destinatario e con eventuali servizi di sicurezza della posta che sai essere posizionati davanti a quel dominio.

La posta del destinatario può passare attraverso un gateway di filtraggio prima di raggiungere il server della sua casella. Se il gateway rifiuta il messaggio durante lo scambio SMTP, il server della casella del destinatario potrebbe non riceverlo mai. La notifica può indicare direttamente il gateway oppure mostrare un nome host che dovrà essere verificato dall’amministratore del destinatario.

Esamina la sequenza delle risposte del server, invece di basarti sui campi «Da» o «A» di una notifica. Per esempio, una trascrizione potrebbe mostrare il tuo sistema di invio mentre si connette a un host, trasmette i dati del messaggio e riceve da quell’host una risposta 550. La risposta identifica il sistema che ha preso la decisione, anche se la casella del destinatario è gestita da un altro provider.

Alcune piattaforme di invio mostrano nella dashboard solo un breve riepilogo. Se possibile, apri i dettagli dell’evento o esporta la notifica di mancato recapito completa: le righe aggiuntive possono rivelare quale host ha rifiutato il messaggio e in quale fase.

Perché un messaggio può essere rifiutato dopo che il server ha accettato la connessione?

L’accettazione di una connessione SMTP significa soltanto che il sistema ricevente ha consentito l’avvio della conversazione. Non significa che abbia approvato il mittente, il destinatario o il messaggio. I controlli delle policy possono avvenire in diverse fasi: dopo l’invio dell’indirizzo del mittente, dopo aver specificato il destinatario o dopo aver trasmesso il contenuto del messaggio.

Un server può accettare la connessione e poi rifiutare uno specifico indirizzo del destinatario. In altri casi, può accettare i dati della busta SMTP e controllare il messaggio solo dopo che il server mittente ne ha trasmesso il contenuto. Perciò la risposta finale può arrivare più avanti nello scambio, anche se la connessione iniziale sembrava regolare.

Il momento in cui compare l’errore aiuta a circoscrivere l’indagine. Se il rifiuto arriva prima dell’invio del corpo del messaggio, il problema potrebbe riguardare l’host di invio, l’identità del mittente o la policy applicata al destinatario. Se invece arriva dopo l’invio del corpo, il sistema potrebbe aver valutato il contenuto oppure la combinazione di mittente, destinatario e dettagli del messaggio. Il testo della risposta resta l’indizio principale.

Che cosa controllare nella notifica completa prima di modificare la configurazione della posta?

Salva la notifica originale prima di modificare i record DNS, cambiare l’indirizzo di invio o ritentare l’invio del messaggio. Una notifica completa documenta la decisione del sistema ricevente e consente di confrontare più facilmente i tentativi successivi. Controlla questi dettagli:

• Codice di stato esteso: verifica se la risposta è 5.7.1 o un altro codice. Il riepilogo della notifica potrebbe omettere il codice esatto restituito durante lo scambio SMTP.
• Testo diagnostico: copia per intero la spiegazione del server, compresi eventuali numeri di riferimento o indicazioni sulla policy. Non basarti su un messaggio abbreviato nella dashboard.
• Host che ha rifiutato il messaggio: annota il nome host o l’indirizzo IP associato alla risposta. Questo aiuta a capire se la decisione proviene dal server del destinatario o da un gateway di filtraggio.
• Data e ora: annotale, includendo il fuso orario se indicato. L’amministratore del destinatario potrebbe usarle per cercare l’evento nei registri di posta.
• Dettagli del messaggio e del destinatario: conserva l’ID del messaggio, l’indirizzo del mittente, quello del destinatario e i dettagli di eventuali tentativi di consegna. Queste informazioni identificano la transazione senza dover fare supposizioni.

Conserva il testo originale senza modificarlo, anche se contiene intestazioni tecniche. Prima di condividerlo, può essere opportuno rimuovere informazioni personali non pertinenti; tuttavia, eliminare l’host che ha rifiutato il messaggio o la riga diagnostica può rendere molto più difficile l’indagine.

Come distinguere un blocco dovuto a una policy lato mittente da una regola specifica del destinatario?

Confronta i risultati tra destinatari e domini. Se più domini non correlati rifiutano lo stesso messaggio con formulazioni simili, è più probabile che il problema riguardi il mittente. Se invece il messaggio viene rifiutato da un solo indirizzo o da una sola organizzazione mentre gli altri destinatari lo ricevono, è più probabile che si tratti di una regola locale del destinatario o di una policy del gateway.

Questi schemi sono indizi, non prove. Il gateway di un destinatario può applicare una regola a un intero dominio mittente e coinvolgere così più persone della stessa organizzazione. Al contrario, un problema di configurazione lato mittente può manifestarsi solo con alcuni provider di destinazione, se sono gli unici ad applicare la policy pertinente.

Nel messaggio diagnostico cerca indicazioni sull’ambito del problema, come un mittente bloccato, un destinatario con restrizioni o una regola di sicurezza locale. Poi esegui un test controllato: invia un messaggio dello stesso tipo a un altro destinatario autorizzato, senza modificare più impostazioni contemporaneamente. Se il messaggio arriva ad altri domini ma continua a non raggiungere una determinata azienda, condividi le informazioni con il suo amministratore della posta.

Se il rifiuto menziona l’autenticazione o una policy del dominio, controlla i record del dominio mittente e il loro allineamento prima di chiedere un’eccezione. Una guida pratica come questa alla configurazione dell’autenticazione email può aiutarti a verificare i record pertinenti; da sola, però, non dimostra che l’errore 550 dipenda dall’autenticazione, a meno che la notifica non lo confermi.

Quali informazioni fornire all’amministratore della posta del destinatario?

Invia una segnalazione concisa, ma con dettagli sufficienti perché l’amministratore possa trovare l’evento nei propri registri. Includi la notifica di mancato recapito completa o la trascrizione SMTP, l’ID del messaggio, gli indirizzi del mittente e del destinatario e l’ora approssimativa dell’invio, con il relativo fuso orario. Aggiungi il nome host che ha rifiutato il messaggio e la riga diagnostica esatta con il codice 550 5.7.1.

Descrivi l’accaduto senza fare supposizioni sulla causa. Per esempio: «Un messaggio inviato ad alex@example.com alle 14:20 UTC è stato rifiutato da mx.example.net con il codice 550 5.7.1; la notifica allegata contiene la risposta completa». Così l’amministratore saprà cosa cercare, senza che un’ipotesi non verificata venga presentata come un fatto.

Se il messaggio è stato inviato tramite un provider o un’applicazione, indica quale servizio hai usato e, se disponibile, aggiungi l’identificativo dell’evento di consegna. Per la posta transazionale, il registro eventi può aiutare a collegare un’azione dell’applicazione al tentativo SMTP; le informazioni sui webhook per le email transazionali possono aiutare i team a conservare questi eventi di consegna per consultarli in seguito.

Come risolvere errore SMTP 550 5.7.1?

Per capire come risolvere errore SMTP 550 5.7.1, inizia dalla notifica completa: individua il testo diagnostico, l’host che ha rifiutato il messaggio e la fase dello scambio SMTP in cui è comparso il codice. Poi verifica se il rifiuto riguarda il mittente o una policy specifica del destinatario; evita di modificare più impostazioni contemporaneamente e chiedi all’amministratore del destinatario di controllare i registri quando il rifiuto proviene dal suo gateway o server.

Quando è opportuno chiedere al destinatario di inserire un mittente nella allowlist?

Chiedi di inserire il mittente nella allowlist quando l’amministratore del destinatario conferma che una regola locale sta bloccando un mittente legittimo e può specificare quale identità o dominio del mittente richiede un’eccezione. Fornisci la notifica esatta e indica l’indirizzo o il dominio interessato. Spetta all’amministratore stabilire se l’eccezione è compatibile con le policy della sua organizzazione.

L’inserimento nella allowlist non risolve tutti gli errori 550 5.7.1. Se la notifica segnala un problema di autenticazione lato mittente, un indirizzo non valido o una violazione più ampia delle policy, un’eccezione potrebbe nascondere il sintomo senza correggerne la causa. Parti dal motivo di rifiuto indicato e chiedi un’eccezione locale solo se l’amministratore della posta del destinatario conferma che il problema dipende dalla sua policy.