Inicio Otros Cómo corregir el error 550 5.7.515 — Autenticación de correo electrónico vía Google Workspace

Cómo corregir el error 550 5.7.515 — Autenticación de correo electrónico vía Google Workspace

Última actualización el Aug 03, 2026

Cuándo usarlo

  • Usas Google Workspace y los mensajes que envías desde Cloud Chat a destinatarios Microsoft (Outlook, Hotmail, Live, Microsoft 365) están siendo rechazados con el error 550 5.7.515
  • El envío directo desde Gmail funciona, pero desde Cloud Chat (o cualquier otra plataforma de terceros) falla
  • Necesitas configurar SPF, DKIM y DMARC alineados con tu dominio para cumplir los requisitos de Microsoft

Requisitos previos

  • Acceso de Súper Administrador a Google Workspace (admin.google.com)
  • Acceso al proveedor de DNS de tu dominio (Registro.br, Cloudflare, GoDaddy, AWS Route 53, etc.)
  • Gmail activado en el dominio desde hace al menos 24 a 72 horas antes de generar la clave DKIM
  • Casilla de correo conectada — ver Cómo conectar una casilla de correo de Google a Cloud Chat

Reemplaza SEUDOMINIO.COM.BR por tu dominio real a lo largo de todo este documento. Los ejemplos usan ese marcador solo como ilustración.

Sobre este artículo

Este error no es una debilidad de Cloud Chat: lo mismo ocurriría con cualquier plataforma de atención que envíe correos en nombre de tu dominio.

Cuando envías directamente desde Gmail, el mensaje sale de los servidores de Google, que ya están autorizados en el SPF y firman el DKIM con tu dominio automáticamente. Todo pasa.

Cuando el correo sale por Cloud Chat (o cualquier plataforma de terceros), parte de servidores distintos, que no están en el SPF de tu dominio y no tienen acceso a su clave DKIM. Resultado: el SPF falla, el DKIM no alinea, el DMARC no pasa y Microsoft rechaza el mensaje con 550 5.7.515:

550 5.7.515 Access denied, sending domain SEUDOMINIO.COM.BR doesn't meet
the required authentication level. The sender's domain in the 5322.From
address doesn't meet the authentication requirements defined for the
sender. Spf=Fail , Dkim=Pass , DMARC=None

La causa raíz: el dominio no tiene SPF, DKIM y DMARC debidamente configurados. El envío directo por Gmail "esconde" el problema porque Google se encarga de eso automáticamente para sus propios servidores. Cualquier envío externo deja la falta a la vista.

Esta guía corrige esa configuración en Google Workspace y en tu proveedor de DNS. Una vez aplicada, la autenticación pasa tanto por Gmail como por Cloud Chat.

Diagnóstico

Microsoft rechaza tus mensajes porque falta autenticación alineada con el dominio del encabezado From:. El encabezado del rebote suele mostrar:

  • SPF = Fail — el registro SPF no incluye _spf.google.com, o no existe

  • DKIM = Pass, pero sin alineación — Google firma con d=gmail.com en lugar de d=<tu-dominio>. Pasa técnicamente, pero no cuenta para el DMARC

  • DMARC = None — no hay ningún registro DMARC publicado

Desde finales de 2024, Microsoft exige al menos un mecanismo de autenticación alineado con el From: para remitentes de alto volumen (≥ 5.000 mensajes a outlook.com, hotmail.com, live.com, msn.com). Si ya estás recibiendo este error, tu dominio superó ese umbral.

Sobre la alineación: para que el DMARC pase, basta con que el SPF o el DKIM esté alineado. Esta guía configura ambos para mayor confiabilidad, pero el DKIM alineado (Etapa 2) es el componente principal.

Inspeccionar el encabezado de un mensaje rebotado

Antes de tocar el DNS, confirma el estado actual. Ubica un mensaje rebotado con el código 550 5.7.515, ábrelo en Gmail y haz clic en Mostrar original. Busca la línea Authentication-Results:

