Error 550 5.7.26 de Gmail: causas y solución

Gmail responde con 550-5.7.26 cuando un mensaje llega sin una autenticación que pueda vincular con el dominio de tu dirección de remitente (From): o no pasó ni SPF ni DKIM, o pasaron para un dominio ajeno y tu política DMARC le indicó a Gmail que rechazara el correo. La solución casi nunca es «añadir otro include al SPF»; consiste en que DKIM firme con tu propio dominio y en que el remitente del sobre (Return-Path) también esté en tu dominio, para que al menos uno de los dos quede alineado con el From.

¿Qué significa el error 550-5.7.26 de Gmail?

Es un rechazo permanente (el 5 inicial) del correo que Gmail considera no autenticado. La referencia de códigos de error SMTP de Google recoge tres textos distintos bajo 5.7.26, y la frase exacta de tu rebote te dice cuál de las comprobaciones falló.

El guion de 550- no es otro código. Los servidores SMTP envían las respuestas de varias líneas con 550- en todas las líneas menos la última, que lleva 550 con espacio, así que el mismo error aparece como «550-5.7.26» o como «550 5.7.26» según de dónde lo copies.

Actualizado a noviembre de 2026, textos de la referencia de errores SMTP de Google.

Por qué lo ves cada vez más: las directrices de Gmail para remitentes exigen desde el 1 de febrero de 2024 que todos los remitentes usen SPF o DKIM, y que los remitentes masivos (más de 5.000 mensajes al día a Gmail) usen SPF, DKIM y DMARC con el dominio From alineado. Las preguntas frecuentes de esas directrices indican que desde noviembre de 2025 Gmail intensifica la aplicación sobre el tráfico que no cumple, con rechazos temporales y permanentes. El correo que antes acababa en spam ahora rebota.

Lo básico de cada registro lo explica nuestro artículo qué son SPF, DKIM y DMARC. Aquí nos centramos en este rebote concreto y en cómo eliminarlo.

¿Cómo se lee Authentication-Results en «Mostrar original»?

Envía un mensaje a una dirección de Gmail que controles, ábrelo, elige Más → Mostrar original y busca la cabecera Authentication-Results: mx.google.com. Registra tres veredictos y, lo más importante, los tres dominios a los que se refiere cada uno.

Si el mensaje rebotó y no llegó, el propio rebote suele citar esos resultados. Si no, cambia temporalmente tu DMARC a p=none para que el mensaje se entregue y puedas examinarlo.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@relay.example.net header.s=s1 header.b=Ab12Cd34;
       spf=pass (google.com: domain of bounces+8812@mail.relay.example.net designates 203.0.113.25 as permitted sender) smtp.mailfrom="bounces+8812@mail.relay.example.net";
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=example.com

Es el caso típico del 550-5.7.26: SPF y DKIM dicen pass y, aun así, DMARC falla. Lee los dominios, no los veredictos:

DMARC pasa cuando al menos uno de SPF y DKIM pasa y su dominio está alineado con header.from. Aquí ninguno lo está, así que dmarc=fail, y como example.com publica p=reject, el resultado es dis=REJECT: el rebote.

💡 Consejo: Un mensaje puede llevar varias firmas DKIM. Basta con una alineada, así que antes de cambiar nada busca un dkim=pass cuyo header.i termine en tu propio dominio.

¿Por qué el correo enviado por un relay no pasa DMARC?

Porque, de serie, la mayoría de los relays firman con su propio dominio y usan su propio dominio de rebotes, de modo que ambas comprobaciones pasan para el relay y no para ti. La alineación solo aparece cuando le das tu dominio para al menos una de las dos.

La especificación actual de DMARC, RFC 9989 (mayo de 2026, sustituye al RFC 7489), define dos modos. La alineación relajada, la predeterminada, acepta cualquier dominio con el mismo dominio organizativo, así que bounce.example.com se alinea con example.com. La alineación estricta (aspf=s o adkim=s) exige coincidencia exacta. RFC 9989 determina el dominio organizativo recorriendo el árbol DNS en lugar de usar la Public Suffix List; para dominios normales el resultado es el mismo.

Actualizado a noviembre de 2026, reglas de alineación del RFC 9989.

Apunta a la penúltima fila. La alineación DKIM sobrevive a los reenvíos mejor que SPF (las secciones siguientes explican por qué), y la alineación SPF te da una segunda vía cuando una pasarela que reescribe el cuerpo rompe la firma DKIM.

Otras causas habituales del mismo fallo:

• Un servicio nuevo que nadie configuró. Un CRM, un helpdesk o un programa de facturación envía como @example.es con sus valores por defecto. Cada servicio que use tu dominio From necesita el mismo tratamiento, también los buzones de Arsys, IONOS o Hostinger si envías desde ellos el correo de la empresa.
• Un dominio From que no es del remitente. Enviar como @gmail.com o @hotmail.com a través de tu propio servidor nunca puede alinearse.
• Una alineación estricta innecesaria. adkim=s; aspf=s falla cuando un relay firma con mail.example.com y el From es example.com.
• Una clave DKIM rota. Un registro TXT mal dividido en cadenas, una clave que el panel DNS recortó o un selector que el relay rotó: dkim=fail o dkim=neutral (body hash did not verify).

