Inicio › Blog › Correo, dominio y hosting
Correo, dominio y hostingPor qué los correos de tu aula virtual caen en spam (SPF, DKIM y DMARC explicados sin técnica)

Los correos de un aula virtual caen en spam por tres razones casi siempre: el dominio no tiene SPF, DKIM y DMARC (los registros que le prueban a Gmail y Outlook que el correo es tuyo), el aula envía con un remitente que no corresponde a tu dominio, o envía demasiados avisos de golpe. Desde 2024 Gmail exige SPF o DKIM a todo remitente, y DMARC a quien envía más de 5,000 correos al día. Se arregla configurando esos tres registros, usando un noreply@ de tu dominio y apagando las notificaciones que nadie necesita.
En este artículo
- ¿Por qué los correos de mi aula virtual caen en spam?
- SPF, DKIM y DMARC explicados sin técnica
- El remitente: el error que más vemos en las aulas
- Demasiados correos de golpe
- Cómo comprobar si tus correos pasan las pruebas
- Checklist: correos del aula que sí llegan
- ¿Y los formularios de mi web?
- En resumen
- Preguntas frecuentes
«Profesor, no me llegó el correo para cambiar mi contraseña.» Si coordinas un aula virtual, conoces la frase. El alumno revisa su bandeja, no encuentra nada y termina escribiendo por WhatsApp. Casi siempre el correo sí salió, pero cayó en spam o fue rechazado por Gmail, Hotmail u Outlook antes de llegar.
La buena noticia es que el problema casi nunca es misterioso. En las aulas y webs que administramos en CONIT, cuando los correos no llegan, la causa suele estar en tres registros del dominio que nadie configuró, en un remitente mal puesto o en el exceso de avisos. Aquí te explicamos cada cosa sin tecnicismos y al final tienes una lista para revisarlo todo en una tarde.
¿Por qué los correos de mi aula virtual caen en spam?
Por tres razones, casi siempre: tu dominio no tiene SPF, DKIM y DMARC, el aula envía con un remitente que no es de tu dominio, o envía demasiados correos de golpe. Gmail y Outlook revisan cada correo que reciben y, si no pueden comprobar que de verdad viene de tu institución, lo mandan a spam o lo rechazan.
Piénsalo así: si un sobre llega con el logo de un banco pero sin sello, enviado desde una dirección rara, desconfías. Gmail hace lo mismo, millones de veces por minuto, y con reglas cada vez más estrictas.
SPF, DKIM y DMARC explicados sin técnica
Son tres registros que se agregan al dominio (no al aula ni a la web). Cada uno responde una pregunta:
| Registro | La pregunta que responde | La comparación |
|---|---|---|
| SPF | ¿Este servidor tiene permiso para enviar correos de tuinstituto.com? | La lista de carteros autorizados a repartir tus cartas |
| DKIM | ¿El correo salió de verdad de tuinstituto.com y nadie lo alteró en el camino? | El sello lacrado del sobre |
| DMARC | ¿Qué hago si un correo dice ser de tuinstituto.com y falla las pruebas? | Las instrucciones que dejas en la portería: «si no trae sello, devuélvelo» |
Con los tres bien puestos, Gmail puede comprobar que el aviso de tu aula es legítimo. Sin ellos, tu correo se parece demasiado al de un estafador que usa tu nombre.
Lo que exigen Gmail, Yahoo y Outlook
Desde el 1 de febrero de 2024, Google exige a todos los remitentes configurar SPF o DKIM, y a quienes envían más de 5,000 correos al día a cuentas de Gmail, SPF, DKIM y DMARC, mantener la tasa de spam reportada por debajo de 0.3 % y ofrecer baja con un clic en los correos de marketing (lineamientos de Google para remitentes). Yahoo pide lo mismo en lo esencial (Yahoo Sender Hub), y Microsoft aplica requisitos parecidos desde mayo de 2025 para quienes envían más de 5,000 correos al día a Outlook.com y Hotmail (anuncio de Microsoft).
Un aula con 2,000 alumnos que publica notas, recordatorios y avisos de foro puede acercarse a esos volúmenes más rápido de lo que crees.
El remitente: el error que más vemos en las aulas
Aunque el dominio tenga SPF y DKIM, el correo falla si el aula envía con una dirección que no corresponde. Los casos típicos:
- El aula envía desde un Gmail personal (el del administrador que la instaló). Tu servidor no tiene permiso para enviar en nombre de gmail.com, así que el correo falla todas las pruebas.
- La dirección «noreply» está mal escrita o es de un subdominio que no existe, por ejemplo [email protected] cuando ese subdominio no tiene correo configurado. Lo encontramos más de una vez al revisar aulas: un guion de más o de menos en el dominio y ningún aviso salía.
- Moodle pone el correo del docente como remitente. Cuando un docente escribe en un foro, Moodle puede enviar la notificación «a nombre» del docente. Si su correo es de Hotmail o Gmail, el aviso falla. Moodle permite enviar desde el noreply de tu dominio mostrando el nombre del docente («Juan Pérez vía Aula Virtual»): es la configuración correcta.
La regla es simple: todo lo que envía tu aula o tu web debe salir con una dirección de tu dominio, como [email protected], a través de un servidor que tu dominio autorizó.

