Gestión del correo de clientes: cómo evitar el caos de la propiedad

Esta es la pregunta que pone en apuros a una agencia: ¿quién controla este buzón y quién puede restablecerlo? Usa 60 segundos como objetivo para consultar responsables y permisos, no como prueba de propiedad. La falta de claridad puede complicar una baja, una investigación de seguridad o el bloqueo de la cuenta support@ de un cliente.

No es un riesgo teórico. Los incidentes reales repiten el patrón: exempleados cuyo acceso nunca se revocó, soporte que aprobó un restablecimiento sin verificar la identidad o una contraseña compartida en Slack. El modelo operativo completo abarca dominios, enrutamiento y entregabilidad. Este artículo trata la propiedad: cómo evitar el caos antes de que empiece.

Cómo falla la gestión del correo de clientes (el patrón de la propiedad mal definida)

Una dependencia peligrosa puede empezar por comodidad. Un contratista crea support@ y conserva «temporalmente» la contraseña. Admin@ se convierte en destino de recuperación porque es fácil de recordar. Un buzón funcional pasa a ser un acceso compartido guardado en Notion. Nadie documenta qué buzón controla el registrador.

Después alguien se marcha, pero su acceso permanece. O soporte aprueba con urgencia un restablecimiento sin verificar la identidad. En su demanda, Clorox alegó que el soporte externalizado realizó varios restablecimientos de contraseñas y MFA sin verificar debidamente al solicitante. Es una alegación de la empresa, no una sentencia ni la prueba de que controlar un solo destino de recuperación explique todo el ataque.

Regla operativa: el destino de recuperación es una vía sensible de control. Si es una bandeja compartida o la dirección de un exempleado, revisa quién accede, las verificaciones adicionales y la autorización vigente.

El patrón es predecible:

1. Una decisión cómoda crea una dependencia sin documentar
2. La rotación de personal vuelve invisible esa dependencia
3. La urgencia evita la verificación que la habría detectado
4. Ocurre el incidente y todos discuten sobre la responsabilidad

La solución no es un memorando, sino un modelo estructural que separe expresamente propiedad y acceso.

Propiedad frente a acceso: la separación que evita gran parte del caos

Las agencias fallan cuando «quién lo usa» se convierte silenciosamente en «quién lo controla». Son conceptos distintos, y confundirlos origina muchas disputas sobre credenciales.

Propiedad = autoridad sobre el ciclo de las credenciales: quién puede restablecer, recuperar y conceder acceso.
Acceso = capacidad de leer y enviar correo según la política.

Este es el modelo mínimo de separación:

El requisito básico: la agencia aprovisiona los buzones, pero el usuario debe custodiar su contraseña personal, que puede cambiar y revocarse. Si tu personal «tiene la contraseña», añades un riesgo ante un incidente o una disputa.

El aprovisionamiento por invitación de TrekMail sigue este modelo. El destinatario autorizado define su contraseña mediante un enlace de un solo uso y con caducidad, y recibe un código de recuperación de un solo uso y vigencia limitada. La agencia debe verificar a quién invita y proteger el envío; custodiar la credencial no sustituye la autoridad de la empresa. Consulta las invitaciones para configurar buzones.

El modelo de traspaso en tres capas

Un traspaso real no consiste en «aquí está la contraseña». Termina con el usuario como autoridad de las credenciales, sin convertir a la agencia en su custodio.

Capa 1: responsable del cliente: decide quién accede, sobre todo a direcciones funcionales.
Capa 2: operador de la agencia: aprovisiona el buzón y aplica la política.
Capa 3: usuario o propietario: define su contraseña personal y recibe el mecanismo de recuperación.

Documenta cada buzón importante. Para gestionar clientes a escala necesitas una fuente única de verdad por buzón crítico:

mailbox:
  address: support@client-domain.com
  mailbox_type: role
  business_owner: "Client Ops Lead"      # approves membership and resets
  operator_team: "Agency Ops Team A"     # executes changes
  access:
    shared_login_allowed: false
    authorized_users:
      - alice@client-domain.com
      - bob@client-domain.com
  reset_policy:
    default: "user-driven reset"
    break_glass: "temp secret + force-change + dual approval"
  recovery:
    recovery_contact: "it-owner@client-domain.com"
    escalation_contact: "security@agency.com"
  last_reviewed_utc: "2026-01-28T00:00:00Z"

No es burocracia: es lo que consultas cuando alguien llama a las 11pm porque no puede entrar en su correo.

