Nuevos requisitos de Microsoft para SPF, DKIM y DMARC

El 5 de mayo de 2025 marcó un hito en el ecosistema del correo electrónico: Microsoft comenzó a exigir nuevos requisitos de autenticación para los dominios que envían grandes volúmenes de correo a sus servicios (Outlook.com, Hotmail.com y Live.com). A partir de esa fecha, cualquier mensaje de un dominio no autenticado correctamente (en términos de SPF, DKIM y DMARC) puede ser rechazado antes de llegar siquiera a la bandeja de entrada del destinatario.

La seguridad como objetivo

Esta iniciativa forma parte de un esfuerzo más amplio de la industria por combatir el spam, el phishing y la suplantación de identidad, alineándose con medidas similares adoptadas por Google y Yahoo en 2024.

En este artículo profundizaremos en estos nuevos requisitos de autenticación de Microsoft – qué cambios introducen, por qué se implementaron y qué consecuencias están teniendo en el envío legítimo de correos. Nos enfocaremos tanto en los detalles técnicos (SPF, DKIM, DMARC) como en las implicaciones de negocio para email marketing, entregabilidad (deliverability) y reputación de dominio. También ofreceremos recomendaciones prácticas para adaptarse rápidamente a las nuevas reglas, abordando errores comunes y estrategias para mantener sus campañas de correo en buen cauce.

¿Qué son SPF, DKIM y DMARC? (Autenticación de correo explicada)

Antes de entrar en los cambios, conviene repasar brevemente qué significan estas siglas clave:

SPF (Sender Policy Framework)

Es un protocolo que permite al propietario de un dominio especificar qué servidores o direcciones IP están autorizados para enviar correos en su nombre. Cuando un servidor de correo receptor recibe un mensaje, consulta el registro SPF del dominio remitente para verificar si el correo proviene de un host autorizado. Si la IP no está en la lista, la verificación SPF falla. En resumen, SPF indica qué servidores pueden enviar correo desde un dominio, ayudando a prevenir que spammers se hagan pasar por remitentes legítimos.

DKIM (DomainKeys Identified Mail)

Es un mecanismo de autenticación que añade una firma digital criptográfica a los encabezados del correo. El dominio remitente publica una clave pública en DNS, y el servidor emisor firma los correos con la clave privada correspondiente. El servidor receptor puede usar la clave pública para verificar que la firma DKIM concuerda. Si el mensaje se ha modificado en tránsito o el dominio no lo firmó, la validación DKIM falla. En esencia, DKIM confirma que el mensaje no fue alterado y que proviene realmente del dominio firmante.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Es una política que se asienta sobre SPF y DKIM. DMARC permite al dominio remitente indicar cómo quiere que el receptor maneje los correos que no pasen SPF ni DKIM (por ejemplo, ninguna acción, enviarlos a spam, o rechazarlos directamente). Además, DMARC proporciona un sistema de reportes (Aggregate Reports y Forensic Reports) que da visibilidad al dueño del dominio sobre quién está enviando correos en su nombre y si esos mensajes están pasando o fallando las validaciones. Para que DMARC “considere legítimo” un correo, al menos una de las dos autenticaciones (SPF o DKIM) debe pasar y estar alineada con el dominio del remitente. Esto último – la alineación – significa que el dominio en la firma DKIM o en el SPF (el dominio usado en el envelope o return-path) coincide con el dominio visible en el campo “From:” del correo. En resumen, DMARC valida que SPF/DKIM estén en uso y define qué hacer si ambas fallan (pudiendo simplemente monitorear, enviar a spam, o rechazar).

El trípode de la seguridad

En conjunto, SPF, DKIM y DMARC conforman un trípode de seguridad para el correo electrónico. Implementados correctamente, verifican la identidad del remitente y permiten frenar intentos de suplantación (spoofing). Para una empresa, esto no solo protege a sus receptores, sino también su propia marca: evita que actores maliciosos utilicen su dominio para enviar phishing o spam, dañando su reputación. Hasta ahora, adoptar estos estándares se consideraba una “mejor práctica” voluntaria. Pero las cosas han cambiado en 2025: Microsoft está pasando de la recomendación a la exigencia.

¿Qué ha cambiado en mayo de 2025? Nuevas políticas de Microsoft

