Moodle envía correo constantemente: notificaciones de foro, confirmaciones de matrícula, recordatorios de tareas, alertas de calificación. Si tu dominio no tiene bien configurados SPF, DKIM y DMARC, dos cosas malas pueden pasar a la vez: que esos correos legítimos acaben en spam, y que cualquiera pueda enviar correo suplantando tu dominio sin que los proveedores de email lo bloqueen.
En esta guía vas a ver qué hace cada uno de estos tres registros, cómo se complementan, y cómo configurarlos correctamente para el correo que sale de tu Moodle.
Qué problema resuelve cada uno
SPF (Sender Policy Framework)
Es una lista pública, publicada como registro DNS de tipo TXT en la raíz de tu dominio, que indica qué servidores están autorizados a enviar correo en nombre de tu dominio. Cuando un servidor de correo recibe un mensaje, comprueba si el servidor de origen está en esa lista, si no lo está, es una señal de que el correo podría ser una suplantación.
Un registro SPF típico para un Moodle que envía a través de un proveedor SMTP transaccional se ve así:
ejemplo.com. IN TXT "v=spf1 include:_spf.tu-proveedor-smtp.com ip4:198.51.100.10 -all"Aquí include: autoriza los servidores del proveedor externo, ip4: añade la IP concreta de tu propio servidor (por si Moodle envía también por sendmail local), y el -all del final es la parte importante: significa “cualquier otro servidor que no esté en esta lista, recházalo” (hardfail). Muchos dominios usan ~all (softfail), que solo marca el correo como sospechoso en vez de rechazarlo. Empieza por ~all si no estás seguro de tener inventariados todos tus emisores, y endurece a -all cuando lo estés.
DKIM (DomainKeys Identified Mail)
Añade una firma digital criptográfica a cada correo saliente, verificable con una clave pública publicada también en el DNS de tu dominio. Esto permite comprobar no solo que el correo salió de un servidor autorizado, sino que su contenido no ha sido alterado en el camino.
La clave pública se publica en un registro TXT bajo un selector, una etiqueta que elige el servidor de envío para poder rotar claves sin romper nada:
selector1._domainkey.ejemplo.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."El servidor de correo firma cada mensaje con la clave privada (que nunca sale del servidor) y añade una cabecera DKIM-Signature. El receptor recupera la clave pública del DNS, comprueba la firma y confirma que el cuerpo y las cabeceras firmadas no se han tocado.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
Es la política que le dice a los proveedores de correo qué hacer cuando un mensaje falla las comprobaciones de SPF o DKIM: rechazarlo, ponerlo en cuarentena (spam), o simplemente registrar el fallo sin actuar. DMARC también permite recibir informes sobre intentos de suplantación de tu dominio.
Se publica en un registro TXT bajo el subdominio _dmarc:
_dmarc.ejemplo.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"El p=none es la política (aquí, solo observar). El rua= es la dirección donde quieres recibir los informes agregados diarios de qué correo se envía en nombre de tu dominio y si pasa o no las comprobaciones, es la parte que casi nadie configura y la que de verdad te da los ojos sobre lo que ocurre.
Un detalle que rompe DMARC aunque SPF y DKIM pasen: el alineamiento. DMARC no basta con que SPF o DKIM den “pass”; exige que el dominio validado coincida con el dominio del From: que ve el usuario. Si tu Moodle envía con un From: de ejemplo.com pero el Return-Path que valida SPF apunta a un dominio del proveedor SMTP, SPF pasa pero no alinea, y DMARC lo cuenta como fallo. Por eso DKIM firmado con tu propio dominio suele ser el camino más robusto para lograr alineamiento.
Por qué los tres juntos, no solo uno
SPF por sí solo puede romperse si el correo se reenvía a través de otro servidor. DKIM por sí solo verifica la firma, pero no dice qué hacer si falla. DMARC es el que conecta ambos mecanismos con una política de actuación clara, y además da visibilidad mediante informes de qué está pasando con el correo de tu dominio, incluidos los intentos de suplantación que de otra forma nunca verías.
La cadena, en una frase: SPF autoriza el servidor, DKIM firma el mensaje, DMARC decide qué hacer si algo falla y te informa. Esta tabla resume dónde vive cada uno:
| Registro | Tipo DNS | Qué hace | Dónde se publica |
|---|---|---|---|
| SPF | TXT | Autoriza qué servidores pueden enviar por tu dominio | Raíz del dominio (ejemplo.com) |
| DKIM | TXT | Firma criptográfica que prueba integridad y origen | selector._domainkey.ejemplo.com |
| DMARC | TXT | Define la política ante fallos y activa los informes | _dmarc.ejemplo.com |
Fíjate en que los tres son registros TXT pero cuelgan de sitios distintos del DNS: es el error más habitual: publicar el DMARC en la raíz en vez de bajo _dmarc, o el DKIM sin el prefijo del selector.
Cómo configurarlos para el correo de Moodle
1. Publica el registro SPF
Añade un registro TXT en el DNS de tu dominio que incluya la IP o el servidor SMTP que usa tu Moodle para enviar correo. Si usas un servicio de envío externo (por ejemplo, un proveedor SMTP transaccional), incluye su mecanismo de inclusión (include:) en el registro.
2. Activa DKIM en tu servidor de correo saliente
La configuración exacta depende del servidor de correo que uses (Postfix, Exim, o el proveedor SMTP externo que tenga configurado Moodle). Genera el par de claves, publica la clave pública en el DNS, y activa la firma automática en el servidor de envío.
3. Publica una política DMARC progresiva
No actives directamente una política de rechazo total (p=reject) desde el primer día. La práctica recomendada es empezar con una política de solo monitorización (p=none), revisar los informes durante unas semanas para confirmar que todo el correo legítimo pasa las comprobaciones, y solo entonces avanzar a cuarentena (p=quarantine) y finalmente a rechazo (p=reject).
Esta es la progresión, con qué buscas en cada fase antes de pasar a la siguiente:
| Fase | Política | Qué hace el receptor | Cuándo pasar a la siguiente |
|---|---|---|---|
| Observar | p=none | Entrega todo, pero te manda informes | Cuando los informes muestran 100% del correo legítimo pasando SPF o DKIM con alineamiento |
| Cuarentena | p=quarantine | Manda a spam lo que falla | Cuando llevas semanas sin correo legítimo cayendo en cuarentena |
| Rechazo | p=reject | Descarta lo que falla, ni llega a spam | Objetivo final: solo con el flujo validado del todo |
El salto peligroso es de p=none directo a p=reject. Si te queda un emisor legítimo sin autorizar, un plugin de Moodle que manda por su cuenta, un servicio de avisos, tu propio sendmail local no incluido en el SPF, con p=reject esos correos desaparecen sin dejar rastro, ni en la bandeja ni en spam. La fase p=none existe precisamente para descubrir esos emisores olvidados antes de que bloquearlos tenga consecuencias.
4. Verifica la configuración de correo saliente en Moodle
En Site administration > Server > Email > Outgoing mail configuration, confirma que Moodle está usando el servidor SMTP correcto y que el dominio del remitente coincide con el que has configurado en SPF, DKIM y DMARC, un desajuste aquí invalida todo el trabajo de configuración DNS.
Aquí hay una decisión de fondo que determina si todo lo anterior sirve de algo: cómo envía Moodle.
- SMTP autenticado (recomendado). Rellenas los campos SMTP hosts, SMTP security (normalmente TLS o SSL), SMTP auth type y usuario/contraseña de una cuenta real de tu dominio o de tu proveedor transaccional. Moodle entrega los correos a ese servidor, que los firma con DKIM y sale desde una IP que está en tu SPF. Es el camino que da alineamiento limpio.
sendmail/ funciónmail()de PHP. Si dejas la configuración SMTP vacía, Moodle entrega los correos al MTA local del servidor (Postfix, Exim). Esto solo funciona bien si ese servidor tiene DKIM configurado, una IP con reputación yPTR/rDNS correcto, y está incluido en tu SPF. En un servidor compartido o mal configurado, es la causa número uno de correo de Moodle en spam.
El otro campo crítico es la dirección de remitente. En Moodle configuras un no-reply address (por ejemplo [email protected]) que debe estar en tu propio dominio, el mismo que has autenticado. El error clásico es dejar el noreply@localhost por defecto, o una dirección de un dominio genérico: el From: no alinea con nada de lo que has publicado en DNS y DMARC lo marca como fallo aunque la infraestructura esté bien. Revisa también, en la misma pantalla, que no haya activado “Allow user to select from email” para notificaciones automáticas, porque eso puede sacar correos con un From: de un dominio que no controlas.
La razón de fondo de por qué el correo de Moodle acaba tanto en spam: la plataforma manda mucho volumen y muy repetitivo (foros, tareas, calificaciones), y si el servidor que lo emite no está autorizado a enviar por tu dominio, cada mensaje parece un intento de suplantación a ojos de Gmail u Outlook. Autenticar el dominio es lo que convierte ese tráfico de “sospechoso por defecto” a “confiable”.
Cómo comprobar que funciona
No des por buena la configuración hasta verla pasar de verdad. Dos formas rápidas:
- Envía un correo de prueba desde Moodle a una dirección de mail-tester.com. Te da una nota sobre 10 y desglosa si SPF, DKIM y DMARC pasan, si el
From:alinea y si el contenido dispara filtros de spam. Es la comprobación más completa en un solo paso. - Revisa la cabecera
Authentication-Resultsde un correo real recibido (en Gmail: Mostrar original). Buscas las tres en verde:
Authentication-Results: mx.google.com;
dkim=pass [email protected];
spf=pass [email protected];
dmarc=pass (p=NONE) header.from=ejemplo.comSi ves dkim=pass, spf=pass y dmarc=pass con el header.from de tu dominio, la cadena está completa. Un dmarc=fail con SPF y DKIM en pass casi siempre es un problema de alineamiento del From:, no de los registros en sí.
Errores comunes que rompen esta configuración
- Configurar SPF pero no DKIM, dejando el correo vulnerable a fallos si se reenvía a través de otro servidor.
- Activar DMARC en modo rechazo desde el primer día, sin haber revisado antes los informes de monitorización, bloqueando accidentalmente correo legítimo.
- Usar un dominio de envío distinto al configurado en los registros DNS, invalidando toda la protección aunque los registros estén bien publicados.
- No revisar los informes de DMARC una vez configurado, perdiendo la visibilidad sobre intentos de suplantación de tu dominio.
- Cambiar de proveedor SMTP sin actualizar el registro SPF, dejando el nuevo servidor sin autorización y provocando que los correos empiecen a caer en spam.
Por qué esto importa especialmente en un Moodle de formación bonificada
Si tu Moodle gestiona formación bonificada FUNDAE, los correos de confirmación de matrícula, recordatorios y notificaciones de tutoría forman parte de la comunicación documentable con el alumno. Un correo que no llega porque cayó en spam por una mala configuración de SPF/DKIM no es solo un problema de imagen, puede afectar directamente a que un alumno complete a tiempo una actividad crítica para la trazabilidad del curso.
Por eso conviene tratar la autenticación del correo como parte del mismo bloque que el resto de la seguridad de la plataforma, no como algo aparte del sysadmin de correo. Va de la mano con el checklist de hardening de Moodle: un dominio que cualquiera puede suplantar es un vector de phishing contra tus propios alumnos, que reciben “de tu Moodle” un correo con un enlace falso a la plataforma. SPF, DKIM y DMARC bien puestos cierran esa puerta a la vez que arreglan la entregabilidad.
Preguntas frecuentes
¿Necesito los tres registros (SPF, DKIM, DMARC) o basta con uno? Se recomienda configurar los tres, ya que se complementan: SPF autoriza servidores, DKIM verifica integridad, y DMARC define qué hacer si algo falla y da visibilidad mediante informes.
¿Cómo sé si mis correos de Moodle están llegando a spam? Los informes de DMARC te dan visibilidad agregada, pero también puedes hacer pruebas de envío a distintos proveedores de correo (Gmail, Outlook) y revisar directamente si el mensaje llega a la bandeja principal o a spam.
¿Puedo activar DMARC en modo rechazo directamente?
No es recomendable sin antes pasar por una fase de monitorización (p=none), para confirmar que todo tu correo legítimo pasa las comprobaciones antes de bloquear nada.
¿Qué pasa si cambio de proveedor de correo saliente? Debes actualizar el registro SPF para incluir el nuevo servidor autorizado, o los correos empezarán a fallar las comprobaciones y probablemente acabarán en spam.
¿DKIM protege el contenido del correo de ser modificado? Sí, la firma digital de DKIM permite verificar que el contenido no ha sido alterado entre el envío y la recepción.
¿Esto afecta a las notificaciones automáticas de Moodle (foros, calificaciones)? Sí, todas las notificaciones salientes de Moodle pasan por esta misma configuración de correo del servidor, así que una mala configuración afecta a todas ellas por igual.
¿Cuánto tiempo tarda en propagarse un cambio en estos registros DNS? Depende del TTL configurado, pero puede tardar desde minutos hasta 24-48 horas en propagarse completamente a nivel global.
Mi SPF y DKIM dan “pass” pero DMARC sigue en “fail”. ¿Por qué?
Casi siempre es un problema de alineamiento: la comprobación pasa, pero el dominio que se valida no coincide con el dominio del From: que ve el alumno. Suele ocurrir cuando Moodle envía con un From: de tu dominio pero el Return-Path (lo que valida SPF) apunta al dominio del proveedor SMTP. La solución robusta es asegurarte de que DKIM firma con tu propio dominio, porque el alineamiento de DKIM es más fácil de conseguir que el de SPF cuando hay un intermediario de por medio.
¿Puedo tener varios registros SPF en el mismo dominio?
No. Solo puede haber un registro SPF (una sola línea v=spf1 ...) por dominio; si publicas dos, muchos receptores lo tratan como error de configuración y SPF deja de validar. Cuando añades un nuevo emisor, amplías el include: o el ip4: del registro existente, no creas otro. Ojo también con el límite de 10 búsquedas DNS que impone SPF: encadenar muchos include: puede hacer que el registro deje de evaluarse.
¿Sirve el mismo selector de DKIM si cambio de proveedor SMTP?
No necesariamente: cada servidor de envío usa su propio par de claves y su propio selector. Al cambiar de proveedor tendrás que publicar el nuevo registro DKIM con el selector que te indique el nuevo proveedor, y actualizar el SPF con su include:. Es el momento en que más correo de Moodle se rompe silenciosamente, así que hazlo con la política DMARC en p=none o p=quarantine, nunca en pleno p=reject sin margen.
¿Cada cuánto debería mirar los informes de DMARC?
Semanalmente durante la fase p=none, que es cuando estás cazando emisores legítimos que se te escapan. Una vez en p=reject con el flujo estable, una revisión mensual basta para detectar picos de intentos de suplantación. Los informes llegan en XML poco legible; un visor de informes DMARC (hay varios gratuitos) te los convierte en algo que se lee de un vistazo.
Conclusión
SPF, DKIM y DMARC no son configuraciones exclusivas de grandes departamentos de IT, son la diferencia entre que las notificaciones de tu Moodle lleguen de forma fiable a tus alumnos y profesores, o se pierdan en spam sin que nadie lo note hasta que ya es un problema. Configurarlos bien, con una transición progresiva en DMARC, protege tanto la entregabilidad como la reputación de tu dominio.
Si prefieres que alguien configure y vigile esto por ti, en Avantys lo incluimos como parte del mantenimiento de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Checklist de hardening de Moodle
- Cómo proteger Moodle de ataques y vulnerabilidades
- RGPD y LOPD en plataformas Moodle
¿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.
