Server SMTP di riserva per WordPress: continuare a inviare nonostante un errore 401, 500 o un limite di quota superato

Server SMTP di riserva per WordPress: il problema sollevato sui forum

La questione torna spesso sui forum di WordPress.org: il sito invia le sue email tramite Mailgun, Brevo, un altro fornitore o un account SMTP. Un giorno, l’invio fallisce. I messaggi restituiscono a volte un errore “401 Forbidden” o “450 4.7.1 monthly message limit exceeded”. Altre volte, il fornitore risponde semplicemente con un errore 500. I moduli di contatto, gli ordini e i reset delle password non partono più.

Una persona lo riassume così sul forum: il plugin di invio fallisce e, invece di passare a qualcos’altro, blocca tutto. Quello che si cerca allora è un server SMTP di riserva per WordPress: una seconda via di invio, da utilizzare quando la prima si rifiuta di funzionare.

Per arrivare a questo punto, bisogna prima capire perché il server principale rifiuta i messaggi. Solo allora si decide se una riserva è sufficiente o se l’errore deve essere corretto alla fonte.

Leggere l’errore prima di cercare una riserva

I tre errori citati sopra non hanno la stessa causa e non si risolvono nello stesso modo.

Un errore 401 significa che il fornitore non riconosce le credenziali: chiave API revocata o digitata in modo errato, password cambiata, account sospeso o dominio non ancora convalidato presso il fornitore. Un server di riserva permette di continuare a inviare, ma finché la chiave non viene corretta, il server principale non ripartirà.

Un limite di quota superato, come il “450 4.7.1 monthly message limit exceeded”, dipende dal vostro piano presso il fornitore. Il server funziona, ma si rifiuta di inviare altri messaggi prima della fine del periodo. Questo è il caso in cui un secondo server risulta più utile, a patto che non utilizzi lo stesso account e quindi la stessa quota.

Un errore 500 proviene il più delle volte dal lato del fornitore ed è spesso temporaneo. La riserva serve quindi a non perdere nulla durante il disservizio.

In nexya, il modulo Mail tiene un registro degli invii. Per ogni email che non è partita, mostra la causa esatta fornita dal server. È lì che si leggono il codice e il messaggio, invece di tirare ad indovinare a partire da un modulo che non risponde più.

• 401: credenziali rifiutate, da correggere presso il fornitore o nella connessione.
• Quota superata: limite del piano raggiunto, un secondo account o un secondo fornitore subentra.
• 500: errore dal lato del fornitore, spesso temporaneo, la riserva evita le perdite.

Cosa fa la versione gratuita del modulo Mail

Il modulo Mail è gratuito, come il resto di nexya, e senza limiti sul numero di siti. Si attiva dall’hub. Finché è disattivato, nessuno dei suoi hook viene eseguito sul sito.

Offre tre modalità di invio: un server SMTP, un fornitore tramite API o un account Gmail o Microsoft 365 connesso tramite OAuth, senza password salvate sul sito. Un’email di test verifica la configurazione non appena viene impostata.

Il registro degli invii indica la causa di ogni fallimento. Per un guasto isolato, spesso è sufficiente: si legge l’errore, si corregge la chiave o si cambia piano, poi si invia un’email di test.

La versione gratuita non include invece né un secondo server di invio né avvisi in caso di errore. Questo codice non è presente in questa versione, fa parte di nexya Pro.

Cosa aggiunge nexya Pro: un secondo server e un sistema di avvisi

nexya Pro, venduto su nexya.dev, aggiunge al modulo Mail un secondo server di invio e avvisi in caso di errore. Quando il server principale rifiuta un’email, l’invio passa al server di riserva e un avviso segnala il problema.

Il messaggio parte comunque e voi sapete di dover controllare il server principale. È esattamente ciò che viene richiesto nei post del forum: non dipendere da un solo fornitore e non scoprire il guasto tre giorni dopo tramite un cliente che non ha mai ricevuto la sua conferma.

nexya Pro viene fornito da Freemius dopo l’acquisto. Subentra al plugin gratuito mantenendo le stesse impostazioni: la connessione principale già configurata rimane attiva, bisogna solo aggiungere la seconda. nexya Pro conserva inoltre i registri più a lungo, il che aiuta a individuare un guasto ricorrente.

Un server di riserva non sostituisce la correzione dell’errore: mantiene il sito in grado di inviare email mentre voi lo correggete.

Configurare un server di invio di riserva, passo dopo passo

1. 1

   Attivare il modulo Mail

   Nell'hub di nexya, attivate il modulo Mail. Finché è spento, nessuno dei suoi hook viene eseguito sul sito.

   
2. 2

   Leggere la causa del fallimento nel registro

   Aprite il registro di invio e prendete nota del codice e del messaggio del server: 401, quota superata o errore 500. Correggere alla fonte ciò che può esserlo, ad esempio una chiave API o un dominio non convalidato.

   
3. 3

   Verificare la connessione principale

   Controllate il metodo di invio principale (SMTP, provider API, Gmail o Microsoft 365 con OAuth), quindi inviate un'e-mail di test per confermare che funzioni nuovamente.

   
4. 4

   Aggiungere il secondo server con nexya Pro

   Con nexya Pro, aggiungete un secondo server di invio su un altro account o un altro provider. In caso di fallimento di quello principale, l'invio passa a questa riserva e un avviso vi avviserà. Testatelo subito con l'e-mail di test.

   

Scegliere correttamente il server di riserva

Una riserva è utile solo se non si guasta contemporaneamente al server principale. Alcune semplici regole aiutano a sceglierla.

Scegliete un account diverso, o meglio ancora un altro fornitore. Due connessioni sullo stesso account condividono la stessa quota e le stesse credenziali: una quota superata o una chiave revocata le bloccherà entrambe.

Se possibile, variate il metodo. Ad esempio, un’API come principale e un account Gmail o Microsoft 365 connesso tramite OAuth come riserva, oppure un SMTP presso il vostro hosting. I tre metodi del modulo Mail possono essere utilizzati in entrambi i ruoli.

Verificate l’indirizzo del mittente. Il server di riserva deve avere il permesso di inviare per conto del vostro dominio. In caso contrario, le email partono ma rischiano di finire nello spam. Il modulo non verifica i record SPF, DKIM o DMARC: questi vanno controllati presso il fornitore e nella zona DNS del dominio.

Infine, testate la riserva una volta configurata, utilizzando l’email di test, senza aspettare il prossimo guasto.

• Un account o un fornitore diverso da quello principale.
• Un metodo diverso, se possibile: API, SMTP o OAuth.
• Un dominio di spedizione autorizzato presso il fornitore di riserva.
• Un’email di test inviata subito dopo la configurazione.

Cosa nexya non fa ancora

Un limite riguarda direttamente questo caso: non è possibile disattivare una connessione senza eliminarla. Se volete mettere da parte il server principale il tempo di risolvere un problema con le chiavi, dovete cancellarlo e poi riconsultarlo in seguito. Prima di eliminare una connessione, prendete quindi nota delle sue impostazioni: host, porta, nome utente, chiave o account connesso.

I fatti noti del modulo non descrivono nemmeno un passaggio automatico alla funzione mail() di PHP. Il backup previsto è un secondo server, che configurate voi stessi in nexya Pro.

Il modulo non ha nemmeno un pulsante per reinviare un’e-mail non riuscita. Il registro indica cosa non è partito e perché. Il reinvio viene effettuato dallo strumento originale, ad esempio elaborando nuovamente la richiesta ricevuta tramite modulo.