Greylisting es una técnica antispam que rechaza temporalmente el primer intento de entrega de un correo desconocido. El servidor legítimo reintenta minutos después y el mensaje entra. El servidor de spam, que suele ir con prisa y sin cola de reintentos, no vuelve nunca. Ese es todo el truco: un rechazo temporal de email con código SMTP 4xx que separa a los que respetan el estándar de los que no. Como filtro de correo es de los más baratos que existen —no analiza contenido, no entrena modelos, no necesita GPU— y con Postgrey lo tienes montado en un servidor Postfix en un cuarto de hora. El precio a pagar: tu jefe recibirá el email de recuperación de contraseña con quince minutos de retraso y te llamará. Preparado.
Cómo funciona el greylisting por dentro
Cuando un servidor remoto intenta entregarte un mensaje, tu MTA registra una tripleta: IP del remitente, dirección del emisor (envelope sender) y dirección del destinatario (envelope recipient). Si esa combinación no la ha visto nunca, responde con un código de estado temporal.
La respuesta típica es 450 4.2.0 Recipient address rejected: Greylisted, try again later. La clave está en el 4. Los códigos 4xx del protocolo SMTP significan "ahora no puedo, vuelve más tarde". Los 5xx significan "no y no vuelvas". Un servidor de correo que cumpla el RFC 5321 está obligado a encolar el mensaje y reintentar la entrega.
El flujo completo es este:
- Llega el mensaje. Tripleta desconocida. Se registra con marca de tiempo y se devuelve un 450.
- Pasa el periodo de retención (típicamente 5 minutos en la configuración por defecto de Postgrey).
- El remitente reintenta. La tripleta ya existe y ha pasado el tiempo mínimo. Se acepta el mensaje.
- La tripleta pasa a una lista blanca automática durante semanas. Los siguientes correos entran directos.
Ese cuarto punto es el que hace la técnica soportable. El retraso solo lo sufres la primera vez que un remitente concreto te escribe. Después, transparente.
Por qué el spam no reintenta (y por qué eso está cambiando)
El spam masivo tradicional se envía desde ratware: software que abre conexiones SMTP, escupe el mensaje y cierra. Sin cola. Sin reintentos. Sin estado. Cuando ese software se ejecuta en una botnet de máquinas comprometidas, mantener colas de reintento es un lujo que no se pueden permitir: la máquina puede estar limpia mañana, la IP puede estar en listas negras en una hora, y el objetivo es volumen, no fiabilidad.
El rechazo temporal aprovecha exactamente esa asimetría. No mira el contenido. No busca palabras. Solo comprueba si el otro lado se comporta como un servidor de correo de verdad.
El problema: la técnica es de 2003, cuando Evan Harris publicó el documento original que la definió. Veintitantos años después, buena parte del spam sí reintenta. Muchas campañas se envían hoy desde cuentas legítimas comprometidas de Microsoft 365 o Google Workspace, y esas sí tienen infraestructura de reintento profesional. Contra eso, el greylisting no hace absolutamente nada.
La lectura honesta: la técnica antispam del greylisting sigue siendo eficaz contra el ruido de fondo de botnets, pero ya no es una defensa completa. Es una capa. Va antes del filtro de contenido, reduce la carga que llega a los sistemas caros, y ya. Si alguien te vende greylisting como solución antispam integral, está vendiéndote 2005.
Instalar y configurar Postgrey en Postfix
Postgrey es la implementación de referencia en Debian y derivados. Se integra como policy server de Postfix mediante un socket.
Instalación en Debian o Ubuntu:
sudo apt install postgrey— instala el daemon y arranca en el puerto 10023 o en un socket Unix.- En
/etc/postfix/main.cf, añade la política asmtpd_recipient_restrictions, siempre después dereject_unauth_destination. - La línea es
check_policy_service inet:127.0.0.1:10023. sudo postfix reloady a mirar logs.
El orden importa y mucho. Si pones el greylisting antes de las restricciones de relay, estarás greylisteando intentos de relay abierto y llenando la base de datos de basura. Después de las comprobaciones baratas (listas negras DNS, sintaxis, destinatario válido), antes de nada más.
Parámetros que vas a querer tocar en /etc/default/postgrey:
| Parámetro | Qué hace | Valor razonable |
|---|---|---|
--delay | Segundos mínimos antes de aceptar el reintento | 300 (5 min) o menos |
--max-age | Días que se recuerda una tripleta ya validada | 35 |
--retry-window | Ventana para que llegue el reintento | 2 días |
--auto-whitelist-clients | Reintentos correctos antes de confiar en una IP entera | 5 |
--whitelist-clients | Fichero de clientes (IPs o hosts) exentos | Ver abajo |
El --delay por defecto de 300 segundos viene de otra época. La mayoría de MTAs modernos reintentan en menos de un minuto. Bajarlo a 60 segundos mantiene casi toda la eficacia y recorta buena parte de las quejas de usuarios. Pruébalo antes de asumirlo.
El problema de las granjas de servidores
Aquí es donde el greylisting se rompe de verdad, y donde muchos administradores lo desactivan frustrados sin entender qué pasaba.
Los grandes proveedores no reintentan desde la misma IP. Cuando Google, Microsoft o Amazon SES encuentran un 450, el mensaje vuelve a la cola general y el reintento sale de cualquier máquina del pool. La tripleta cambia porque la IP cambia. Nuevo 450. Y otra vez. Y otra vez.
El resultado son mensajes retrasados horas, o que directamente rebotan tras agotar la ventana de reintento. Si el aviso de tu banco o un código de doble factor llegan por esa vía, el usuario ya está gritando.
Soluciones, en orden de preferencia:
- Listas blancas por remitente. Postgrey trae
/etc/postgrey/whitelist_clientscon los sospechosos habituales precargados. Mantenlo actualizado. - Greylisting por bloque de red (/24) en vez de por IP. Con
--lookup-by-subnetPostgrey compara los tres primeros octetos. Cubre buena parte de las granjas sin desactivar nada. - Exención por SPF válido. Si el remitente pasa la comprobación SPF del dominio, sáltate el greylisting. Ya tienes una señal de autenticidad mejor.
- Exención para transaccionales. Notificaciones bancarias, códigos 2FA, plataformas de pago. Whitelist directa, sin debate.
Y una regla que no se negocia: nunca apliques greylisting a correo autenticado. Si el usuario se ha autenticado en tu servidor con permit_sasl_authenticated, es tu usuario enviando, no un desconocido llamando a la puerta.
Dónde encaja el greylisting en un stack antispam real
Un servidor de correo serio en 2026 tiene varias capas, y el greylisting no es la protagonista de ninguna. Es el portero que filtra a los que ni saben llamar al timbre.
- Autenticación del dominio: SPF, DKIM y DMARC. Desde febrero de 2024, Google y Yahoo exigen DMARC configurado a quien envíe a partir de unos 5.000 mensajes diarios a sus usuarios. Si no lo tienes, tu problema no es el spam entrante.
- Listas negras DNS: Spamhaus, SpamCop. Baratas y rápidas.
- Greylisting: aquí. Recorta el ruido de botnets antes del análisis caro.
- Filtro de contenido: Rspamd o SpamAssassin. Puntúan, aprenden, deciden.
- Sandboxing de adjuntos: los ataques modernos ya no llegan como ejecutable adjunto. Si te interesa cómo esquivan los filtros, el artículo sobre HTML Smuggling y evasión de seguridad en el email explica una de las técnicas más usadas hoy.
Sobre Rspamd frente a Postgrey conviene decir algo: Rspamd incluye su propio módulo de greylisting integrado, y es superior. En lugar de rechazar todo lo desconocido, solo greylistea mensajes cuya puntuación queda en zona gris —ni claramente limpios ni claramente spam—. Menos retraso, menos quejas, eficacia equivalente en la práctica contra botnets. Si estás montando un servidor desde cero, empieza por Rspamd y olvídate de Postgrey.
El greylisting tampoco toca lo que llega por otras vías. Un SMS fraudulento o un mensaje de phishing con Bizum no pasan por tu MTA, y ninguna cantidad de configuración de Postfix va a pararlos. Ahí toca denunciar el spam por los cauces legales y educar al usuario.
Cuándo NO usar greylisting
Hay escenarios donde la técnica genera más problemas de los que resuelve:
- Recuperación de contraseñas y códigos 2FA. Un enlace de reseteo con caducidad de 10 minutos que llega a los 15 es un ticket de soporte garantizado.
- Comercio electrónico. Confirmaciones de pedido retrasadas equivalen a clientes llamando a atención al cliente.
- Buzones que ya usan Microsoft 365 o Google Workspace. Tienen su propio filtrado en capas. Añadir greylisting delante suele ser redundante y contraproducente.
- Comunicación crítica en tiempo real. Alertas de monitorización, avisos médicos, cualquier cosa donde cinco minutos importen.
En estos casos, o lo desactivas para esos buzones concretos, o usas el greylisting adaptativo de Rspamd. Configurar mal esta técnica antispam hace más daño que no tenerla.
Preguntas frecuentes
¿Cuánto tiempo tarda un email en llegar con greylisting activado?
Depende del intervalo de reintento del servidor remitente, no de tu configuración. Los MTAs modernos suelen reintentar en menos de un minuto, pero algunos configurados con intervalos conservadores tardan 15 o 30 minutos. Solo afecta al primer mensaje de cada remitente nuevo.
¿El greylisting bloquea correo legítimo?
No lo bloquea, lo retrasa. Cualquier servidor que cumpla el RFC 5321 reintentará y el mensaje entrará. El riesgo real está en remitentes mal configurados que no reintentan o que agotan la ventana de reintento por rotar entre demasiadas IPs.
¿Sigue siendo efectivo el greylisting en 2026?
Contra spam de botnets sí, y sigue reduciendo carga en los filtros de contenido. Contra campañas enviadas desde cuentas legítimas comprometidas, nada: esas reintentan igual que cualquier correo real. Úsalo como capa complementaria, nunca como defensa única.
¿Cuál es la diferencia entre greylisting y blacklisting?
El blacklisting rechaza permanentemente (código 5xx) según una lista de IPs o dominios conocidos como maliciosos. El greylisting rechaza temporalmente (450) a cualquier remitente desconocido, sin juzgar su reputación, y le da una segunda oportunidad.
¿Cómo desactivo el greylisting para un remitente concreto?
Añade su dominio o IP al fichero /etc/postgrey/whitelist_clients, una entrada por línea, y reinicia el servicio con systemctl restart postgrey. Para destinatarios exentos, usa whitelist_recipients con la misma sintaxis.
El siguiente paso
Revisa los logs de tu servidor de correo y cuenta cuántas tripletas greylisteadas nunca reintentaron: grep -c "Greylisted" /var/log/mail.log frente al total de entregas aceptadas. Ese ratio te dice exactamente cuánto ruido te está quitando de encima antes de tocar nada más. Si el número es bajo, tu problema está en otra capa —y si no tienes SPF, DKIM y DMARC bien configurados en tus dominios, empieza por ahí antes que por Postgrey. Un servidor bien configurado vale más que diez filtros mal puestos.