¿Cómo se soluciona el 550-5.7.26 paso a paso?

Haz que DKIM firme con tu dominio, da tu dominio al remitente del sobre donde el relay lo permita, mantén SPF válido para el dominio del sobre y publica DMARC. Sigue los pasos en este orden; cada uno se puede probar por separado.

1. Haz una lista de todo lo que envía como tu dominio

   El relay de tu plataforma de email marketing, tu proveedor de correo (Google Workspace, Microsoft 365, IONOS, Arsys), el correo transaccional de tu aplicación, el CRM, el helpdesk, la facturación. Los informes agregados de DMARC (paso 5) te mostrarán lo que olvides.

2. Activa DKIM con tu propio dominio en cada relay

   Cada relay te da o bien registros CNAME que apuntan a claves que él rota, o bien un registro TXT con una clave pública. Publica exactamente lo que muestra y verifícalo en su consola. Google recomienda claves de 2048 bits si el proveedor las admite (directrices para remitentes).

3. Configura un dominio MAIL FROM (Return-Path) propio

   La mayoría de los relays permiten usar un subdominio como bounce.example.com como remitente del sobre. Piden un registro MX (para que los rebotes les sigan llegando) y un registro TXT de SPF en ese subdominio.

4. Corrige el SPF del dominio del sobre

   Un solo registro SPF por nombre, terminado en ~all o -all, con un máximo de 10 mecanismos que generen consultas DNS (include, a, mx, ptr, exists, redirect), según el RFC 7208, sección 4.6.4. Dos registros SPF en el mismo nombre dan permerror, que cuenta como fallo.

5. Publica DMARC, empezando por p=none

   Un registro TXT en _dmarc.example.com con una dirección para informes. Pasa a quarantine y reject solo cuando los informes muestren alineadas todas las fuentes legítimas.

6. Vuelve a probar

   Envía un mensaje a un buzón de prueba de Gmail y confirma dmarc=pass antes de volver a enviar a suscriptores reales.

Registros de ejemplo para un dominio que envía el correo del equipo por Google Workspace y los newsletters por Amazon SES (cambia los tokens, la región y la dirección de informes por los tuyos):

; SPF del dominio From (correo del equipo por Google Workspace)
example.com.                      TXT   "v=spf1 include:_spf.google.com ~all"

; Subdominio MAIL FROM propio para Amazon SES
bounce.example.com.               MX    10 feedback-smtp.eu-west-3.amazonses.com.
bounce.example.com.               TXT   "v=spf1 include:amazonses.com ~all"

; Easy DKIM: tres CNAME de la consola de SES (se muestra uno)
abc123token._domainkey.example.com. CNAME abc123token.dkim.amazonses.com.

; DMARC, primero solo supervisión
_dmarc.example.com.               TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Los detalles de SES (sandbox, regiones, credenciales SMTP) están en nuestra guía de Amazon SES como relay SMTP. Otros relays llaman a lo mismo de otra forma: «custom return path», «bounce domain», «branded sending domain» o «domain authentication».

⚠️ Atención: No saltes directamente a p=reject para «cumplir». La norma de Gmail para remitentes masivos acepta p=none; una política estricta publicada antes de alinear todas las fuentes es justo lo que provoca el 550-5.7.26 en tu propio correo legítimo.

El proceso completo para endurecer DMARC, calentar la IP y supervisar está en la guía de entregabilidad para remitentes autoalojados (en inglés).

¿Por qué rebotan los reenvíos y las listas de correo?

Un reenvío manda tu mensaje desde una IP nueva que no está en tu SPF, así que SPF falla; las listas de correo suelen cambiar el asunto o añadir un pie, lo que rompe tu firma DKIM. Sin ninguno de los dos, una política DMARC estricta rechaza la copia reenviada.

Las buenas prácticas de Google para reenviar correo a Gmail dicen que los mensajes reenviados suelen fallar SPF y que Gmail vuelve a comprobar la autenticación por su cuenta. Por eso importa más DKIM alineado que SPF: un mensaje sin modificar conserva una firma válida tras el reenvío.

ARC (Authenticated Received Chain, RFC 8617, un RFC experimental) permite que cada intermediario registre los resultados de autenticación que vio y los selle con su propia firma. Un receptor que confíe en ese intermediario puede usar esos resultados cuando las comprobaciones originales ya no pasan. ARC lo añaden los reenviadores y los servidores de listas, no tú como remitente original, y cada receptor decide si confía en un sello concreto.

• Si tu correo rebota tras un reenvío: asegúrate de que DKIM está alineado y de que nada modifica el mensaje después de firmarlo (algunas pasarelas de seguimiento de enlaces o de pies de página lo hacen).
• Si gestionas el reenvío o la lista: sigue el consejo de Google de reescribir el remitente del sobre con tu dominio de reenvío, mantén SPF y DKIM para ese dominio y evita cambios que rompan DKIM. El software de listas suele sustituir el From por la dirección de la lista cuando el remitente tiene una política DMARC estricta.
• Si es el reenvío privado de un suscriptor: no puedes arreglar su configuración; un rebote aislado de una dirección así no significa que tu autenticación esté rota.

