Referencia: 550 5.7.26 en la wiki de códigos de error
En esta página
- Qué significa realmente 550 5.7.26
- Paso 1: mira los encabezados del mensaje original
- Paso 2: corrige la alineación DKIM
- Paso 3: publica un registro DMARC (aunque sea p=none)
- Paso 4: confirma que SPF no esté roto sin que lo notes
- Paso 5: regístrate en Google Postmaster Tools y léelo
- Paso 6: vuelve a probar desde una conexión nueva
- Por qué podrías seguir recibiendo 550 5.7.26 después de corregirlo todo
- Preguntas frecuentes
- Adelántate a las reglas de Gmail
- 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:
- Ni SPF ni DKIM están alineados con el dominio visible del
From:. - La propia política DMARC de tu dominio (
p=quarantineop=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. - 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:
- Tasa de autenticación correcta (objetivo: >99%)
- Reputación del dominio
- Reputación de la IP
- Tasa de spam (el techo duro de Gmail es 0.3%; apunta a menos de 0.1%)
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.compero DKIM está configurado enyourdomain.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 aadkim=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
- Gmail SMTP errors and codes (Ayuda de Google Workspace), los tres textos de 550 5.7.26 (remitente no autenticado, hard fail de SPF, política DMARC) y el 5.7.40 aparte para un registro DMARC ausente.
- Email sender guidelines (Ayuda de Gmail), SPF o DKIM para todos los remitentes; SPF, DKIM, DMARC y alineación del From para los remitentes masivos; y claves DKIM de al menos 1024 bits.
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), el estándar DMARC actual (mayo de 2026, reemplaza a RFC 7489), incluida la alineación de identificadores y los modos
adkim/aspf. - RFC 7208: Sender Policy Framework (SPF), el límite de 10 consultas DNS y el permerror que produce cuando se supera.