Demasiados correos de golpe
El tercer motivo es el volumen. Cuando publicas las notas de un curso con 300 alumnos, o cuando un foro activo envía un aviso por cada mensaje, el aula dispara cientos de correos en minutos. Dos problemas:
- Los límites del proveedor. Muchos proveedores limitan cuántos correos puede enviar cada cuenta por hora o por día. Si los superas, los correos se retrasan o se rechazan. En la configuración que usamos, cuando el proveedor responde «límite superado», el servidor guarda el correo y lo reintenta más tarde en lugar de perderlo.
- Los alumnos marcan como spam lo que no quieren. Cada vez que alguien pulsa «Es spam» sobre un aviso de tu aula, tu dominio pierde reputación, y los siguientes correos llegan peor a todos.
Por eso conviene apagar las notificaciones que nadie necesita. Un ejemplo: Moodle avisa por correo cada vez que alguien inicia sesión desde un dispositivo nuevo. En un aula con miles de alumnos, eso son miles de correos inútiles. En las aulas que administramos los desactivamos y dejamos solo los avisos que el alumno espera: acceso, recuperación de contraseña, tareas, calificaciones y mensajes del docente.
Lo que hacemos en CONIT
En cada aula y web que administramos, los avisos salen con un noreply@ del dominio de la institución, con SPF, DKIM y DMARC configurados y con reintentos automáticos si el proveedor pone límites. Si tus correos no llegan, lo revisamos. Conoce nuestro servicio de correo corporativo y el de aula virtual.
Cómo comprobar si tus correos pasan las pruebas
No necesitas herramientas técnicas para un primer diagnóstico:
- Desde tu aula, usa «¿Olvidó su contraseña?» con una cuenta de prueba de Gmail.
- Abre el correo (búscalo también en Spam).
- En el menú de los tres puntos, elige «Mostrar original».
- Arriba verás tres líneas: SPF, DKIM y DMARC. Lo correcto es que las tres digan PASS.
- Revisa también el campo «De»: debe ser una dirección de tu dominio.
Si alguna dice FAIL o no aparece, ya sabes por dónde empezar. Repite la prueba con un correo de Outlook o Hotmail, que suelen ser más estrictos.
Checklist: correos del aula que sí llegan
Revisa estos 10 puntos (o pídeselos a tu proveedor):
- El dominio tiene un solo registro SPF que incluye todos los servicios que envían en tu nombre (correo corporativo, aula, web, herramienta de email marketing). Dos registros SPF separados invalidan los dos.
- El dominio tiene DKIM activado con tu proveedor de correo.
- El dominio tiene DMARC, al menos con la política p=none para empezar.
- El aula envía desde noreply@tudominio y no desde un Gmail o Hotmail.
- La dirección noreply está bien escrita y su dominio existe.
- Moodle envía las notificaciones de foros «vía» tu noreply, no con el correo del docente.
- El aula y la web envían por SMTP autenticado a través de tu proveedor, no por la función de correo básica del hosting.
- Están apagadas las notificaciones innecesarias (como el aviso de nuevo inicio de sesión).
- Conoces el límite de envío por hora de tu proveedor y el servidor reintenta si lo superas.
- Los correos masivos de marketing (campañas, nuevos cursos) salen por una herramienta de email marketing con baja con un clic, no desde el aula.
¿Y los formularios de mi web?
El mismo problema afecta a los formularios de contacto y a los correos de compra de WordPress: si la web envía «desde» el correo del visitante o sin SMTP autenticado, esos avisos llegan a spam o no llegan, y te enteras de una consulta días después. Aplica la misma regla: que la web envíe con una dirección de tu dominio y ponga el correo del visitante en «Responder a».
Si estás armando tu correo desde cero, empieza por cómo crear un correo corporativo para tu instituto, y si no sabes qué buzones necesitas, revisa cuántos buzones necesita un instituto.
En resumen
- Los correos del aula caen en spam sobre todo por falta de SPF, DKIM y DMARC, por un remitente que no es de tu dominio o por exceso de avisos.
- SPF autoriza a tus servidores, DKIM firma tus correos y DMARC dice qué hacer con los que fallan.
- Gmail exige SPF o DKIM a todos, y DMARC a quien envía más de 5,000 correos al día.
- Todo lo que envía el aula debe salir desde noreply@tudominio, por SMTP autenticado.
- Apaga las notificaciones innecesarias y comprueba con «Mostrar original» en Gmail que todo diga PASS.
Preguntas frecuentes
¿Qué es SPF, DKIM y DMARC en palabras simples?
Son tres registros que se agregan al dominio. SPF es la lista de servidores autorizados a enviar correos en tu nombre. DKIM es una firma que prueba que el correo no fue alterado y que salió de tu dominio. DMARC le dice a Gmail u Outlook qué hacer si un correo falla esas pruebas y te envía reportes.
¿Por qué los correos de Moodle no llegan a Gmail?
Lo más común es que Moodle envíe con una dirección que no es de tu dominio o desde un servidor que tu dominio no autorizó en su SPF, o que el dominio no tenga DKIM. Otras veces la dirección noreply está mal escrita o es de un subdominio que no existe. Revisa la configuración de correo saliente del aula y los registros del dominio.
¿Cómo sé si mi correo pasa SPF, DKIM y DMARC?
Envía un correo desde tu aula o tu web a una cuenta de Gmail, ábrelo y usa la opción «Mostrar original» del menú de tres puntos. Gmail muestra arriba si el mensaje pasó SPF, DKIM y DMARC (PASS) o si falló (FAIL).
¿Puedo enviar los correos del aula desde mi Gmail personal?
No es recomendable. Los servidores de tu aula no están autorizados a enviar en nombre de gmail.com, así que esos correos fallan las pruebas y suelen ir a spam o ser rechazados. Usa una dirección de tu propio dominio, como [email protected].
¿DMARC es obligatorio?
Para quienes envían más de 5,000 correos al día a cuentas de Gmail, Google lo exige desde febrero de 2024, aunque acepta la política más suave (p=none). Para el resto no es obligatorio, pero conviene tenerlo: protege tu dominio contra quienes intentan suplantarlo y mejora la entrega.
¿Cuántos correos puede enviar mi aula por hora?
Depende del proveedor de correo con el que salen. Muchos ponen límites por hora o por día a cada cuenta. Si tu aula envía cientos de notificaciones de golpe, por ejemplo al publicar notas, algunos correos se retrasan o se rechazan. Pregunta el límite a tu proveedor y configura el servidor para que reintente en lugar de perderlos.
¿Tus alumnos no reciben los correos del aula?
Revisamos tu dominio, tu aula y tu web, configuramos SPF, DKIM y DMARC y dejamos los avisos saliendo con un remitente de tu institución.
Escríbenos por WhatsApp


