Cómo corregir el error 550 5.7.515 — Autenticación de correo electrónico vía Google Workspace
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
:::error 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
:::info 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.
:::
:::info 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 |
:::error 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...
:::warning ¿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
:::info 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
:::warning 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
:::error 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.
:::warning 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>;
:::success 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.
:::
:::warning 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
- Set up DKIM — Google Workspace Admin Help
- Turn on DKIM for your domain — Google Workspace Admin Help
- Set up SPF — Google Workspace Admin Help
- Define your SPF record — Google Workspace Admin Help
- Add your DMARC record — Google Workspace Admin Help
- Recommended DMARC rollout — Google Workspace Admin Help
- Email sender guidelines — Google Workspace Admin Help
- Microsoft: Corregir el error NDR 550 5.7.515 — Outlook.com
Observaciones
- Para conectar una casilla de Gmail a Cloud Chat: Cómo conectar una casilla de correo de Google a Cloud Chat
- Para conectar una casilla de Outlook a Cloud Chat: Cómo conectar una casilla de correo Outlook/Microsoft a Cloud
Chat
- Para entender cómo funcionan los adjuntos de correo: Cómo funcionan los adjuntos por correo electrónico en Cloud
Chat
