Defaults.Exposed › Soluciones › Guides

Outlook rechaza su correo: 550 5.7.515, 550 5.7.509 y compauth=fail, explicados y resueltos (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. Consulte cómo calificamos.

Dos sistemas distintos de Microsoft rechazan correo. El Outlook.com de consumo rebota a los remitentes de alto volumen que fallan la autenticación (550 5.7.515, en vigor desde mayo de 2025); Exchange Online rebota el correo que falla su propia política DMARC de rechazo (550 5.7.509). De 10.205.070 dominios que autorizan spf.protection.outlook.com, el 85,0% tiene SPF estricto pero solo el 21,7% aplica DMARC, según el censo de Defaults.Exposed de 261.086.232 dominios.

La mayoría de los problemas de “Outlook está rechazando mi correo” no son rechazos en absoluto — es correo que aterriza silenciosamente en Correo no deseado con compauth=fail en las cabeceras. Esta guía descifra los códigos de Microsoft, le muestra cómo leer la cabecera Authentication-Results y recorre la solución en orden: confirmar SPF, habilitar DKIM para su dominio personalizado, publicar y aplicar DMARC, volver a probar.

¿Qué error de Microsoft tiene realmente?

Microsoft opera dos superficies de recepción separadas, y rechazan por motivos distintos. Identifique primero su síntoma — un diagnóstico equivocado desperdicia un día.

La redacción exacta de los NDR cambia; verifique las cadenas que cite contra un rebote real antes de confiar en ellas.

¿Qué significa 550 5.7.515?

Es el requisito del Outlook.com/Hotmail de consumo, no un error de tenant de Microsoft 365. Desde mayo de 2025, los remitentes de más de 5.000 mensajes al día a direcciones de Outlook de consumo deben pasar SPF, pasar DKIM y publicar un registro DMARC (al menos p=none) alineado con el dominio From. Si no supera ese listón, el Outlook de consumo rechaza con un texto como:

550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.

Dos cosas que esto no es: no es un mandato de 2026 (si su correo acaba de empezar a rebotar, cambió su volumen o su DNS, no la regla), y no tiene que ver con la configuración del tenant M365 del destinatario. La solución es la escalera de autenticación de abajo — y los días puntuales de campaña que superan los 5.000/día también cuentan.

¿Qué significa 550 5.7.509?

Este procede de Exchange Online Protection en tenants de empresa, y significa que se está haciendo cumplir su propia política DMARC:

550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.

Léalo con atención — no es Microsoft poniéndose difícil. Su dominio publica p=reject, este mensaje falló DMARC, y el receptor hizo exactamente lo que usted pidió. Si el correo rebotado es legítimo, alguna fuente de envío (una herramienta de boletines, un CRM, un dispositivo de escaneo a correo) no está autenticada de forma alineada. No debilite la política; dé a esa fuente SPF o DKIM alineados — consulte arreglar DMARC y de p=none a p=reject.

¿Por qué Outlook manda mi correo a spam con compauth=fail en lugar de rebotarlo?

La mayoría de los dolores de entregabilidad en Microsoft nunca produce un rebote. El mensaje se acepta, se puntúa y se archiva en Correo no deseado — la única evidencia es la cabecera Authentication-Results. En el buzón del destinatario (o en su propio buzón de prueba de outlook.com), abra el mensaje, elija Ver origen del mensaje y busque la línea:

Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001

compauth es el veredicto de autenticación compuesta de Microsoft: incluso cuando un dominio no publica registro DMARC, Microsoft aplica comprobaciones implícitas de tipo DMARC. Valores que se ven habitualmente:

• compauth=fail reason=000 — el mensaje falló la autenticación explícita: la política DMARC de su dominio es quarantine/reject y el mensaje la falló.
• compauth=fail reason=001 — el mensaje falló la autenticación implícita: su dominio no publica registros de autenticación (o no suficientes), y el mensaje no parecía venir de usted. La firma clásica de “nunca configuramos DKIM/DMARC”.
• compauth=fail reason=6xx — variantes de fallo de autenticación implícita; 601 significa específicamente que el dominio remitente es uno de los dominios aceptados de su propia organización (suplantación intraorganización, de sí mismo a sí mismo).

La lección: en Microsoft, lea la cabecera, no solo el NDR. Los veredictos spf=, dkim= y dmarc= de esa misma línea le dicen exactamente qué vía arreglar.

¿Cómo se arreglan los rechazos y el correo a spam de Outlook?

1. Ejecute primero el análisis gratuito. Califica su SPF, DKIM y DMARC en una sola pasada y muestra qué vía está fallando antes de tocar el DNS.
2. Confirme el SPF — normalmente ya está bien en Microsoft 365. El registro estándar es v=spf1 include:spf.protection.outlook.com -all, y la configuración de M365 lo deja ahí: el 85,0% de los 10.205.070 dominios que autorizan spf.protection.outlook.com ya termina en -all estricto (datos a fecha de 2026-06-29). Una salvaguarda: los sistemas receptores evalúan SPF contra el dominio del Return-Path (RFC5321.MailFrom), no contra la cabecera From — así que una herramienta de boletines puede pasar SPF en su dominio de rebote sin hacer nada por el suyo. Por eso importan más los pasos 3 y 4.
3. Habilite DKIM para su dominio personalizado — dos CNAME de selector. M365 firma con un valor predeterminado no alineado de onmicrosoft.com hasta que active la firma de dominio personalizado: publique los CNAME selector1._domainkey y selector2._domainkey apuntando a las claves de su tenant, y active después la firma en el portal de Defender. Ruta de clics completa: configurar DKIM en Microsoft 365. Si DKIM muestra “pass” pero DMARC sigue fallando, está en la trampa de la firma predeterminada.
4. Publique DMARC y después aplíquelo. Empiece con v=DMARC1; p=none; rua=mailto:... para recibir informes, corrija todas las fuentes legítimas que revele y suba después a p=quarantine y p=reject — el camino por etapas está en arreglar DMARC. Este es el paso que la mayoría de las organizaciones con Microsoft se salta: solo el 21,7% de los dominios que envían con M365 aplica DMARC.
5. Vuelva a probar leyendo la cabecera. Envíe a un buzón outlook.com de consumo, abra el origen del mensaje y confirme spf=pass, dkim=pass, dmarc=pass y compauth=pass.
6. Remitentes de alto volumen: cumplan el listón del Outlook de consumo. Por encima de 5.000/día necesita además un From/reply-to válido y supervisado, una cancelación de suscripción funcional y listas limpias — la autenticación resuelve el 5.7.515; la tasa de quejas le mantiene fuera de los bloqueos de IP S3140/S3150. Si su IP ya está bloqueada, arreglar SPF/DKIM/DMARC no levanta el bloqueo: solicite la retirada de la lista a través del soporte para remitentes de Microsoft, y trate la autenticación como la razón por la que no volverá a estar ahí.

¿Por qué siguen fallando tantos dominios de Microsoft 365?

Porque la configuración predeterminada hace el primer paso por usted y ninguno de los demás. Entre los 10.205.070 dominios que autorizan spf.protection.outlook.com, el 85,0% lleva SPF estricto — el registro que M365 le entrega al configurarlo — pero solo el 21,7% aplica DMARC, según el censo de Defaults.Exposed de 261.086.232 dominios. M365 le da SPF estricto por defecto, y ahí se queda la mayoría de los tenants — exactamente la población que compauth fue diseñado para atrapar (aunque todavía por delante del 10,59% de aplicación de DMARC entre todos los dominios calificados). Comparativa completa de proveedores: nuestra clasificación de SPF por proveedor de correo.

Preguntas frecuentes

¿Es 550 5.7.515 un error de Microsoft 365? No. Procede del Outlook.com/Hotmail de consumo y afecta a remitentes de >5.000 mensajes/día, en vigor desde mayo de 2025. Los rechazos del Exchange Online de empresa usan códigos distintos — los más comunes son 550 5.7.509 (su política DMARC de rechazo) o 5.7.511 (remitente prohibido).

Recibimos 550 5.7.509 pero el correo era legítimo — ¿deberíamos abandonar p=reject? No — su política atrapó una fuente sin autenticar, que es justo su trabajo. Encuentre la fuente en la cabecera o en sus informes DMARC y dele DKIM alineado (o SPF alineado). Debilitar a p=none reabre la suplantación exacta del dominio para todo el mundo.

¿compauth=fail significa que alguien nos está suplantando? No necesariamente. reason=001 suele significar que su propio correo no puede demostrar que es suyo — sin DKIM alineado, sin DMARC. Solo el 21,7% de los 10.205.070 dominios que envían con M365 aplica DMARC (datos a fecha de 2026-06-29), así que Microsoft aplica comprobaciones implícitas a todos los demás, y el correo legítimo sin autenticar también las falla.

Envío menos de 5.000 correos al día — ¿puedo ignorar esto? Esquivará el 550 5.7.515, pero no la carpeta de spam: compauth se aplica a cualquier volumen. Gmail juega la misma partida — consulte la guía del 550 5.7.26 de Gmail. Las soluciones son gratuitas; la barrera es el desconocimiento, no el coste.

Envíe el informe al propietario

Si arregla el correo para otra persona — un cliente, su jefe, la empresa cuyas facturas rebotaban — remate el trabajo con pruebas. Vuelva a ejecutar el análisis gratuito cuando el DNS se asiente y reenvíe el informe calificado. Muestra SPF, DKIM y DMARC pasando a verde en lenguaje claro que un propietario de negocio puede leer, y es el documento que necesitarán la próxima vez que la renovación del ciberseguro o un cuestionario de seguridad de un cliente pregunte si su correo está autenticado. Arreglado está bien; arreglado de forma demostrable es lo que hace que le paguen y que ellos queden cubiertos.

Compruebe su dominio gratis

Vea en qué vía le está suspendiendo Microsoft — SPF, DKIM, DMARC — de forma privada y solo para el propietario.

Compruebe su dominio → · Arreglar DMARC → · DKIM pasa pero DMARC falla → · Cómo calificamos → · Solo datos agregados. Datos almacenados y procesados en la UE.