¿Cómo compruebas que la solución funciona?

Comprueba el DNS desde fuera, envía un mensaje a un buzón de prueba de Gmail, lee Authentication-Results y luego sigue Postmaster Tools durante al menos una semana.

# 1. Los registros tal como los ve el mundo (un solo registro SPF)
dig +short TXT example.com | grep spf1
dig +short TXT bounce.example.com
dig +short TXT _dmarc.example.com
dig +short CNAME abc123token._domainkey.example.com

# 2. Una prueba por el mismo relay y puerto que usa tu plataforma (swaks)
swaks --to tu@gmail.com --from newsletter@example.com \
      --server email-smtp.eu-west-3.amazonaws.com --port 587 --tls \
      --auth LOGIN --auth-user "$SMTP_USER" --auth-password "$SMTP_PASS" \
      --header "Subject: Prueba de alineacion DMARC"

Un resultado correcto se ve así, con tu dominio en los tres sitios:

dkim=pass header.i=@example.com header.s=abc123token
spf=pass (google.com: domain of 0102018f-test@bounce.example.com designates 203.0.113.40 as permitted sender) smtp.mailfrom=bounce.example.com
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

El panel de estado de cumplimiento de Google Postmaster Tools muestra si tu dominio cumple las directrices (SPF, DKIM y, para remitentes masivos, DMARC y la baja con un clic). Google advierte de que los datos son una media móvil de varios días y aconseja volver a mirar a los 7 días, así que no esperes verlo en verde una hora después de corregir el DNS. La baja con un clic es un requisito aparte; consulta nuestra guía sobre el RFC 8058.

¿Y si nunca enviaste el mensaje que rebotó?

Entonces otra persona puso tu dominio en la dirección De, y Gmail hizo exactamente lo que pide tu política DMARC. Un rebote de un mensaje que no enviaste se llama backscatter: el servidor del falsificador entregó el rechazo al Return-Path falsificado, que puede ser tuyo.

Revisa las cabeceras citadas en el rebote. Una IP que no pertenece a ninguno de tus proveedores, un formato de Message-ID que tus sistemas no usan o un asunto que nunca escribiste apuntan a suplantación. Tus informes agregados de DMARC muestran lo mismo a gran escala: fuentes con tu header.from que no pasan ni SPF ni DKIM.

• No relajes DMARC para que paren los rebotes; p=reject es lo que protege a tus destinatarios del correo falsificado.
• Filtra o descarta los rebotes dirigidos a direcciones que nunca usas como Return-Path.
• Si los rebotes señalan a un remitente real tuyo que habías olvidado, eso es el paso 1 de la solución, no una suplantación.

Los rebotes persistentes de correo legítimo son otro tema: la diferencia entre rebotes duros y blandos y cómo suprimir direcciones lo explica nuestra guía de gestión de rebotes.

Solucionar el 550-5.7.26 al enviar desde NetSendo

NetSendo envía a través del buzón que conectes (un relay SMTP como Amazon SES o Mailgun, la API de Gmail, SendGrid o NMI, la NetSendo Mail Infrastructure), así que la autenticación se configura en ese proveedor y en tu DNS. NetSendo no publica ningún include de SPF propio.

• Quién firma DKIM: en los buzones SMTP, SendGrid y Gmail firma el proveedor, no NetSendo; activa allí DKIM con tu dominio. NMI genera claves DKIM de 2048 bits y muestra los registros DNS para copiarlos.
• Return-Path: desde NetSendo 2.2.0, la dirección de rebotes del buzón que envía se fija como remitente del sobre en cada envío por buzones SMTP y Gmail, no solo en las automatizaciones. Con un buzón de rebotes en tu dominio, SPF se comprueba para ese dominio, así que su registro SPF debe autorizar al relay. La API de SendGrid fija su propio remitente del sobre; usa allí la autenticación de dominio de SendGrid. Algunos relays sustituyen el remitente del sobre por su propio dominio de rebotes; revisa su opción de MAIL FROM propio.
• Comprobaciones en NetSendo: Deliverability Shield, incluido en la licencia GOLD, revisa periódicamente SPF, DKIM y DMARC de los dominios verificados. Desde la 2.8.0 puedes indicar el selector DKIM de relays como Amazon SES que usan tokens por dominio, y el generador de DMARC empieza por p=none con alineación relajada. Los registros DNS funcionan con cualquier licencia, también con la licencia gratuita SILVER.

Los buzones, las opciones de envío y NMI se describen en la documentación de configuración; instalar NetSendo son unos pocos comandos del inicio rápido.

Preguntas frecuentes

Fuentes

• Google Workspace: Gmail SMTP errors and codes
• Google: Email sender guidelines
• Google: Email sender guidelines FAQ
• Google: Postmaster Tools dashboards
• Gmail Help: Best practices for forwarding email to Gmail
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 7208: Sender Policy Framework (SPF)
• RFC 8617: Authenticated Received Chain (ARC)