Domingo, 15 de noviembre de 2026

Lo más relevante del hosting en el mundo, en español · ehost.ec →

Outlook.com empieza a bloquear correos de dominios sin DMARC válido

Microsoft ha actualizado Outlook.com para rechazar mensajes procedentes de dominios que no pasan la autenticación DMARC. La medida afecta a remitentes y administradores de correo que no tengan políticas DMARC configuradas o correctas.

Por Equipo ehost3 min de lecturaFuente: GIGAZINE
Outlook.com empieza a bloquear correos de dominios sin DMARC válido
Imagen ilustrativa generada con inteligencia artificial.

Outlook.com ha introducido un cambio en su tratamiento del correo entrante: ahora puede rechazar mensajes originados en dominios que no superen la comprobación DMARC. La modificación persigue reducir el correo fraudulento y el phishing que suplantan dominios legítimos, pero también implica acciones concretas para administradores de correo y propietarios de sitios web que envían correo transaccional o marketing.

Qué es DMARC y por qué importa

DMARC (Domain-based Message Authentication, Reporting & Conformance) es un estándar de autenticación de correo que se apoya en SPF y DKIM para verificar que un mensaje proviene realmente del dominio que declara en el encabezado. Además de comprobar firmas y registros, DMARC permite al propietario del dominio indicar a los receptores qué hacer con los mensajes que fallan la autenticación: permitirlos, marcarlos o rechazarlos.

Qué cambia en Outlook.com

Según el informe original, Outlook.com toma ahora una postura más estricta: si un dominio remitente no tiene una política DMARC válida o los mensajes fallan la verificación, el servicio puede rechazar esos correos en origen en lugar de entregarlos con advertencias o enviarlos a spam. El objetivo declarado es reducir la suplantación y el phishing que utilizan dominios falsificados.

A quién afecta y por qué debe importarle

  • Propietarios de dominios y administradores de correo: si su dominio no publica registros DMARC (o los tiene mal configurados), los correos salientes legítimos —como notificaciones, facturas o correos de soporte— podrían ser rechazados por Outlook.com y no llegar a usuarios de ese servicio.
  • Servicios que envían correo en nombre de terceros: plataformas de mailing, CRM o aplicaciones que envían correos desde dominios de clientes deben asegurarse de que SPF, DKIM y DMARC estén correctamente implementados para cada dominio remitente.
  • Desarrolladores y responsables de WordPress y aplicaciones web: los plugins o scripts que envían correo (por ejemplo, notificaciones de usuarios, restablecimiento de contraseñas) deben usar mecanismos que respeten la autenticación del dominio del remitente.

Qué deben hacer los administradores

Si su correo puede verse afectado, estas son las acciones prácticas recomendadas:

  1. Verificar que el dominio tenga registros SPF que incluyan todos los servidores y servicios autorizados para enviar correo.
  2. Configurar DKIM para firmar los mensajes salientes; muchas plataformas permiten generar claves DKIM y publicar la clave pública en DNS.
  3. Publicar una política DMARC en DNS. Empiece con una política de monitoreo (p=none) para recibir informes y comprobar el estado antes de pasar a políticas más estrictas (p=quarantine o p=reject).
  4. Revisar los informes DMARC que reciba para identificar remitentes no autorizados y ajustar SPF/DKIM según sea necesario.
  5. Para envíos desde plataformas de terceros, asegurarse de que se use autenticación alineada (por ejemplo, que DKIM firme con el dominio propio o que el servicio autorice el envío vía SPF correctamente).

Impacto operativo y consideraciones

La medida de Outlook.com mejora la protección contra suplantación, pero puede aumentar la tasa de entrega fallida si los remitentes no adaptan su configuración. Para organizaciones con volúmenes altos de correo, es recomendable planificar la implementación de DMARC en fases y usar la recopilación de informes para ajustar registros sin interrumpir comunicaciones críticas.

Si ya tiene DMARC activo y recibe rechazos, revise los informes y la alineación entre SPF/DKIM y el dominio visible en el correo. En muchos casos los problemas derivan de envíos desde servicios externos no autorizados o de falta de firma DKIM.

Nota: esta noticia recoge la información publicada por una fuente especializada. No se incluyen fechas de implementación concretas ni cambios en políticas de Microsoft que no hayan sido detallados en esa fuente.

Lee también:

Fuente: GIGAZINE

Compartir