Los umbrales son públicos desde febrero de 2024: las directrices de remitentes de Gmail fijan un hard requirement del 0,3 % de quejas spam, y la mayoría de las plataformas consideran que un hard bounce rate superior al 2 % por campaña activa un throttling. El código SMTP 501 forma parte de los rechazos permanentes que pesan en este cálculo, y miente por omisión. Su verdadera naturaleza está en el subcódigo Enhanced Status que lo acompaña: 5.1.3, 5.1.7, 5.5.4 u otras variantes según el servidor destinatario. Cada subcódigo tiene una causa distinta y una corrección que no se parece a la anterior. Reenviar el mensaje sin haber leído ese subcódigo equivale a añadir un segundo hard bounce a tu cola, lo que perjudica directamente tu sender reputation.
Qué significa el código 501
Un código SMTP que empieza por 5 es un rechazo permanente. El servidor remoto dice: no intentará reenviar este mensaje, ni ahora ni más tarde. A diferencia de los errores 4xx (temporales), un 501 no se resuelve esperando o reenviando el mensaje de forma idéntica.
La sintaxis completa de un mensaje de error 501 se ve así en tu NDR (Non-Delivery Report):
501 5.1.3 Invalid address format
El primer dígito (5) indica el rechazo permanente. El segundo dígito indica la categoría del error Enhanced Status: 1 = problema de dirección, 5 = problema de protocolo o de sintaxis de comando. El tercer dígito precisa el diagnóstico exacto. Esa combinación de tres dígitos, después del 501, es la que debe guiar la corrección.
En la práctica, muchos equipos leen el «501» y se detienen ahí. El subcódigo desaparece en la lógica de reporting de los ESPs (Email Service Providers). El resultado: tratan un problema del remitente como un problema del destinatario, o al revés.
Subcódigo 5.1.3: formato de dirección del destinatario inválido
El subcódigo 5.1.3 indica que la dirección del destinatario contiene un error de formato que el servidor SMTP remoto se niega a procesar. El servidor no intenta verificar si ese buzón existe realmente: ha detectado una anomalía sintáctica antes incluso de llegar a esa etapa.
Las causas más frecuentes:
- Doble arroba:
prenom@domaine@example.com - Dominio ausente:
prenom.nom@ - Caracteres no permitidos en la parte local (espacios sin codificar, paréntesis, corchetes fuera de comillas)
- Extensión de dominio ausente:
prenom@domaine - Punto al inicio o al final de la parte local:
.prenom@domaine.com
Estas direcciones entran en tus listas a través de formularios sin validación del lado del servidor, importaciones CSV mal limpiadas o entradas manuales en la base CRM. La corrección no se hace en el lado SMTP: se hace antes, antes del envío.
Pasa tu lista por un validador de formato que aplique la sintaxis RFC 5321 antes de cada campaña. Las direcciones 5.1.3 son recuperables: o bien se recupera la dirección correcta contactando al lead por otro canal, o bien se elimina definitivamente el contacto de la lista. Conservarlo con ese estado garantiza un hard bounce en el próximo envío.
Subcódigo 5.1.7: dirección del remitente incorrecta o rechazada
Aquí el problema cambia de lado. El subcódigo 5.1.7 concierne a la dirección del remitente, no a la del destinatario. El servidor remoto ha rechazado tu comando MAIL FROM porque la dirección de envío no es válida según sus criterios.
Este subcódigo aparece en dos situaciones distintas. Primera situación: tu dirección de envío contiene en sí misma un error de formato (dominio inexistente, sintaxis inválida). Segunda situación: el servidor destinatario aplica una política estricta que bloquea a los remitentes cuya dirección From o Return-Path no supera los controles de autenticación.
Un 5.1.7 puede, por tanto, revelar un problema de SPF mal configurado en tu dominio de envío. Si tu registro SPF no incluye la dirección IP o el dominio de tu ESP, algunos servidores receptores rechazan el comando MAIL FROM con este subcódigo en lugar de un 550 clásico.
Abre el NDR completo e identifica la dirección señalada. Si es tu Return-Path (dirección técnica de rebote), comprueba que tu registro SPF incluye el dominio de tu plataforma de envío. Si es tu dirección From visible, verifica que el dominio de envío corresponde a tu dominio SPF autorizado.
Verifica también tu alineación DMARC: un remitente cuyo dominio From difiere del dominio SPF (o DKIM) puede provocar rechazos 5.1.7 en los servidores que aplican una política DMARC estricta en recepción.
Subcódigo 5.5.4: comando SMTP inválido
El subcódigo 5.5.4 difiere de los dos anteriores. Ya no concierne a la dirección sino al propio comando SMTP. El servidor remoto recibió un comando mal formado o parámetros que no reconoce.
En la práctica, este subcódigo aparece raramente en envíos estándar a través de un ESP reconocido (Brevo, Mailgun, Postmark, Amazon SES). Es más frecuente cuando se envía a través de un servidor SMTP propio, un relé SMTP configurado manualmente o una integración API que construye la sesión SMTP directamente.
Las causas típicas de un 5.5.4:
- Cabeceras SMTP mal formateadas (codificación incorrecta en el
EHLOo elMAIL FROM) - Parámetros no soportados en el comando (p. ej. extensiones SMTP no negociadas mediante
EHLO) - Incoherencia entre el nombre de host anunciado en
EHLOy la dirección IP del servidor de envío - Conector o middleware que inserta caracteres de control en la sesión
La corrección pasa por los logs SMTP brutos, no solo por el NDR. Activa el modo debug en tu servidor o relé para capturar la transacción completa e identificar el comando exacto que provoca el rechazo.
Otras variantes del 501: leer el mensaje de texto
No todos los servidores implementan los códigos Enhanced Status de forma uniforme. Algunos devuelven un 501 sin subcódigo o con un subcódigo propietario (5.0.0, 5.7.1, etc.). En ese caso, el diagnóstico se basa íntegramente en el mensaje de texto que acompaña al código.
Ejemplos de mensajes 501 sin subcódigo estandarizado:
501 Syntax: MAIL FROM: <address>, problema de formato en el comando MAIL FROM, en el lado del remitente501 Bad recipient address syntax, variante del 5.1.3, problema en el lado del destinatario501 Domain must be present in address, dominio ausente en la dirección, variante 5.1.3501 Too many invalid addresses, el servidor ha alcanzado su umbral de tolerancia para una sesión con múltiples destinatarios inválidos
Ojo con ese último caso. Si tu lista contiene un alto porcentaje de direcciones inválidas en un mismo dominio destinatario, algunos servidores bloquean la sesión completa tras N errores consecutivos. Obtienes entonces un 501 en direcciones que habrían podido pasar. El hard bounce rate aparente supera entonces el porcentaje de direcciones realmente inválidas.
Leer el NDR para identificar el subcódigo correcto
Tu ESP suele devolverte un resumen del error. Ese resumen está con frecuencia truncado. Para diagnosticar correctamente, necesitas el NDR completo.
En Gmail / Google Workspace: el NDR llega al buzón del remitente. Abre el mensaje, haz clic en los tres puntos de la esquina superior derecha y selecciona Mostrar original. El código SMTP completo aparece en la cabecera Diagnostic-Code.
En Outlook / Exchange: mismo procedimiento. El NDR contiene una sección Diagnostic information for administrators con el código completo devuelto por el servidor remoto.
En tu ESP (Brevo, Mailchimp, Postmark): ve a la actividad del mensaje o al informe de bounce. La mayoría de los ESPs muestran el código Enhanced Status y el mensaje de texto sin formato en la ficha de actividad de cada envío. Si tu ESP no lo muestra, exporta los logs de actividad y filtra por el código 501.
Una vez identificado el subcódigo, aplica la corrección correspondiente. Corrige la dirección para los 5.1.3, corrige el remitente o el SPF para los 5.1.7, corrige la sesión SMTP para los 5.5.4.
Evitar los 501 antes del envío: verificación de direcciones
La corrección después del bounce es costosa: un hard bounce registrado, un contacto a eliminar, una reputación IP ligeramente dañada. Actuar antes del envío sale más barato.
Para los errores 5.1.3 (formato de dirección inválido), la verificación sintáctica antes de la importación es una primera barrera. Detecta los dobles arrobas, los dominios ausentes y los caracteres no permitidos. No tiene ningún coste y se aplica al importar el archivo o al enviar el formulario.
Una verificación SMTP en vivo (ping al servidor destinatario sin enviar el mensaje) permite detectar dominios que no existen o que ya no aceptan correo, categoría que también genera bounces 5.1.x. Servicios como Captain Verify combinan la verificación sintáctica, la resolución DNS y el ping SMTP en una sola pasada, con un resultado por dirección que distingue los catchall, los inválidos y los válidos.
Para los errores 5.1.7, la prevención pasa por una auditoría de tu configuración de autenticación (SPF, DKIM, alineación DMARC) antes de tocar la lista. Un dominio de envío mal configurado genera 5.1.7 independientemente de la calidad de tus direcciones destinatarias.
Una list hygiene regular (eliminar bounces, inactivos de larga duración y catchall no verificados) reduce la probabilidad de acumular 501 durante la sesión.
El efecto de acumulación sobre la reputación
Un 501 aislado no destruye una reputación. El problema surge cuando se acumulan en varias campañas consecutivas desde la misma IP o el mismo dominio de envío. Gmail Postmaster Tools y Microsoft SNDS rastrean la tasa de rechazos permanentes por dominio remitente. Un hard bounce rate superior al 2 % en una campaña es suficiente para activar un throttling o un bloqueo temporal por parte de algunos servidores.
Algo que pocas guías sobre errores SMTP mencionan: los servidores destinatarios se comunican entre sí a través de los sistemas de reputación compartida (Spamhaus, Senderscore, Microsoft SNDS). Un remitente que acumula bounces permanentes en Gmail puede ver su IP warming comprometido en Outlook pocas semanas después, aunque nunca haya tenido un problema directo con ese servidor.
Las directrices de remitentes de Gmail, actualizadas en 2024, recomiendan mantener la tasa de spam por debajo del 0,1 % y fijan el umbral duro de rechazo en el 0,3 %. Para los rechazos permanentes repetidos, la tolerancia está en el mismo rango.
Un 501 se lee. Treinta segundos más que ignorar el rebote. Es la única diferencia entre una corrección que funciona y un reenvío que empeora las cosas.