Microsoft ha endurecido sus políticas de recepción de correo. En concreto, desde el 5 de mayo de 2025, todo dominio que envíe más de 5.000 correos diarios a servicios Microsoft (Outlook.com, Hotmail, Live) debe autenticar correctamente sus mensajes con SPF, DKIM y DMARC. Los correos provenientes de dominios que no cumplan estos requisitos serán directamente rechazados en la conexión SMTP, con un mensaje de error como el siguiente:

pgsql
550 5.7.15 Access denied, sending domain [ejemplo.com] does not meet the required authentication level.

Este código de error 550 5.7.15 (“Access Denied”) indica que el dominio remitente no alcanza el nivel de autenticación requerido por Microsoft. En la práctica, significa que el correo no será entregado al destinatario ni siquiera como spam; será rechazado durante el envío. Este es un cambio importante, ya que anteriormente el plan de Microsoft era algo más gradual. Inicialmente, la compañía había anunciado que a partir de mayo las misivas no conformes se moverían al buzón de junk (correo no deseado) del usuario, para dar a los remitentes la oportunidad de corregir problemas, con miras a futuros rechazos totales. Sin embargo, a última hora decidieron acelerar la aplicación:

“Después de considerarlo cuidadosamente, y para asegurar la protección de los usuarios y eliminar cualquier confusión sobre por qué un mensaje estaba en la carpeta de junk tanto para el destinatario como para el remitente, hemos tomado la decisión de rechazar los mensajes que no pasen los requisitos de autenticación… Este cambio comenzará a tener efecto el 5 de mayo como se indicó originalmente.”

Poco tiempo de reacción

En otras palabras, Microsoft optó por no dar ese periodo intermedio de “entrega en spam”: desde el día uno de la medida, correo no autenticado = correo devuelto. Esto obligó a los remitentes a reaccionar rápidamente.

Los requisitos específicos que impone Microsoft son esencialmente tres:

1. SPF debe “pasar”: el servidor que envía el correo debe estar incluido en el registro SPF del dominio remitente. Es imprescindible revisar los DNS y listar todas las IP o hosts autorizados para enviar en nombre de nuestro dominio. Si usamos proveedores de email marketing o servicios de terceros, sus servidores deben aparecer en nuestro SPF (p. ej., mediante mecanismos include).
2. DKIM debe “pasar”: el correo debe llevar una firma DKIM válida que el receptor pueda verificar con la clave pública publicada en DNS. Cualquier dominio que envíe alto volumen a Outlook/Hotmail debería firmar digitalmente sus mensajes. Esto garantiza la integridad y autenticidad del email.
3. DMARC con política p=none: el dominio debe tener publicado un registro DMARC, al menos con política “none” (monitorización). Además, como mencionamos, DMARC exige alineación: el correo debe alinear en SPF o DKIM (preferiblemente ambos). Es decir, no basta con tener los registros en DNS; el envío tiene que estar configurado de tal manera que o bien la firma DKIM corresponda al dominio que aparece en “From:”, o bien el SPF se valide contra el dominio correcto. Microsoft literalmente requiere un nivel de cumplimiento de DMARC equivalente a si pudieras poner una política más estricta (quarantine/reject) sin romper tus envíos. En la práctica, están forzando a que los remitentes alcancen la madurez necesaria para implementar DMARC de verdad.

No se admiten cero políticas DMARC

En cuanto a la política DMARC, “p=none” es el mínimo aceptado. Esto significa que el dominio declara una política (aunque no esté bloqueando ni poniendo en cuarentena directamente). Microsoft no llega (todavía) a exigir “quarantine” o “reject” en DMARC, pero deja claro que tener cero política ya no es admisible. De hecho, según reportan algunas fuentes, incluso solicitan que los reportes DMARC (RUA/RUF) estén habilitados en el registro, y que no haya ambigüedades en la configuración DNS. Todo apunta a que quieren que los remitentes tomen en serio DMARC como herramienta de monitoreo y mejora continua.

Unificación en el sector

Cabe destacar que Microsoft se suma así a Google y Yahoo en esta iniciativa. Google y Yahoo anunciaron en 2023 que empezarían a exigir DMARC para grandes remitentes, aplicándolo ya en 2024. El objetivo común es elevar el estándar de seguridad del correo a nivel global. Como señalaba un experto: “Estas nuevas exigencias no se tratan solo de cumplir por cumplir, sino de confianza del cliente. Los remitentes de alto volumen deben tomarse la entregabilidad y la autenticación como partes centrales de su estrategia de marca digital, no solo como higiene de IT”. En última instancia, al reforzar la autenticación, se protege al usuario final de correos maliciosos y se recompensa al remitente legítimo con mejor entregabilidad y protección de su marca.

