# Dual delivery: ¿migración segura o caos por duplicado? > Cómo usar dual delivery durante una migración de correo, conservar una vía de retorno y evitar que dos buzones se conviertan en caos permanente. - Source: https://www.techcroud.com/es/blog/dual-delivery-migracion-segura-o-caos-duplicado - Author: Karol Barański (https://www.linkedin.com/in/karol-baranski-96529a3/) - Publisher: techcroud.com Sp. z o.o. (https://www.techcroud.com) - Published: 2026-07-20 - Updated: 2026-07-20 - Language: es --- Una migración de correo tiene un momento decisivo poco cómodo. Durante semanas se preparan cuentas, dominio, controles de seguridad y datos. Después llega la tarde en que hay que pasar toda la organización del sistema anterior al nuevo. A partir de ese instante, un grupo ausente, un alias mal configurado o una aplicación incompatible deja de ser un punto en una lista. Se convierte en un problema para los usuarios. Es natural preguntarse si durante un tiempo los mensajes pueden llegar a ambos sistemas. El buzón antiguo sigue funcionando, el nuevo recibe una copia, el equipo observa el tráfico real y solo entonces realiza el cambio definitivo. Sí, se puede. Este modelo se llama **dual delivery** y puede ser una excelente fase de migración. Da tiempo para encontrar carencias, comparar filtros y validar la plataforma de destino con tráfico real. Sin embargo, no sincroniza dos buzones ni protege automáticamente frente a cualquier fallo. Sin un objetivo y una fecha final claros, crea dos versiones distintas de la misma correspondencia. ## Un mensaje, dos lugares de entrega Con dual delivery, un mensaje llega primero al sistema indicado por el registro MX del dominio. Ese sistema lo entrega al buzón principal y envía una copia adicional a la segunda plataforma de correo. ![Dual delivery durante una migración: plataforma principal y copia entregada al sistema de destino](/images/blog/dual-delivery-flow.svg) El usuario continúa trabajando en el buzón principal. Al principio, el segundo buzón sirve para observar: recibe correo real y permite validar routing, políticas de seguridad, alias y rendimiento de la plataforma de destino. Google Workspace admite oficialmente este modelo y documenta la entrega simultánea en Gmail y en un sistema externo, como Microsoft Exchange o un servidor de archivo. Google recomienda Gmail como servidor principal, aunque también permite mantener el sistema anterior como primario durante un piloto o una migración. [Documentación de dual delivery](https://knowledge.workspace.google.com/admin/gmail/advanced/deliver-email-to-multiple-inboxes-with-dual-delivery?hl=es) Dual delivery es distinto del [modelo split delivery](/es/blog/un-dominio-dos-correos-split-delivery) que analizamos en el artículo anterior. Con split delivery, usuarios diferentes tienen sus buzones en sistemas distintos. Con dual delivery, el mismo mensaje se copia en dos lugares. ## Por qué funciona como primera fase de una migración Un cambio completo exige confiar al mismo tiempo en cuentas, DNS, rutas, seguridad, aplicaciones emisoras, dispositivos móviles y procedimientos de soporte. Unas pocas pruebas artificiales no revelan todas las dependencias. Dual delivery introduce tráfico real en la plataforma de destino antes de que toda la organización dependa de ella. Permite comprobar: - si todas las direcciones activas existen en el sistema de destino, - si funcionan alias, grupos y buzones compartidos, - cómo clasifica la nueva plataforma el spam, el phishing y los adjuntos, - si llegan los mensajes de formularios, CRM, contabilidad y dispositivos, - cuánto retraso añade la ruta secundaria, - si el administrador puede localizar un mensaje concreto en los logs, - si las políticas de retención y protección cubren las cuentas correctas. La principal ventaja no consiste en tener dos copias, sino en observar el sistema de destino sin convertirlo inmediatamente en una dependencia crítica para toda la empresa. ## Escenarios donde dual delivery tiene sentido ### Migración entre Google Workspace y Microsoft 365 La plataforma de destino está preparada, las cuentas existen y los datos históricos se trasladan por lotes. Dual delivery hace que los mensajes nuevos también aparezcan en el destino, reduciendo el intervalo entre la primera migración de datos y el cutover final. Esto no elimina la necesidad de una migración incremental. Los enviados, carpetas, etiquetas, contactos, calendarios y cambios realizados por los usuarios siguen necesitando un proceso aparte. ### Piloto antes de decidir una compra o migración La organización quiere evaluar la nueva plataforma con mensajes reales sin cambiar todavía la forma de trabajo de toda la plantilla. Un grupo seleccionado puede revisar entrega, protección y administración antes de anunciar una migración. Un piloto necesita criterios de éxito. «Los mensajes llegan» dice poco. Conviene medir tiempo de entrega, falsos positivos, cobertura de alias, calidad de los logs y número de intervenciones del administrador. ### Adquisición o fusión de empresas Después de una operación corporativa, la continuidad de las comunicaciones suele ser urgente aunque la plataforma definitiva todavía no esté decidida. Dual delivery proporciona tiempo para inventariar y probar. Si distintos grupos van a permanecer en sistemas diferentes, el diseño posterior puede ser split delivery. Si toda la organización va a una sola plataforma, dual delivery debe terminar con un cutover. ### Comparación de la protección de correo Los mismos mensajes pueden llegar temporalmente a dos plataformas para comparar la detección de spam, phishing, archivos maliciosos y enlaces sospechosos. Hay que interpretar los resultados con cuidado: el sistema secundario recibe correo reenviado por el principal y puede ver un contexto SMTP diferente. ### Copia destinada a un archivo Google incluye un servidor de archivo entre los posibles destinos adicionales. Solo tiene sentido si el segundo sistema funciona realmente como archivo controlado. Un buzón normal no garantiza inmutabilidad, retención, auditoría ni protección frente al borrado. Los requisitos legales suelen conducir a journaling o a un archivo dedicado, no a otro buzón del usuario. ## Qué copia dual delivery y qué deja fuera Al principio ambos buzones pueden parecer idénticos. Contienen los mismos mensajes entrantes y una estructura de cuentas parecida. La diferencia aparece con la primera acción del usuario. ![Separación progresiva de los buzones: mensajes iguales el primer día y distintos enviados, respuestas, reglas y calendarios semanas después](/images/blog/dual-delivery-drift.svg) Dual delivery puede copiar un mensaje entrante. No sincroniza automáticamente: - estado leído o no leído, - respuestas y elementos enviados, - borrado y movimiento de mensajes, - carpetas y etiquetas, - reglas del buzón, - delegaciones y permisos, - contactos, - calendarios, reuniones y reservas de recursos, - tareas y notas, - configuración del cliente de correo. Si una persona empieza a trabajar activamente en ambos buzones, en pocos días aparecen dos historiales diferentes. Unirlos después puede resultar más difícil que ejecutar una migración planificada. Por eso todo proyecto de dual delivery necesita un **buzón de trabajo** claramente definido. Desde él se responde, se envía, se administra el calendario y se realizan las tareas diarias. El otro permanece como entorno de observación hasta el cutover acordado. ## Dual delivery forma parte del plan, no es toda la migración Una migración segura se compone de varios trabajos que deben coincidir en el orden correcto. ### 1. Inventario Antes de añadir una ruta hay que documentar dominios, buzones, alias, grupos, aplicaciones emisoras, reglas de transporte, dispositivos e integraciones. Merecen especial atención las direcciones que no pertenecen a usuarios normales: facturación, formularios, monitorización, escáneres, alarmas y notificaciones automáticas. ### 2. Preparación del destino Creamos cuentas, asignamos licencias y configuramos dominio, políticas de acceso, MFA, protección de correo y DKIM. Nadie debería recibir copias en un buzón inaccesible o con políticas todavía incompletas. ### 3. Migración de datos históricos La primera fase mueve correo, carpetas, calendarios y contactos. Algunas herramientas ejecutan después sincronizaciones incrementales. Dual delivery ayuda con los nuevos mensajes entrantes, pero no sustituye esas sincronizaciones. ### 4. Entrega adicional La plataforma principal sigue recibiendo mediante MX y entregando en los buzones existentes. Envía una copia a través de una ruta directa y cifrada hacia el destino. La copia no debe volver a consultar el MX público del mismo dominio si eso la devuelve al sistema de origen. ### 5. Piloto y observación Probamos todos los tipos de destinatario y revisamos retrasos, cuarentena y logs. Usuarios seleccionados o administradores confirman que el destino está completo y se comporta de forma previsible. ### 6. Sincronización final y cutover Durante una ventana acordada se detienen los cambios en el buzón antiguo, se ejecuta la última sincronización incremental, se cambia el MX o las reglas de entrega y se dirige a los usuarios al nuevo sistema. El buzón de destino pasa a ser la fuente de verdad. ### 7. Periodo de control y retirada de la ruta La plataforma anterior puede permanecer durante un plazo corto en modo de solo lectura. Dual delivery se desactiva cuando se cumplen los criterios de aceptación. Mantenerlo «por si acaso» sin fecha final conserva costes y responsabilidades ambiguas. ## El sistema principal debe estar claro El servidor indicado en los registros MX públicos es el primer receptor del correo de internet. En una migración típica, la plataforma existente mantiene ese papel hasta el cutover. Ejecuta el filtrado inicial, la entrega local y el envío de la copia. La plataforma secundaria necesita un punto de recepción protegido y una lista completa de los destinatarios incluidos en el piloto. El correo interno también importa. Algunos sistemas lo entregan localmente sin consultar el MX público, de modo que la regla debe cubrir tráfico entrante e interno si ambos deben aparecer en el destino. Google permite aplicar la configuración a una unidad organizativa o grupo de configuración, lo que facilita un piloto limitado. Los cambios de routing pueden tardar en propagarse; no conviene activarlos pocos minutos antes de una prueba con dirección. ## Cuando la segunda copia falla en silencio Una ventaja de dual delivery es que un problema del sistema secundario no tiene por qué bloquear el buzón de trabajo. La misma característica tiene una desventaja: los usuarios pueden no advertir que las copias llevan horas sin llegar al destino. Google ofrece la posibilidad de suprimir avisos de error del destino adicional. Esto evita que el remitente reciba errores de un buzón que todavía no utiliza, pero hace imprescindible la monitorización administrativa. Si se ocultan los rebotes, alguien debe vigilar logs, colas y mensajes sintéticos. Una monitorización útil cubre: - cantidad de mensajes aceptados por ambos sistemas, - diferencia en los tiempos de entrega, - rechazos y errores TLS, - destinatarios desconocidos, - mensajes en cuarentena solo en una plataforma, - continuidad de un mensaje de prueba recurrente, - cambios de reglas en el registro de auditoría administrativa. Sin esas evidencias, dual delivery aporta tranquilidad pero no demuestra que la segunda copia esté completa. ## SPF, DKIM y DMARC durante la migración Recibir copias no significa que el segundo sistema ya deba enviar correo con el dominio corporativo. Mientras los usuarios continúan trabajando en la plataforma principal, una sola ruta de salida es más fácil de gestionar. Si el destino también envía durante el piloto, debe estar autorizado en SPF y firmar con su propio DKIM. El dominio mantiene un único registro SPF aunque incluya varios proveedores. Los informes DMARC permiten comprobar si los mensajes de ambos entornos superan la autenticación y el alignment. No conviene endurecer varios controles la noche del cutover. Primero activamos firma e informes, verificamos los resultados y después reforzamos la política de rechazo. Así un error de DNS no convierte una migración controlada en un problema general de entrega. ## Por qué dual delivery no es backup ni alta disponibilidad Un segundo buzón puede ayudar a recuperar algunos mensajes entrantes, pero no es un backup completo. No protege automáticamente enviados, calendarios, contactos ni cambios hechos en el buzón principal. Si una regla de borrado o una acción maliciosa alcanza ambos entornos, también pueden desaparecer las dos copias. Tampoco ofrece redundancia automática entre proveedores. Cuando el MX apunta a la plataforma principal, cada mensaje debe pasar primero por ella. Una caída prolongada, DNS incorrecto o una regla rota puede afectar a los dos destinos. Un plan real de continuidad aborda por separado DNS, aceptación de mensajes, colas SMTP, acceso de usuarios, envío, datos históricos, identidad y procedimiento de cambio. Dual delivery puede formar parte del plan, pero no sustituirlo. ## Errores habituales Los mismos problemas se repiten con frecuencia: - algunos alias o grupos no existen en el sistema de destino, - se copia el correo de internet pero se omite el interno, - los usuarios empiezan a responder desde ambos buzones, - las respuestas de ausencia funcionan en dos lugares, - las copias secundarias caen en otra cuarentena, - la copia sigue el MX y vuelve al punto inicial, - enviados y calendarios faltan en la sincronización final, - licencias y rutas antiguas siguen activas meses después del cutover, - nadie sabe qué archivo de correspondencia es el oficial. Cada riesgo resulta manejable cuando el diseño define el sistema principal, la forma de trabajo permitida y las condiciones de salida. ## Dual, split, migración o archivo Mecanismos técnicamente parecidos responden a necesidades muy diferentes. La elección debe empezar por el resultado de negocio. ![Árbol de decisión para split delivery, dual delivery, migración y archivo o journaling](/images/blog/mail-delivery-strategy-decision.svg) - Elegimos **split delivery** cuando distintos usuarios trabajarán de forma permanente en sistemas separados bajo un dominio común. - Usamos **dual delivery** para entregar temporalmente el mismo mensaje en dos lugares, normalmente durante un piloto o migración. - Una **migración** mueve el servicio completo: datos, identidad, configuración, procesos y responsabilidad. - **Archivo o journaling** responden a la necesidad de conservar una copia controlada y, con frecuencia, inmutable. Usar dual delivery como sustituto de archivo o sincronización permanente acaba mal porque el mecanismo no fue diseñado para ello. ## Cuándo se puede desactivar con seguridad La fecha final debe formar parte del plan antes de activar la primera copia. Una fecha por sí sola no basta; hacen falta criterios de aceptación. Dual delivery puede desactivarse cuando: - todos los buzones, alias y grupos activos existen en el destino, - la migración histórica y la sincronización final han terminado correctamente, - las aplicaciones emisoras críticas han superado las pruebas, - SPF, DKIM y DMARC muestran los resultados esperados, - los usuarios pueden trabajar en el nuevo entorno, - monitorización y respuesta a incidentes están preparadas, - existe un plan de rollback confirmado para la ventana de cutover, - los responsables de negocio han aceptado el resultado. A partir de ese momento, dos buzones activos dejan de aumentar la seguridad y mantienen complejidad innecesaria. ## Un buen puente necesita la otra orilla Dual delivery es valioso cuando una organización quiere reducir el riesgo de un cambio brusco de correo. Permite observar el destino con carga real, descubrir direcciones ausentes y preparar al equipo para el cutover. La regla principal es sencilla: un buzón permanece activo y el segundo sirve para un objetivo migratorio claramente definido. El proyecto tiene responsable, monitorización, criterios de éxito y fecha final. En esas condiciones, dual delivery es un puente seguro. Sin ellas, se convierte en caos por duplicado y nadie quiere desactivarlo. Si estás planificando una migración de Google Workspace, Microsoft 365 u otro sistema de correo, nuestro servicio de [Socio IT](/es/servicios-it) puede preparar el inventario, la arquitectura de routing, el plan de pruebas, el cutover y un rollback controlado para mantener el correo disponible en el momento más importante del cambio.