Colega, si estás leyendo esto probablemente te encuentras en una de estas situaciones: eres un abogado Jr. al que le acaban de asignar un caso donde toda la prueba gira alrededor de correos electrónicos y no tienes idea de cómo ofrecerlos sin que te los impugnen. Eres un abogado litigante con años de experiencia que siempre ha presentado correos como PDF y nunca le habían dicho que eso tiene problemas técnicos. Eres un empresario que tiene en Outlook la evidencia que demuestra que su ex socio lo defraudó, pero no sabe cómo convertir esos correos en prueba admisible. O eres el abogado de la contraparte buscando exactamente cómo impugnar los correos que presentó el otro lado.
Sea cual sea tu situación, necesito que leas esto completo, porque lo que voy a explicar es la diferencia entre ganar y perder un caso donde la evidencia clave está en un correo electrónico.
Les soy franco: en Duriva recibimos al menos dos o tres casos por semana donde un abogado presentó un correo electrónico como prueba y la contraparte lo desmontó en audiencia. No porque el correo fuera falso. Sino porque la forma en que se presentó — un PDF, una impresión, un reenvío — destruyó el valor probatorio que ese correo tenía. La prueba llegó mutilada.
Este artículo va a explicar qué debe hacer un abogado para presentar correos electrónicos como prueba en juicio de manera que sean técnicamente inobjetables. Sin atajos. Sin «trucos.» Con la precisión que un caso serio exige.
Un PDF de un correo electrónico no es prueba: es una fotografía de la prueba
Esta es la primera verdad que necesita escuchar todo abogado que litiga con evidencia digital: un PDF de un correo no es el correo. Es una representación visual del correo. Y la diferencia entre una cosa y la otra es la diferencia entre presentar un arma homicida y presentar una fotografía del arma homicida.
Cuando un abogado selecciona un mensaje y le da «Guardar como PDF» o «Imprimir,» obtiene una imagen estática del contenido visible: texto, remitente aparente, fecha aparente, asunto. Nada más.
Pero, pero, pero, pero — un correo electrónico no es solo lo que se ve en pantalla. Es un archivo digital con una estructura interna que incluye información que nunca aparece en un PDF. Esa información se llama headers — encabezados técnicos — y son la columna vertebral forense de cualquier correo.
Los headers contienen:
- La dirección IP del servidor que originó el correo
- La ruta completa que siguió el mensaje desde el servidor de origen hasta el servidor de destino (cada servidor intermedio que tocó)
- Los timestamps de cada salto entre servidores (con precisión de segundos y zona horaria)
- Los registros de autenticación del dominio: SPF, DKIM y DMARC — mecanismos que verifican si el correo realmente salió del dominio que dice haber salido
- El Message-ID único, que es como el número de serie del correo
- La versión del cliente de correo que lo envió
- Si el correo fue modificado, reenviado o redirigido en algún punto
Cuando un abogado convierte un correo a PDF, toda esa información desaparece. Se destruye. Lo que le entregas al juez es un documento que dice «De: fulano@empresa.com, Fecha: 15 de marzo de 2025» — y nada más. El juez no tiene forma de verificar si ese correo realmente lo envió fulano, si se envió en esa fecha, si el contenido fue alterado, o si alguien lo fabricó en cinco minutos.
Y fabricar un PDF que parezca un correo toma exactamente eso: cinco minutos. Cualquier persona con conocimientos básicos de edición puede crear un documento visualmente idéntico a un correo legítimo. Si ese es el estándar de prueba que el abogado presenta, la contraparte lo va a destruir. Y tiene toda la razón en hacerlo.
Reitero: el problema no es que el correo sea falso. El problema es que al presentarlo como PDF, el abogado eliminó todos los mecanismos técnicos que permiten verificar que es auténtico. Le quitó al juez las herramientas para evaluarlo. Y le dio a la contraparte el argumento perfecto para impugnarlo.
Abogado Jr. que quiere lucirse en su primer caso con evidencia digital: lo que te acabo de explicar es lo que tu socio sénior probablemente no sabe. Si llegas a la reunión de estrategia diciendo «necesitamos los archivos nativos, no PDFs, y tenemos que preservar los headers,» acabas de demostrar que entiendes la materia mejor que el 90% de los litigantes que manejan este tipo de casos. Eso no es presunción. Es preparación.
Qué debe solicitar el abogado: archivos .eml y .msg
Si el PDF es la fotografía del arma, el archivo nativo del correo es el arma misma. Y los archivos nativos de correo electrónico vienen en dos formatos principales: .eml y .msg.
El archivo .eml es el formato estándar universal. Lo generan prácticamente todos los sistemas de correo: Gmail, Yahoo, servidores Linux, sistemas basados en IMAP. Es un archivo de texto plano que contiene el cuerpo del mensaje, los adjuntos codificados y — esto es lo crítico — los headers completos. Toda la información técnica que un PDF destruye, el .eml la preserva intacta.
El archivo .msg es el formato propietario de Microsoft Outlook. Contiene la misma información que el .eml pero en una estructura binaria propia de Microsoft. Incluye headers, metadatos internos de Exchange, marcas de tiempo del servidor, y en muchos casos información adicional sobre la cuenta, el buzón y las reglas de organización del correo.
Esto es muy importante: cuando un abogado solicita evidencia de correos, debe pedir específicamente archivos en formato nativo. No PDFs. No impresiones. No capturas de pantalla. No reenvíos. Archivos nativos.
Y aquí viene un punto que lo veo mal hecho en la mitad de los casos que llegan al laboratorio: reenviar un correo no es lo mismo que entregar el correo original. Cuando alguien reenvía un correo, el sistema crea un mensaje nuevo con nuevo Message-ID, nuevos headers, nueva ruta de servidores. Los headers originales se pierden o alteran. Es como si alguien te diera una fotocopia de un contrato firmado y te dijera «aquí está el contrato.» No. El contrato es el documento original con la firma original. En correos electrónicos, el archivo .eml o .msg descargado directamente del buzón donde se recibió es el equivalente al documento original.
Empresario que tiene las pruebas en su Outlook: no reenvíe los correos a su abogado. Abra Outlook, seleccione el correo, vaya a Archivo > Guardar como, y guárdelo en formato .msg. Cada correo, uno por uno, en una carpeta. Esos archivos son su evidencia.
Abogado que está preparando un ofrecimiento de pruebas: en su escrito, no diga «se ofrece como prueba el correo electrónico de fecha tal.» Diga «se ofrece como prueba el archivo nativo en formato .msg/.eml del correo electrónico de fecha tal, con headers completos, preservado mediante [método de preservación].» Esa precisión le cierra puertas a la contraparte desde el escrito mismo.
El error del reenvío: cómo un abogado destruye su propia prueba sin saberlo
Escena que veo todas las semanas: un abogado le pide a su cliente que le mande los correos importantes del caso. El cliente abre su correo, selecciona los mensajes, y se los reenvía. El abogado los recibe, verifica que el contenido coincide con lo que le contaron, y los ofrece como prueba.
Lo que ese abogado no sabe es que acaba de destruir la evidencia.
Cuando un correo se reenvía, el sistema genera un nuevo Message-ID — el número de serie irrepetible que vincula al correo con los registros de los servidores de origen y destino desaparece. Se reescriben los headers de enrutamiento: la ruta original se sustituye por la ruta del reenvío. Los registros de autenticación (SPF, DKIM, DMARC) dejan de ser válidos porque el mensaje ya no viene del servidor original sino del servidor del reenviador. Los metadatos — fechas de recepción, estado de lectura, marcas del servidor — se modifican o se pierden.
A ver, a ver, a ver. Voy a ponerlo de una manera que no deje lugar a dudas: un correo reenviado tiene, para efectos periciales, el mismo valor probatorio que una captura de pantalla. Puede servir como indicio. Pero ¿como prueba autónoma que acredite la autenticidad, integridad y origen del mensaje? No.
Abogado de la contraparte que está buscando cómo impugnar: si la otra parte ofreció correos reenviados como prueba, solicita al juez que se requiera la exhibición de los archivos nativos (.eml/.msg) directamente del servidor o buzón original. Si no los pueden entregar — porque solo tienen los reenvíos — la autenticidad de esos correos no está acreditada técnicamente. No es una opinión tuya. Es un hecho técnico que cualquier perito informático puede ratificar.
Headers: la evidencia que nadie ve pero que todo lo demuestra
Los headers de un correo electrónico son, para el perito informático, lo que la autopsia es para el médico forense. El cuerpo del correo es lo visible. Los headers son lo que está debajo: la evidencia técnica que revela la verdad sobre ese correo independientemente de lo que diga su contenido visible.
Ejemplo concreto. El abogado recibe un correo que dice «De: director@empresa.com, Fecha: 10 de enero de 2025, Asunto: Aprobación del contrato.» Lo imprime. Lo ofrece como prueba.
Ahora veamos qué dicen los headers del mismo correo:
El campo Received muestra que el correo fue procesado por el servidor de origen a las 14:32:07 UTC y recibido por el servidor de destino a las 14:32:09 UTC. Esos dos segundos de diferencia son consistentes con una transmisión normal entre servidores. Si la diferencia fuera de horas o días, habría una anomalía que investigar.
El campo SPF indica si el servidor que envió el correo está autorizado para enviar en nombre del dominio empresa.com. Si el resultado es «pass,» el servidor está autorizado. Si es «fail» o «softfail,» el correo salió de un servidor no autorizado. Eso puede significar suplantación.
El campo DKIM contiene una firma criptográfica que el servidor de origen generó al enviar el mensaje. Si esa firma se verifica correctamente contra la clave pública publicada en el DNS del dominio, el contenido del correo no fue alterado después de salir del servidor de origen. Si la verificación falla, el correo fue modificado en tránsito o la firma fue falsificada.
El campo DMARC es la política que combina SPF y DKIM para determinar qué hacer con correos que no superan las verificaciones. Si DMARC indica «fail,» ese correo no pasó las verificaciones de autenticidad del dominio.
El Message-ID es único para cada correo. Cada servidor que procesa el mensaje lo registra. Si obtienes los logs del servidor de origen y del servidor de destino, puedes verificar que el Message-ID aparece en ambos registros. Eso confirma que el correo realmente transitó entre esos dos servidores en la fecha indicada. Es la trazabilidad completa del mensaje.
El X-Originating-IP en algunos servidores revela la dirección IP del equipo desde el que se envió el correo. No del servidor. Del equipo del usuario. Eso puede ubicar físicamente desde dónde se envió el mensaje.
Escuchen bien esto: toda esa información — SPF, DKIM, DMARC, Message-ID, IPs, timestamps, rutas de servidores — existe en el archivo nativo del correo. En el .eml. En el .msg. Está ahí, esperando a ser leída por alguien que sepa interpretarla. Y desaparece completamente cuando el abogado convierte el correo a PDF o lo reenvía.
El diablo está en los detalles. Y en materia de correos electrónicos, los detalles están en los headers.
El cuestionario pericial: preguntas que cierran puertas
Esta sección es la que va a separar al abogado que sabe manejar evidencia de correo electrónico del que no. El cuestionario pericial es donde el abogado formula las preguntas que el perito responde en su dictamen. Una pregunta mal formulada le da espacio a la contraparte. Una pregunta bien formulada le cierra puertas.
Estas son las preguntas clave cuando la prueba es un correo electrónico:
«Diga el perito si el archivo analizado corresponde al formato nativo del correo electrónico (.eml/.msg) y si contiene los headers completos del mensaje.»
Establece desde el inicio que lo que se analizó es el archivo original, no un PDF. Si la contraparte ofreció PDFs, esta pregunta evidencia la diferencia de calidad probatoria.
«Diga el perito si los registros de autenticación SPF, DKIM y DMARC del correo son consistentes con un envío legítimo desde el dominio de origen declarado.»
Verifica si el correo realmente salió de donde dice que salió. Si pasan, el correo es auténtico desde la perspectiva del servidor de origen. Si no pasan, hay un problema de autenticidad que la contraparte va a tener que explicar.
«Diga el perito si el contenido del correo ha sido modificado posterior a su envío, con base en la verificación de la firma DKIM.»
DKIM es una firma criptográfica. Si el contenido se alteró después de salir del servidor, la firma no verifica. Si la respuesta es «la firma DKIM verifica correctamente,» nadie tocó ese correo.
«Diga el perito si el Message-ID del correo analizado es consistente con los estándares de generación del servidor de origen y si presenta indicios de manipulación.»
El Message-ID tiene un formato específico según el servidor. Exchange genera Message-IDs distintos a Gmail o a un servidor Linux. Si alguien fabricó un correo y le puso un Message-ID inventado, un perito lo detecta porque el formato no corresponde al servidor que supuestamente lo envió.
«Diga el perito si los timestamps registrados en los headers Received son cronológicamente consistentes entre sí y con la fecha declarada del correo.»
Cada servidor que toca el correo agrega un header Received con su timestamp. Deben ser cronológicamente consecutivos. Si están desordenados o hay saltos temporales inexplicables, hay una anomalía que señalar.
«Diga el perito si el correo electrónico fue reenviado, redirigido o modificado en algún punto entre su origen y su destino final, con base en el análisis de los headers.»
Fundamental cuando la contraparte presentó correos que recibió de un tercero. Si fue reenviado, los headers lo revelan y la cadena de autenticidad se rompió.
«Señale la razón de su dicho.»
Esta frase cierra cada pregunta del cuestionario. Y no es una formalidad. «Señale la razón de su dicho» obliga al perito a explicar la fundamentación técnica de cada respuesta. No basta con decir «sí, el correo es auténtico.» Tiene que decir por qué: qué datos técnicos revisó, qué verificaciones realizó, qué estándares aplicó. Esto hace que el dictamen sea autosuficiente — el juez puede leerlo y entender no solo la conclusión sino la evidencia que la sustenta. Y hace que el perito de la contraparte tenga que rebatir no solo la conclusión sino toda la fundamentación. Eso es cerrar puertas.
Abogado Jr. que está preparando su primer cuestionario pericial: no copies formularios genéricos. Cada caso es distinto. Pero esta estructura — autenticidad de origen, integridad de contenido, coherencia temporal, ausencia de manipulación — es la base. Si tu cuestionario cubre esos cuatro ejes, tu prueba va a ser sólida. Si solo dice «diga el perito si el correo es auténtico,» le acabas de dar a la contraparte todo el espacio para argumentar que la pregunta es vaga.
La cadena de custodia del servidor: lo que nadie preserva y todos necesitan
Aquí entramos en el territorio que separa al peritaje forense serio del peritaje de escritorio.
Un correo electrónico no existe en el vacío. Existe en un servidor. Y ese servidor tiene logs — registros de actividad — que documentan todo lo que pasa con los correos que aloja: cuándo se recibieron, desde dónde, a quién se entregaron, si fueron leídos, si fueron eliminados, si fueron modificados.
Cuando un abogado ofrece un correo electrónico como prueba, debería estar pensando no solo en el archivo del correo sino en los logs del servidor donde ese correo reside. Porque los logs del servidor son la verificación independiente que confirma que el correo es real.
Es como la analogía de la maleta que uso en todos mis cursos. Si alguien te entrega una maleta y te dice «nadie la abrió,» tu primera pregunta debería ser: «¿y cómo lo compruebo?» La cadena de custodia del servidor es exactamente eso: la documentación que comprueba que el correo estuvo donde dice que estuvo, desde cuándo dice que estuvo, sin que nadie lo tocara.
Esto es muy importante para casos laborales, que son los más frecuentes en materia de correos: cuando un empleado es dado de baja de una empresa y la empresa quiere usar los correos de ese empleado como prueba, la pregunta crítica es:
«Diga el perito si el equipo ha estado bajo resguardo de forma inalterable desde el día en que el empleado fue dado de baja.»
Esta pregunta es demoledora si la respuesta es no. Si el buzón siguió activo después de la baja, si alguien más accedió, si el administrador entró «a buscar información,» la integridad está comprometida. No importa que los correos sean reales. Si no puedes demostrar que nadie los tocó entre la baja y la preservación formal, la contraparte tiene un argumento legítimo de impugnación.
Y reitero: esto pasa todo el tiempo. Las empresas dan de baja a un empleado, reasignan la cuenta, el administrador entra a buscar archivos, alguien reenvía correos «importantes» a recursos humanos, y cuando tres meses después el abogado pide la evidencia, lo que queda es un buzón contaminado.
Lo que debe hacer una empresa que anticipa un litigio donde los correos serán relevantes:
Primero: congelar la cuenta de correo. No eliminarla. No reasignarla. No acceder a ella. Congelarla. En Exchange y Microsoft 365 existe la función de Litigation Hold que preserva todo el contenido del buzón, incluyendo correos eliminados, en su estado actual. En Google Workspace existe Vault. Estas herramientas existen precisamente para preservación legal. Usarlas.
Segundo: documentar quién tiene acceso al servidor y restringir ese acceso. El acceso al buzón en cuestión debe restringirse desde el momento en que se anticipa el litigio.
Tercero: generar y preservar los logs del servidor. Los logs tienen período de retención limitado — si nadie los preserva, se sobrescriben y se pierden. Y cuando se pierden, se pierde la verificación independiente que respalda la autenticidad de los correos.
Cuarto: solicitar un peritaje de preservación. Un perito puede generar una imagen forense del buzón, calcular valores hash que certifiquen su integridad, y documentar todo con cadena de custodia formal. A partir de ahí, cualquier análisis se hace sobre la copia forense, no sobre el servidor en producción.
Empresario que acaba de despedir a alguien y cree que los correos lo incriminan: no toque nada. No entre al buzón. No le pida a sistemas que «le saque los correos importantes.» Llame a su abogado, que su abogado contacte a un perito, y que el perito preserve la evidencia de manera forense. Ese es el orden correcto. Cualquier otro orden le va a costar caro en la audiencia.
El artículo 210-A y la NOM-151: el marco legal que respalda (y exige) la evidencia digital
El artículo 210-A del Código Federal de Procedimientos Civiles establece que para valorar la fuerza probatoria de información generada por medios electrónicos, el juzgador debe considerar la fiabilidad del método con el que fue generada, comunicada, recibida o archivada. Traducción: el juez no está obligado a darle valor probatorio a un correo solo porque existe. Debe evaluar si el método de preservación es confiable. Un PDF no lo es. Un archivo nativo analizado pericialmente con verificación de headers y cadena de custodia sí lo es.
El 210-A es tu aliado si sabes usarlo. Y es tu enemigo si lo ignoras.
La NOM-151-SCFI establece los requisitos para que un mensaje de datos tenga valor probatorio. Entre otras cosas, exige que se conserve en el formato en que fue generado, enviado o recibido.
A ver, a ver, a ver. Lean eso otra vez: «en el formato en que fue generado, enviado o recibido.» La propia NOM-151 está diciendo que el formato importa. Un correo generado como .eml debe conservarse como .eml. No como PDF. No como impresión. Si el abogado no preservó el formato nativo, tiene un problema con la NOM-151. Y si la contraparte lo sabe, va a usar ese argumento.
El caso del notario y la página web: por qué la certificación notarial no alcanza
Esto lo cuento porque ilustra un problema que aplica directamente a los correos electrónicos.
Un abogado necesita certificar el contenido de una página web. Llama a un notario. El notario abre el navegador, accede a la página, y levanta una fe de hechos: «Doy fe de que en esta página aparecía el siguiente contenido.»
El notario actuó de buena fe. Pero hay un problema técnico: cualquier persona puede modificar lo que aparece en pantalla en un navegador web en diez segundos usando Inspeccionar Elemento. Diez segundos. Clic derecho, Inspeccionar, cambiar el texto, tomar la captura o llamar al notario. Lo que el notario certificó no es lo que realmente decía la página, sino lo que alguien quiso que dijera.
Con los correos electrónicos pasa exactamente lo mismo. Un notario puede dar fe de que abrió un correo en Outlook y el correo decía tal cosa. Pero no puede dar fe de que ese correo es auténtico, de que no fue fabricado, de que sus headers son consistentes, de que las firmas criptográficas verifican. Eso requiere un perito informático.
La certificación notarial y el peritaje informático son complementarios, no excluyentes. El notario da fe de la existencia. El perito verifica la autenticidad. La combinación de ambos es la posición más sólida. Pero entre los dos, el peritaje informático es el que tiene el peso técnico. La fe de hechos notarial dice «esto existía.» El dictamen pericial dice «esto es auténtico, íntegro, y no ha sido manipulado.» En un litigio donde la contraparte impugna la autenticidad del correo, es el perito quien cierra la discusión, no el notario.
Objetar las pruebas: el arte más fino
Objetar las pruebas es el tema más fino. Y en materia de correos electrónicos, las oportunidades de objeción son abundantes porque la mayoría de los abogados no sabe preservar ni presentar esta evidencia correctamente.
Si eres el abogado de la contraparte, estos son tus vectores de impugnación:
- Formato: PDFs, impresiones o capturas no preservan headers ni permiten verificación de autenticidad. El 210-A requiere fiabilidad del método. Objeta.
- Reenvíos: headers originales perdidos, autenticación (SPF, DKIM, DMARC) no verificable, cadena de autenticidad rota. Objeta.
- Cadena de custodia: si múltiples personas accedieron al buzón, si la cuenta fue reasignada, si no hay logs de acceso, la integridad es cuestionable. La pregunta pericial clave: «Diga el perito si el equipo ha estado bajo resguardo de forma inalterable desde el día en que el empleado fue dado de baja.» Si la respuesta es no, tienes tu argumento.
- Ausencia de peritaje: un correo electrónico sin dictamen pericial que acredite su autenticidad es un documento electrónico sin verificación. Valor probatorio débil. Tu objeción queda en el registro para la apelación.
- Inconsistencias técnicas: si el peritaje no verificó headers, no validó DKIM, no revisó SPF/DMARC, no verificó logs del servidor, solicita que el perito explique por qué omitió esas verificaciones. Un dictamen que dice «el correo es auténtico» sin fundamentar cómo llegó a esa conclusión es un dictamen vulnerable.
Cada uno de estos puntos puede ser fatal para la prueba de la contraparte si se argumenta correctamente.
La mancuerna perito-abogado en correos electrónicos
El peritaje informático no empieza cuando el perito recibe los archivos. Empieza cuando el abogado y el perito se sientan a diseñar la estrategia. El abogado conoce la teoría del caso. El perito conoce la realidad técnica: qué información contiene un correo, qué se puede verificar, dónde están las fortalezas y debilidades de la evidencia, y cómo traducir hallazgos técnicos en lenguaje que un juez entienda.
Cuando la mancuerna funciona, el perito le dice al abogado: «Solicita los archivos nativos, no PDFs. Pide los logs del servidor de esta fecha a esta fecha. En el cuestionario, pregunta esto, esto y esto. Y cuando el perito de la contraparte ratifique, hazle esta pregunta en el contrainterrogatorio porque su dictamen no verificó DKIM.»
Eso no es un peritaje. Es asesoría técnico-jurídica. Y trata de buscarla en internet. No hay, no hay. Esa intersección entre el conocimiento técnico de la informática forense y el conocimiento procesal del litigio es lo que permite que la prueba de correos electrónicos se presente de manera inobjetable — o, del otro lado, que se impugne de manera demoledora.
Abogado que nunca ha trabajado con un perito en materia de correos: la primera consulta es la más importante. Traiga su caso, explique su teoría, muestre lo que tiene. Esa consulta le ahorra meses de litigio mal enfocado y miles de pesos en estrategias que no van a funcionar porque la evidencia no se presentó correctamente.
Preguntas frecuentes
¿Un correo impreso tiene valor legal en México?
Tiene valor como indicio, no como prueba plena. El 210-A exige verificar la fiabilidad del método y la atribución del contenido a su autor. Una impresión no permite esas verificaciones. Necesita respaldo del archivo nativo y un dictamen pericial.
¿Es suficiente con que el notario certifique el correo?
La certificación notarial acredita que el correo existía con cierto contenido. Pero no acredita autenticidad técnica. Es complemento, no sustituto del peritaje informático.
¿Qué pasa si la otra parte presentó correos como PDF y yo no los objeté a tiempo?
Si todavía estás en posibilidad de objetar, hazlo argumentando falta de integridad conforme al 210-A. Si ya pasó la oportunidad, puedes cuestionar el valor probatorio en tus alegatos y ofrecer un peritaje propio que demuestre las limitaciones técnicas de un PDF como formato probatorio.
¿Puedo recuperar los headers de un correo que ya fue reenviado?
Los headers originales se perdieron en el reenvío. Ve a la fuente: solicita el archivo nativo directamente del buzón original, o requiere al servidor los logs que correspondan a ese Message-ID. Si el buzón existe y el correo no fue eliminado, el archivo nativo con sus headers sigue ahí.
¿Cuánto tiempo conservan los servidores de correo los mensajes?
Depende de la configuración y las políticas de retención. El punto crítico es que los logs del servidor — los registros de actividad que complementan la evidencia — sí tienen períodos de retención limitados. Si no se preservan a tiempo, se pierden.
¿Qué diferencia hay entre un correo original y un correo reenviado para efectos legales?
La misma que existe entre un documento original firmado y una fotocopia. El original en formato nativo (.eml/.msg) conserva headers, metadatos, firmas criptográficas y registros de autenticación verificables. El reenvío pierde esa información. Para efectos legales, el original es verificable; el reenvío es, en el mejor de los casos, un indicio.
Mi empresa usa Microsoft 365. ¿Cómo preservo los correos para un litigio?
Active la función Litigation Hold sobre el buzón del usuario antes de que nadie acceda a él. Documente cuándo lo activó y quién lo hizo. Solicite a un perito informático que genere una extracción forense del contenido. Eso le da la preservación formal que un litigio exige.
Lo que debe hacer el abogado ahora
Si llegaste a este artículo porque tienes un caso donde los correos electrónicos son prueba clave, esto es lo que necesitas hacer, en este orden:
Primero: identifica dónde están los correos originales. No los reenvíos. Los archivos nativos en el buzón donde se recibieron originalmente. Outlook: .msg. Gmail u otro IMAP: .eml.
Segundo: no toques nada. No reenvíes. No guardes como PDF. No mandes por email. Si necesitas compartirlos con tu equipo legal, copia los archivos nativos en una memoria USB. El archivo nativo se puede copiar sin alterar su contenido.
Tercero: preserva los logs del servidor. Solicita al administrador que resguarde los logs de correo del período relevante. Si no se preservan, se sobrescriben y los pierdes.
Cuarto: consulta con un perito informático antes de ofrecer la prueba. No después. Antes. Esa consulta previa puede ser la diferencia entre una prueba inobjetable y una prueba que la contraparte desmonta en cinco minutos.
Quinto: diseña el cuestionario pericial con el perito. Las preguntas que incluiste en el cuestionario son las únicas que el perito va a responder en su dictamen. Si no preguntaste sobre DKIM, el perito no va a hablar de DKIM. Lo que no preguntas, no existe en el dictamen. Y lo que no existe en el dictamen, no existe para el juez.
Un correo electrónico bien preservado — archivo nativo, headers completos, verificación de autenticidad, cadena de custodia documentada — es una de las pruebas más sólidas que existen en el derecho contemporáneo. Un registro con verificaciones criptográficas integradas que un perito puede validar con certeza científica.
Un correo mal preservado — reenviado, impreso, convertido a PDF, sin headers, sin cadena de custodia — es un papel que dice lo que alguien quiere que diga. Y eso, en un juicio serio, no alcanza.
La diferencia entre uno y otro no es tecnología sofisticada ni presupuestos millonarios. Es saber qué pedir, cómo preservarlo y a quién consultar.
En Duriva evaluamos la evidencia de correos electrónicos, asesoramos al abogado sobre cómo ofrecerla y preservarla, generamos el dictamen pericial con la profundidad técnica que el caso exige, y ratificamos en audiencia oral. Si tienes un caso donde los correos son la pieza clave, lo peor que puedes hacer es presentarlos mal. Lo segundo peor es no presentarlos.