¿Por qué Microsoft implementó estos cambios?

La motivación principal es la seguridad y la confianza en el correo electrónico. El correo sigue siendo uno de los vectores favoritos para ataques de phishing, estafas y propagación de malware. Al exigir SPF, DKIM y DMARC, Microsoft busca reducir la suplantación de dominios y el spam que llega a sus millones de usuarios, elevando la barra para los remitentes masivos. En palabras de Microsoft, se trata de “impulsar a la industria hacia mejores prácticas y salvaguardar a los usuarios que confían en nosotros cada día”. Quieren asegurarse de que quien mande 5.000 correos diarios o más sea realmente quien dice ser.

Mejora de la entregabilidad de los remitentes legítimos

Esta medida también empodera a los remitentes legítimos. Aunque suene contradictorio (pues impone obligaciones adicionales), en teoría los remitentes que autentican correctamente verán menos de sus correos filtrados como spam y gozarán de mayor protección de marca. Microsoft señala que todos los remitentes (no solo los de gran volumen) “se benefician de estas prácticas”, ya que un ecosistema de correo más auténtico mejora la entregabilidad global.

Armonización con otros proveedores de correo

Otra razón de peso es la armonización con otros grandes proveedores. Como mencionamos, Google y Yahoo ya habían endurecido sus políticas de autenticación en 2024 para quienes envían correos masivos. Microsoft no iba a quedarse atrás. De hecho, en julio de 2023 Microsoft también anunció que empezaría a honrar las políticas DMARC entrantes tanto en su servicio de consumidores como en Office 365, lo que significa que si tu dominio publicaba p=reject, ellos respetarían ese deseo y rechazarían correos que finjan ser tuyos sin autenticación. Era cuestión de tiempo que también exigieran DMARC a los remitentes. El mensaje es claro: “solo los correos electrónicos legítimos llegan a los usuarios”.

Claridad sobre los rechazos

Además, había un incentivo de claridad operativa. Antes, cuando Microsoft no imponía estas reglas, muchas veces los correos de remitentes sin DMARC o mal configurados terminaban en spam sin una explicación evidente. Para un remitente esto podía pasar desapercibido (si no monitoreaba entregas) y para un usuario final podría significar perderse mensajes importantes en la carpeta de correo no deseado. Al rechazar directamente los mensajes no autenticados, Microsoft fuerza a que el problema salga a la luz a ojos del remitente (que recibirá un bounce con el código de error). Esto elimina la “zona gris” de correos perdidos en spam sin visibilidad. En palabras de Microsoft, la decisión de rechazar busca “eliminar la confusión sobre por qué un mensaje acabó en junk” tanto para quien envía como para quien recibe. Es una manera drástica pero efectiva de notificar: “Tu correo no pasó mis filtros de autenticación. Arréglalo”.

Finalmente, desde una perspectiva estratégica, Microsoft entiende que el correo electrónico sigue siendo crítico para comunicaciones empresariales y de consumidores. Al “doblar la apuesta” en seguridad y confianza, no solo protegen a sus usuarios, sino que también presionan a la industria para adoptar estas medidas. Es una evolución natural del ecosistema de correo: hace años casi nadie usaba estas autenticaciones, hoy son recomendables, y mañana serán imprescindibles. Como resumió Cristian Borghello (Segu-Info): “Para atacar los enormes problemas de seguridad derivados de correos maliciosos, empresas como Google, Microsoft o Yahoo han decidido tomar cartas en el asunto y bloquearán cualquier correo que no tenga estos registros de seguridad adecuadamente configurados”.

Consejos prácticos y estratégicos para adaptarse rápidamente

Además de configurar técnicamente SPF, DKIM y DMARC, es fundamental adoptar una estrategia proactiva para enfrentar estos cambios. La autenticación del correo ya no es solo un asunto técnico, sino un factor clave para el marketing, la reputación de marca y la eficacia de las campañas. Es crucial involucrar a distintos equipos dentro de la organización—desde marketing hasta TI—para que entiendan la importancia de estos requisitos y apoyen su correcta implementación.

Monitoreo de la reputación

