Rechazos Gmail 550‑5.7.26 y UsernameCaseMapped: causas, diagnóstico y soluciones
Por CaptainDNS
Publicado el 26 de febrero de 2026
- Gmail devuelve 550 5.7.26 cuando SPF, DKIM o la alineación DMARC fallan: es un rechazo permanente, el servidor no reintentará
- El error UsernameCaseMapped proviene de la normalización PRECIS (RFC 8265): la local-part de la dirección From debe estar en minúsculas
- Desde febrero de 2024, Google exige SPF + DKIM + DMARC para los remitentes masivos (>5 000 correos/día) y SPF o DKIM para todos los demás
- Corrígelo normalizando tus direcciones en minúsculas, verificando SPF/DKIM/DMARC y controlando la alineación del dominio From:
Tus correos hacia Gmail vuelven con un código 550. Sin carpeta de spam, sin retraso: un rechazo limpio y definitivo. El servidor corta la conexión y no reintentará. Esto es lo que constatan cada vez más equipos de entregabilidad desde principios de 2026, con dos motivos de rechazo en aumento: 550 5.7.26 (remitente no autenticado) y UsernameCaseMapped (mayúsculas/minúsculas de la dirección inválidas).
Estos dos errores comparten un punto en común: son el resultado del refuerzo continuo de las políticas anti-spoofing de Google. Lo que pasaba hace un año ahora queda bloqueado. Esta guía cubre las causas técnicas de cada error, el diagnóstico preciso a través de los logs SMTP, y las correcciones a aplicar en tu infraestructura de envío.
Entender el error 550 5.7.26 de Gmail
El código 550 5.7.26 es un rechazo permanente (clase 5xx) que significa que Gmail no pudo validar la autenticidad de tu mensaje. A diferencia de un código 4xx (temporal), el servidor emisor no debe reintentar: el correo queda definitivamente rechazado.
Las tres variantes del código 550 5.7.26
Google devuelve tres mensajes diferentes bajo el mismo código, cada uno correspondiente a una causa distinta:
Variante 1, remitente no autenticado:
550-5.7.26 This email has been blocked because the sender is
unauthenticated. Gmail requires all senders to authenticate with
either SPF or DKIM. Authentication results: DKIM = did not pass
SPF [captaindns.com] with ip: [203.0.113.42] = did not pass.
Ni SPF ni DKIM superaron la verificación. Es la variante más frecuente.
Variante 2, SPF hard fail:
550-5.7.26 The MAIL FROM domain [captaindns.com] has an SPF record
with a hard fail policy (-all) but it fails to pass SPF checks
with the ip: [203.0.113.42].
Tu registro SPF termina con -all (rechazo estricto), pero la IP que envía no está autorizada. Gmail aplica tu propia política al pie de la letra.
Variante 3, política DMARC:
550-5.7.26 Unauthenticated email from captaindns.com is not accepted
due to domain's DMARC policy. Contact the administrator of
captaindns.com domain if this was legitimate email.
SPF o DKIM pueden haber pasado, pero la alineación DMARC falla: el dominio From: no coincide con el dominio autenticado por SPF o DKIM.
Diferencia entre 550 5.7.26 y 421 4.7.26
| Código | Clase | Comportamiento | Acción requerida |
|---|---|---|---|
| 421 4.7.26 | Temporal | El servidor emisor reintenta más tarde | Verificar, pero el correo puede acabar pasando |
| 550 5.7.26 | Permanente | El correo queda definitivamente rechazado | Corregir la configuración antes de reenviar |
Un 421 es una advertencia con rate limiting. Un 550 es un muro. Si ves 550, el problema es estructural y no se resolverá reintentando.
¿Por qué estos rechazos aumentan ahora?
Desde el 1 de febrero de 2024, Google endureció sus requisitos para remitentes:
| Requisito | Todos los remitentes | Remitentes masivos (>5 000/día) |
|---|---|---|
| SPF o DKIM | Obligatorio | Obligatorio |
| SPF y DKIM | Recomendado | Obligatorio |
| DMARC | Recomendado | Obligatorio (p=none mínimo) |
| Alineación From: | Recomendado | Obligatorio |
| TLS (STARTTLS) | Obligatorio | Obligatorio |
| Tasa de spam <0,3 % | Obligatorio | Obligatorio |
Lo que cambió en la práctica: antes, un correo sin autenticación aterrizaba en spam. Hoy, Gmail lo rechaza con un 550. Es una diferencia importante.
Entender el error UsernameCaseMapped
El error UsernameCaseMapped está menos documentado pero es igual de bloqueante. Provoca un rechazo permanente 550 vinculado a las mayúsculas/minúsculas de la dirección del remitente.
¿Qué es el perfil UsernameCaseMapped?
El término proviene de la RFC 8265 (PRECIS: Preparation, Enforcement, and Comparison of Internationalized Strings). Esta RFC define cómo los servidores deben normalizar los identificadores de usuario antes de compararlos.
El perfil UsernameCaseMapped impone dos operaciones:
- Normalización Unicode (NFKC): los caracteres se reducen a su forma canónica
- Case folding: las mayúsculas se convierten en minúsculas
En la práctica, cuando Gmail recibe un correo, normaliza la local-part (la parte antes del @) de la dirección From: aplicando este perfil. Si el resultado no coincide con la dirección esperada, el mensaje es rechazado.
¿Cómo se produce este error?
El escenario típico:
- Tu CRM o script envía un correo con
From: Marketing@captaindns.com - Gmail normaliza la local-part:
marketing@captaindns.com - La comparación falla si el servidor espera exactamente
Marketing@captaindns.como si la autenticación (SPF/DKIM) se realizó con mayúsculas/minúsculas diferentes - Resultado: rechazo 550 UsernameCaseMapped
Los sistemas que generan este error con más frecuencia:
- CRM y plataformas de marketing que almacenan la dirección con las mayúsculas/minúsculas introducidas por el usuario
- Alias de correo y redirecciones que conservan las mayúsculas/minúsculas originales
- Scripts legacy que construyen la dirección From sin normalización
- Formularios web que utilizan la entrada del usuario tal cual en el MAIL FROM
RFC 5321 y las mayúsculas/minúsculas de las direcciones de correo
La RFC 5321 (SMTP) estipula que la local-part de una dirección de correo es teóricamente case-sensitive: es el servidor de recepción quien decide si User y user son el mismo buzón. En la práctica, la gran mayoría de los servidores tratan la local-part en minúsculas. Gmail va más allá aplicando la normalización PRECIS y rechazando los mensajes cuyas mayúsculas/minúsculas no coinciden.
La trampa: la RFC autoriza las mayúsculas, pero las implementaciones modernas las prohíben de hecho. Si tu infraestructura de envío conserva mayúsculas en la dirección From o el MAIL FROM, te arriesgas a un rechazo.
Diagnosticar estos errores
Leer los logs SMTP
El diagnóstico empieza por los logs de tu servidor de correo o de tu proveedor de envío. Busca las respuestas 550:
Feb 12 14:23:01 mail postfix/smtp[12345]: to=<contact@gmail.com>,
relay=gmail-smtp-in.l.google.com[142.250.115.27]:25,
status=bounced (host gmail-smtp-in.l.google.com said:
550-5.7.26 This email has been blocked because the sender is
unauthenticated.)
Puntos a verificar en los logs:
- El código exacto (550 vs 421)
- La IP de envío mencionada en el mensaje
- Los resultados SPF y DKIM citados por Gmail
- El dominio From: y el dominio MAIL FROM (envelope sender)
Verificar la autenticación con los encabezados
Si tienes acceso a un correo que llegó (o a un informe DMARC), examina los encabezados Authentication-Results:
Authentication-Results: mx.google.com;
dkim=pass header.d=captaindns.com header.s=selector1;
spf=pass (google.com: domain of bounce@captaindns.com
designates 203.0.113.42 as permitted sender)
smtp.mailfrom=bounce@captaindns.com;
dmarc=pass (p=REJECT sp=REJECT) header.from=captaindns.com
Si uno de estos tres resultados es fail, has encontrado la fuente del problema. Utiliza el verificador DMARC CaptainDNS para comprobar tu configuración en unos segundos.
Utilizar Google Postmaster Tools
Google Postmaster Tools proporciona métricas sobre tus envíos hacia Gmail:
- Tasa de spam reportada por los destinatarios
- Reputación de tu dominio y de tus IPs de envío
- Volumen de rechazos por código de error
Si tu tasa de spam supera el 0,3 %, Gmail empieza a aplicar rate limiting a tus envíos (421) y luego a rechazarlos (550).
Corregir el error 550 5.7.26
Paso 1: configurar SPF correctamente
Tu registro SPF debe autorizar todas las IPs y servicios que envían en nombre de tu dominio:
captaindns.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all"
Errores frecuentes:
- Un proveedor de envío ausente del SPF (CRM, herramienta de marketing, servicio transaccional)
- Un
-all(hard fail) cuando no todos los remitentes están listados: usa~all(soft fail) mientras completas la lista - Más de 10 lookups DNS en el registro SPF, lo que invalida toda la política
Verifica con el verificador SPF CaptainDNS.
Paso 2: activar DKIM en todos los flujos de envío
Cada servicio que envía correos para tu dominio debe firmar con DKIM:
selector1._domainkey.captaindns.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
Puntos críticos:
- La clave debe ser de 1 024 bits mínimo (2 048 recomendado por Google)
- El dominio de firma DKIM (
d=) debe coincidir con el dominio From: para la alineación DMARC - Verifica que la clave pública sea accesible en el DNS:
dig TXT selector1._domainkey.captaindns.com
Paso 3: desplegar una política DMARC
Si aún no tienes DMARC, empieza con una política de monitoreo:
_dmarc.captaindns.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com; adkim=r; aspf=r"
Progresión recomendada:
| Paso | Política | Duración | Objetivo |
|---|---|---|---|
| 1 | p=none | 2-4 semanas | Recopilar informes, identificar flujos |
| 2 | p=quarantine; pct=25 | 2 semanas | Probar con el 25 % del tráfico |
| 3 | p=quarantine; pct=100 | 2 semanas | Cuarentena completa |
| 4 | p=reject | Permanente | Rechazo de correos no autenticados |
Paso 4: verificar la alineación DMARC
La alineación es la pieza faltante más frecuente. Exige que el dominio From: (encabezado RFC 5322) coincida con el dominio autenticado por SPF o DKIM:
| Verificación | Dominio comparado | Alineación |
|---|---|---|
| SPF | Dominio del MAIL FROM (envelope) | Debe coincidir con el dominio From: |
| DKIM | Dominio d= de la firma | Debe coincidir con el dominio From: |
Ejemplo de fallo de alineación:
- From:
contact@captaindns.com - MAIL FROM:
bounce@promo.captaindns.com - SPF pasa para
promo.captaindns.com, pero DMARC falla porque el From: escaptaindns.com
En modo relaxed (adkim=r; aspf=r), los subdominios son aceptados. En modo strict (adkim=s; aspf=s), el dominio debe ser idéntico.
Paso 5: asegurar el cifrado TLS
Gmail exige una conexión TLS (STARTTLS) para aceptar correos. Verifica que tu servidor soporte STARTTLS:
openssl s_client -starttls smtp -connect mail.captaindns.com:25
Si la conexión TLS falla, Gmail devolverá un rechazo. Activa TLS-RPT para recibir informes diarios sobre los fallos de negociación TLS.
Plan de acción recomendado
- Auditar tus flujos de envío: lista todos los sistemas que envían en nombre de tu dominio (CRM, marketing, transaccional, scripts, formularios)
- Normalizar en minúsculas: fuerza todas las direcciones From, MAIL FROM y Return-Path en minúsculas en cada sistema
- Verificar SPF: ¿están autorizados todos los remitentes? ¿El número de lookups DNS es <10?
- Verificar DKIM: ¿clave ≥1 024 bits publicada en el DNS, dominio
d=alineado con el From:? - Publicar una política DMARC:
p=nonemínimo con informes RUA activos para empezar - Controlar la alineación: ¿el dominio From: coincide con el dominio SPF o DKIM?
- Activar TLS-RPT: para monitorear los fallos de cifrado en tus correos entrantes
- Vigilar Postmaster Tools: verificar a diario la tasa de spam y la reputación dominio/IP
FAQ
¿Cuál es la diferencia entre 550 5.7.26 y 421 4.7.26?
El código 421 4.7.26 es un rechazo temporal con rate limiting: Gmail ralentiza tus envíos pero el servidor emisor puede reintentar más tarde. El código 550 5.7.26 es un rechazo permanente: el correo queda definitivamente rechazado y el servidor no debe reintentar. Un 421 señala un problema puntual o un volumen inusual. Un 550 señala un defecto estructural de autenticación que requiere una corrección de configuración.
¿Cómo saber si mi error es UsernameCaseMapped o 550 5.7.26?
El texto del mensaje de error SMTP hace la distinción. Un rechazo 550 5.7.26 menciona explícitamente "unauthenticated", "SPF" o "DMARC policy". El error UsernameCaseMapped aparece en el texto de la respuesta SMTP con el término "UsernameCaseMapped" y se refiere a las mayúsculas/minúsculas de la dirección, no a la autenticación del dominio. Consulta los logs SMTP de tu servidor o de tu proveedor para leer el mensaje completo.
Mi SPF está configurado, ¿por qué sigo recibiendo 550 5.7.26?
Tres causas frecuentes: (1) la IP de envío no está listada en el SPF, verifica que todos tus proveedores estén incluidos; (2) el SPF supera los 10 lookups DNS, lo que invalida toda la política; (3) SPF pasa pero la alineación DMARC falla porque el dominio MAIL FROM no coincide con el dominio From:. Verifica la alineación además del SPF.
¿Es necesaria una política DMARC p=reject para evitar el rechazo?
No. Gmail exige un registro DMARC publicado para los remitentes masivos, pero p=none basta como política mínima. El rechazo 550 5.7.26 se produce cuando la autenticación falla (SPF y DKIM no pasan), independientemente de tu política DMARC. Sin embargo, la variante "not accepted due to domain's DMARC policy" puede activarse si tu propia política es p=reject y la alineación falla.
¿El error UsernameCaseMapped también afecta a Google Workspace?
Sí. Google Workspace aplica las mismas reglas de normalización PRECIS que Gmail personal. Si envías correos hacia direcciones @tuempresa.com alojadas en Google Workspace con mayúsculas/minúsculas incorrectas en la dirección From, el rechazo UsernameCaseMapped puede producirse. La normalización en minúsculas se aplica a todas las cuentas Google.
¿Cómo probar la alineación DMARC antes de enviar en producción?
Publica una política p=none con informes RUA activados (rua=mailto:dmarc@captaindns.com). Envía un correo de prueba a una cuenta Gmail y examina los encabezados Authentication-Results. Verifica que dmarc=pass aparezca. Si dmarc=fail, compara el dominio From: con los dominios SPF y DKIM en los resultados para identificar el defecto de alineación.
¿Qué significa 'Unauthenticated email not accepted due to domain's DMARC policy'?
Este mensaje indica que tu dominio ha publicado una política DMARC restrictiva (p=quarantine o p=reject) y que el correo no superó ni la verificación SPF alineada ni la verificación DKIM alineada. Gmail aplica tu propia política: dado que pediste el rechazo de correos no autenticados, Gmail rechaza. Verifica la alineación SPF y DKIM con el dominio From:.
¿Los rechazos 550 5.7.26 afectan mi reputación de remitente?
Sí, indirectamente. Rechazos permanentes repetidos señalan a Gmail que tu infraestructura de envío no está correctamente configurada. Esto puede degradar la reputación de tus IPs y de tu dominio en Google Postmaster Tools, lo que luego provoca rate limiting (421) en tus envíos que sí pasan la autenticación. Corrige rápidamente para evitar el efecto bola de nieve.
Glosario
- 550: código SMTP de rechazo permanente. El servidor emisor no debe reintentar el envío.
- 5.7.26: enhanced status code (RFC 3463) que indica un fallo de autenticación del remitente.
- UsernameCaseMapped: perfil de normalización definido en la RFC 8265 (PRECIS) que impone la conversión a minúsculas de la local-part de los identificadores.
- Alineación DMARC: correspondencia entre el dominio del encabezado From: (RFC 5322) y el dominio autenticado por SPF o DKIM. Requerida para superar la verificación DMARC.
- Envelope sender: dirección MAIL FROM utilizada en la transacción SMTP (RFC 5321), distinta del encabezado From: visible para el destinatario.
- Remitente masivo (bulk sender): remitente que envía más de 5 000 correos por día a cuentas Gmail. Sujeto a requisitos reforzados desde febrero de 2024.
