Ir al contenido
La bitácora de la entregabilidad · 9 min de lectura

550 5.7.26 “This message does not have authentication information”: guía de solución para Gmail

El rebote 550 5.7.26 de Gmail significa que tu correo no pasó las verificaciones de autenticación de Gmail para remitentes masivos. Aquí ves exactamente qué verificación falla y la solución precisa para cada una.

Autor
Google
Tema
Publicado
Actualizado

Referencia: 550 5.7.26 en la wiki de códigos de error

En esta página
  1. Qué significa realmente 550 5.7.26
  2. Paso 1: mira los encabezados del mensaje original
  3. Paso 2: corrige la alineación DKIM
  4. Paso 3: publica un registro DMARC (aunque sea p=none)
  5. Paso 4: confirma que SPF no esté roto sin que lo notes
  6. Paso 5: regístrate en Google Postmaster Tools y léelo
  7. Paso 6: vuelve a probar desde una conexión nueva
  8. Por qué podrías seguir recibiendo 550 5.7.26 después de corregirlo todo
  9. Preguntas frecuentes
  10. Adelántate a las reglas de Gmail
  11. Fuentes

Si Gmail rebota tu correo con esta respuesta SMTP, te estás topando con la aplicación de las reglas de Gmail para remitentes masivos:

550-5.7.26 This message does not have authentication information or fails to
550-5.7.26 pass authentication checks (SPF or DKIM). To best protect our users
550-5.7.26 from spam, the message has been blocked. Please visit
550 5.7.26 https://support.google.com/mail/answer/81126 for more information.

Es un rechazo por autenticación; la reputación, el contenido y los filtros por usuario no tienen nada que ver. Los requisitos de Gmail para remitentes (vigentes desde febrero de 2024 y aplicados con más dureza desde noviembre de 2025) exigen que todo remitente pase SPF o DKIM, y que quienes envían unos 5,000 mensajes o más al día a cuentas personales de Gmail pasen SPF y DKIM, alineen el dominio From con uno de los dos y publiquen un registro DMARC. Cuando la autenticación falla, Gmail rechaza el mensaje en el momento del SMTP.

Qué significa realmente 550 5.7.26

El error tiene tres causas raíz posibles, en orden de frecuencia:

  1. Ni SPF ni DKIM están alineados con el dominio visible del From:.
  2. La propia política DMARC de tu dominio (p=quarantine o p=reject) le dice a Gmail que rechace el correo que falla. Un registro DMARC ausente tiene su propio código, 4.7.40 o 5.7.40, en la lista de errores de Gmail.
  3. SPF y DKIM pasan los dos, pero el dominio del encabezado From: no coincide con el dominio autenticado (fallo de alineación).

Gmail no cuenta un SPF que pasa solo en el dominio del Return-Path/rebotes. Si tu dominio de rebotes es bounces.esp.com y tu From es hello@yourdomain.com, SPF pasa pero no se alinea, así que dependes de un DKIM firmado por yourdomain.com.

Paso 1: mira los encabezados del mensaje original

Envíate una prueba desde la misma plataforma de envío a una cuenta de Gmail que todavía lo acepte (o a una cuenta de Workspace donde puedas leer la carpeta de spam). Abre el mensaje → tres puntos → Mostrar original.

Busca el encabezado Authentication-Results::

Authentication-Results: mx.google.com;
       dkim=pass header.i=@esp.com;
       spf=pass smtp.mailfrom=bounces.esp.com;
       dmarc=fail (p=NONE) header.from=yourdomain.com

En este ejemplo DKIM pasa para esp.com, pero el From es yourdomain.com, y por eso DMARC falla. La solución es configurar la firma DKIM con yourdomain.com dentro de tu ESP, no cambiar SPF.

Paso 2: corrige la alineación DKIM

La alineación DKIM es la victoria más fácil. Casi todos los ESP grandes (Mailchimp, HubSpot, SendGrid, Brevo, Klaviyo, ActiveCampaign, Customer.io, Resend, Postmark) admiten DKIM con dominio propio. Agregas el registro CNAME o TXT que te dan en selector._domainkey.yourdomain.com y luego activas la firma DKIM en su panel.

Después de la propagación (de unos minutos a unas horas), el encabezado Authentication-Results debería decir dkim=pass header.i=@yourdomain.com, y DMARC va a pasar por la vía de DKIM aunque SPF no esté alineado.