También es importante aprovechar herramientas avanzadas de monitoreo de reputación, como SNDS o JMRP de Microsoft, que ayudan a detectar rápidamente problemas y mantener una buena reputación con los principales proveedores de correo. Asimismo, mantener una higiene adecuada en las listas de suscriptores y cuidar el contenido enviado es imprescindible para asegurar que los mensajes no solo lleguen a las bandejas de entrada, sino que sean relevantes y bien recibidos por los destinatarios.

Políticas de máxima protección

Por último, las organizaciones deben pensar a largo plazo: conviene empezar con una política DMARC básica (p=none) e ir incrementando progresivamente su rigurosidad hacia quarantine o reject, garantizando máxima protección contra phishing y mejor reputación. Contar con el apoyo de expertos o plataformas especializadas puede acelerar esta transición, ofreciendo tranquilidad y mayor eficiencia.

En definitiva, gestionar activamente la autenticación del correo electrónico ya no es opcional, sino una estrategia esencial para garantizar el éxito y la estabilidad en las comunicaciones digitales.

Falta de visibilidad en los tenants de Microsoft y sus efectos

Un aspecto mencionado por varios actores de la industria es la falta de visibilidad que estos rechazos introducen en ciertos escenarios. ¿Qué ocurre, por ejemplo, cuando un correo legítimo es rechazado por Microsoft por no cumplir DMARC? Desde el punto de vista del remitente, recibirá un NDR (Non-Delivery Report) con el código 5.7.15, pero desde el punto de vista del destinatario (el usuario de Outlook/Hotmail) no verá nada. Ni siquiera podrá buscar en “correo no deseado”, porque el mensaje nunca llegó a su servidor de correo. Esto puede generar situaciones peculiares en entornos corporativos:

Destinatarios ajenos al problema

Imagina un usuario de Office 365 que espera un informe de un proveedor externo. Si el proveedor no autenticó su dominio y el mail fue rechazado, el usuario no tendrá forma de saberlo por sí mismo. Podría pensar simplemente que el proveedor no le envió nada. A nivel de administración del tenant de Microsoft 365 (empresa receptora), en los message traces aparecerá como mensaje rechazado por “Policy (DMARC)” o similar, pero eso requiere que el administrador esté buscando activamente el porqué. En general, hay poca visibilidad interna en el tenant receptor de que “faltó un correo”, lo cual puede dificultar la resolución de incidencias hasta que el remitente se entera.

Responsabilidad desplazada al remitente

Con esta política, Microsoft básicamente transfiere la carga al remitente para darse cuenta y arreglarlo. Desde el punto de vista de Microsoft, esto tiene sentido (ellos protegen a sus usuarios y notifican al remitente con el bounce). Pero para una organización receptora, significa que poco puede hacer más que informar al remitente que “tus correos están siendo rechazados, por favor revisa tu autenticación”. Varios administradores de correo corporativo se encontraron en medio mediando entre colegas que decían “X compañía no me envía los documentos” y la realidad de “sí los envían, pero rebotan por DMARC”. Hubo casos en que el área de IT de la empresa receptora tuvo que comunicar al proveedor externo lo que pasaba (cuando éste no lo había detectado aún).

Justificación de la medida

Microsoft reconoció esta posible falta de visibilidad y, como vimos, la usó como argumento para preferir rechazo sobre cuarentena. Prefirieron que el remitente se entere (vía mensaje devuelto) a que el correo se pierda silenciosamente en spam. No obstante, esto supone que el remitente monitoree dichos rebotes. Si un remitente no tiene buenos procesos de seguimiento de devoluciones (bounce logs), podría inicialmente pasar por alto el problema. Es recomendable que, junto con DMARC, los remitentes implementen monitoreo de entregas en sus sistemas o proveedores – la mayoría de plataformas de envío masivo ofrecen reportes de bounce; úsalos para identificar códigos 5.7.15 u otros inusuales.

DMARC aumenta la visibilidad a mediano plazo

Paradójicamente, una vez que una organización adopta DMARC (aunque sea p=none), obtiene más visibilidad gracias a los informes agregados. Esos reportes DMARC les permitirán ver si Microsoft u otros están rechazando correos de su dominio, incluso si sus propios usuarios no lo notan. Por ejemplo, si alguien intenta suplantar tu dominio hacia usuarios de Outlook, los informes DMARC de Microsoft te lo dirán. O si sin querer estás enviando algo sin DKIM, verás en los reportes un porcentaje de “fail”. Así que, aunque en el instante un correo se pierda, a la larga DMARC mejora la transparencia del ecosistema para los dominios que lo implementan correctamente.

