No hay un número universal, porque "cuántos correos al día" son dos preguntas encimadas. El límite técnico es lo que tu proveedor deja pasar antes de rechazar o retrasar el envío: Google Workspace publica 2,000 mensajes al día por buzón (Gmail sending limits in Google Workspace, Google Workspace Admin Help, consultado el 2026-09-18). El volumen sostenible es lo que la reputación de ese buzón aguanta antes de que el filtro del destinatario lo castigue, y ese no lo publica nadie: depende de tus rebotes.
¿Cuántos correos al día puedo enviar por buzón en 2026?
El límite técnico es idéntico para cualquier cuenta con el mismo plan, esté el dominio calentado desde hace tres años o desde ayer. El volumen sostenible es individual: dos buzones del mismo plan, con el mismo tope de 2,000, aguantan cifras distintas porque llegan con historiales distintos.
Confundir "el proveedor me deja enviarlo" con "es seguro enviarlo" es lo que quema un dominio sin violar ningún límite. Un buzón de Google Workspace creado esta mañana puede mandar 2,000 correos esta tarde sin que el servidor rechace uno solo. Ninguna alerta técnica avisa en el momento: el filtro de Gmail reacciona días después, cuando el lote ya salió y la reputación ya se movió.
La regla de decisión cabe en una línea. Si la semana que acaba de cerrar no dejó ninguna señal negativa, subes el volumen; si dejó una, no lo subes esa semana, sin importar cuán lejos estés del límite técnico. El techo que importa es el de cada buzón, y la capacidad se gobierna por mailbox. Topear campañas y dejar los buzones holgados es hacerlo al revés.
Los dos proveedores miden sobre una ventana móvil de 24 horas, no sobre el día de calendario (Google Workspace Admin Help y Microsoft Learn, consultados el 2026-09-18). Partir un envío entre las 11 de la noche y las 7 de la mañana no lo divide en dos días para el contador.
¿Cuál es el límite técnico de Google Workspace y Microsoft 365?
Google cuenta mensajes y Microsoft cuenta destinatarios, y esa sola diferencia decide qué fila te limita primero cuando mandas correos con un solo nombre en el To.
| Google Workspace | Microsoft 365 | |
|---|---|---|
| Qué cuenta | Mensajes enviados | Destinatarios, uno a uno |
| Tope por buzón | 2,000 al día (1,500 con mail merge; 500 en cuenta de prueba) | 10,000 destinatarios al día |
| Ritmo | Sin límite por minuto en esa documentación | 30 mensajes por minuto |
| Ventana | Móvil de 24 horas | Móvil de 24 horas |
| Al cruzarlo | Se rechaza el envío | El tope de destinatarios rechaza; el de 30 por minuto solo retrasa |
| Segundo techo | No tiene | TERRL por tenant, con NDR 550 5.7.233 |
Esa fila de "solo retrasa" importa más de lo que parece en la operación diaria. Cuando un buzón toca su ritmo —30 por minuto en Microsoft, o el tope que tu herramienta de secuencias le puso al mailbox—, el comportamiento correcto no es pintar un error rojo al operador. Es encolar el correo para la siguiente ventana y seguir. El mensaje no falló: se programó. Si la UI trata el rate limit como fallo, el equipo pausa campañas que solo estaban esperando su turno, o empieza a "arreglar" un buzón que no está roto.
La distinción es la misma que ya hace el proveedor: retraso ≠ rechazo. Una herramienta de outbound bien diseñada la refleja hacia quien opera. El correo que tocó el límite sale en la siguiente ventana móvil; el que cruzó el techo diario o el TERRL sí merece alerta, porque ahí el buzón de verdad dejó de enviar. Confundir las dos lecturas es cómo se inventan fires drills en un stack que solo estaba respetando su propio ritmo.
Fuentes: Gmail sending limits in Google Workspace (Google Workspace Admin Help, consultado el 2026-09-18) y Troubleshoot outbound sending limits in Exchange Online (Microsoft Learn, consultado el 2026-09-18).
El matiz del mail merge importa para quien manda outbound con la función nativa de Gmail o con una herramienta que la usa por debajo: el tope aplicable deja de ser 2,000 y pasa a 1,500. Descontarlo mal es la forma más común de creer que queda un margen técnico que no existe.
El TERRL (Tenant External Recipient Rate Limit) es el techo de Microsoft que no tiene equivalente en Google: limita los destinatarios externos de todo el tenant al día, escala automáticamente con el número de licencias y arranca en 5,000 para organizaciones de prueba. Se vigila con el reporte "Tenant Outbound External Recipients" del centro de administración de Exchange. Cuando se cruza, se bloquea el envío externo de todos los usuarios a la vez, no solo del buzón que se pasó.
Los dos números vienen de las propias empresas: Google y Microsoft documentan las reglas de su propio servicio. Son la fuente primaria y, a la vez, juez y parte, porque no existe un árbitro independiente que publique estos topes. El desglose fila por fila —destinatarios por mensaje, destinatarios únicos, tope que el administrador puede bajar— está en la comparativa de Google Workspace contra Microsoft 365 para outbound.
¿Por qué el número del proveedor no es el que te limita?
Pasarte del volumen sostenible no bloquea tu envío ese día. Te mueve a spam los días siguientes, y revertirlo toma tiempo que no controlas. El costo es de licencia y de calendario.
Un buzón de Google Workspace Business Starter cuesta $140 MXN por usuario al mes, en facturación flexible sin compromiso anual, y la página lo dice textual: "el precio es por usuario al mes y no incluye impuestos" (precios de Google Workspace para México, consultado el 2026-09-18). Con IVA de 16%, son $162.40 MXN por buzón. Ese cargo llega igual el mes en que el buzón manda 300 correos productivos que el mes en que no manda nada porque está recalentándose.
La aritmética del error, con los supuestos declarados: si quemas 5 buzones, la licencia sigue corriendo a 5 × $140 = $700 MXN al mes ($812 MXN con IVA) mientras esos buzones no envían nada útil. El calentamiento antes del primer correo real toma 3 semanas en nuestra operación (verificado el 2026-08-07); si recuperar un buzón dañado costara lo mismo (nadie publica esa cifra, el supuesto es nuestro), lo caro serían las 3 semanas de campaña detenida, más que los $700 MXN.
Ahora el caso contrario, con un ejemplo construido para el cálculo, no tomado de una campaña real. Un equipo con 5 buzones de Google Workspace, cada uno mandando 300 correos al día, suma 1,500 diarios. El tope técnico combinado es 5 × 2,000 = 10,000, así que ese equipo está al 15% de su capacidad técnica: margen de sobra, aparentemente. Si esos 5 buzones arrancaron en 300 desde el primer día, ese 15% no dice nada sobre si el volumen es seguro. La reputación se construye contra el historial del propio dominio, no contra el margen que queda hasta el tope del servidor. La capa de dominios y buzones como costo fijo está desarrollada en el stack completo de infraestructura de outbound.
¿Qué volumen aguanta un buzón según su fase?
Un buzón nuevo, o uno recién movido a outbound, necesita un rango bajo y creciente, gobernado por si la semana anterior dejó señales negativas y no por una tabla de "correos por día" copiada de otro dominio. El mecanismo completo, con el incremento exacto y cuándo pausar, está en cómo calentar un dominio nuevo sin quemarlo.
Un buzón con meses de historial y buena reputación sostiene un rango más alto, pero tampoco es un número fijo: lo marca la primera señal negativa contra su propia semana anterior. "Ya está calentado" describe un punto de partida más generoso, no una exención de vigilar. Un salto brusco quema un buzón viejo con la misma facilidad que uno nuevo. La fase cambia dónde arrancas, y la lógica con la que decides subir es la misma.
Los números de una operación propia dan la escala real. Dos campañas corridas sobre 31 buzones activos en 6 dominios (verificado por API el 2026-08-07) mandaron 4,804 correos a 1,657 empresas de industria, con 1.79% de rebote, y 9,211 correos a 3,162 empresas de software, con 1.40% de rebote y 96 respuestas humanas. En las dos, 2.9 correos por empresa. El umbral que esa operación usa como señal roja es 2% de rebote: un número medido contra sus propias campañas.
¿Qué señal dice que ya te pasaste del volumen sostenible?
Cuando el proveedor bloquea el envío, ya perdiste la semana. La señal aparece antes, en lo que tu propia lista te dice.
| Señal | Qué revisar | Contra qué se compara |
|---|---|---|
| Queja de spam | Cualquier queja, aunque sea una en un lote chico | Cero es el único número aceptable en el corto plazo |
| Rebote duro | Porcentaje por buzón, nunca en agregado | Tu propia semana anterior, no un promedio de mercado |
| Respuestas humanas | Caída respecto a tu línea base reciente | Tu propio histórico de las últimas 2-3 semanas |
Gmail pide mantener la tasa de queja de spam que reporta Postmaster Tools por debajo de 0.30%, idealmente por debajo de 0.10% (Directrices para remitentes de correo, Google, consultado el 2026-09-18). Con volumen bajo, ese umbral se cruza con una sola queja: en un lote de 300 correos, un reporte ya es 0.33%.
Superar 5,000 mensajes al día a cuentas de Gmail activa además los requisitos de remitente masivo (SPF, DKIM y DMARC, más baja de un clic en mensajes de marketing y suscripción), vigentes desde el 1 de febrero de 2024 (misma fuente). Ese umbral suma todos los buzones que le escriben a Gmail, sin importar desde qué proveedor envías: cinco buzones de Microsoft 365 mandando 1,200 correos cada uno a destinatarios de Gmail ya están en 6,000 y cruzaron la línea, aunque ninguno se acerque a esa cifra por separado. Cruzarlo no se resuelve repartiendo el volumen entre más buzones. Es una obligación de autenticación que hay que cumplir, y su configuración está en qué configurar antes del primer envío.
Al ver cualquiera de las tres señales de la tabla, la regla es bajar al último volumen que no las mostró, no cortar a cero. El daño ya ocurrió con el volumen que las disparó, y cortar de golpe desperdicia el calentamiento que el buzón había ganado antes de esa semana.
¿Cuándo no deberías subir el volumen esta semana?
No lo subes si la semana que acaba de cerrar dejó cualquier señal roja: una queja de spam, un rebote duro por encima de tu propia media o una caída de apertura contra tu línea base. Si subes igual, el filtro que ya te estaba castigando recibe más señal en la misma dirección, y el buzón sale de circulación hasta que la reputación se recupere, un plazo que ningún proveedor publica y que tú no controlas.
Tampoco lo subes solo porque estés lejos del límite técnico. Como muestra el ejemplo de los 5 buzones, estar al 15% del tope de Google no es evidencia de nada.
Y no lo subes si el rebote viene de la lista y no del volumen. Subir envíos sobre contactos sin verificar multiplica los rebotes duros, que es lo que más rápido daña la reputación de un dominio: ahí la variable a mover es la verificación.
Si la señal roja ya se disparó y la apertura o las respuestas cayeron de golpe, el diagnóstico está en otro artículo: qué revisar cuando la tasa de apertura cae de golpe tiene el árbol de decisión para una caída que ya ocurrió, del chequeo más barato al más caro.
¿Qué haces con esto esta semana?
Saca tres números por buzón, nunca en agregado, de la semana que acaba de cerrar, y compáralos contra la semana anterior:
- Rebotes duros, en porcentaje sobre los correos enviados por ese buzón.
- Quejas de spam, en unidades absolutas (una ya cuenta).
- Respuestas humanas, contra tu línea base de las últimas 2-3 semanas. (La tasa de apertura con pixel es señal sucia y el tracking daña entregabilidad: no la uses como referencia.)
Ese corte decide si puedes subir volumen. Si hoy no lo tienes, armarlo es la prioridad antes de tocar cualquier número, sin importar en qué rango estés: sin él adivinas contra un tope de servidor que nunca fue tu límite.
Mandar menos y mejor investigado es el trade que está detrás de las dos primeras letras del método IMPRO (Investiga, Mensajes que llegan, Personalizados, Respuestas, Oportunidades) que usa Improvitz, consultoría de prospección B2B con IA en México: 2.9 correos por empresa, no 2,000 al día por buzón. Si no sabes en qué punto de la curva está tu operación hoy, agenda un diagnóstico antes de mover el número.
Nota: los resultados citados corresponden a implementaciones concretas, con su propio punto de partida, equipo y stack. No son una proyección de lo que va a pasar en otra empresa. Este artículo describe cómo se construyó el sistema, no promete su resultado.
