onmicrosoft.com ya no es solo un dominio feo: es un carril lento

El 28 de agosto Microsoft publicó en el centro de mensajes el aviso MC1463510: las organizaciones que solo usan el dominio por defecto *.onmicrosoft.com van a tener límites de mensajería externa en Teams. El despliegue mundial es de mediados de septiembre, o sea, ya, viene activado de fábrica y no hay nada que un administrador tenga que encender. Leído solo, es un ajuste antispam de los que no llegan ni a la reunión del lunes. Leído junto a lo que ya pasó con el correo, es otra cosa: Microsoft lleva un año convirtiendo el dominio por defecto en un carril lento, servicio a servicio, y el del correo terminó de aplicarse a todos los tamaños de empresa el 1 de junio.

Qué es ese dominio y para qué estaba pensado

Cuando alguien crea un tenant de Microsoft 365, Microsoft le regala un dominio: loquesea.onmicrosoft.com. Se llama MOERA —Microsoft Online Email Routing Address— y en la documentación del equipo de Exchange su propósito está escrito sin ambigüedad: «These MOERA (Microsoft Online Email Routing Address) domains enable immediate connectivity and user creation. Having enabled a quick start and testing of a new tenant, customers are expected to add their own custom domains for better brand representation and control moving forward.» Es el dominio de arranque. La rampa de entrada, no la autopista.

Lo que ha cambiado no es la intención, que siempre fue esa, sino que ahora hay consecuencias. La frase que marca el giro es cortita: «In the future, MOERA domains should only be used for testing purposes, not regular email sending.» Y unas líneas antes, cerrando el apartado anterior, la confesión de que hasta entonces esto era barra libre: «Until now, we did not have any limits on use of MOERA domains for email delivery.»

El límite del correo ya se aplica a todo el mundo

El número es 100 destinatarios externos por ventana móvil de 24 horas. Lo de entrada no se toca. Y hay un detalle en la letra pequeña que decide si te afecta o no: «External recipients are counted after the expansion of any of the original recipients.» Es decir, se cuentan después de expandir las listas. Un correo a una lista de distribución con sesenta contactos externos consume sesenta, no uno. Quien manda un aviso a clientes desde un buzón de este tipo llega al tope con dos envíos y sin haber hecho nada raro.

Cuando se llega al tope, el remitente recibe un rechazo con este texto, que conviene tener a mano porque es lo único que verá quien llame al soporte:

550 5.7.236 Your message can't be sent because your tenant has
exceeded its daily limit for sending email to external recipients
from your tenant's onmicrosoft.com domains

El despliegue fue escalonado por número de asientos de Exchange en el tenant, y este es el calendario completo que publicó Microsoft:

Mira la última fila y mira el calendario. No queda ninguna banda pendiente. Esto no es algo que vaya a pasar: pasó, y a la empresa de once personas le llegó el 2 de febrero. Si alguien de tu organización envía correo externo desde una dirección acabada en .onmicrosoft.com, el límite lleva meses aplicándose, y lo más probable es que nadie lo haya relacionado con el rechazo raro que salió un martes. Y conviene releer ese rechazo, porque el tope no es por buzón: la frase dice «your tenant has exceeded its daily limit». Es una cuota del tenant entero. Un solo remitente olvidado se la puede comer, y el rebote le llega a todos los demás.

El motivo, dicho por ellos: es un barrio, no una casa

Microsoft explica por qué esto no se arregla portándote bien: «because these domains all share the 'onmicrosoft' domain (for example, 'contoso.onmicrosoft.com'), their reputation is collectively impacted», y a continuación: «spammers often exploit newly created tenants to send bursts of spam from '.onmicrosoft.com' addresses before we can intervene. This degrades this shared domain's reputation, affecting all legitimate users.»

Traducido a lo que significa para ti: tu tenant no tiene mala reputación por nada que haya hecho tu gente. La tiene por el apellido. Vive en un barrio al que se muda cada spammer del mundo en cuanto abre una cuenta de prueba, y la única salida del barrio es mudarse. Microsoft ni siquiera lo esconde: la solución que propone es que tu empresa tenga su propio dominio y lo use para enviar. Lo caro viene después.

Y ahora Teams, con el umbral sin publicar

El aviso de agosto aplica la misma idea al chat. Alcance: organizaciones que solo tienen el dominio por defecto; si ya tienes uno propio verificado, no va contigo. Efecto: al superar el umbral, el usuario queda temporalmente sin poder mandar mensajes a externos, ve un aviso dentro del producto y recupera la capacidad solo cuando la actividad baja. Lo interno no se toca. Y no hay nada que encender: viene activado.

Lo que el aviso no trae es el número. En el correo sabes que son cien y sabes qué rechazo vas a ver; en Teams sabes que hay un tope y que Microsoft espera que la mayoría de organizaciones no lo rocen, pero no sabes dónde está. Es una diferencia que importa a la hora de dar soporte: cuando un usuario diga que no puede escribir a un proveedor, no vas a poder decirle cuántos mensajes le quedan ni cuánto tiene que esperar. Vas a poder decirle por qué.

El caso que pilla a quien se cree a salvo

Los dos cambios tienen alcances distintos y ahí está el detalle que casi nadie separa. El de Teams va contra organizaciones que solo usan el dominio por defecto. El del correo, en cambio, está escrito de otra forma: limita «messages sent from your organization's onmicrosoft.com domains». No dice tenants sin dominio propio: dice mensajes enviados desde esas direcciones. Tu empresa puede llevar quince años con su dominio y tener, aun así, remitentes que salen por el de fábrica.

