Requisitos de Outlook para remitentes desde mayo de 2025 y el rechazo 550 5.7.515

El rebote 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level significa que Outlook.com ha rechazado su mensaje porque su dominio no ha superado las comprobaciones SPF, DKIM y DMARC que Microsoft exige a los remitentes de gran volumen. La solución está en su DNS y en la configuración de los sistemas que envían su correo, no en el contenido del mensaje.

Microsoft anunció las reglas en su blog de Microsoft Defender for Office 365 en abril de 2025, con aplicación a partir del 5 de mayo de 2025. Afectan a Outlook.com, el servicio de Microsoft para consumidores, que incluye las direcciones de outlook.com, hotmail.com y live.com.

Los requisitos siguen muy de cerca lo que Gmail y Yahoo introdujeron en 2024, así que un dominio bien configurado para un proveedor suele tener hecho la mayor parte del trabajo para los demás.

Qué exige Microsoft

Según el anuncio, los dominios que envían más de 5000 correos al día a Outlook.com deben cumplir 3 condiciones:

• SPF debe superarse para el dominio de envío, con un registro DNS que enumere con precisión las direcciones IP y los hosts autorizados.
• DKIM debe superarse, para validar la integridad y la autenticidad del mensaje.
• DMARC debe estar publicado con al menos p=none y alineado con SPF o con DKIM (Microsoft indica que preferiblemente con ambos).

Microsoft enumera además prácticas de higiene del correo para los grandes remitentes y se reserva el derecho de filtrar o bloquear a quienes las ignoren:

• Una dirección From o Reply-To válida, que refleje el dominio de envío real y pueda recibir respuestas.
• Una opción de baja clara y operativa en el correo de marketing y masivo.
• Eliminación periódica de direcciones no válidas y gestión de los rebotes.
• Asuntos veraces, cabeceras sin engaños y destinatarios que hayan aceptado recibir sus mensajes.

Carpeta de correo no deseado o rechazo

El anuncio original decía que el correo que no cumpliera las reglas se enviaría primero a la carpeta de correo no deseado. Microsoft actualizó la publicación el 29 de abril de 2025: los mensajes que no superan los requisitos de autenticación se rechazan con el error 550 5.7.515, con efecto desde el 5 de mayo de 2025, como estaba previsto (fuente).

En la práctica esto resulta útil: un rechazo aparece en sus registros de envío y en los informes de rebotes, mientras que un traslado silencioso al correo no deseado puede pasar desapercibido durante mucho tiempo.

Por qué un dominio legítimo recibe el 5.7.515

Las causas habituales son lagunas de configuración, no nada malicioso:

Una herramienta de envío sin DKIM para su dominio. Las plataformas de newsletters, los CRM y las herramientas de facturación suelen firmar con su propio dominio, salvo que añada sus registros DKIM al suyo.

SPF superado para el proveedor, no para usted. Muchos servicios usan su propia ruta de retorno, de modo que SPF se supera para bounce.vendor.net. Sin un DKIM alineado, DMARC falla.

Ningún registro DMARC. Microsoft exige al menos p=none. Basta con que falte el registro _dmarc para fallar.

SPF por encima de su límite de consultas. SPF permite como máximo 10 consultas DNS (RFC 7208, sección 4.6.4). Si añade un servicio de más, SPF devuelve un error en cada mensaje.

Un cambio reciente de DNS. Una migración a un nuevo proveedor de DNS o de correo en la que se quedó fuera un selector DKIM o el include de SPF de algún servicio.

Cómo encontrar la causa

Empiece por su DNS:

dig +short TXT yourcompany.com | grep spf1
dig +short TXT _dmarc.yourcompany.com
dig +short TXT selector1._domainkey.yourcompany.com

A continuación, averigüe qué sistema envió el mensaje rebotado. El rebote suele contener las cabeceras originales. Después envíe una prueba desde ese mismo sistema a una dirección de Outlook.com que usted controle y revise la cabecera Authentication-Results. Microsoft explica cómo leerla en su documentación sobre cabeceras de mensajes. Lo que busca es esto:

spf=pass smtp.mailfrom=yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass header.from=yourcompany.com

Si smtp.mailfrom o header.d muestran el dominio del proveedor en lugar del suyo, el problema es la alineación. Si aparece dkim=none, el sistema no está firmando en absoluto.

Cómo corregirlo

1. Publique un registro DMARC si no lo tiene: v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com.
2. En cada herramienta de envío, configure DKIM con su propio dominio (la herramienta le facilita los registros CNAME o TXT que debe añadir).
3. Si la herramienta admite una ruta de retorno personalizada, apúntela a un subdominio suyo para que SPF también quede alineado.
4. Unifique SPF en un solo registro, elimine los servicios que ya no usa y manténgase por debajo de 10 consultas.
5. Vuelva a enviar una prueba a Outlook.com y confirme que se superan las 3 comprobaciones.
6. Cuando los informes DMARC muestren que todo el correo legítimo pasa, avance hacia p=quarantine y después a p=reject.

Microsoft remite a los remitentes a su portal de soporte para remitentes de Outlook para obtener más ayuda. Nuestra guía de SPF, DKIM y DMARC explica cada registro con más detalle.

Lista de comprobación breve

• SPF superado, un solo registro, menos de 10 consultas.
• Firma DKIM con su dominio en todos los sistemas que envían correo.
• DMARC publicado, al menos p=none, alineado con SPF o DKIM.
• Registros de rebotes revisados en busca de 5.7.515 tras cualquier cambio de DNS o de proveedor.
• Una baja operativa y listas depuradas para el correo de marketing.

Dónde encaja Datahorses

Datahorses vigila desde fuera todos los días los registros DNS relacionados con su correo, de modo que un selector DKIM eliminado, un registro SPF roto o una política DMARC debilitada se detectan antes de convertirse en rebotes. Una persona revisa cada cambio y envía a su desarrollador los registros exactos que hay que corregir. Consulte lo que vigilamos, cómo gestionamos un hallazgo o el panel de ejemplo.