Restablecimientos en la gestión del correo de clientes: la jerarquía de procedimientos

Los restablecimientos pueden exponer a una agencia a una intrusión o una disputa. La urgencia puede favorecer la ingeniería social. La demanda de Clorox describe presuntas deficiencias de verificación en varios restablecimientos; no debe reducirse a un único cambio de contraseña como causa demostrada.

Usa siempre la opción de menor riesgo disponible:

1. Restablecimiento por token del usuario (predeterminado): tokens de corta duración; registra los eventos, no sus valores secretos. El operador no ve la contraseña personal.
2. Restablecimiento aprobado por el responsable (buzones funcionales): aprobación expresa y registrada antes de ejecutarlo.
3. Restablecimiento de emergencia (raro, solo para buzones de alto riesgo): secreto temporal aleatorio de un uso + cambio obligatorio + verificación adicional.

Este es un ejemplo de procedimiento de emergencia. Usa el cambio obligatorio solo si la plataforma lo admite; si no, confirma que el usuario ha cambiado la contraseña antes de cerrar el traspaso. Conserva evidencias antes de retirar reenvíos sospechosos, sin retrasar la contención. Revoca sesiones y tokens afectados según la plataforma:

BREAK-GLASS RESET RUNBOOK

1) VERIFY REQUESTER IDENTITY
   - Do not trust the ticket email alone
   - Use a pre-registered out-of-band channel
   - CEO/CFO/admin/postmaster mailboxes: require a second approver

2) CONTAIN
   - Freeze further changes until reset completes
   - Remove suspicious forwarding rules (common persistence path)

3) EXECUTE RESET
   - Set a unique random temp password (16+ chars)
   - Require password change at next login (must-change flag on)

4) NOTIFY AND LOG
   - Notify mailbox business owner + security contact
   - Record: requester, verifier, approver, executor,
     mailbox, timestamp (UTC), reason, ticket ID

5) CONFIRM CLOSURE
   - Confirm user rotated password and regained access
   - Re-review forwarding and delegations for persistence

Registra quién emitió el restablecimiento, cuándo y por qué; el aprobador; cambios de reenvío o delegación; y el estado anterior necesario para investigar. Restringe el acceso a los registros y excluye secretos y datos personales innecesarios. Solo restaura una configuración que siga siendo segura y autorizada, sin reactivar credenciales revocadas; el registro no es una copia de seguridad completa.

El autoservicio de TrekMail puede reducir las solicitudes de restablecimiento gestionadas por la agencia, pero sigue requiriendo verificación y protección de la recuperación. Consulta la documentación del cambio de contraseña por autoservicio.

Bajas: la lista que evita accesos fantasma

Una baja incompleta puede dejar accesos residuales. Cash App Investing comunicó a la SEC un acceso no autorizado de un exempleado a determinados informes después de terminar su empleo, no una intrusión en todo Cash App. El caso de Cisco descrito por el DOJ documenta acceso no autorizado a AWS tras una dimisión; no establece que el mecanismo fueran tokens huérfanos.

El objetivo es simple: conservar los datos y revocar todas las vías de acceso. No la mayoría, sino todas.

Lista mínima de baja para operadores:

1. Desactivar el acceso del usuario y comprobar la revocación efectiva de sesiones, tokens y credenciales según la plataforma, sin eliminar los datos que deban conservarse
2. Rotar las credenciales de cada buzón compartido o funcional que utilizó
3. Eliminar delegaciones y accesos compartidos
4. Eliminar o auditar reenvíos y excepciones catch-all
5. Retirar de inmediato las funciones administrativas, sin periodo de gracia
6. Registrar qué se revocó, quién lo hizo y cuándo (UTC)

«Desactivamos el buzón» suele ser solo parte del trabajo. La persistencia se oculta en reenvíos, delegaciones y excepciones «temporales». Revisa las tres antes de cerrar el ticket.

Buzones compartidos y direcciones funcionales: quién controla qué

Los buzones funcionales, support@, sales@ y billing@, combinan varios usuarios, rotación y urgencia («support@ no funciona»). Compartir una contraseña por comodidad añade riesgos de control y trazabilidad.

Reglas preventivas: no presupongas que evitan el 80% de los incidentes sin datos verificados:

• Ninguna contraseña compartida, ni en Slack, documentos u hojas de cálculo
• Cada buzón tiene un responsable del cliente que aprueba miembros y restablecimientos
• El operador ejecuta; el propietario aprueba cambios de acceso
• Los buzones de administrador y postmaster requieren operador sénior y doble aprobación