Los sospechosos habituales son siempre los mismos, y ninguno es una persona: el buzón desde el que la multifunción manda los escaneos, la cuenta de servicio del ERP que envía facturas, el remitente de las alertas de monitorización, el usuario que se creó para una integración y nunca pasó por el alta ordenada. Nadie les cambió nunca la dirección principal porque nadie los mira: no están en la lista de empleados, no tienen jefe y no se quejan. Es la misma familia de objetos de la que hablábamos cuando contamos que en el directorio hay más fichas que empleados, y la misma que aparece cuando se queda un Exchange encendido después de la migración.

Cómo saberlo esta mañana

En el centro de administración, Configuración → Dominios: si el único que aparece acaba en .onmicrosoft.com, el aviso de Teams va contigo y no hay más que hablar. Si hay dominio propio, la comprobación interesante es la otra, y son dos órdenes de Exchange Online PowerShell:

Get-AcceptedDomain | Format-Table DomainName, Default

Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.PrimarySmtpAddress -like "*.onmicrosoft.*" } |
  Format-Table DisplayName, PrimarySmtpAddress, RecipientTypeDetails

La primera dice cuál es el dominio predeterminado de Exchange. La segunda saca los buzones cuya dirección principal sigue siendo la de fábrica, que es la lista que de verdad importa: ahí aparecen los buzones compartidos y las salas antes que las personas. El comodín del final del patrón está puesto a propósito, porque hay dominios por defecto que no acaban en .com; y si aparece algo con mail.onmicrosoft.com, no lo cuentes todavía como problema: Microsoft dice que esos dominios de enrutado híbrido no se limitan mientras no se usen para tráfico original. La tercera comprobación no es un comando y la explica la propia página de Microsoft: en el seguimiento de mensajes del centro de administración de Exchange, pon un comodín en el campo de remitentes para sacar todo el tráfico que sale por tu dominio de fábrica, y quita después el interno filtrando por dominio del destinatario. Si ahí hay correo yendo a clientes, esto no es una hipótesis.

Arreglarlo no es comprar un dominio

Microsoft describe la solución en cuatro pasos —comprar el dominio, usarlo solo para envíos reales, ponerlo como predeterminado y cambiar la dirección SMTP principal de los buzones— y a continuación añade la frase que convierte el tercer paso en un proyecto: «Changing the primary SMTP address will have an impact on the username used to log into accounts so updates may need to be made to any credentials configured to authenticate devices or applications with users' accounts.»

Ahí está la factura real. Lo que se toca no es una dirección de correo: es el nombre con el que la gente inicia sesión, y detrás vienen las impresoras configuradas con una cuenta, los dispositivos que autentican con un usuario, las aplicaciones que guardan credenciales de alguien y los scripts que nadie recuerda haber escrito. Se hace, se hace bien y se hace por lotes, pero no se hace un viernes por la tarde ni en una ventana de dos horas. Microsoft añade además un caso aparte: «Customers with Federated Domains will have to add a non-Federated custom domain in Microsoft 365 to act as a default domain». Si tu identidad está federada, hay un paso extra antes de empezar.

Nuestra opinión, dicha como opinión: esto no es una emergencia y tratarlo como tal es la forma de romper algo. Es una tarea de fondo con una fecha que ya pasó, y el orden que funciona es al revés de como suele plantearse —primero los remitentes que no son personas, que se arreglan sin avisar a nadie y son los que consumen el límite; después las personas, con calendario y aviso—. Y como con todo lo que cuelga de este proveedor, conviene recordar que aquí seis servicios dependen de una sola cosa: el nombre con el que entras.

Nota de fuentes

Todo consultado el 20 de septiembre de 2026. Uno: la entrada del blog del equipo de Exchange «Limiting Onmicrosoft Domain Usage for Sending Emails», publicada el 20 de agosto de 2025 y actualizada por última vez el 30 de marzo de 2026 (versión 9.0), de donde salen todas las citas en inglés sobre el correo, el límite de 100 destinatarios externos por ventana móvil de 24 horas, el texto del rechazo 550 5.7.236, la tabla completa de despliegue por asientos, la explicación de la reputación compartida, los pasos que recomienda Microsoft y las dos advertencias sobre el nombre de inicio de sesión y los dominios federados. Dos: el aviso del centro de mensajes de Microsoft 365 MC1463510, «External messaging limits for onmicrosoft.com-only organizations in Microsoft Teams», publicado el 28 de agosto de 2026, con disponibilidad general mundial desde mediados de septiembre de 2026; de ahí salen el alcance (organizaciones que solo usan el dominio por defecto), el efecto temporal sobre la mensajería externa con recuperación automática, que lo interno no se ve afectado y que la protección se activa sin intervención del administrador. Lo que no afirmamos: no hemos reproducido ninguno de los dos límites en un tenant propio; el umbral de Teams no lo publica Microsoft y por eso no damos ninguna cifra; y las dos órdenes de PowerShell son comprobaciones de lectura que no modifican nada, pero cada cual las ejecuta en su tenant. Opinión nuestra: que los dos cambios se leen mejor juntos que por separado; que el caso que más se escapa son los remitentes que no son personas; que el coste real está en el nombre de inicio de sesión y no en el dominio; y el orden que proponemos para arreglarlo.

Imagen de portada: fotografía de dominio público, recortada por nosotros. Los textos y la marca los añadimos nosotros encima.