La respuesta breve#
El greylisting es una técnica de filtrado de spam en la que un servidor de correo rechaza temporalmente los mensajes — y los sondeos de verificación — de remitentes que no ha visto antes, respondiendo con un «inténtalo de nuevo más tarde» de SMTP en lugar de un sí o un no. Los servidores de correo legítimos reintentan unos minutos después y consiguen pasar; el software de spam rudimentario contra el que se diseñó la técnica, históricamente, no lo hacía. Para la verificación de correo la consecuencia es sencilla: la respuesta de un servidor con greylisting es todavía no, así que un verificador honesto o bien reintenta dentro de su presupuesto de tiempo o bien informa de la dirección como desconocido. Lo que no debe hacer es adivinar.
Cómo se ve el greylisting en la conversación SMTP#
El aplazamiento ocurre en el mismo punto de la conversación SMTP donde un servidor normal confirmaría o rechazaría el buzón:
> RCPT TO:<jane@example.com>
< 451 4.7.1 Greylisted, please try again later
El primer dígito lo cuenta todo (la gramática completa está en
los códigos de respuesta SMTP explicados). Una
respuesta 5xx (550 5.1.1 user unknown) es permanente — la dirección está
muerta, el veredicto es undeliverable. Una respuesta 4xx (421, 450,
451) es temporal por definición: el servidor está diciendo explícitamente
que la misma petición podría tener éxito más tarde. Las implementaciones
clásicas de greylisting registran la IP del remitente y las direcciones de
origen y destino, rechazan el primer intento y aceptan un reintento que
llegue tras unos minutos — prueba de que al otro lado hay un servidor de
correo real con una cola de reintentos.
La técnica se remonta a principios de los años 2000 y sobrevive porque es barata y silenciosamente eficaz: un servidor de correo legítimo mantiene una cola de reintentos de forma habitual, así que aplazar el primer intento no cuesta a los remitentes reales más que unos minutos, mientras que el software de spam de disparar y olvidar nunca vuelve. Las implementaciones típicas recuerdan la terna formada por la IP del remitente, la dirección de origen y la dirección de destino; una vez que un reintento para esa terna tiene éxito, el remitente suele quedar en lista blanca durante semanas, de modo que el retraso es un peaje único y no un impuesto permanente.
Te encontrarás con el greylisting sobre todo en las pasarelas de correo corporativas, los servidores autoalojados y los dispositivos de seguridad. Los grandes proveedores de consumo hacen mayoritariamente algo distinto que parece idéntico visto desde fuera — más sobre esto abajo, porque la diferencia importa para la verificación.
Qué le hace un 4xx a un sondeo de verificación#
Un verificador que topa con un servidor con greylisting tiene exactamente tres opciones:
- Esperar y reintentar. Honesto y a menudo eficaz, pero cuesta tiempo — la ventana de greylisting es de minutos, y un trabajo masivo no puede esperar eternamente.
- Informar de desconocido. Honesto, cuando reintentar no lo resolvió. La dirección no es mala; simplemente el servidor nunca dio una respuesta utilizable.
- Adivinar. Deshonesto. Cualquier herramienta que convierta un
451en un rotundo «válido» o «inválido» está fabricando una certeza que el servidor se negó a dar.
Así lo gestiona Qualisend: una dirección con greylisting se reintenta dentro
de un presupuesto de tiempo acotado, y si el servidor sigue aplazando cuando
ese presupuesto se agota, el veredicto es unknown con motivo timeout y una
puntuación de confianza intermedia — una dirección que vale la pena volver a
comprobar más tarde, no una muerta, que es exactamente como deberías tratarla.
Una excepción deliberada: cuando el servidor que aplaza pertenece a un gran
proveedor de buzones de consumo, un 4xx casi nunca es greylisting clásico.
Es limitación de tasa basada en reputación, y reintentar rara vez cambia la
respuesta. Qualisend reconoce esos casos y los resuelve como unknown en
lugar de tener tu trabajo secuestrado por un reintento que no va a ayudar — el
mismo veredicto honesto, sin la espera.
Por qué el greylisting no puede atascar tu lista#
El coste sutil de los aplazamientos no es la precisión — es el tiempo. Un
verificador masivo ingenuo que reintenta obedientemente cada 4xx puede
acabar con un trabajo de 100 000 filas secuestrado por un puñado de servidores
tercos, atascado en el «99 % completado» durante una hora. Lo aprendimos por
la vía práctica, y ahora la canalización lleva varias capas de tiempos de
espera y topes para que unos pocos servidores tercos no puedan atascar el
trabajo entero:
- cada conversación SMTP corre bajo un plazo estricto — un servidor que hace
tarpitting más allá de él se convierte en un
unknown, y el trabajo sigue adelante; - los reintentos por greylisting están limitados y se registran por dirección en lugar de dejarse en bucle;
- un trabajo cuyas últimas direcciones dejan de avanzar tiene esa cola
resuelta como
unknownen vez de dejar que un rezagado retenga la línea «N−1 de N», con una red de seguridad detrás para cualquier cosa atascada por otros motivos.
La postura de diseño: un unknown honesto tardío es mejor que una conjetura a
tiempo, pero un desconocido que obtienes en minutos es mejor que ambos. Sea
como sea que un verificador lo implemente, esta es una pregunta justa que
hacerle a cualquier herramienta: ¿qué le pasa a tu trabajo cuando un servidor
simplemente se niega a responder?
El greylisting frente a sus imitadores#
Varios comportamientos distintos del servidor terminan en una casi-respuesta, y se corresponden con veredictos diferentes:
| Qué hizo el servidor | Señal en la conversación | Veredicto de Qualisend |
|---|---|---|
| Greylisting clásico | 451 a un remitente desconocido, acepta un reintento posterior | unknown / timeout tras el presupuesto de reintentos
— reverificar más tarde |
| Limitación de tasa del proveedor | 4xx de un gran proveedor de consumo | unknown / timeout, resuelto de inmediato —
reintentar dentro de un trabajo no ayuda |
| Aceptación catch-all | 250 a todas las direcciones, sean reales o no | risky / low_deliverability — consulta la
guía de catch-all |
| Silencio o corte de conexión | Ninguna respuesta utilizable | unknown / timeout o
unavailable_smtp |
| Rechazo tajante | Negativa de clase 550 | undeliverable / rejected_email |
El hilo común: unknown es una afirmación sobre la conversación, no sobre
el buzón. risky significa que alcanzamos el servidor y averiguamos algo
preocupante; unknown significa que la infraestructura nunca respondió de
forma concluyente. Cada uno merece un trato distinto en tu lista.
Qué hacer con los veredictos desconocido#
- No suprimas por un solo desconocido. Detrás de servidores gruñones viven buzones reales y activos. Tratar desconocido como inválido tira a la basura suscriptores solo para que un panel parezca contundente.
- Reverifica más tarde. Las ventanas de greylisting pasan y los límites de tasa se reinician — la misma dirección a menudo se resuelve limpiamente en una segunda ejecución horas o días después. Por eso también dos verificadores (o dos ejecuciones de uno) pueden discrepar sobre una dirección sin que ninguno mienta: el buzón es determinista, el servidor no.
- Mantén los desconocido sin verificar fuera de los envíos de alto riesgo. Hasta que un desconocido se resuelva o interactúe, trátalo como el segmento catch-all: envíos pequeños y regulados donde un rebote cuesta poco — se aplica el mismo manual de la guía de limpieza de Klaviyo, veredicto a veredicto.
- Lee la tasa de desconocido como un hecho sobre los servidores de tu lista, no como un fallo de la verificación. Las listas B2B con muchas pasarelas corporativas siempre acarrearán más desconocido que las listas de consumo — la herramienta no empeoró, la infraestructura se volvió más defensiva.
Preguntas frecuentes#
¿Un veredicto desconocido significa que la dirección es mala?#
No. Desconocido significa que el servidor de correo nunca dio una respuesta concluyente durante la verificación — por greylisting, limitación de tasa, un tiempo de espera agotado o un servidor inaccesible. El buzón que hay detrás puede estar perfectamente sano. Trata desconocido como «reintentar más tarde», no como un eufemismo de inválido.
¿Por qué la misma dirección dio resultados distintos en dos ejecuciones?#
Porque lo que cambió entre ejecuciones fue el comportamiento del servidor, no
el buzón. Un servidor con greylisting rechaza el primer intento y acepta un
reintento; un servidor con limitación de tasa te aplaza en los momentos de
mayor carga y responde en los tranquilos. Una dirección que ayer era
unknown y hoy es deliverable es el sistema funcionando tal como está
diseñado.
¿Puede un verificador saltarse el greylisting?#
El único «atajo» legítimo es la paciencia: reintentar tras la ventana de
greylisting, que es lo que hacen los verificadores dentro de sus presupuestos
de tiempo. Nada garantiza una respuesta dentro del tiempo de ejecución de un
trabajo masivo, y por eso precisamente el conjunto de veredictos honestos
incluye unknown. Una herramienta que afirma que nunca devuelve desconocido
te está diciendo que adivina.
¿Cuánto debo esperar antes de reverificar los desconocido?#
Más que la ventana de greylisting, menos que tu próxima campaña. El retraso clásico de greylisting es de minutos, así que desde unas horas hasta unos días después da a los servidores que aplazan margen de sobra para haber visto ya tu sonda — mientras que los desconocido provocados por límites de tasa se benefician simplemente de llegar en un momento más tranquilo. Volver a ejecutar solo el segmento de desconocido antes de un envío importante es un seguro barato; los desconocido que sobreviven a varias reejecuciones espaciadas merecen el mismo trato escéptico que una dirección catch-all fría.
¿Sigue siendo común el greylisting en 2026?#
Sí, aunque de forma desigual. Sigue siendo una herramienta estándar en las pasarelas corporativas, los dispositivos de seguridad y los servidores autoalojados, donde es barato y eficaz. Los grandes proveedores de consumo se han pasado en su mayoría a la limitación de tasa basada en reputación — que produce los mismos aplazamientos temporales desde el punto de vista de un verificador, y la misma respuesta honesta: desconocido, reintentar más tarde.
