Moodle email non partono: capire se il messaggio non viene generato, resta in coda o viene rifiutato in consegna.
Verifichiamo evento Moodle, task di spedizione, SMTP/relay, From/envelope e reputazione DNS prima di cambiare credenziali a caso.
Reset password, iscrizioni e forum senza notifica: l’UI puo sembrare ok mentre la mail non esiste in uscita.
Il guasto sta a monte (evento/cron), in mezzo (SMTP reject) o a valle (spam/DMARC). Ogni strato ha log diversi.
Ordine per isolare generazione, trasporto e consegna.
Messaggio creato?
Esiste il record in uscita / log mail Moodle o l’evento non genera nulla?
SMTP risponde?
Stesse credenziali/host di Moodle: annota 535, 550, timeout.
DNS e From
SPF/DKIM/DMARC sull’envelope reale e allineamento al From.
Dove guardare: log messaggi e debug output.
Logging mail Moodle + php error: reject, could not connect, auth failed.


Dove guardare: Postfix, Exchange, SES, SendGrid.
Il message-id deve comparire lato provider. Se manca, non ha lasciato Moodle/cron.
Dove guardare: task legati alle notifiche.
Cron indietro = mail generate ma non spedite. Incrocia con diagnosi cron.


Possibile causa: host, porta, TLS o credenziali.
STARTTLS vs SSL, 587 vs 465, account senza relay: tipico post-migrazione.
Possibile causa: From non autorizzato.
noreply non verificato: login ok ma MAIL FROM rifiutato.


Possibile causa: SPF/DKIM assenti o DMARC reject.
Mail partite ma in quarantena: header Analysis su BCC di test.
Possibile causa: plugin messaggi che spezza l’evento.
Dopo update spariscono solo alcuni tipi di notifica.


Possibile causa: throttling su picchi iscrizione.
Prime ok, poi 421/454: servono coda e retry.
Correzione: SMTP sul relay approvato.
Documenta host/encryption/user; evita mail() cieca su shared hosting.


Correzione: From e noreply coerenti col dominio auth.
Verifica mailbox presso provider; reply-to tracciabile.
Correzione: SPF/DKIM e DMARC in monitoraggio.
Policy soft prima, poi restringi con ownership DNS chiaro.


Correzione: sblocca task e replay mirato.
Niente reinvio cieco a migliaia di utenti.
Verifica: reset, iscrizione corso, forum.
Tre percorsi + header Authentication-Results.


Monitora bounce e soft-fail.
Casella piena o filtro destinatario non e bug Moodle.
LMS + CRM: chi spedisce cosa.
Atlas Learning evita doppi invii e buchi di notifica.


Sulle email chiedo: creato, spedito, o solo promesso dall’interfaccia?
Separare generazione, trasporto e DNS evita giornate a cambiare SMTP senza un log.
Atlas Learning opera come partner tecnico: leggiamo log, riproduciamo il caso e interveniamo sul livello responsabile, senza sostituirci alla vostra governance di piattaforma.
Cosa dicono i clienti che lavorano con Atlas Learning.
Le recensioni vengono mostrate dinamicamente tramite Trustindex.
Domande frequenti su Moodle email non partono.
Test pannello ok, notifiche no?
Percorsi e code diversi: il test non simula il carico reale.
Serve SMTP esterno?
In produzione si, per deliverability misurabile.
Vedete lo spam?
Con inbox di test e header si; senza DNS indichiamo cosa verificare.
E il cron?
Se restano in coda task, si collega; altrimenti resta SMTP/DNS.
Notifiche Moodle assenti per utenti o docenti?
Condividi host SMTP, un message-id di test, versione Moodle e stato del cron.