En resumen
El greylisting rechaza temporalmente el primer correo de un remitente desconocido. Un servidor de correo real lo reintenta a los pocos minutos y entra; muchos bots de spam no reintentan nunca. En cPanel se activa en WHM › Email › Greylisting. Funciona mejor con los proveedores grandes en la lista de confianza y con un retraso inicial corto, porque su costo es que el primer correo de cada remitente nuevo llega con unos minutos de demora.
Cómo funciona el greylisting
Cada vez que llega un correo, el servidor mira tres datos: la IP que se conecta, el remitente y el destinatario. Si esa combinación es nueva, responde con un error temporal (código 451, "inténtalo más tarde") y la anota.
- Primer intento: combinación desconocida. Exim responde "451 temporalmente rechazado".
- Reintento: el servidor del remitente vuelve a intentar después del retraso inicial. Como la combinación ya está anotada, se acepta.
- Correos siguientes: la combinación queda aceptada durante días, así que no hay más demoras con ese remitente.
Los programas de spam que envían millones de mensajes desde equipos infectados no suelen guardar una cola de reintentos. Por eso el greylisting frena una parte importante del spam sin analizar el contenido.
Cómo activarlo en WHM
- Entra a WHM › Email › Greylisting.
- Activa el servicio con el interruptor de la parte superior.
- Revisa la configuración con la tabla de la sección siguiente.
- En Common Mail Providers, confía en los proveedores grandes y activa su actualización automática.
- En Trusted Hosts, agrega tus propios servidores y los de proveedores o sistemas que no pueden esperar.
Si usas un antispam externo o un relay de entrada delante del servidor, agrega sus IPs a Trusted Hosts. Si no, el greylisting vería todas las conexiones como si vinieran del mismo lugar.
Qué valores usar
| Opción | Qué controla | Valor recomendado |
|---|---|---|
| Initial deferral period | Cuánto tiempo se rechaza la combinación nueva | 1 a 5 minutos |
| Resend acceptance period | Plazo para que el remitente reintente y sea aceptado | 240 minutos (4 horas) o más |
| Record expiration | Cuánto dura la combinación aceptada sin nuevos correos | 3 a 7 días o más |
| Automatically trust IP addresses with valid SPF records | Salta el greylisting a remitentes cuyo SPF autoriza esa IP | On, si tus clientes no toleran demoras |
Un retraso inicial de 1 minuto frena casi lo mismo que uno de 15, porque los bots no vuelven nunca. Lo que sí cambia es cuánto espera un cliente legítimo, ya que cada servidor reintenta según su propia programación, que puede ser de 5, 15 o 30 minutos.
Problemas típicos y cómo evitarlos
| Síntoma | Causa | Solución |
|---|---|---|
| Los códigos de verificación y los enlaces de restablecer contraseña llegan tarde | Plataformas que envían desde muchas IPs distintas, y cada IP nueva vuelve a esperar | Activa la confianza por SPF o agrega sus rangos a Trusted Hosts |
| Un proveedor dice que su correo "rebota" | Su servidor no reintenta, o tarda horas | Agrega su IP a Trusted Hosts y pídele que revise su cola |
| El correo de Gmail o Microsoft tarda en llegar | Proveedores grandes no confiados | Activa Common Mail Providers y su actualización automática |
| Las demoras parecen aleatorias | Un mismo remitente sale por varias IPs de un mismo rango | Sube el retraso aceptado y confía en los proveedores conocidos |
Para ver si el greylisting retuvo un correo concreto, busca la dirección en el log de Exim. Los rechazos temporales aparecen como "temporarily rejected", seguidos de la entrega cuando el remitente reintenta:
# Rechazos temporales de hoy (incluye los del greylisting)
grep "$(date +%F)" /var/log/exim_mainlog | grep -ci "temporarily rejected"
# Ver si un remitente concreto fue retenido y cuándo volvió a intentar
grep "remitente@dominio.cl" /var/log/exim_mainlog | grep -i "temporarily rejected\|<="Cuándo conviene y cuándo no
- Conviene en servidores que reciben mucho spam de botnets y con clientes que toleran unos minutos de demora con remitentes nuevos.
- Conviene menos en servidores de tiendas o plataformas que dependen de códigos de verificación, confirmaciones de pago o alertas que tienen que llegar al instante.
- No reemplaza a las RBL ni a SpamAssassin: es una capa más. Las tres juntas forman el antispam básico de cPanel, que describimos en configurar Exim contra el spam en WHM.
- No frena el phishing dirigido, porque se envía desde servidores reales que reintentan, a menudo desde cuentas comprometidas en Microsoft 365 o Gmail. Lo explicamos en antispam para cPanel.
Preguntas frecuentes
¿El greylisting hace que se pierdan correos?
No, si el remitente usa un servidor de correo real: reintenta y el mensaje llega con unos minutos de demora. Solo se pierden los correos de sistemas que no reintentan, que son sobre todo programas de spam.
¿Dónde está el greylisting en cPanel?
Lo configura el administrador del servidor en WHM › Email › Greylisting. Los usuarios de cPanel no pueden activarlo ni desactivarlo para su cuenta.
¿El greylisting retrasa los correos de Gmail?
Si los proveedores grandes están en la lista de confianza (Common Mail Providers), no. Por eso conviene activar esa opción y su actualización automática.
¿Cuánto spam frena el greylisting?
Depende del servidor, pero frena sobre todo el spam de botnets, que es una parte grande del volumen. No frena el spam enviado desde servidores reales ni el phishing dirigido.
Antispam y antiphishing para todo tu servidor cPanel
El greylisting frena a los bots. Clisec analiza el correo que sí reintenta, incluido el phishing enviado desde cuentas reales comprometidas, en todas las cuentas de tu servidor cPanel.