Permisos mínimos para que una aplicación lea metadatos de correo en Microsoft 365 y Google Workspace
Qué incluye cada nivel de acceso al correo en Microsoft Graph y Gmail API, cómo acotar un permiso de aplicación a ciertos buzones y qué permisos pide EmailDelDia para leer metadatos.
Cuando una herramienta pide acceso al correo de la organización, quien concede el permiso necesita saber qué puede leer exactamente. Microsoft 365 y Google Workspace permiten conceder desde accesos que alcanzan el contenido de todos los buzones hasta accesos que solo ven cabeceras, fechas y participantes. La diferencia está en el permiso que se elige, en el ámbito al que se limita y en quién conserva la credencial.
Esta guía explica qué incluye cada nivel de acceso, qué pide EmailDelDia y cómo acotarlo. Antes de conceder nada, conviene leer la guía sobre auditar el correo en Microsoft 365 y Google Workspace, que describe qué registran las plataformas y qué queda fuera de ellas.
Lo que se describe se ha contrastado con la documentación de Microsoft y de Google a 16 de octubre de 2026, y con el código de los conectores de EmailDelDia. Si la documentación cambia, manda la versión vigente.
Metadatos o contenido: qué separa cada nivel
En el correo hay tres capas. Los metadatos son los datos del sobre y de la cabecera: quién escribe, a quién, cuándo y con qué identificador. El asunto es un dato intermedio, porque a menudo dice más de lo que parece. El contenido es el cuerpo del mensaje, su vista previa y los adjuntos.
En Microsoft Graph, Mail.ReadBasic.All permite leer las propiedades básicas de los mensajes en todos los buzones, sin usuario que inicie sesión. Según la referencia de permisos de Microsoft Graph, deja fuera el cuerpo, la vista previa (previewBody), los adjuntos y las propiedades extendidas. En Gmail, gmail.metadata da acceso a cabeceras y etiquetas, pero no al cuerpo, según la documentación de ámbitos de la API de Gmail.
| Nivel | Qué incluye | Qué queda fuera |
|---|---|---|
| Metadatos | Remitente, destinatarios, fecha, identificador del mensaje, etiquetas y participantes | Cuerpo, vista previa y adjuntos |
| Asunto | Texto del asunto | Cuerpo, vista previa y adjuntos |
| Contenido | Vista previa o cuerpo completo, según el permiso o el ámbito concedido | Nada, si el permiso es de contenido completo |
El asunto merece atención propia. Un asunto como «Propuesta confidencial para el cliente» ya revela bastante. EmailDelDia solo guarda el asunto si la organización activa la retención de contenido. En Gmail, según el código revisado, ni siquiera se pide la cabecera Subject mientras esa retención esté en cero días.
Microsoft Graph: permisos de aplicación
Una aplicación que trabaja sin usuario que inicie sesión usa permisos de aplicación. Estos permisos requieren consentimiento de un administrador y, si no se acotan, alcanzan a todos los buzones del inquilino.
Para leer correo, las dos opciones habituales son Mail.ReadBasic.All y Mail.Read. El primero da acceso a las propiedades básicas de los mensajes y deja fuera el cuerpo, la vista previa, los adjuntos y las propiedades extendidas. El segundo permite leer el contenido completo del mensaje. La diferencia está en qué contenido queda al alcance de la aplicación.
Para saber a qué usuario y a qué buzón corresponde cada mensaje, el producto necesita además lectura de directorio: User.Read.All para usuarios, alias y licencias asignadas; GroupMember.Read.All para grupos y pertenencias, con Group.Read.All como alternativa; y LicenseAssignment.Read.All para el catálogo de licencias del inquilino.
EmailDelDia también puede pedir Mail.Read, y conviene entender por qué es opcional. Con ese permiso, la aplicación puede leer el contenido completo de los mensajes. El producto solo selecciona la vista previa (bodyPreview), y solo si la organización ha activado la retención de contenido. Un permiso que da más de lo que se usa es más amplio de lo necesario, así que conviene concederlo solo si la organización lo quiere de forma expresa.
MailboxSettings.Read también es opcional. Sirve para confirmar qué buzones son compartidos. Sin él, un buzón que parece compartido queda marcado como sin confirmar.
Limitar la aplicación a ciertos buzones
Exchange Online permite acotar un permiso de aplicación a un conjunto de buzones con RBAC para aplicaciones. Microsoft indica que este mecanismo sustituye a las antiguas directivas de acceso a aplicaciones y que el ámbito se suma a lo que se conceda en Entra ID. En líneas generales, el proceso tiene cinco pasos:
- Definir el ámbito: un ámbito de gestión con un filtro de destinatarios o una unidad administrativa de Entra ID. Microsoft recomienda la unidad administrativa como parámetro de la asignación, para no crear un ámbito intermedio.
- Registrar la aplicación en Exchange con
New-ServicePrincipal, usando el ID de aplicación y el ID de objeto de la entidad de servicio en Entra ID. - Crear la asignación de rol con
New-ManagementRoleAssignment, indicando la aplicación y el ámbito. - Retirar la concesión global del mismo permiso en Entra ID.
- Comprobar el resultado con
Test-ServicePrincipalAuthorization.
El cuarto paso es el que más se olvida, y el que más importa. Los permisos de Entra ID y los de RBAC se suman. Si la aplicación conserva Mail.Read sin ámbito en Entra ID, el acotado en RBAC no restringe nada, porque la suma de una concesión sin ámbito y otra acotada deja el acceso sin restricción efectiva.
Los cambios también tardan en aplicarse. Según la documentación de RBAC para aplicaciones en Exchange Online, la caché de permisos de una aplicación se renueva entre 30 minutos y 2 horas, según su actividad reciente. El comando de prueba salta esa caché, así que valida la configuración, pero no garantiza lo que la aplicación ve en ese momento. Si la aplicación está en uso durante el cambio, conviene esperar a que pase la ventana antes de dar la configuración por cerrada.
La tabla de roles de esa documentación nombra el rol como Application Mail.ReadBasic y lo asocia al permisoMail.ReadBasic, sin el sufijo .All que usa EmailDelDia. Antes de confiar en el acotado, comprueba con Test-ServicePrincipalAuthorization que el ámbito se aplica a la concesión que de verdad vas a hacer.
Google: cuenta de servicio y delegación de todo el dominio
En Google Workspace, la aplicación actúa como una cuenta de servicio con delegación de todo el dominio. El superadministrador autoriza en la consola el identificador numérico de cliente de esa cuenta y la lista de ámbitos permitidos. Google advierte de que, si se autoriza la cuenta por su dirección de correo en lugar de por el ID numérico, la petición falla con un error unauthorized_client.
Google también señala lo que la delegación no limita, y conviene leerlo dos veces. Según sus buenas prácticas para la delegación de todo el dominio, los ámbitos no restringen a qué usuarios se puede suplantar: solo limitan qué tipos de datos se pueden leer. Para acotar quién puede usar la cuenta de servicio, Google recomienda roles de IAM. Y antes de nada, recomienda evitar la delegación de todo el dominio si el trabajo se puede hacer de otra manera.
Los ámbitos que pide EmailDelDia son cinco. Tres son de solo lectura del directorio: admin.directory.user.readonly para usuarios, alias y suspensiones; admin.directory.group.readonly para grupos y miembros; y admin.directory.domain.readonly para reconocer los dominios propios. Gmail usa gmail.metadata, que da cabeceras y etiquetas sin cuerpo ni adjuntos, y gmail.settings.basic, que el producto usa para leer los alias de envío (sendAs).
Hay que anotar un detalle. gmail.settings.basic permite también cambiar ajustes y filtros de Gmail. El código de EmailDelDia solo consulta los alias, pero el ámbito, tal como lo define Google, es más amplio que esa lectura.
Hay además una limitación en la búsqueda. La referencia del método messages.list indica que el parámetro q no puede usarse con el ámbito gmail.metadata. Por eso la sincronización no busca por texto: recorre los mensajes del más reciente al más antiguo y se detiene al llegar a la ventana de histórico configurada.
Google clasifica gmail.metadata y gmail.settings.basic como ámbitos restringidos. Antes de fijar fechas con un proveedor, conviene confirmar en la documentación vigente qué exige Google para ellos.
Credenciales de la propia organización
Quién es titular de la credencial pesa tanto como los permisos. EmailDelDia permite que cada organización use su propia aplicación de Entra ID, registrada en su inquilino y consentida por su administrador. Si existe una aplicación de la plataforma, solo se usa cuando la organización no aporta la suya.
Con la aplicación en su propio inquilino, la organización ve el consentimiento, puede retirarlo y puede eliminar la aplicación desde su portal de Entra ID.
En Google, la credencial es una clave JSON de una cuenta de servicio del proyecto de Google Cloud de la organización. La documentación de Google indica que esa clave privada es la única copia, porque Google solo guarda la parte pública. Hay que almacenarla y gestionarla con seguridad en desarrollo y en producción, y si se pierde, hay que generar otra. Google recomienda también evitar las claves de cuentas de servicio cuando sea posible y usar alternativas, como la API signJwt.
Retirar el consentimiento o la delegación corta el acceso. Después, la cuenta de servicio o la aplicación pueden eliminarse sin dejar nada activo.
Revisar lo concedido
Una concesión que nadie revisa acaba siendo un permiso heredado. En Microsoft Entra ID, revisa los permisos de aplicación en el apartado de aplicaciones empresariales o de registros de aplicaciones. El acotado de RBAC se revisa aparte, con los cmdlets de asignación de roles de Exchange Online PowerShell. Microsoft anuncia una vista unificada de estos permisos en Entra ID, pero en la documentación revisada figura como próxima, así que conviene mirar las dos partes.
En Google, la delegación se revisa en la consola de administración, en la sección de controles de API, donde aparecen los identificadores de cliente y sus ámbitos. Google recomienda además revisar quién tiene acceso a la cuenta de servicio con la API de Cloud Asset Inventory, y vigilar los roles que permiten crear tokens o gestionar claves de cuentas de servicio.
Lo que pide EmailDelDia
La tabla recoge los permisos que pide el código de sincronización revisado y su uso. Los marcados como opcionales no son necesarios para la sincronización básica de metadatos.
| Plataforma | Permiso o ámbito | Obligatorio | Para qué se usa |
|---|---|---|---|
| Microsoft 365 | User.Read.All | Sí | Usuarios, alias y licencias asignadas |
| Microsoft 365 | GroupMember.Read.All | Sí (o Group.Read.All) | Grupos y pertenencias |
| Microsoft 365 | LicenseAssignment.Read.All | Sí | Catálogo de licencias del inquilino |
| Microsoft 365 | Mail.ReadBasic.All | Sí | Metadatos del correo; el asunto solo con retención de contenido |
| Microsoft 365 | MailboxSettings.Read | No | Confirmar qué buzones son compartidos |
| Microsoft 365 | Mail.Read | No | Vista previa, solo con retención de contenido activa |
| Google Workspace | admin.directory.user.readonly | Sí | Usuarios, alias y suspensiones |
| Google Workspace | admin.directory.group.readonly | Sí | Grupos y miembros |
| Google Workspace | admin.directory.domain.readonly | Sí | Dominios propios |
| Google Workspace | gmail.metadata | Sí | Cabeceras y etiquetas; sin cuerpo ni adjuntos |
| Google Workspace | gmail.settings.basic | Sí | Alias de envío de cada buzón |
El asunto de Gmail no necesita un permiso adicional, porque se lee de la cabecera con el mismo ámbito. Con gmail.metadata tampoco se sabe si un mensaje lleva adjuntos. Si la cola de correo gira en torno a facturas, esa parte se mide por otro medio. El detalle por fuente está en integraciones.
Preguntas frecuentes
¿Mail.ReadBasic.All permite leer el asunto de los correos?
Sí. Microsoft describe el permiso como acceso a todas las propiedades básicas salvo el cuerpo, la vista previa, los adjuntos y las propiedades extendidas, y el asunto no figura entre las exclusiones. EmailDelDia solo guarda el asunto si la organización activa la retención de contenido.
¿Puedo dar acceso solo a los buzones de un departamento?
En Microsoft 365, sí, con RBAC para aplicaciones, siempre que retires la concesión global en Entra ID y compruebes el resultado con Test-ServicePrincipalAuthorization. En Google Workspace, la delegación no se acota por buzón: los ámbitos limitan el tipo de datos, no las cuentas. El control queda en quién puede usar la cuenta de servicio, con roles de IAM.
¿EmailDelDia lee el cuerpo de los correos?
No con los permisos que pide por defecto. Mail.Read da acceso técnico al contenido completo, pero el producto solo selecciona la vista previa, y solo si la organización activa la retención de contenido. Por eso el permiso es opcional.
¿Qué pasa si retiro un permiso a la aplicación?
Las siguientes sincronizaciones dejan de obtener los datos que dependían de ese permiso y fallan con un error de acceso. En Microsoft, se retira en Entra ID y se revisa el acotado de RBAC; en Google, se retira el ámbito de la delegación. Los datos ya guardados no se borran por retirar un permiso: el momento de eliminarlos lo fija la retención de la organización.
¿Por qué la aplicación debe estar registrada en mi inquilino?
Porque así la organización controla el consentimiento, puede verlo y retirarlo desde su propio portal, y no depende de una aplicación compartida para cortar el acceso. Cuando la organización aporta sus propias credenciales, esa es la configuración que el producto usa con preferencia.