Usa esta matriz de propiedad o crea otra, pero ten una:

Para decenas de clientes, las invitaciones de TrekMail ofrecen configuraciones pendientes visibles y controles para reenviar o cancelar, sin convertir al equipo en una caja fuerte de contraseñas. Las invitaciones masivas a buzones sirven para grandes carteras de dominios.

El registro de auditoría: la memoria no es evidencia

Los registros ayudan a investigar disputas. Si un cliente afirma «nos habéis bloqueado», una revisión inicial de 10 minutos puede ser un objetivo de planificación, no un plazo garantizado de resolución. La evidencia disponible y el alcance del incidente determinarán el trabajo necesario.

Debes responder cinco preguntas en todo momento:

• ¿Qué cambió?
• ¿Quién lo cambió?
• ¿Cuándo (UTC)?
• ¿Por qué (ticket o ID de aprobación)?
• ¿Cuál era el estado anterior (para revertir)?

Eventos mínimos que registrar:

• Buzón creado o eliminado
• Invitación enviada, reenviada o cancelada
• Restablecimiento emitido y aprobado
• Código de recuperación regenerado
• Delegación añadida o retirada
• Reenvío o catch-all activado o desactivado
• Destino de enrutamiento cambiado
• Permisos administrativos cambiados

No presupongas una cobertura del 90% de las disputas sin datos verificados. Comprueba qué eventos registra realmente tu plataforma y sus lagunas; conserva la evidencia disponible sin inventar un historial retroactivo.

El procedimiento de una página que necesita cada agencia

Esta es la versión mínima para evitar el caos. Sin documentarla, improvisas con producción:

Diagnóstico rápido cuando «el correo no funciona»:

1. Alcance: ¿un buzón, dominio o toda la cartera?
2. Dirección: ¿entrada, salida o ambas?
3. Categoría: ¿DNS/autenticación, enrutamiento o credenciales?
4. Estabilizar: conservar evidencias y restaurar solo un estado seguro y actualmente autorizado
5. Registrar: quién cambió qué y por qué

El papel de TrekMail en la gestión del correo de clientes

El método manual funciona, pero escala mal. Cada dominio, buzón funcional y baja crea otra oportunidad de que falle un traspaso si se gestiona en hojas y Slack.

TrekMail es un centro multidominio para agencias: dominios, buzones, enrutamiento y envío desde un panel. Su arquitectura sigue este modelo:

• Aprovisionamiento por invitación: el destinatario autorizado define su contraseña mediante un enlace de un solo uso y con caducidad; la agencia verifica a quién invita, sin recopilar la contraseña.
• Códigos de recuperación de un solo uso: se generan al configurar, tienen vigencia limitada y debe protegerlos el destinatario autorizado.
• Configuraciones pendientes visibles: consulta, reenvía o cancela invitaciones según los permisos disponibles.
• Prioridad a los estándares: IMAP/SMTP y almacenamiento compartido sujetos al plan y sus cuotas. Verifica los derechos de SMTP gestionado; solo en el modelo Nano descrito, todo envío, incluidas las respuestas, requiere SMTP propio.

El ejemplo histórico del plan gratuito cita 10 dominios, 10 usuarios/dominio y 5GB compartidos. Agency se describe con 1,000+ dominios, 200GB+ compartidos y soporte dedicado. Verifica disponibilidad, precios por cuenta, límites y soporte actuales en el desglose completo de precios.

Para la implementación, consulta cómo crear un buzón y la lista de primera configuración.

La gestión del correo de clientes depende de una propiedad clara

Gestionar bandejas de clientes comparte patrones con la gestión del correo de usuarios: las mismas reglas de propiedad, recuperación y bajas sirven para agencias y usuarios directos.

No consiste solo en «hacer funcionar buzones», sino en poder identificar responsables y permisos bajo presión. Una búsqueda de 20 minutos entre conversaciones de Slack ilustra el coste de no mantener un registro accesible, no un plazo fijo.

Aplica lo básico: separa propiedad y acceso, documenta buzones críticos, trata restablecimientos y bajas como operaciones controladas y conserva una auditoría defendible. Es el mínimo que ayuda a evitar incidentes capaces de romper la relación con el cliente.

Deja atrás el caos de propiedad. Prueba TrekMail gratis y gestiona el correo como infraestructura, no como una hoja de cálculo.