En resumen, la “falta de visibilidad en los tenants” se refiere a que los administradores y usuarios de correo Microsoft no verán los mensajes no autenticados – simplemente dejan de existir para ellos. Esto fue un cambio cultural también: históricamente, muchos administradores estaban acostumbrados a revisar la carpeta de quarantine o junk para rescatar falsos positivos. Ahora, con el rechazo SMTP, ese flujo cambia. La recomendación aquí es mejorar la comunicación entre organizaciones: si sabes que un socio o proveedor no recibió tu correo, hazle llegar el aviso del rechazo; y viceversa, si esperas algo que no llega, chequea con el remitente si recibió algún bounce. Mientras tanto, conforme todos adoptemos estas políticas, estos casos irán disminuyendo.

El futuro de la entregabilidad pasa por la autenticación

La decisión de Microsoft de exigir DMARC, SPF y DKIM a los remitentes masivos marca un antes y un después. No es un capricho ni una moda pasajera, sino la evolución natural de la seguridad en correo electrónico. Estamos entrando en una etapa donde ya no será opcional autenticar los correos – será un requisito básico para poder participar en la “conversación” por email.

Para las empresas dedicadas al email marketing y comunicaciones, esto implica un cambio de mentalidad: hay que invertir en infraestructura y buenas prácticas de autenticación como parte de la estrategia central. La reputación de dominio se consolida como un activo que necesita ser gestionado activamente, igual que se gestiona la reputación de marca. Como bien apuntan los expertos, “hoy en día es impensable que un servicio de correo electrónico no esté correctamente autenticado”. DMARC bien implementado protege al usuario final y a la empresa emisora; es una situación de beneficio mutuo que reduce phishing y mejora la confianza en los mensajes.

Consecuencias que se han sufrido

En términos de impacto, a corto plazo algunas organizaciones legítimas sufrieron contratiempos (emails perdidos, métricas de campaña a la baja) por no haber estado al tanto o listos para el cambio. Pero esto ha servido de catalizador para que finalmente adopten medidas que eran recomendadas desde hace años. A mediano y largo plazo, veremos un ecosistema de correo más saludable: menos spam llegando a usuarios, y los correos de remitentes legítimos mejor posicionados para llegar a la bandeja de entrada. Quienes se adapten rápidamente cosecharán esos beneficios y evitarán interrupciones en sus comunicaciones; quienes se resistan o demoren, lamentablemente verán sus esfuerzos de correo electrónico desperdiciarse con mensajes que no llegan.

¿Esto termina aquí?

También es posible que Microsoft y otros proveedores vayan subiendo la apuesta con el tiempo. Hoy piden p=none, pero en unos años podrían requerir políticas más estrictas o extender estas exigencias a volúmenes menores. De hecho, Microsoft dejó la puerta abierta indicando que, en el futuro, “los mensajes no conformes serán rechazados completamente para prevenir fraude” (haciendo pensar que quizás todos los dominios deberían adoptar DMARC). Estar preparados para un eventual p=quarantine o p=reject obligatorio sería sensato. La buena noticia es que, si ya cumplimos lo de ahora, ese siguiente paso sería mucho más sencillo.

Conclusiones

En conclusión, la medida de Microsoft refuerza una lección clave: la entregabilidad y la seguridad van de la mano. Autenticar los correos no es solo un asunto técnico, sino parte de brindar una buena experiencia de comunicación. Como industria, estamos moviéndonos hacia un estándar donde cada correo puede ser rastreado a su origen legítimo. Para cualquier empresa que use el email como canal, la recomendación experta es abrazar este cambio cuanto antes. Configure SPF, DKIM y DMARC sin demora (¡si no lo ha hecho ya!), porque ya no se trata de una ventaja competitiva sino de un requisito de base para operar. Aquellas organizaciones que lo hagan estarán protegidas y alineadas con los gigantes del correo, mientras que las que no, arriesgan quedarse hablando solas en un vacío digital.

En palabras del equipo de Bitralix: “La realidad es que DMARC no es una opción, sino una necesidad operativa y de reputación. Tenerlo correctamente configurado es la nueva normalidad en el correo empresarial”. Adaptémonos a esta nueva normalidad y aprovechemos la oportunidad para fortalecer la confianza en el correo electrónico como medio seguro y eficaz.