Authentication-Results: ...
  spf=fail (sender IP is ...) smtp.mailfrom=<seu-dominio>;
  dkim=pass header.d=gmail.com;       ← d=gmail.com = SIN alineación
  dmarc=none action=none header.from=<seu-dominio>;

Si el patrón es ese, sigue esta guía. Si es distinto (por ejemplo, SPF pass, DMARC quarantine), la investigación debe seguir otro camino: abre un ticket de soporte.

Paso a paso

Etapa 1 — Publicar el registro SPF

En tu proveedor de DNS, publica (o actualiza) un registro TXT en el ápice del dominio:

Campo Valor
Tipo TXT
Host / Nombre @ (o el propio dominio)
Valor v=spf1 include:_spf.google.com ~all
TTL 3600

Solo puede existir un único registro SPF por dominio. Si ya hay uno, edítalo y fusiona los includes:

v=spf1 include:_spf.google.com include:outro-servico.com ~all

Verificación:

dig TXT <seu-dominio> +short
# Debe devolver una línea que contenga v=spf1 include:_spf.google.com ~all

Etapa 2 — Configurar el DKIM en Google Workspace (paso principal)

Este es el paso más importante. Hace que Google firme tus mensajes con d=<tu-dominio> en lugar de d=gmail.com, resolviendo el problema de alineación.

2.1 — Generar la clave DKIM

  1. Ingresa a admin.google.com como Súper Administrador

  2. Ve a Menú → Apps → Google Workspace → Gmail → Autenticar correo electrónico

  3. Selecciona tu dominio y haz clic en Generar registro nuevo

  4. Configura: 2048 bits, prefijo del selector: google

  5. Copia los dos valores que aparecen:

    • Nombre de host DNS: google._domainkey

    • Valor TXT: un texto largo que empieza con v=DKIM1; k=rsa; p=MIIBIjAN...

¿Botón deshabilitado? Espera de 24 a 72 h desde la activación de Gmail en el dominio.

2.2 — Publicar el registro DKIM en el DNS

Campo Valor
Tipo TXT
Host / Nombre google._domainkey
Valor Texto copiado de la consola de administración
TTL 3600

2.2.1 — Error CharacterStringTooLong al publicar el DKIM

Síntoma

Al publicar el registro TXT google._domainkey, el proveedor muestra un error similar a:

⚠️ Se produjo un error. Inténtalo de nuevo más tarde. CharacterStringTooLong (Value is too long) encountered with '"v=DKIM1; k=rsa; p=XXXXXXXX..."'

El registro no se guarda y la autenticación DKIM no se puede activar.

Causa

La RFC 1035 (sección 3.3) limita cada character-string de un registro TXT a 255 caracteres. La clave pública RSA de 2048 bits generada por Google Workspace supera ese límite (≈400 caracteres), por lo que el proveedor la rechaza cuando el valor se envía como una sola cadena. No es un problema de la clave ni de Google Workspace: es una limitación del protocolo DNS.

Solución

Divide el valor en varias cadenas de hasta 255 caracteres, cada una entre comillas dobles y separadas por un espacio. El servidor DNS las concatena automáticamente al entregarlas, y el resolver ve una única clave DKIM continua.

Formato esperado:

"v=DKIM1; k=rsa; p=XXXXXXXXXXXXXXXXXXXXXXXXXXXX...ate_255_chars" "continuacao_ate_255_chars..." "parte_final_da_chave"

Cómo dividir la clave

  1. Pega el valor copiado de la consola de administración (v=DKIM1; k=rsa; p=...) en un editor de texto

  2. Cada 255 caracteres de contenido, inserta " " (comillas — espacio — comillas)

  3. Envuelve el valor completo con comillas dobles al inicio y al final

  4. Pega el resultado en el campo Valor / Content del registro TXT

Consejo: No cuentes las comillas externas dentro del límite de 255, solo el contenido de la cadena.

Comportamiento por proveedor de DNS:

