Qué te está diciendo el 550 5.7.26
Imagina un despacho contable de 12 personas que manda cotizaciones y facturas desde su propio dominio. Un martes la persona de administración empieza a recibir de vuelta todos los correos dirigidos a clientes con cuenta de Gmail, y en medio del texto devuelto aparece 550-5.7.26. Esa semana nadie cambió la forma de enviar. Lo que cambió fue una edición de DNS dos semanas antes, o una herramienta de facturación que alguien activó sin avisar.
Ese código significa que Gmail no pudo ligar el mensaje con el dominio que aparece en el remitente visible. Es un veredicto de autenticación, no una opinión sobre tu contenido ni sobre tu historial de envío. Gmail no evaluó el mensaje y lo rechazó por su calidad; se negó a evaluarlo.
Después del código aparecen dos redacciones distintas, y cada una apunta a una solución diferente:
- "Unauthenticated email from tudominio.com is not accepted due to domain's DMARC policy." Tu dominio publica una política DMARC que pide rechazar el correo no autenticado, el mensaje no pasó DMARC y Gmail hizo exactamente lo que le pediste. La política no es el error. Algo en tus envíos dejó de cumplirla.
- "This mail has been blocked because the sender is unauthenticated." No pasó nada. Las directrices de remitentes de Google exigen que todo remitente tenga SPF o DKIM configurado, y este es el resultado cuando ninguno de los dos cumple su trabajo.
Los dos son rechazos permanentes. El mensaje se perdió, no quedó en cola para reintentar, y el destinatario nunca lo vio. Eso pesa con cotizaciones y facturas, porque quien envía suele interpretar el silencio como un cliente lento y no como un rebote.
En qué se diferencia del 550 5.7.1
Estos dos se confunden todo el tiempo, y la confusión cuesta semanas. El 550 5.7.1 con mensaje de reputación baja es un juicio de reputación: Gmail sabe quién eres, ha visto cómo envías y el patrón no le gusta. Ahí la solución es lenta y de comportamiento, medida en semanas de envío limpio.
El 5.7.26 es binario. O el mensaje se autentica o no. No hay calentamiento, ni limpieza de listas, ni recuperación gradual. Publicas los registros correctos, logras que un mensaje de prueba pase, y el siguiente envío entra.
La prueba rápida que usamos: si los rebotes se detienen en cuanto un registro de DNS queda correcto, era autenticación. Si siguen después de que la autenticación pasa de forma comprobable, es reputación. Aplicar un plan de calentamiento a un rebote 5.7.26 es tratar la enfermedad equivocada.
La regla de alineación que Gmail aplica
Aquí vive la mayoría de los casos de 5.7.26, y es la parte que sorprende a quien ya tiene un registro SPF.
DMARC no pregunta si SPF pasó. Pregunta si lo que pasó pertenece al dominio que ve tu destinatario. Son dos verificaciones y basta con que una tenga éxito:
- Alineación de SPF. El dominio del remitente de sobre, la ruta de retorno, tiene que coincidir con el dominio del encabezado From.
- Alineación de DKIM. El dominio de la etiqueta
d=de la firma tiene que coincidir con el dominio del encabezado From.
El RFC 7489 define dos modos para cada una, que se ajustan con las etiquetas aspf y adkim de tu registro DMARC. El modo relajado, que es el predeterminado si no pones las etiquetas, acepta la coincidencia a nivel de dominio organizacional, así que mail.ejemplo.com alinea con ejemplo.com. El estricto exige coincidencia exacta. La guía de resolución de problemas de DMARC de Google dice lo mismo en términos más simples: para pasar DMARC, los mensajes salientes deben pasar SPF o DKIM, y una configuración de alineación estricta aumenta la probabilidad de que los mensajes sean rechazados o enviados a spam.
La falla típica se ve así. Una plataforma de facturación envía en tu nombre. El encabezado From dice facturacion@ejemplo.com. SPF pasa, porque la plataforma autoriza su propio dominio de envío en su propio registro. DKIM pasa, porque la plataforma firma con d=proveedorfactura.net. Las dos verificaciones están en verde y DMARC falla igual, porque ninguno de esos verdes pertenece a ejemplo.com. Publica una política de rechazo encima de eso y cada factura enviada a una cuenta de Gmail se detiene.
Diagnosticarlo en diez minutos
Lo que revisamos primero en un proyecto de cliente, en este orden:
- Lee el rebote completo, no el resumen. Anota el dominio exacto que Gmail nombra. Casi nunca es el dominio desde el que el cliente cree que envía, y ese dato suele cerrar la investigación.
- Haz inventario de todo lo que envía como tú. Los buzones de Workspace o Microsoft 365, el CRM, el proveedor de facturación electrónica, la tienda en línea, la herramienta de boletines, la mesa de ayuda, el escáner del pasillo. Cada uno es un problema de autenticación aparte.
- Manda un mensaje de prueba a una cuenta de Gmail que controles desde cada sistema, ábrelo, elige Mostrar original y lee el encabezado Authentication-Results.
Ese encabezado es toda la respuesta. No busques las palabras pass y fail por sí solas. Fíjate en qué dominio pasó. Un spf=pass junto a un dominio de sobre que pertenece a un proveedor, o un dkim=pass cuyo d= no es el tuyo, es una falla disfrazada de éxito.
Después consulta tu propio registro DMARC y anota la política. Un dominio en p=none no produce la variante del rebote que menciona DMARC, lo cual te dice de inmediato que estás en el segundo caso: no hay ninguna autenticación que pase.
Cómo se arregla en Google Workspace
Tres cosas, y la segunda es la que casi siempre falta.
Primero, un solo registro SPF. Un dominio con dos registros TXT que empiezan con v=spf1 falla SPF de entrada. Para un dominio que envía únicamente por Workspace:
ejemplo.com. TXT "v=spf1 include:_spf.google.com ~all"Segundo, DKIM, que no viene activado. Hay que generarlo y publicarlo por dominio desde la consola de administración, en la configuración de autenticación de Gmail. El prefijo de selector predeterminado de Google es google, así que el registro queda en google._domainkey, y conviene elegir la llave de 2048 bits si tu proveedor de DNS la admite:
google._domainkey.ejemplo.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."Publica el registro primero y después presiona Iniciar autenticación en la consola. Google indica que la activación puede tardar hasta 48 horas, aunque en la práctica suele quedar lista en una hora. No te saltes ese botón: una llave publicada cuya autenticación nunca se inició no firma nada.
Tercero, el registro DMARC, en _dmarc:
_dmarc.ejemplo.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com"Si vienes saliendo de una tormenta de 5.7.26 causada por tu propia política, bajar a p=none detiene el sangrado apenas propague el DNS, y es lo honesto mientras reparas la alineación. Tómalo como una pausa, no como un destino. Nuestra guía de despliegue cubre cómo subir de nuevo.
Cómo se arregla en Microsoft 365
La misma idea con otra plomería. Microsoft 365 maneja DKIM automáticamente para el dominio onmicrosoft.com del inquilino, así que hasta que lo actives para tu dominio propio, el correo de ese dominio sale firmado con un d= que no es el del encabezado From. Las dos verificaciones pueden verse sanas mientras DMARC falla por alineación.
La solución es habilitar DKIM para el dominio propio, lo que implica dos registros CNAME en lugar de un TXT:
selector1._domainkey.ejemplo.com. CNAME selector1-ejemplo-com._domainkey.inquilino.onmicrosoft.com.
selector2._domainkey.ejemplo.com. CNAME selector2-ejemplo-com._domainkey.inquilino.onmicrosoft.com.Hay dos selectores para que Microsoft pueda rotar llaves sin cortar el servicio. No adivines los valores. Léelos en el portal, o desde PowerShell de Exchange Online con Get-DkimSigningConfig, que devuelve el Selector1CNAME y el Selector2CNAME exactos de tu inquilino, y luego activa la firma para el dominio. Nuestra lista de verificación de Microsoft 365 trae la secuencia completa.
Cómo se arregla con las herramientas que envían por ti
El CRM, el proveedor de facturación, la tienda, el boletín. Todos ponen tu dominio en el encabezado From y su propia infraestructura debajo, que es justo la trampa de alineación de arriba.
Agregar al proveedor a tu registro SPF no alcanza, y en realidad no es el punto. Lo que necesitas es la función de autenticación de dominio del proveedor, como sea que la llame: dominio de envío, dominio dedicado, remitente con marca. Esa función publica una llave DKIM bajo tu dominio para que su firma lleve d=ejemplo.com, y por lo general también mueve la ruta de retorno a tu dominio. Eso es lo que convierte el pass de ellos en tu pass.
Dos advertencias de campo. SPF tiene un límite de diez consultas DNS por el RFC 7208, y apilar includes de proveedores agota ese presupuesto más rápido de lo que la gente espera, lo que produce un PermError y otra familia de rebotes; revisa la guía del límite de consultas si tu registro ya está largo. Y las plataformas de marketing tienen cada una sus mañas, con un nombre distinto para el mismo ajuste en cada una.
Dónde entran los umbrales de envío masivo
Las directrices de remitentes de Google, vigentes desde febrero de 2024, definen dos niveles. Todo remitente, sin importar el volumen, necesita SPF o DKIM configurado, DNS directo e inverso válidos para el servidor de envío y una conexión TLS. Quien envía más de 5,000 mensajes al día a cuentas de Gmail carga con más: SPF y DKIM los dos, un registro DMARC en el dominio de envío que puede quedarse en p=none, alineación del encabezado From con el dominio de SPF o el de DKIM para el correo directo, mensajes con formato conforme al RFC 5322 y una tasa de spam en Postmaster Tools por debajo de 0.30 por ciento.
La trampa para las pymes es suponer que la línea de los 5,000 las protege. No las protege. El primer nivel aplica a una empresa de cinco personas que manda cuarenta correos al día, y es el nivel que produce la segunda redacción del 5.7.26. Si tu volumen anda cerca del umbral, apunta de una vez a los requisitos de envío masivo: la distancia entre los dos niveles es una semana de trabajo, no un proyecto.
Cómo ayuda Guanacos Tech
La mayoría de los casos de 5.7.26 que tomamos no son un registro roto. Son cuatro sistemas enviando como un mismo dominio, dos bien autenticados, uno que alguien agregó el año pasado y nadie recuerda, y una política DMARC publicada por quien se saltó la fase de reportes. Hacemos el inventario de remitentes, arreglamos la alineación sistema por sistema, verificamos cada uno con un mensaje real, y seguimos los reportes DMARC hasta que el dominio pueda aplicar su política sin riesgo. Si tienes un rebote en la mano y quieres que alguien lo lea bien, agenda una llamada, o empieza con el diagnóstico gratuito.
Fuentes
- Directrices para remitentes de correo - Ayuda de Gmail
- Preguntas frecuentes sobre las directrices para remitentes - Ayuda de Gmail
- Solucionar problemas de DMARC - Ayuda de Google Workspace
- Configurar DKIM - Ayuda de Google Workspace
- Definir el registro SPF - Ayuda de Google Workspace
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- Usar DKIM para el correo de tu dominio propio - Microsoft Learn