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 levelEse 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.
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-TENANTSon 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. 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
- Microsoft Tech Community: nuevos requisitos de Outlook para remitentes de alto volumen
- Postmaster de Outlook.com: políticas, prácticas y lineamientos
- Microsoft Learn: cómo usar DKIM para el correo de tu dominio propio
- Microsoft Learn: configurar SPF para identificar las fuentes válidas de correo de tu dominio de Microsoft 365
- Microsoft Learn: solucionar problemas de autenticación de correo en Microsoft 365
- RFC 7489: Domain-based Message Authentication, Reporting and Conformance (DMARC)