Proveedor Cómo pegarlo
Cloudflare Pega el valor ya dividido con comillas y espacios en el campo Content. La interfaz lo acepta directamente.
AWS Route 53 Pega las cadenas divididas con comillas en el campo Value. Cada cadena en una línea separada también funciona.
Registro.br Formato de múltiples cadenas entre comillas en una sola línea.
GoDaddy / HostGator / otros Aceptan el mismo formato. Si la interfaz rechaza las comillas, busca la opción raw o advanced.

Verificación

Después de guardar y esperar la propagación (hasta 30 minutos), valida:

dig TXT google._domainkey.<seu-dominio> +short

La salida debe mostrar la clave concatenada. Si la respuesta muestra varias cadenas separadas, sigue siendo válida: lo que importa es que la clave RSA reconstruida sea idéntica al valor de la consola de administración. Para confirmarlo, compara la clave devuelta por dig con la del paso de generación en Google Workspace.

2.3 — Activar la autenticación

  1. Vuelve a Gmail → Autenticar correo electrónico en la consola de administración

  2. Haz clic en Iniciar autenticación

  3. Espera a que el estado cambie a Autenticando correos con DKIM

Puede tardar hasta 48 horas en empezar a funcionar.

Verificación:

dig TXT google._domainkey.<seu-dominio> +short
# Debe devolver v=DKIM1; k=rsa; p=... completo

Etapa 3 — Publicar el registro DMARC

Publica el DMARC solo después de que el SPF y el DKIM estén autenticando correctamente durante al menos 48 horas.

Campo Valor
Tipo TXT
Host / Nombre _dmarc
Valor v=DMARC1; p=none; rua=mailto:dmarc-reports@<seu-dominio>; pct=100; adkim=s; aspf=s
TTL 3600

Crea una casilla o alias dmarc-reports@<seu-dominio> para recibir los informes agregados (XML) que los proveedores envían a diario.

Hoja de ruta de endurecimiento

Avanza de fase solo después de al menos una semana sin falsos positivos en los informes.

Fase Semana Política Efecto
1 — Monitoreo 0 p=none Solo genera informes
2 — Cuarentena parcial ≥ 1 p=quarantine; pct=10 El 10 % de los no autenticados va a spam
3 — Cuarentena total ≥ 2–3 p=quarantine; pct=100 Todos van a spam
4 — Rechazo ≥ 4 p=reject; pct=100 El servidor rechaza los mensajes no autenticados

Desbloqueo rápido (si es urgente)

Si necesitas destrabar el envío a destinatarios Microsoft de inmediato, publica solo:

  1. Etapa 1 — el registro SPF

  2. Etapa 3 — el registro DMARC con p=none (sin esperar las 48 h del DKIM)

En la mayoría de los casos, eso ya pone fin al 550 5.7.515, porque Microsoft apunta específicamente a dominios sin ningún DMARC. Tener un DMARC publicado (incluso permisivo) ya cambia el tratamiento.

La Etapa 2 (DKIM alineado) sigue siendo la corrección definitiva y debe ejecutarse a continuación: sin ella, el SPF y el DMARC quedan sobre una base frágil.

Verificación final

Después de la propagación (30 min para SPF/DMARC, hasta 48 h para DKIM):

dig TXT <seu-dominio> +short                          # SPF
dig TXT google._domainkey.<seu-dominio> +short        # DKIM
dig TXT _dmarc.<seu-dominio> +short                   # DMARC

Prueba funcional

Envía un correo de prueba a cualquier dirección @outlook.com, @hotmail.com o a una cuenta de Microsoft 365. En el encabezado del correo recibido, verifica:

Authentication-Results: ...
  spf=pass smtp.mailfrom=<seu-dominio>;
  dkim=pass header.d=<seu-dominio>;   ← prueba de la alineación
  dmarc=pass header.from=<seu-dominio>;

Si las tres líneas muestran pass con header.d=<seu-dominio> y header.from=<seu-dominio>, la configuración es correcta: el error 550 5.7.515 no volverá a ocurrir.

Si dkim=pass sigue apareciendo con header.d=gmail.com, la Etapa 2.3 todavía no se completó o el DNS sigue propagándose. Espera algunas horas más y prueba de nuevo.

Fuentes oficiales

Observaciones