Verifícalo con nuestra herramienta de consulta DKIM.

Paso 3: publica un registro DMARC (aunque sea p=none)

Las reglas de Gmail para remitentes masivos exigen que exista un registro DMARC. p=none basta para cumplir este requisito mientras sigues monitoreando. El registro mínimo que cumple es:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Agrégalo como registro TXT en _dmarc.yourdomain.com. Genera uno con nuestro generador de DMARC.

Paso 4: confirma que SPF no esté roto sin que lo notes

Aunque DKIM haga el trabajo, te conviene tener SPF limpio. Problemas comunes:

  • Más de 10 consultas DNS en el registro SPF (provoca permerror)
  • Dos registros SPF en el mismo dominio (solo se permite uno)
  • Un -all (hard fail) donde querías ~all (solo importa si tu ESP no está en la lista de include)

Revísalo con nuestra herramienta de consulta SPF. Si pasas del límite de 10 consultas, aplánalo con delegación a subdominios o con un servicio de macros SPF.

Paso 5: regístrate en Google Postmaster Tools y léelo

Si te está llegando el 550 5.7.26, regístrate en Google Postmaster Tools con el dominio From. Después de 24 a 48 horas de tráfico, muestra:

Si el gráfico de autenticación no está en verde casi al 100%, tus correcciones todavía no surtieron efecto del todo.

Paso 6: vuelve a probar desde una conexión nueva

Las colas de reintento de los ESP pueden tardar 30 minutos en vaciarse. Pausa y reanuda la campaña de envío, o manda un mensaje de prueba nuevo después de que DKIM y DMARC se propaguen. El rebote debería desaparecer de inmediato en cuanto la autenticación pase. Gmail no "recuerda" el fallo anterior contra tu IP.

Por qué podrías seguir recibiendo 550 5.7.26 después de corregirlo todo

Algunas causas menos obvias que vemos en soporte:

  • Subdominio que no coincide. Si tu From es hello@mail.yourdomain.com pero DKIM está configurado en yourdomain.com, la alineación es relajada por defecto y debería pasar igual, pero algunos ESP publican alineación estricta en DMARC (adkim=s). Cámbiala a adkim=r.
  • Caché DNS desactualizada. Gmail guarda el DNS en caché durante horas. Después de publicar DKIM, espera al menos 4 horas antes de concluir que la solución no funciona.
  • Selector equivocado. Algunos ESP rotan los selectores (por ejemplo, s1, s2). Si borraste el registro TXT anterior antes de que el nuevo surtiera efecto, vas a ver fallos de DKIM hasta que lo vuelvas a agregar.

Preguntas frecuentes

¿550 5.7.26 es lo mismo que el 550-5.7.1 de Gmail? No. 550-5.7.1 Our system has detected... es un bloqueo por contenido/reputación. 550-5.7.26 es estrictamente un rebote por aplicación de autenticación, y la solución es técnica (DKIM/SPF/DMARC), no de contenido.

¿Gmail va a bloquear toda mi IP después de un 550 5.7.26? No. Este rebote se evalúa por mensaje y por remitente. Por sí solo no daña la reputación de la IP. Pero reintentar una y otra vez con la autenticación rota desperdicia espacios de conexión y con el tiempo puede frenarte con throttling 421.

¿Necesito aplicar DMARC (p=quarantine o p=reject) para resolver esto? No. Gmail exige un registro DMARC publicado. p=none basta para la verificación de remitentes masivos. Pasa a la aplicación solo cuando tus informes agregados de DMARC se vean limpios.

Adelántate a las reglas de Gmail

Gmail endurece estos requisitos cada 12 a 18 meses. MailVitals monitorea tu SPF, DKIM, DMARC y alineación de forma continua y te avisa en el momento en que cualquier registro cambia.

Fuentes

Beat · monitoreo de pago

Un latido para tu correo.

Beat ejecuta cada verificación de este sitio de forma programada: 41 verificaciones, 50 blacklists e inbox placement real. En cuanto algo falla, te dice qué falló, por qué importa y la solución exacta.

example.comVigilando
  • SPFaprobado
  • DKIMaprobado
  • DMARCp=none
  • Blacklists0 / 50

Ilustrativo. Tu dominio, cada pocas horas.

También de nosotros:Pulse: tu propia infraestructura de envíoConsultoría: US$ 65/h, sin cuota mensual