# 550 5.7.515 “Access denied”: por qué Outlook rechaza tu dominio y cómo resolverlo Publicado: 2026-11-04 Autor: Guanacos Tech (https://guanacostech.com/es) Fuente canónica: https://guanacostech.com/es/blog/550-5-7-515-access-denied-outlook-fix > Lee el rebote, identifica cuál falló entre SPF, DKIM, DMARC o la alineación de tu dominio, corrígelos en el orden correcto y vuelve a entrar a Outlook. **Respuesta corta:** 550 5.7.515 significa que Outlook.com rechazó el mensaje porque el dominio del encabezado From no cumple los requisitos de autenticación de Microsoft para remitentes de alto volumen. SPF y DKIM deben pasar, debe existir un registro DMARC con una política válida, y SPF o DKIM deben alinearse con ese dominio From. Revisa la alineación antes de tocar el DNS. El patrón siempre es el mismo. Los recordatorios de factura o las confirmaciones de pedido salen como de costumbre, la mayoría llega, y un puñado de clientes dice que nunca recibió nada. Esos clientes leen su correo en `hotmail.com`, `outlook.com` o `live.com`, y el log de correo trae una línea por cada uno: ``` 550 5.7.515 Access denied, sending domain [example.com] does not meet the required authentication level ``` Ese rebote no es una queja de spam, ni una lista negra, ni un puntaje de reputación. Es un control en la puerta. Microsoft miró el dominio del encabezado From, preguntó si ese dominio autentica su propio correo como Microsoft lo exige a los remitentes de alto volumen, y recibió una respuesta que no aceptó. Hasta que esa respuesta cambie, el correo de ese dominio hacia una dirección de consumo de Microsoft se rechaza en el borde. Nada cae en Correo no deseado, así que de tu lado nadie ve un patrón hasta que un cliente levanta el teléfono. Es una de las fallas de entregabilidad más amables, porque Microsoft dice exactamente qué quiere. El trabajo está en encontrar cuál de cuatro revisiones es la que falla, y por lo que vemos la mayoría de los equipos se equivoca en el primer intento. ## Qué dice el rebote, línea por línea Importan tres partes de ese texto. **550** es un rechazo permanente. El servidor que envía no reintenta, el mensaje se perdió y tu cliente nunca lo vio. **5.7.515** es el código de estado ampliado que Microsoft usa para un rechazo por política basado en la autenticación del remitente, no en el contenido. Y el dominio que aparece entre corchetes es el del encabezado `5322.From`, el remitente que una persona lee en la línea From, no el remitente del sobre que tu servidor usó para entregar el mensaje. Ese último detalle es donde vive casi toda la confusión. La propia guía de Microsoft para este error pide comparar el dominio `5321.MailFrom`, el return path contra el que se revisa SPF, con el dominio `5322.From` que le importa a DMARC. Mucho correo pasa SPF sin problema con un return path que no tiene nada que ver con el From visible, y ese correo igual recibe un 5.7.515. Un SPF en verde en una herramienta de DNS, por sí solo, aquí no prueba nada. ## A quién cuenta Microsoft como remitente de alto volumen Las reglas aplican al correo que entra a los servicios de consumo de Microsoft: `outlook.com`, `hotmail.com` y `live.com`. La guía de Microsoft pone la vara en 5,000 mensajes o más enviados a esos servicios usando el mismo dominio en la dirección `5322.From`. La página de políticas del postmaster de Outlook.com lo plantea como dominios que envían más de 5,000 correos al día a cuentas de Outlook.com, vigente desde el 5 de mayo de 2025, y el anuncio del equipo de Defender for Office 365 describe el rechazo llegando con este mismo texto 5.7.515. Ambas páginas revisadas el 4 de noviembre de 2026. Dos cosas toman desprevenidas a las pymes. Primero, los 5,000 son un total del dominio, no de una campaña. Digamos que una firma contable de 12 personas envía 400 estados de cuenta al mes desde su cliente de correo: está lejísimos del límite. La misma firma con un sistema de facturación, una secuencia de CRM y un boletín mensual, todos enviando como `@example.com`, puede cruzarlo en una semana sin que nadie haya decidido volverse remitente masivo. Nadie se inscribe en este umbral, se cae en él. Segundo, que un destinatario te agregue a su lista de remitentes seguros no te deja pasar. El rechazo ocurre antes de leer cualquier preferencia por destinatario, así que pedirle a tus clientes que te agreguen a su lista es una semana perdida. El arreglo está de tu lado del DNS. ## Las cuatro revisiones, en el orden en que las hacemos Microsoft quiere cuatro cosas verdaderas al mismo tiempo: que SPF pase, que DKIM pase, que exista un registro DMARC con una política válida, y que al menos uno de SPF o DKIM se alinee con el dominio del From. Por lo general tres de las cuatro ya están bien. Trabajamos la lista en este orden porque cada respuesta te dice si vale la pena mirar la línea siguiente. | Revisión | Dónde se lee | Cómo se ve cuando falla | Qué cambiar | | --- | --- | --- | --- | | **SPF** | `Authentication-Results` en una copia entregada del mismo mensaje | `spf=fail`, o `spf=pass` para un dominio que no es tuyo | Agrega el servicio que envía al SPF del dominio del return path | | **DKIM** | El encabezado `DKIM-Signature` y su valor `d=` | Sin firma, `dkim=fail`, o `d=` con el dominio del proveedor | Publica la llave DKIM del proveedor en tu dominio y activa la firma | | **Registro DMARC** | Un registro TXT en `_dmarc.example.com` | Sin registro, más de un registro, o sin valor `p=` | Publica un solo registro con `v=DMARC1`, política y reportes | | **Alineación** | `dmarc=` en el mismo bloque de encabezados | `spf=pass` y `dkim=pass` pero `dmarc=fail` | Haz que el return path o el `d=` de DKIM coincidan con el From | | **Reprueba** | Un mensaje nuevo a una dirección de consumo de Microsoft | El mismo 550 5.7.515 después de que el DNS tuvo tiempo de propagar | Lee los encabezados del rebote nuevo antes de cambiar otra cosa | Lee un mensaje real antes de tocar el DNS. El encabezado `Authentication-Results` que escribe quien recibe nombra cada veredicto y el dominio al que se aplicó, y es la forma más rápida de distinguir un registro ausente de uno mal alineado. Adivinar desde una herramienta de DNS es como un arreglo de una tarde se convierte en dos semanas. Herramienta gratis Descifra las cabeceras de un correo que cayó en spam Pega las cabeceras completas y mira la cadena Received y los resultados de SPF, DKIM y DMARC, línea por línea. [Analizar cabeceras](https://guanacostech.com/es/header-analyzer) ## Las tres fallas que más encontramos ### Microsoft 365 firmando con el dominio equivocado Un tenant al que nunca le activaron DKIM para su dominio propio igual firma el correo que sale, pero lo firma con el dominio `onmicrosoft.com` del tenant. DKIM pasa. DMARC sigue fallando, porque la documentación de Microsoft es explícita: DKIM solo satisface a DMARC cuando el dominio que firma y el dominio del From se alinean. El arreglo es activar la firma DKIM para el dominio exacto que se usa en la dirección From, incluido cualquier subdominio que envíe. Eso significa dos registros CNAME por dominio, `selector1._domainkey` y `selector2._domainkey`, con los destinos copiados tal cual de tu propio tenant y no escritos desde una plantilla. La guía de solución de problemas de Microsoft señala los destinos armados a mano como causa frecuente de fallas de validación, pide los dos registros aunque solo un selector esté activo a la vez, porque el segundo es lo que hace invisible la rotación de llaves, y aclara que un registro TXT en lugar de un CNAME no está soportado. ### Un servicio que envía y se queda con el sobre Una plataforma de facturación o una herramienta de marketing envía por ti y, por defecto, usa su propio dominio de rebote como return path y su propia llave para firmar. Las dos revisiones pasan, y las dos pasan para el proveedor, no para ti. Para DMARC eso se lee como un mensaje que nadie dueño de `example.com` respaldó. Todo servicio que valga la pena tiene una salida: un return path propio en un subdominio tuyo, una llave DKIM publicada en tu dominio, o ambas. Activa una de las dos en cada sistema que envíe como tú, no solo en el más grande. ### Un SPF que no incluye a quien envía Vale leer la guía de SPF de Microsoft antes de editar: un solo registro SPF por dominio y ninguno más, la mayoría de las organizaciones de Microsoft 365 necesitan `include:spf.protection.outlook.com`, cada `include`, `a`, `mx`, `ptr` y `redirect` cuenta contra el límite de consultas DNS, y pasarse hace que la validación de SPF falle por completo. Microsoft recomienda falla dura, `-all`, y un TTL de al menos 3600 segundos. Un subdominio no hereda el registro del dominio padre, así que un subdominio de facturación que envía necesita el suyo. ## Los registros, escritos ``` ; SPF: un solo registro, en el dominio que se usa como return path example.com. 3600 IN TXT "v=spf1 include:spf.protection.outlook.com -all" ; DMARC: el mínimo que pide Microsoft, con reportes activados _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" ; DKIM para un dominio propio en Microsoft 365: dos CNAME, con destinos ; copiados de tu propio tenant, nunca armados a mano selector1._domainkey.example.com. 3600 IN CNAME DESTINO-DE-TU-TENANT selector2._domainkey.example.com. 3600 IN CNAME DESTINO-DE-TU-TENANT ``` Son puntos de partida, no una receta para pegar. El SPF va en el dominio que tu servidor entrega como return path, que no siempre es el de la línea From, y los destinos de DKIM son específicos de tu tenant. ## Después del arreglo: qué vigilamos dos semanas Deja la política DMARC en `p=none` con reportes y no la muevas todavía. El rebote se va en cuanto SPF o DKIM se alinean, así que no hay razón para saltar a `p=reject` esa misma tarde y descubrir el lunes que el sistema de facturación era justo el remitente que se te olvidó. Después, lee los reportes. Los reportes agregados llegan como XML diario desde cada receptor y son la única vista que tendrás de todos los sistemas que envían como tu dominio, incluidos los que nadie te mencionó. Dos semanas suelen bastar para ver la lista completa. Cuando cada remitente legítimo aparezca alineado, aprieta la política por pasos. Vuelve a enviar a una dirección de consumo de Microsoft en cada paso, porque esa es la prueba que importa. Una nota honesta sobre tiempos: los cambios de DNS tardan lo que diga tu TTL, y un receptor que cacheó el registro viejo va a seguir rechazando hasta que expire. Un arreglo correcto puede seguir rebotando una hora. No deshagas un DNS bueno porque el primer reintento falló. ## Cómo ayuda Guanacos Tech Lo tomamos como un trabajo definido: leer un rebote real, leer los encabezados, mapear todos los sistemas que envían como tu dominio, arreglar SPF, DKIM y alineación en el orden de arriba, y luego vigilar los reportes DMARC dos semanas para confirmar que nada más esté firmando como tú. Casi siempre es una tarde de DNS y un ajuste dentro de una herramienta de envío, y lo difícil es solo saber cuál ajuste. Si prefieres no andar adivinando, para eso está nuestra [consultoría de entregabilidad de correo](https://guanacostech.com/es/entregabilidad-de-correo). Agenda una llamada de 30 minutos y trae un mensaje rebotado, y en la llamada te decimos cuál de las cuatro revisiones está fallando y qué implica resolverla. ## Fuentes - [Soporte de Microsoft: corregir el error NDR “550 5.7.515” en Outlook.com](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) - [Microsoft Tech Community: nuevos requisitos de Outlook para remitentes de alto volumen](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730) - [Postmaster de Outlook.com: políticas, prácticas y lineamientos](https://sendersupport.olc.protection.outlook.com/pm/policies) - [Microsoft Learn: cómo usar DKIM para el correo de tu dominio propio](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) - [Microsoft Learn: configurar SPF para identificar las fuentes válidas de correo de tu dominio de Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) - [Microsoft Learn: solucionar problemas de autenticación de correo en Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-troubleshoot) - [RFC 7489: Domain-based Message Authentication, Reporting and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc7489) ## Preguntas frecuentes ### ¿Puedo arreglar el 550 5.7.515 yo mismo o Microsoft tiene que desbloquearme? Lo arreglas tú. No hay nada que apelar ni formulario de salida de lista, porque el rechazo es una revisión en vivo de la autenticación de tu dominio y no un bloqueo en una lista. Cuando SPF o DKIM pasa y se alinea con el dominio del From, y hay un registro DMARC publicado, el siguiente mensaje entra. ### Enviamos muchos menos de 5,000 correos al día. ¿Por qué nos llega este rebote? Cuenta todos los sistemas que envían como tu dominio, no solo tu cliente de correo: la facturación, una secuencia de CRM, la mesa de ayuda, el boletín y la tienda en línea suman al mismo total del dominio. Además conviene arreglarlo sin importar el volumen, porque SPF, DKIM, DMARC y la alineación son lo que ya esperan todos los receptores grandes. ### ¿Necesito p=reject para cumplir con Microsoft? No. La propia guía de Microsoft acepta un registro DMARC publicado con una política válida y su ejemplo usa p=none. Empieza ahí con los reportes activados, confirma que cada remitente legítimo aparezca alineado y luego aprieta la política por pasos si quieres la protección contra suplantación que da p=reject. --- Guanacos Tech es una consultora independiente con ingenieros certificados por Google: entregabilidad de correo, Google Workspace y Google Cloud, en inglés y español. Agenda 30 minutos gratis: https://calendar.app.google/pq2seCCcch9U2GFV8