Greylisting en SMTP: 4xx temporales, reintentos y cómo gestionarlo desde un MTA
Qué es el greylisting, por qué algunos receptores lo aplican, cómo identificar 4xx temporales, configurar reintentos y reducir retrasos en tus envíos.
Cuando un envío legítimo aparece “retrasado” minutos u horas y los logs muestran un 451 4.7.1 Greylisted o un 421 4.7.0 try again later, lo que está pasando es greylisting. Es una técnica antispam que confía en que los spammers no reintentan correctamente y los remitentes legítimos sí. Para ti, como remitente, significa que tu MTA debe respetar reintentos SMTP estándar y que tu proceso de bounces no debe confundir 4xx con 5xx.
Qué es el greylisting
El greylisting es un filtro de admisión SMTP. Cuando un MX lo aplica, ante un trío (IP origen, From, To) que no había visto antes, responde con un código temporal 4xx y rechaza el mensaje sin almacenarlo. La idea:
- Un MTA correcto reintentará en unos minutos. La segunda vez, el receptor reconoce el trío en su lista gris, lo acepta y lo añade a una lista blanca local durante días o semanas.
- Un spammer típico no reintenta o lo hace en bucle inmediato; ambos comportamientos siguen recibiendo
4xxy el mensaje no llega.
Es sencillo, no requiere análisis de contenido y reduce mucho el ruido. La contrapartida es retraso en el primer envío legítimo.
Cómo se ve en los logs
Un servidor que aplica greylisting puede responder con:
451 4.7.1 Greylisted, please try again in 60 seconds
451 4.2.1 Service is temporarily unavailable, please try later
421 4.7.0 try again later
En los logs de tu Postfix:
status=deferred (host mx.destino.com[1.2.3.4] said: 451 4.7.1 Greylisted, try again later (in reply to RCPT TO command))
deferred es la marca: tu MTA encoló el mensaje y reintentará. Si tras varios reintentos sigue greylisted, algo va mal en el receptor o tu IP está en otra lista negra.
Tipos de greylisting
Por trío clásico
(IP, MAIL FROM, RCPT TO). El más común. Cualquier cambio invalida la entrada gris: nueva IP del pool, From distinto, destinatario nuevo.
Por sender domain
Algunos sistemas (postgrey, milter-greylist con configuración específica) aplican por dominio del MAIL FROM en lugar de la dirección completa. Más permisivo.
Por subred
/24 o /16 para IPv4, /64 para IPv6. Útil cuando un ESP envía desde un pool grande: la primera entrega calienta toda la subred.
Greylisting selectivo
El receptor solo aplica greylisting a remitentes desconocidos o con baja reputación. Si tu IP/dominio están en su lista interna, se salta el filtro. Por eso a veces lo ves activarse y otras no, sin razón aparente.
Cómo lidiar con greylisting siendo remitente
1. Que tu MTA reintente correctamente
La especificación SMTP (RFC 5321) dice que el remitente debe reintentar al menos 4-5 días con backoff exponencial. Postfix por defecto:
# /etc/postfix/main.cf
maximal_queue_lifetime = 5d
bounce_queue_lifetime = 5d
minimal_backoff_time = 300s
maximal_backoff_time = 4000s
queue_run_delay = 300s
300 segundos (5 minutos) entre reintentos al inicio, subiendo. La mayoría de receptores con greylisting esperan al menos 5 minutos antes de admitir el segundo intento.
2. No reintentar demasiado rápido
Un MTA que reintenta cada 30 segundos parece spam. Los receptores con greylisting agresivo bloquean a quien reintenta antes del umbral mínimo (típicamente 60-300 segundos).
3. Identificar 4xx vs 5xx en tu pipeline
Es crítico para gestión de bounces. Un 4xx no es bounce permanente; no quites al destinatario de tu lista por un greylisting. Un 5xx sí es definitivo. Pipelines mal hechos confunden los dos y purgan listas tras un greylisting transitorio.
4. Monitorizar tu cola
Si la cola crece persistentemente, algo bloquea entrega más allá de greylisting normal. Postfix:
postqueue -p | tail -n 20
mailq | grep -c 'Greylisted'
Greylisting normal se resuelve solo en 10-30 minutos. Si llevas horas con miles de mensajes deferred contra el mismo destino, hay otro problema (blacklist, firewall, capacidad del receptor).
Cómo lidiar con greylisting siendo receptor
Si gestionas tu propio MX y aplicas greylisting, conviene templarlo:
Listas blancas para grandes remitentes
Hay listas mantenidas (whitelist_clients en postgrey) con IPs de Gmail, Microsoft, Yahoo, ESPs grandes. Saltarlas reduce retrasos sin perder filtrado.
Tiempos razonables
- Espera mínima: 60 segundos.
- Ventana de aceptación: 4 horas.
- Vida en lista blanca tras admisión: 30-60 días.
Tiempos más cortos no filtran spammers; más largos retrasan correo legítimo.
Greylisting condicional
Aplicar solo a remitentes con SPF fail, DKIM ausente o reputación baja. Mensajes con autenticación completa pasan directos.
ESPs y greylisting
Los ESPs grandes manejan greylisting bien: sus colas reintentan cumpliendo los tiempos esperados. No verás retrasos significativos. Si tu ESP no respeta backoff, los receptores con greylisting agresivo pueden bloquearle como mal-comportamiento.
Para SES, Postmark, Brevo y Mailchimp, el greylisting se traduce en retrasos de 5-30 minutos en primer envío hacia un destinatario nuevo. No suele ser visible para ti como cliente porque el ESP lo absorbe internamente.
Diferencia entre greylisting y throttling
Pueden parecer lo mismo (4xx temporal) pero son distintos:
| Aspecto | Greylisting | Throttling |
|---|---|---|
| Disparador | Trío nuevo | Volumen alto |
| Solución | Reintentar tras 5-10 min | Reducir velocidad |
| Persistencia | Una vez al día | Mientras dure el pico |
| Código típico | 451 4.7.1 | 421 4.7.0 |
| Texto típico | ”Greylisted" | "try again later” / “rate limit” |
Throttling significa que estás mandando demasiado rápido para esa IP en ese receptor. La solución es bajar concurrencia o partir envíos a lo largo del tiempo.
Ambos comparten la regla operativa: respetar reintentos y no purgar destinatarios.
Cómo detectar greylisting en logs
Patrones en respuestas SMTP (regex):
4(51|21).*[Gg]reyl
4(51|21).*[Tt]ry again
4(51|21).*[Tt]emporar
Pasarelos por tu pipeline de bounces y márcalos como transient, no permanent.
Comando de ejemplo:
grep -E '45[01].*[Gg]reyl' /var/log/mail.log | wc -l
Si el conteo es alto pero los mensajes terminan entregándose, todo bien. Si encolan y caducan, hay otro problema.
Errores frecuentes
Marcar 4xx como hard bounce
Es el error más caro: pierdes destinatarios legítimos. Tu pipeline debe distinguir 4xx (transient, no tocar lista) de 5xx (permanent, retirar).
Reintentos demasiado agresivos
Si configuras Postfix con minimal_backoff_time = 30s, parece comportamiento de spammer. El receptor puede pasarte a lista negra interna.
Apagar reintentos por “ineficiencia”
Algunos administradores reducen maximal_queue_lifetime a 1 día para liberar disco. Resultado: greylisting que tarda 6 horas (algunos sistemas) hace caducar el mensaje. Mantén 5 días por defecto.
Ignorar logs de “deferred”
Una cola con miles de deferred sin examinar oculta problemas. Una vez por semana, mirar postqueue -p | head -50 y ver patrones.
Confundir greylisting con blacklist
Greylisting se resuelve solo. Blacklist no. Si los reintentos siguen fallando con 4xx tras 24 horas, no es greylisting: revisa blacklists.
Greylisting y reputación
Greylisting no es señal de mala reputación. Es un filtro pasivo que muchos receptores aplican a todo el mundo nuevo. No afecta a reputación de IP o dominio ni se reporta en Postmaster Tools.
Lo que sí pasa: tras varios reintentos correctos, el receptor te admite en su lista blanca local y los siguientes envíos pasan directos. Por eso campañas masivas a destinatarios nuevos tienen siempre un slowdown inicial que se compensa después.
Recursos relacionados
Si quieres profundizar, prueba estas herramientas gratuitas: Domain Health, mail tester, validador SPF y validador DMARC.
¿Necesitas que alguien lleve tu canal de email entero? Abalola Mail es la agencia de email marketing especializada en ecommerce de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.