Defaults.Exposed › Soluciones › Guides
Gmail "550-5.7.1 Message Blocked" — descifre el rebote y arréglelo (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.1 cuando bloquea un mensaje por razones de política y no por un registro ausente: la política de un dominio remitente o receptor, una conexión IPv6 sin DNS inverso, o sospecha de spam. De los 12.145.313 dominios que autorizan los propios servidores de Google en SPF, solo el 18,5% aplica DMARC, según el censo de Defaults.Exposed de 261 millones de dominios.
El 550-5.7.1 es el rechazo comodín más antiguo de Gmail, y la solución depende de la frase que sigue al código en su rebote. A continuación: una tabla de descifrado para la redacción exacta, luego la ruta de solución por variante — rechazos por política, servidores IPv6 sin DNS inverso, bloqueos por spam o contenido — más los códigos parecidos con los que la gente lo confunde, incluida la familia 5.7.26 que Google usa ahora para el rechazo por política DMARC que las referencias antiguas archivaban bajo 5.7.1.
¿Qué significa realmente el 550-5.7.1 de Gmail?
En el esquema de códigos de estado mejorados de SMTP (RFC 3463), todo código 5.7.x significa “fallo permanente, razones de política”. Gmail usa 550-5.7.1 como su familia de política heredada: bloqueos por política del remitente o del destinatario, bloqueos por reputación de spam y — la variante que sorprende a más administradores — correo que llega por IPv6 desde un servidor sin registro de DNS inverso (PTR).
Google lleva tiempo recodificando variantes. El rechazo por política DMARC (“not accepted due to domain’s DMARC policy”) figura ahora bajo 550-5.7.26 en la referencia actual de Google, aunque los rebotes antiguos que circulan aún pueden mostrarlo como 5.7.1; el bloqueo de seguridad de contenido está codificado ahora como 552 5.7.0. Otros dos hermanos se confunden con el 5.7.1: 550-5.7.26, la familia de requisitos de autenticación (su propia guía), y 550-5.7.25, el código de PTR ausente en cualquier versión de IP. Sea cual sea el código, descifre el texto con la tabla siguiente.
¿Qué variante del 550-5.7.1 tiene usted?
Compare la redacción de su informe de no entrega (NDR). Google ajusta estas cadenas de un año a otro — compare el sentido general, no la puntuación.
| Su rebote se parece a… | Qué significa | Su ruta de solución |
|---|---|---|
| ”This message does not meet IPv6 sending guidelines regarding PTR records and authentication.” | Su servidor entregó por IPv6 sin DNS inverso (o con uno que no coincide) | Registro PTR para la dirección IPv6, o retransmisión vía el smarthost de su proveedor (abajo) |
| “The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.” | Un bloqueo por política — del destinatario, o de su propio dominio | Contacte al administrador receptor; si la política en juego es el DMARC de su propio dominio, vea abajo |
| ”This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.” | Bloqueo por spam/reputación sobre su contenido, IP o dominio | Postmaster Tools + higiene de lista + baja en un clic (abajo) |
| “This message is likely suspicious due to the very low reputation of the sending domain” (o “…sending IP address”) | Bloqueo por reputación — dominio o IP | La misma ruta de reputación (abajo) |
| “Unauthenticated email from yourdomain is not accepted due to domain’s DMARC policy.” — codificado 550-5.7.26 en la referencia actual de Google; los rebotes antiguos aún pueden mostrar 5.7.1 | Su propia política DMARC le dijo a Gmail que rechazara un mensaje no autenticado | Encuentre la fuente no autenticada — no relaje primero la política (abajo) |
| “…blocked because its content presents a potential security issue.” — ahora codificado 552 5.7.0 | Bloqueo por contenido/política (tipo de adjunto, reputación de enlaces) | Elimine la clase de contenido señalada; revise enlaces y adjuntos |
| El código es 550-5.7.25, “the sending IP address doesn’t have a PTR record” | Falta el DNS inverso en cualquier versión de IP | La misma corrección de rDNS que la variante IPv6 |
| El código es 550-5.7.26 | Familia de requisitos de autenticación, no 5.7.1 | Vea la guía del 550-5.7.26 |
| El código es 421-4.7.0, “Try again later, closing connection.” | Aplazamiento temporal — ritmo o reputación, no un bloqueo permanente | Reduzca el ritmo, arregle la autenticación y la tasa de spam; suele resolverse |
¿Cómo se arregla un rebote 550-5.7.1?
- Ejecute el análisis gratuito en defaults.exposed — califica su SPF, DKIM y DMARC tal como los ve el mundo, antes de que toque el DNS, y muestra si la variante DMARC es siquiera posible para su dominio.
- Lea el texto completo del NDR contra la tabla de descifrado — es la frase, no el código, lo que identifica la causa.
- Variante DMARC: averigüe qué fuente de envío falló la autenticación y arregle esa fuente (siguiente sección).
- Variante IPv6/PTR: añada un DNS inverso coincidente para la dirección IPv6 del servidor, o retransmita a través del smarthost de su proveedor.
- Variante de spam/política: Postmaster Tools, tasa de spam por debajo del 0,10% (el techo de requisito estricto de Google es el 0,30%), higiene de lista, baja en un clic de RFC 8058.
- Reenvíe una prueba a un buzón de Gmail y vuelva a analizar — confirme que el rebote ha desaparecido y que la calificación lo refleja.
El rebote menciona su política DMARC — por qué eso es su política funcionando
La referencia actual de Google codifica esta cadena como 550-5.7.26, pero los rebotes antiguos y la documentación de terceros aún la muestran bajo 5.7.1 — en cualquier caso la mecánica es idéntica. Parece al revés hasta que lo ve: Gmail comprobó un mensaje que decía venir de su dominio, encontró que ni SPF ni DKIM pasaron con alineación, consultó su registro DMARC e hizo exactamente lo que usted pidió — rechazar. Su valla aguantó. La pregunta es qué quedó atrapado en ella: un remitente legítimo olvidado (un CRM, una herramienta de facturación, una plataforma de boletines) o una suplantación real.
Así que no relaje la política como primer paso. Encuentre la fuente no autenticada. Dos trampas explican la mayoría de los casos:
- SPF pasa, pero sobre el dominio equivocado. Los receptores evalúan SPF contra el dominio del Return-Path (RFC5321.MailFrom), no contra la cabecera From. Una herramienta SaaS que envía “de su parte” suele pasar SPF sobre su propio dominio de rebote, que no se alinea con su dominio From — así que DMARC sigue fallando. Recorrido completo: DMARC falla pero SPF y DKIM pasan.
- DKIM pasa, pero con la firma por defecto. Los valores por defecto
gappssmtp.comde Google Workspace yonmicrosoft.comde Microsoft se verifican sin problema y no se alinean con nada. Vea DKIM pasa pero DMARC sigue fallando.
Esta variante es más rara de lo que pensaría: 27.640.987 de 261.086.232 dominios — el 10,59% — aplican una política DMARC de quarantine o reject, según el censo de Defaults.Exposed (2026-06-29). El otro 89,41% nunca ve este rebote porque no tiene valla que aguante. Arreglar la fuente, no la política, se cubre de principio a fin en la guía de corrección de DMARC.
El rebote menciona las directrices de envío IPv6 — la corrección del DNS inverso
Los servidores modernos suelen conectarse a Gmail por IPv6 de forma predeterminada, y Google exige que la dirección IPv6 que conecta tenga un registro PTR que resuelva a un nombre de host que a su vez resuelva de vuelta a la misma dirección (DNS inverso confirmado hacia delante). Si falta, cada mensaje recibe 550-5.7.1 por muy limpio que esté su SPF.
Tres correcciones, en orden de preferencia:
- Configure el registro PTR para la dirección IPv6 de su servidor — se hace donde vive la IP (el panel de control de su proveedor de VPS o de su ISP, no la zona DNS de su dominio), con un registro AAAA coincidente que apunte de vuelta.
- Retransmita a través del smarthost de su proveedor. Si no puede controlar el rDNS, encamine el correo saliente por el relé de su proveedor de correo o de su ISP, que ya tiene un rDNS correcto.
- Prefiera el transporte IPv4 como parche provisional. Suele ocultar el síntoma porque su dirección IPv4 tiene PTR — un apaño, no una solución. Configure el PTR de IPv6 en cuanto pueda.
El rebote dice “likely unsolicited email” — la ruta de la reputación
Aquí la autenticación puede estar bien, pero los filtros de Gmail no confían en el correo. La autenticación es el suelo, no el techo — entre los 12.145.313 dominios que autorizan _spf.google.com, solo el 8,0% cierra SPF con un -all estricto, así que una comprobación superada dice poco por sí sola. (Comparación completa: qué proveedor de correo ofrece los valores SPF por defecto más sólidos.)
La lista de comprobación de reputación:
- Regístrese en Google Postmaster Tools y vigile el panel de tasa de spam — manténgala por debajo del 0,10%, y nunca deje que alcance el techo del 0,30% que las directrices de Google para remitentes masivos fijan como requisito estricto.
- Depure su lista. Elimine a quienes no interactúan y todo lo comprado o extraído de la web; envíe solo a quien lo pidió.
- Implemente la baja en un clic de RFC 8058 en el correo masivo — exigida por las reglas de Google, y cada baja que no es un clic en “spam” protege su tasa.
- Mantenga la autenticación alineada (SPF y DKIM sobre su propio dominio) para que la reputación se acumule en un dominio que usted controla.
Preguntas frecuentes
¿Es lo mismo 550-5.7.1 que 550-5.7.26? No. El 550-5.7.26 es la familia de requisitos de autenticación de Gmail (SPF/DKIM ausente o fallando) — y la referencia actual de Google también archiva ahí el rechazo por política DMARC. El 550-5.7.1 es la familia de política más antigua: bloqueos por política del destinatario y del remitente, IPv6 sin PTR, bloqueos por spam y reputación. El texto del rebote, no el número, le dice qué solución aplica (a fecha de 2026-06-29 y según las directrices vigentes de Google).
¿Debería volver a poner mi política DMARC en p=none para detener los rebotes? Eso los detiene derribando la valla. Solo el 10,59% de los 261.086.232 dominios del censo de Defaults.Exposed (2026-06-29) aplica DMARC siquiera; si usted es uno de ellos, consérvela y arregle la fuente no autenticada — relajar la política reabre la suplantación exacta de su dominio.
¿Por qué Gmail bloquea mi correo si mi registro SPF pasa todos los verificadores? Los verificadores prueban el registro; Gmail prueba el mensaje. SPF se evalúa contra el dominio del Return-Path, no contra la dirección From visible, así que un pass sobre el dominio de rebote de un proveedor no hace nada por su alineación DMARC — y los bloqueos por reputación ignoran SPF por completo. El análisis gratuito muestra qué capa falla realmente.
¿550-5.7.1 significa que mi IP está en una lista negra? No necesariamente. Gmail gestiona su propio sistema de reputación; puede estar bloqueado por Google sin figurar en ninguna lista de bloqueo pública. Consulte Postmaster Tools para ver la perspectiva de Google — y tenga en cuenta que arreglar la autenticación evita daños futuros pero por sí solo no restablece una mala reputación de envío.
Envíe el informe al propietario
Una vez arreglado el rebote, repita el análisis y reenvíe el informe calificado al propietario del negocio o al cliente cuyo correo rebotaba. Muestra, en lenguaje claro, qué estaba roto, qué arregló usted y dónde queda ahora el dominio frente a la línea base de 261 millones de dominios — exactamente lo que necesitan para la renovación del seguro o el cuestionario de seguridad de un cliente que pregunta “¿autentica usted su correo?”. Un rebote arreglado en silencio es trabajo invisible; un informe de antes y después es una prueba.
Compruebe su dominio → · Gmail 550-5.7.26 — la solución en orden de requisitos → · Arreglar DMARC → · Cómo calificamos → · Solo datos agregados. Datos almacenados y procesados en la UE.