SMTP e coda e-mail: configurazione, recapito e recupero errori

Perché configurare più SMTP

Gli SMTP salvati diventano canali selezionabili da fatture, ticket, comunicazioni, attività e altri moduli. Più profili permettono di separare amministrazione, supporto e commerciale, rispettare limiti differenti e mantenere un’alternativa controllata. Ogni modulo deve però indicare esplicitamente il profilo previsto: la sola presenza nell’elenco non lo rende automaticamente utilizzato.

Campi del profilo

Compilare Nome come etichetta interna, Descrizione/From come nome visibile del mittente, indirizzo e-mail, host, username e password forniti dal gestore. Se la descrizione resta vuota viene usato il nome ISP predefinito.

Non riutilizzare password personali. Per Gmail o Google Workspace con verifica in due passaggi utilizzare una password per app e verificare che l’indirizzo From sia autorizzato.

Porta e crittografia

Usare i valori del provider. Nell’interfaccia la porta determina la combinazione prevista: normalmente 587 o 2525 con TLS, 465 con SSL implicito. Non scegliere una porta soltanto perché “funziona” su un altro server. Mantenere TLS e verifica dei certificati; eventuali eccezioni di rete devono essere valutate dall’amministratore del sistema.

Predefinito, salvataggio e modifica

Impostare come predefinito il profilo destinato agli invii generici, poi scegliere consapevolmente gli altri nelle impostazioni dei singoli moduli. Il salvataggio conserva le credenziali del tenant; la modifica deve essere seguita da un nuovo test e da una verifica di un messaggio applicativo reale.

Prima di eliminare un SMTP cercare dove è referenziato. Una campagna o un reparto che punta a un profilo rimosso può non avere un mittente valido.

Test di connessione e monitoraggio

Il test controlla collegamento, autenticazione e, nel percorso previsto, recapito verso l’indirizzo indicato. Un successo SMTP prova l’accettazione da parte del server, non la consegna in Inbox: verificare destinatario, spam, log e intestazioni. Il controllo pianificato può monitorare i profili salvati; trattare l’errore come segnale operativo e non continuare a rilanciare senza correggere la causa.

SPF, DKIM e DMARC

La pagina propone record DNS di riferimento. SPF autorizza i server di invio; DKIM firma i messaggi con la chiave del dominio; DMARC definisce allineamento, report e politica. I valori reali devono provenire dal provider e dal dominio usato nel From.

Pubblicare inizialmente DMARC con monitoraggio, esaminare i report e passare a quarantine o reject solo quando tutti i flussi legittimi risultano allineati. Evitare più record SPF separati sullo stesso dominio.

Come funziona la coda

Gli invii applicativi vengono accodati con destinatario, oggetto, tipo, tentativi e prossima esecuzione. La pagina mostra soltanto In attesa, In lavorazione e Errore; quando un messaggio viene completato non rimane nella lista operativa. Il dispatcher è un processo CLI pianificato, non una pagina da richiamare manualmente.

Un job fermo In lavorazione può essere recuperato dal processo secondo le regole previste. Dopo più errori passa a fallito e richiede analisi.

Riprova, Rimuovi e Svuota coda

Riprova riporta un errore in attesa e azzera la prossima esecuzione; usarlo dopo aver corretto SMTP, rete, destinatario o contenuto. Rimuovi annulla il singolo job. Svuota coda elimina gli invii pendenti o falliti visualizzati dal processo e può far perdere comunicazioni dovute.

Prima di riprovare controllare se il provider abbia già accettato il messaggio: un timeout successivo all’accettazione può produrre duplicati.

Diagnosi

• Autenticazione: username, password per app, account bloccato o From non autorizzato.
• Timeout: host/porta errati, firewall o rete in uscita.
• Certificato/TLS: nome host, data sistema, catena o combinazione porta-crittografia.
• Rifiuto destinatario: formato, dominio, mailbox o policy antispam.
• Accettata ma non vista: spam, reputazione, SPF/DKIM/DMARC o filtri del destinatario.

Registrare l’errore tecnico senza copiare password o contenuti personali nei ticket.

Checklist

• Creare un profilo per funzione quando necessario
• Usare credenziali dedicate
• Allineare porta e crittografia
• Verificare il From autorizzato
• Pubblicare SPF, DKIM e DMARC corretti
• Eseguire test e controllare il recapito
• Associare lo SMTP ai moduli
• Monitorare coda e processo CLI
• Correggere la causa prima di Riprova
• Valutare il rischio duplicati
• Svuotare la coda solo con autorizzazione
• Non esporre credenziali o contenuti