Cuando parece que Moodle no envía correos, la conclusión suele llegar sola y suele estar equivocada.
Un tutor escribe a sus alumnos desde el campus y nadie contesta. Alguien mira su carpeta de correo no deseado, encuentra allí un par de avisos y la conclusión parece evidente: "los mensajes del campus están cayendo en spam". A partir de ahí empieza un mes de trabajo en la dirección equivocada.
Porque hay otra posibilidad, y es bastante más frecuente de lo que parece: que el correo del alumno no haya llegado nunca. Que Gmail lo haya rechazado en la puerta y lo haya devuelto al servidor. No está en no deseado, no está en ningún sitio, no existe.
Son dos problemas distintos, con causas distintas y con arreglos distintos. Y confundirlos cuesta semanas, porque todo lo que haces para salir de spam no sirve absolutamente de nada cuando lo que te pasa es que te devuelven el correo.
La diferencia, en una frase
En un rechazo, el servidor del destinatario dice que no y cierra la puerta. Tu servidor recibe esa negativa por escrito, con un código y un motivo. El mensaje no se entrega, ni a la bandeja de entrada ni a la de no deseado. Se pierde.
En una clasificación como spam, el servidor del destinatario dice que sí y acepta el mensaje. Lo entrega, pero decide guardarlo en la carpeta de correo no deseado en lugar de en la principal. El correo existe, está ahí, y el alumno puede encontrarlo si mira.
Esa distinción no es teórica. Es la que decide si tienes que tocar la configuración de tu dominio o tienes que armarte de paciencia, y son dos caminos que no se parecen en nada.
Cómo saber cuál de los dos te está pasando
La respuesta no está en Moodle. Moodle entrega el mensaje a su servidor de correo y da la tarea por hecha, así que en el campus todo se ve normal. La respuesta está en el registro del servidor que envía.
Ahí cada mensaje deja una línea con su desenlace. Un mensaje aceptado por el destinatario aparece como entregado. Un mensaje rechazado aparece como devuelto, y lo mejor es que viene acompañado del motivo, escrito por el propio Gmail o por Outlook. No hay que interpretarlo ni deducirlo: te lo dicen.
Si no tienes acceso a ese registro, hay dos atajos que funcionan casi igual de bien:
- Pregúntale a un alumno concreto por un mensaje concreto, y que mire también en no deseado. Si el mensaje está en esa carpeta, es clasificación. Si no está en ninguna parte, sospecha de rechazo.
- Mira el buzón desde el que sale el campus. Cuando un servidor recibe un rechazo, muchas veces genera un aviso de devolución. Si ese buzón lleva semanas sin que nadie lo abra, puede estar lleno de respuestas que explican el problema entero.
Qué aspecto tiene un rechazo de verdad
Este es el texto que devuelve Gmail cuando un mensaje no viene acreditado, y conviene reconocerlo porque lo dice todo:
550-5.7.26 Your email has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26 Authentication results:
550-5.7.26 DKIM = did not pass
550-5.7.26 SPF [tu-campus.es] with ip: [203.0.113.10] = did not pass
Traducido: "no sé quién eres y no pienso aceptar tu mensaje". Gmail exige desde hace tiempo que quien envía correo demuestre que es quien dice ser, y lo comprueba con dos mecanismos. SPF es una anotación en tu dominio que declara qué servidores tienen permiso para enviar en su nombre. DKIM es una firma que el servidor añade a cada mensaje y que el destinatario puede verificar. Los dos, y el tercero que los remata, los explicamos paso a paso en SPF, DKIM y DMARC en Moodle.
Si tu campus no tiene ninguno de los dos, no estás en spam. Estás rechazado. Y por mucho que tus alumnos marquen mensajes como "no es spam", no van a ver ninguna mejora, porque no hay mensajes que marcar.
Por qué a un campus le pasa esto de repente
Lo más desconcertante de este fallo es que aparece de golpe en una plataforma que llevaba años funcionando. Casi siempre hay una de estas tres explicaciones detrás:
- Cambió el servidor. Una migración, un servidor nuevo, una máquina de refuerzo para el curso que viene. La anotación SPF del dominio sigue autorizando al servidor viejo y nadie se acordó de añadir el nuevo.
- Cambiaron las reglas. Los grandes proveedores de correo han ido endureciendo lo que aceptan. Lo que hace tres años pasaba con una advertencia, hoy se devuelve.
- Se dio de alta un subdominio nuevo. Un campus en
formacion.tudominio.esno hereda la acreditación detudominio.es. Es un remitente distinto y necesita lo suyo.
En un caso que vimos este curso, un centro tenía dos campus casi idénticos en el mismo servidor. Uno enviaba sin problemas y el otro acumulaba más de un centenar de mensajes devueltos en tres semanas. La configuración de Moodle era la misma campo por campo. Lo único distinto era que uno firmaba sus envíos y el otro no.
Cómo se lee el registro sin ser técnico
Si tienes acceso al servidor o puedes pedirle el dato a quien lo administra, cada intento de envío deja una línea con tres datos que son los que importan: a quién iba, qué contestó el destinatario y en qué quedó la cosa. Ese último campo solo tiene tres desenlaces posibles, y saber cuál es te ahorra el resto del diagnóstico.
Entregado. El destinatario aceptó el mensaje. A partir de aquí ya no es cosa tuya dónde lo guarde: puede estar en la bandeja de entrada o en no deseado, pero llegó.
Devuelto. El destinatario dijo que no. El mensaje no se entregó y no va a entregarse.
Aplazado. El destinatario no ha dicho ni que sí ni que no, y tu servidor lo reintentará más tarde. Normalmente se resuelve solo en unas horas. Si un mensaje lleva días aplazado, acaba convirtiéndose en devuelto.
Y hay un detalle que separa los problemas graves de los pasajeros: el número con el que empieza la respuesta. Si empieza por 5, es definitivo y no va a cambiar reintentando. Si empieza por 4, es temporal: el destinatario está pidiendo que lo intentes luego.
| Empieza por | Qué significa | Qué hacer |
|---|---|---|
| 2 | Aceptado | Nada, llegó |
| 4 | "Ahora no, prueba más tarde" | Esperar. Si se repite días, mirarlo |
| 5 | "No, y no insistas" | Leer el motivo: ahí está la causa |
La mayoría de la gente que dice "estamos en spam" tiene en su registro una fila de respuestas que empiezan por 5, y en el texto de esas respuestas está escrita la causa exacta con todas sus letras.
Las tres piezas que te acreditan, y para qué sirve cada una
Se nombran siempre juntas y hacen cosas distintas. Entender la diferencia evita perder el tiempo en la que no te toca.
SPF es una lista. Una anotación pública en tu dominio que dice qué servidores pueden enviar en su nombre. Es lo primero que hay que revisar cuando el campus ha cambiado de máquina, porque la lista sigue nombrando a la anterior.
DKIM es una firma. Tu servidor firma cada mensaje con una clave y publica la contraparte en el dominio, para que el destinatario compruebe que el mensaje es auténtico y no lo han tocado por el camino. Es la que suele faltar por completo, porque hay que activarla y casi nadie la activa sola.
DMARC es la instrucción. Le dice al destinatario qué hacer con los mensajes de tu dominio que no pasen las dos anteriores: dejarlos pasar, apartarlos o rechazarlos. Y tiene una función que casi nadie usa y que es la más útil de todas: pedir informes. Añadiendo una dirección de correo a esa anotación, los grandes proveedores empiezan a mandarte un resumen de quién está enviando en nombre de tu dominio y qué tal le va.
Sin esa dirección de informes estás a ciegas. Con ella, cada semana te llega el dato en lugar de tener que ir a buscarlo. Es gratis y consiste en añadir una línea a la configuración de tu dominio.
Un detalle que descoloca: el remitente que ve Gmail no es el que ves tú
Cuando Moodle envía un aviso, suele hacerlo en nombre de quien lo origina: si un profesor escribe a su grupo, el alumno ve el nombre del profesor. Pero el correo no sale del buzón del profesor, sale del servidor del campus.
Los proveedores de correo saben que eso pasa y lo toleran, siempre que el dominio que firma técnicamente el mensaje esté acreditado. Ahora, si el campus intenta enviar poniendo literalmente la dirección personal del profesor como remitente, y esa dirección es de un proveedor externo, el mensaje sale de un servidor que ese proveedor no autoriza. Y eso sí se rechaza.
Por eso Moodle trae un ajuste para enviar en nombre de alguien sin suplantar su dirección, y por eso conviene dejarlo activado. Es un caso que da muchos quebraderos de cabeza porque el síntoma es desconcertante: los avisos automáticos del campus llegan bien y los que escribe una persona concreta, no.
Qué pedirle a quien administra tu servidor
Si el campus lo lleva un proveedor, no necesitas entrar tú a ningún sitio. Necesitas hacer tres preguntas concretas, y son estas:
- ¿Los envíos de este dominio salen firmados? La respuesta es sí o no, no admite matices.
- ¿La anotación de autorización incluye la máquina desde la que sale el campus hoy? Ojo con el "hoy": es donde se cuela el fallo tras una migración.
- ¿Cuántos mensajes se han devuelto en las dos últimas semanas, y con qué motivo? Esta es la que de verdad cierra el diagnóstico.
Si las tres respuestas tardan o llegan vagas, ya sabes por dónde seguir. Un proveedor que administra un campus tiene esos tres datos a mano.
El error caro: cambiar de dirección IP
Cuando alguien plantea un problema de entrega de correo, la propuesta que aparece antes que ninguna es contratar una dirección IP propia para el campus, para "empezar de cero". Suena lógico y a veces es un gasto recurrente para siempre.
Merece la pena pensarlo dos veces, porque lo que los proveedores de correo juzgan no es solo la IP: es el dominio que firma el mensaje. Si tu dominio no acredita sus envíos, cambiar de IP no arregla nada, porque el problema viaja con el remitente. En ese caso de los dos campus, el que funcionaba bien enviaba desde una dirección compartida y multiplicaba por seis el volumen del otro sin un solo rechazo.
Una IP propia tiene sentido en algunos escenarios, sobre todo con volúmenes grandes y sostenidos. Pero es una decisión que se toma después de tener la acreditación en orden, nunca en lugar de ella.
Si de verdad es spam, esto es lo que ayuda
Puede que compruebes el registro y veas que tus mensajes sí se están entregando, y que acaban en no deseado. Entonces sí estás en el otro escenario, y el trabajo es distinto: ya no es configuración, es reputación, y la reputación no se arregla, se construye.
Lo que mueve la aguja:
- Que los alumnos saquen los mensajes de no deseado y marquen que no lo son. Es la señal más fuerte que existe, y la da el destinatario, no tú.
- Un remitente estable. Cambiar la dirección desde la que sale el campus cada temporada reinicia el contador.
- Un volumen sin picos, y listas limpias. Cada mensaje enviado a una dirección que ya no existe es un punto en contra.
- Paciencia medida en semanas. Cuando un dominio ha estado semanas fallando la acreditación, arreglar la causa no borra el historial de golpe.
Y algo que casi nadie hace y cuesta diez minutos: darte de alta en las herramientas para remitentes de Google. Te enseñan cómo te ve Gmail. Deja de ser una discusión de opiniones y pasa a ser un dato.
El aviso que no llega porque nunca se envió
Antes de dar por cerrado el diagnóstico, merece la pena descartar un tercer caso que se confunde con los otros dos: que el mensaje no haya salido nunca de Moodle.
Moodle procesa buena parte de sus notificaciones mediante una tarea de fondo que se ejecuta periódicamente. Si esa tarea está parada, los avisos se quedan encolados dentro de la plataforma. No hay rechazo ni hay spam, porque no ha habido envío. El síntoma que lo delata es característico: unas cosas llegan y otras no, sin ningún patrón claro, porque los mensajes que se envían en el momento salen y los diferidos se quedan atrás.
Por eso el orden del diagnóstico importa. Primero se comprueba que el mensaje salió, después qué contestó el destinatario, y solo al final se habla de reputación.
En resumen
Que un aviso de tu campus no aparezca puede significar tres cosas muy distintas, y cada una se arregla por su lado:
| Lo que ves | Lo que pasa | Por dónde se empieza |
|---|---|---|
| No está en ninguna carpeta y hay devoluciones | Te lo rechazan | Acreditar el dominio con SPF y DKIM |
| Está en no deseado | Te clasifican | Reputación del remitente, y tiempo |
| Unos llegan y otros no, sin lógica | No se envían | Revisar las tareas de fondo del campus |
La conclusión práctica: antes de gastar un euro, mira el registro de tu servidor. La respuesta suele estar escrita ahí, con todas sus letras, desde el primer día.
Preguntas frecuentes
¿Puedo saber si me rechazan sin acceso al servidor? En parte. Pregúntale a un alumno por un mensaje concreto y que mire también en correo no deseado. Si no aparece en ninguna carpeta, lo más probable es un rechazo. La confirmación, eso sí, está en el registro del servidor.
¿Cuánto tarda en mejorar la entrega después de acreditar el dominio? Los rechazos paran de inmediato, en cuanto el primer mensaje sale firmado. La clasificación en no deseado tarda más, porque depende de la reputación acumulada y esa se construye con semanas de envíos correctos.
¿Sirve de algo pedir a los alumnos que nos marquen como remitente de confianza? Sirve, y bastante, pero solo cuando el problema es de clasificación. Si te están rechazando los mensajes, no hay nada que marcar porque no llegan.
¿Esto me puede pasar con el correo del centro y no solo con el campus? Sí. Cualquier remitente de tu dominio pasa por las mismas comprobaciones. Si el campus falla, merece la pena revisar también el correo corporativo antes de que aparezca el mismo problema.
Si prefieres no entrar en esto, es parte de lo que hacemos en gestión de Moodle: vigilamos la entrega del correo de tu campus y te avisamos nosotros cuando algo deja de llegar.
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.