Defaults.Exposed › Soluciones › Guides
Gmail 550 5.7.26 "The Sender Is Unauthenticated": la solución, en orden de requisitos (2026)
Publicado 2026-07-08
Cifras a fecha de 2026-06-29 · metodología v7. Datos agregados del censo sobre 261 millones de dominios calificados. Vea cómo calificamos.
Gmail devuelve 550 5.7.26 cuando su mensaje falla las comprobaciones de autenticación SPF y DKIM. Se arregla haciendo que al menos uno de los dos — SPF o DKIM — pase para su dominio de envío. A la mayoría de los remitentes les falta esto: de los 12.145.313 dominios que autorizan los servidores de Google mediante _spf.google.com, solo el 18,5% aplica DMARC, según el censo de Defaults.Exposed de 261.086.232 dominios.
La solución es trabajo de DNS, no un ticket de soporte: confirme que su IP de envío tiene DNS inverso, consiga que SPF o DKIM pasen para el dominio que Gmail comprueba realmente, y luego haga que DKIM se alinee con su dirección From y publique un registro DMARC. Abajo está el orden completo de requisitos, más una tabla de descifrado para la familia 550 5.7.26 y sus códigos hermanos.
¿Qué significa el error 550 5.7.26 de Gmail?
Desde los requisitos de remitente de Google de 2024, todo remitente hacia Gmail — no solo los masivos — debe pasar al menos uno de SPF o DKIM para el dominio de envío. Si fallan los dos, Gmail rechaza en el momento SMTP con 550 5.7.26 en lugar de entregar en spam.
La versión de texto completo actual dice: “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 [domain] with ip: [ip] = did not pass.” Los rebotes antiguos que circulan aún pueden llevar la redacción anterior de Google (“This mail is unauthenticated, which poses a security risk…”), y existe un hermano de limitación de ritmo — 421 4.7.26 This email has been rate limited because it is unauthenticated — con la misma causa.
El 550 5.7.26 no es un único mensaje sino parte de una familia de códigos, y la redacción le dice qué pata falló: la referencia actual de Google mantiene tres cadenas 5.7.26 (sin autenticar, fallo estricto de SPF, política DMARC) y traslada los fallos de solo-SPF y solo-DKIM para remitentes masivos a sus propios códigos, 5.7.27 y 5.7.30. Lea el texto exacto antes de tocar el DNS — es su primer diagnóstico.
La escala de la brecha explica por qué este rebote es tan común: 12.145.313 dominios autorizan los servidores de correo de Google en su registro SPF (de 138.927.207 dominios en todo el mundo que publican SPF), y sin embargo solo el 18,5% tiene una política DMARC de aplicación y apenas el 8,0% usa SPF estricto (-all). La mayoría de los remitentes alojados en Google no cumple las propias reglas de Google para remitentes masivos — y Gmail ahora exige lo básico a todo el mundo.
¿Qué variante del 550 5.7.26 — o código hermano — tiene usted?
Compare el texto del rebote que recibió con esta tabla. Los fragmentos citados siguen la referencia actual de errores SMTP de Google — contrástelos siempre con su NDR real, ya que Google revisa la redacción periódicamente.
| Código | El texto del rebote dice (fragmento) | Qué falló | Dónde está la solución |
|---|---|---|---|
| 550 5.7.26 (sin autenticar) | “This email has been blocked because the sender is unauthenticated … authenticate with either SPF or DKIM” | Ni SPF ni DKIM pasaron | Esta guía, pasos 2–4 |
| 550 5.7.26 (fallo estricto de SPF) | “has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks” | Su registro SPF estricto no autoriza la IP de envío | Paso 3 abajo + arreglar SPF |
| 550 5.7.26 (política DMARC) | “Unauthenticated email from [domain] is not accepted due to domain’s DMARC policy” | Su propia política DMARC rechazó correo no alineado | Paso 4 abajo |
| 550 5.7.27 (masivo, SPF) | “didn’t pass SPF authentication … Gmail requires bulk email senders to authenticate their email with SPF” | SPF falló, y usted está en el nivel de remitente masivo | Paso 3 abajo + arreglar SPF |
| 550 5.7.30 (masivo, DKIM) | “didn’t pass DKIM authentication … Gmail requires bulk email senders to authenticate their email with DKIM” | Sin firma DKIM válida, y usted está en el nivel de remitente masivo | Paso 3 abajo + arreglar DKIM |
| 550 5.7.29 (masivo, TLS) | “wasn’t sent over a TLS connection” | Correo masivo enviado sin TLS | Paso 6 abajo |
| 550 5.7.25 | ”doesn’t have a PTR record” | Sin DNS inverso (PTR) en la IP de envío | Paso 2 abajo |
| 421-4.7.0 | ”try again later” / unusual traffic | Aplazamiento temporal — reputación o ritmo, no permanente | Reintente; revise los pasos 2–3 y el paso 8 |
| 550 5.7.28 | ”unusual rate of unsolicited email” | Límite de ritmo de envío / tasa de spam | Paso 8 abajo |
| 550-5.7.1 | ”message blocked” / texto de política | Rechazo por política, spam o IPv6 sin PTR | Vea la guía del Gmail 550-5.7.1 |
¿Cómo se arregla el 550 5.7.26, en orden de requisitos?
Google no publica un “orden de comprobación” literal — pero sus requisitos se apilan con lógica, así que trabájelos en este orden de requisitos. La mayoría de los remitentes queda desbloqueada tras el paso 3; termine la lista de todos modos, porque los pasos posteriores son los que le mantienen fuera del spam una vez que sale del rebote.
- Ejecute primero el análisis gratuito. Lee su configuración real de SPF, DKIM, DMARC y DNS y muestra exactamente qué pata está fallando — diagnostique antes de tocar el DNS.
- Dé DNS inverso (PTR) a su IP de envío. La IP que conecta debe tener un registro PTR cuyo nombre de host resuelva de vuelta a la misma IP. Los proveedores convencionales se encargan de esto por usted; muerde a quienes envían desde sus propios servidores (y es toda la historia detrás del código hermano 550 5.7.25).
- Consiga que SPF o DKIM pasen. Primero una barandilla: los receptores evalúan SPF contra el dominio del Return-Path (RFC5321.MailFrom), no contra la cabecera From — compruebe a qué dominio rebota realmente su correo antes de decidir que SPF “debería” pasar. Añada sus servicios de envío reales al registro SPF de ese dominio (recorrido completo de SPF), o active la firma DKIM en su proveedor (recorrido completo de DKIM). Con que uno de los dos pase se elimina el bloqueo básico del 550 5.7.26.
- Haga que DKIM se alinee con su dominio From. Para el envío masivo — y para DMARC — Gmail quiere autenticación para el dominio de su dirección From, no un valor por defecto del proveedor. Usuarios de Google Workspace: publiquen su propia clave DKIM (configuración de DKIM en Workspace); una firma por defecto
gappssmtp.compasa DKIM pero no se alinea — una trampa con su propia guía. El DKIM alineado además sobrevive al reenvío, cosa que SPF nunca hace. - Publique un registro DMARC. Los requisitos de remitente de Google piden como mínimo
p=nonecon una dirección de informes. Es una edición de DNS de cinco minutos — vea “DMARC policy not enabled” para el primer paso honesto y lo quep=noneprotege y no protege. - Envíe por TLS. Cualquier servidor o proveedor de correo moderno lo hace por defecto; si opera su propio MTA, confirme que el TLS saliente está activo — el correo masivo sin él ahora rebota con su propio código, 550 5.7.29.
- Añada la baja en un clic de RFC 8058 (cabeceras
List-Unsubscribe+List-Unsubscribe-Post) para el correo de marketing y de suscripción. - Mantenga su tasa de spam por debajo del 0,10% en Google Postmaster Tools — y nunca deje que llegue al 0,30%. El techo de requisito de Google es el 0,3%; su recomendación es mantenerse bajo el 0,10%. Registre allí su dominio; es el boletín de notas que Google tiene sobre usted, y el umbral de tasa de spam es el requisito que ningún registro DNS puede arreglar.
Una cosa que esta lista no hará: sacarle de una lista de bloqueo de terceros. La autenticación detiene los rechazos de Gmail por falta de autenticación; una IP con historial de spam es un problema de reputación con su propia ruta de limpieza — arreglar la autenticación evita recaídas, no le quita de la lista.
¿Se aplican las reglas de remitente masivo si envía menos de 5.000 correos al día?
La lista completa — autenticación alineada, DMARC publicado, baja en un clic, tasa de spam — se aplica formalmente a partir de 5.000+ mensajes al día hacia Gmail, y los códigos exclusivos de masivo (5.7.27, 5.7.29, 5.7.30) provienen de ese nivel. Pero lo básico de la autenticación (SPF o DKIM pasando, PTR válido) se exige a todo el mundo, y por eso los remitentes pequeños también se topan con el 550 5.7.26. Trate los pasos 1–5 como obligatorios a cualquier volumen, y los pasos 7–8 como obligatorios desde el momento en que envíe en masa. El conjunto completo de requisitos de ambos proveedores está en nuestro artículo de datos sobre los requisitos de remitente de Google y Yahoo.
Preguntas frecuentes
¿550 5.7.26 significa que mi dominio o IP está en una lista de bloqueo? No. Es un fallo de autenticación, no un juicio de reputación — Gmail está diciendo “demuestre quién es”, no “sabemos que es un spammer”. Esa es la buena noticia: se arregla por completo en el DNS. La mala noticia es lo normal que es — en todo el censo de 261.086.232 dominios (a fecha de 2026-06-29), solo el 10,59% tiene una política DMARC de aplicación.
¿Arreglar solo SPF detendrá los rebotes? Normalmente sí, para la variante básica — Gmail exige al menos uno de SPF o DKIM. Pero SPF se evalúa contra el dominio del Return-Path y se rompe con el reenvío, así que el DKIM alineado (paso 4) es la solución duradera. Solo el 8,0% de los 12.145.313 dominios remitentes alojados en Google usa SPF estricto (datos a fecha de 2026-06-29), así que en cualquier caso irá por delante del pelotón.
Uso Google Workspace — ¿por qué Google rebota mi propio correo? Porque Gmail autentica el dominio, no al proveedor del buzón. Un dominio de Workspace sin registro SPF y sin clave DKIM personalizada envía correo que ni el propio Google puede verificar — de 12.145.313 dominios que autorizan los servidores de Google, solo el 18,5% tiene DMARC en aplicación (datos a fecha de 2026-06-29). Ser cliente de Google y cumplir las reglas de Google son cosas distintas.
¿Cuánto tarda Gmail en aceptar mi correo tras la corrección de DNS? En cuanto los nuevos registros sean visibles — normalmente de minutos a unas pocas horas, hasta 48 horas con TTL lentos. Las correcciones de autenticación actúan de inmediato sobre la comprobación del 550 5.7.26; la recuperación de la tasa de spam y de la reputación (421-4.7.0, 5.7.28) lleva de días a semanas de envío limpio.
Envíe el informe al propietario
Si está arreglando esto para un cliente, no cierre el ticket con “rebotes resueltos”. Repita el análisis gratuito tras sus cambios de DNS y reenvíe el informe calificado al propietario del negocio. Muestra, en lenguaje claro, que su dominio ahora autentica su correo y dónde sigue quedándose corto — la prueba que necesitan para las renovaciones del ciberseguro y los cuestionarios de seguridad de proveedores. Usted arregló el rebote; el informe lo demuestra.
Compruebe su dominio gratis
Vea en qué pata de SPF, DKIM y DMARC le está suspendiendo Gmail — de forma privada y solo para el propietario.
Compruebe su dominio → · Arreglar SPF → · Gmail “550-5.7.1 message blocked” → · Cómo calificamos → · Solo datos agregados. Datos almacenados y procesados en la UE.