Pericia informática de parte: ¿son auténticos los correos que se reenvió un empleado?

Es uno de los casos más comunes en el fuero laboral. Martín trabajaba "en negro" en un corralón y tenía una cuenta de correo de la empresa. Cuando se enteró de que lo iban a despedir, se reenvió a su Gmail los correos de trabajo que tenía: horarios, repartos, el aviso de que el viernes pasara "a buscar el sobre"… Ahora su abogado quiere usarlos para probar la relación laboral, y lo llama a un perito informático de parte para que diga si esa prueba se sostiene.

Para escribir esta entrada armé el caso de verdad: creé dos casillas en el dominio de este blog ([email protected] y [email protected]), mandé los correos entre ellas, los reenvié a un Gmail desde el webmail del hosting (algunos tal cual, uno editado y uno inventado) y después hice la pericia sobre los archivos descargados. Todo lo que ves acá son cabeceras y resultados reales.

⚖️ Antes de empezar: el perito de parte trabaja siempre junto al abogado, que es quien encuadra el caso, ofrece la prueba y define la estrategia. Las normas cambian según la provincia y el fuero, y se actualizan (en 2026, por ejemplo, la Ley 27.802 reformó la Ley de Contrato de Trabajo). Lo legal que menciono acá es orientativo: para un caso concreto, asesorate con tu abogado de confianza. Lo que sí depende del perito es que el procedimiento técnico esté bien hecho.

El caso

Los personajes son ficticios; el dominio y los correos, reales:

• Raúl Gómez ([email protected]), encargado del "Corralón Los Andes".
• Martín Pérez ([email protected]), el empleado no registrado.
• La cuenta personal de Martín es un Gmail (en este laboratorio, el mío: [email protected]).

Raúl y Martín se cruzaron siete correos: los horarios de la semana con una planilla adjunta, un hilo sobre el reparto con la camioneta, el pago "en efectivo, como siempre", un pedido de vacaciones ("desde que entré en marzo del año pasado") y el último: "No vengas más".

Martín se reenvió varios a su Gmail, algunos más de una vez. Lo que el abogado le acerca al perito son siete reenvíos.

Primero: qué hace un perito de parte

En un juicio, el perito "oficial" lo designa el tribunal (en Río Negro, por sorteo entre los matriculados). Cada parte puede sumar su propio consultor técnico, que en la calle se llama "perito de parte": controla la pericia oficial, propone puntos, puede presenciar las operaciones y presentar sus observaciones.

Trabajar para una parte no significa decir lo que esa parte quiere escuchar. El trabajo del perito de parte es decirle al abogado, antes que nadie, qué prueba se sostiene y cuál no. Un correo trucho que se presenta y después se cae en la pericia oficial no solo se pierde: arrastra la credibilidad de todo lo demás. Vas a ver que en este caso eso pasa.

Paso 1: adquirir la evidencia (y no con capturas)

Una captura de pantalla o un correo impreso no sirven para una pericia: no tienen cabeceras ni firmas, y se pueden fabricar en dos minutos. Lo que hay que conseguir es el mensaje original completo, el archivo .eml.

En Gmail: abrís el correo, menú ⋮ → Descargar mensaje. Para muchos correos, Google Takeout exporta el buzón entero en formato mbox. Si querés un primer vistazo, ⋮ → Mostrar original te muestra el resultado de SPF, DKIM y DMARC.

Apenas tenés los archivos, se fija su estado con un hash. Si después alguien toca un solo byte, el hash cambia:

sha256sum *.eml > hashes-origen.txt
cp --preserve=timestamps *.eml /evidencia/caso-perez/
chmod 444 /evidencia/caso-perez/*.eml       # solo lectura
cd /evidencia/caso-perez && sha256sum *.eml > hashes-copia.txt
diff ~/hashes-origen.txt hashes-copia.txt && echo "HASHES COINCIDEN"

Estos son los siete archivos del caso:

En el informe van los hashes completos. Lo ideal es que la descarga se haga ante escribano, con acta notarial, o como prueba anticipada si hay riesgo de que la evidencia desaparezca. Como mínimo, el perito labra su propia acta: qué cuenta, desde qué equipo, fecha y hora, qué archivos y con qué hash.

💡 Trabajá siempre sobre copias. Los originales quedan en solo lectura y no se vuelven a abrir con un cliente de correo, que podría modificarlos (por ejemplo, marcándolos como leídos).

Paso 2: ¿de quién es el dominio?

Antes de mirar un solo correo hay que responder algo básico: ¿luiszambrana.ar es de la empresa? Si el dominio es del dueño del negocio, una cuenta mperez@ en ese dominio la creó alguien con acceso al panel del dueño.

Para los .ar, el registro público es el de NIC.ar, que se puede consultar por RDAP:

curl -s https://rdap.nic.ar/domain/luiszambrana.ar
curl -s https://rdap.nic.ar/entity/<CUIT-del-titular>

Para este dominio devuelve:

Con eso, el perito puede:

• Cruzar el CUIT con la constancia de inscripción de ARCA: ¿coincide la actividad y el domicilio con el negocio?
• Ver quién presta el correo, mirando los registros MX, SPF y DKIM. Acá todo apunta a Ferozo/DonWeb (dattaweb.com). Ese es el proveedor al que el juzgado le puede pedir por oficio los registros de la cuenta.
• Revisar la historia: la primera captura del sitio en la Wayback Machine es del 28/04/2025.
• Controlar la cronología: si el dominio existe desde abril de 2025, ningún correo de esa cuenta puede ser anterior. Es un control simple que tumba más de una prueba armada.

dig +short MX luiszambrana.ar
dig +short TXT luiszambrana.ar                      # SPF
dig +short TXT mail._domainkey.luiszambrana.ar      # clave pública DKIM
dig +short TXT _dmarc.luiszambrana.ar

💡 Guardá en el acta la salida de estos comandos con fecha y hora, sobre todo la clave DKIM. Los proveedores rotan las claves, y dentro de un año la firma de estos correos puede no verificarse más con lo que haya publicado en el DNS.

Paso 3: leer las cabeceras

Un .eml se lee de abajo hacia arriba: cada servidor por el que pasa el mensaje agrega su línea Received arriba de todo. Este es el recorrido real de "Pago del viernes":

Tardó dos segundos, todo cifrado y por servidores coherentes con el hosting. Y Gmail dejó constancia de lo que verificó al recibirlo:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=sh2026rsa;
       dkim=pass [email protected] header.s=mail;
       spf=pass (google.com: domain of [email protected] designates 200.58.119.11 as permitted sender);
       dmarc=pass (p=QUARANTINE) header.from=luiszambrana.ar

Hay otro detalle muy valioso. Al reenviar, el webmail del hosting (Roundcube) guarda el identificador del correo original:

Subject: Fwd: Pago del viernes
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>

Ese In-Reply-To ata el reenvío a un mensaje concreto que tiene que existir en la casilla de Martín, en la del encargado y en los registros del servidor. Es lo que después permite pedir un cotejo.

💡 El formato del Message-ID delata al programa que escribió el correo. Los de Roundcube son 32 caracteres hexadecimales; los originales de este caso tienen otro formato porque, en el laboratorio, los mandé con un script de Python. En un caso real, un Message-ID que no coincide con el programa que la persona dice haber usado es una señal de alarma.

Paso 4: verificar las firmas por tu cuenta

No alcanza con creerle a Gmail: el perito verifica las firmas él mismo. Con dkimpy (en Debian/Ubuntu, apt install python3-dkim, o pip install dkimpy):

$ dkimverify < "Pago del viernes.eml"
signature ok
$ dkimverify --index 1 < "Pago del viernes.eml"
signature ok
$ arcverify < "Pago del viernes.eml"
arc verification: cv=b'pass' success

El hosting firma dos veces: una con el dominio del cliente (d=luiszambrana.ar, selector mail) y otra con el suyo (d=dattaweb.com). Además está el sello ARC de Google, que certifica lo que Google vio al recibirlo y que se puede verificar aunque el dominio cambie su clave.

¿Y si alguien edita el .eml después de descargarlo? Lo probé: cambié "como siempre en efectivo" por "como siempre por transferencia" en una copia de trabajo.

$ dkimverify < adulterado.eml
dkim.ValidationError: body hash mismatch (got b'Jw0gvVat…', expected b'7zpanfBn…')

La firma cubre el cuerpo del mensaje: cualquier cambio después del envío rompe la firma. Hasta acá, todo bien para Martín. Pero falta lo más importante.

Paso 5: lo que la firma NO prueba

Acá está la trampa en la que cae mucha gente. Que los reenvíos tengan DKIM válido prueba que:

• la cuenta [email protected] existía y funcionaba;
• esos mensajes salieron desde el servidor de correo de la empresa, autenticados con esa cuenta;
• en esa fecha y hora, y con ese contenido exacto.

Lo que no prueba es que el texto citado sea el que escribió Raúl. El servidor firma lo que Martín manda, y en un reenvío común Martín puede editar el texto citado antes de apretar Enviar.

Y hay un detalle más que descubrí al armar el laboratorio: los correos internos no tienen firma DKIM. Cuando Raúl le escribió a Martín, el mensaje nunca salió del servidor: se entregó en forma local, sin firmar. El original no tiene ninguna firma que verificar:

Received: from [IP del encargado] (helo=…)
    by c279.dattaweb.com with esmtpsa (TLS1.3) (Exim)
    (envelope-from <[email protected]>)
    id 1xJaqE-00GiMv-HQ
    for [email protected]; Wed, 21 Oct 2026 15:15:10 -0300
X-Spam: Mismo dominio [luiszambrana.ar]

En una empresa chica, casi todo lo que importa son correos internos. Así que el contenido de lo que escribió el encargado se defiende con coherencia y cotejo, no con criptografía.

En línea o como adjunto: no es lo mismo

"No vengas más" lo reenvié de las dos formas para comparar:

Hice el cotejo: el adjunto de "No vengas más (1)" es idéntico byte a byte a la copia que bajé por IMAP de la casilla de Martín (mismo SHA-256, c8f77ccc…). Es exactamente lo que haría el perito oficial si el juez ordena revisar el servidor.

💡 Si alguien te pregunta cómo guardar correos que quizás tenga que usar en un juicio: reenviarlos como adjunto, o mejor todavía, descargar el .eml. El reenvío común es lo menos confiable.

Las dos trampas del caso

Para probar el procedimiento, metí dos correos que no resisten el análisis. Los dos tienen DKIM, SPF, DMARC y ARC válidos.

1. El reenvío editado

"Re: Reparto de mañana" llegó dos veces al Gmail, a las 15:23 y a las 15:34. El texto citado de Raúl dice cosas distintas en cada uno:

- Sí, con la tarjeta del corralón. Guardá el ticket y me lo dejás en la oficina.
+ Sí, con tu tarjeta por favor como siempre. NO guardes el ticket ya que no ahce falta....

Cómo se detecta, aun sin acceso al servidor:

1. Dos reenvíos con el mismo In-Reply-To y distinto texto citado: uno de los dos fue alterado.
2. No encaja con el hilo. Martín había preguntado "¿El combustible lo cargo con la tarjeta del corralón?". La "respuesta" habla de su tarjeta "como siempre".
3. El estilo no es el de Raúl: errores de tipeo, puntos suspensivos de más, mayúsculas para remarcar.
4. Con la copia del servidor, el cotejo lo confirma.

2. El reenvío inventado

"Fwd: ANtiguedad" se armó reenviando "Reparto de mañana" y reemplazando todo el texto por "La verdad con una semana de antiguedad no podes esperar nada." Salió del servidor de la empresa, así que la firma es válida. Lo delata todo lo demás:

1. El asunto no coincide. El webmail arma solo "Fwd: ", pero acá el asunto es "Fwd: ANtiguedad" y el bloque citado dice ASUNTO: "Reparto de mañana". Alguien lo cambió a mano.
2. El In-Reply-To lo traiciona. Apunta al Message-ID de "Reparto de mañana". Ese mismo identificador aparece en los References de los otros reenvíos del hilo, y en el servidor ese correo es una lista de entregas, no un comentario sobre la antigüedad.
3. Contradice otra prueba: en "Vacaciones", Martín dice que entró "en marzo del año pasado".
4. El estilo: "ANtiguedad", sin tildes, nada parecido al resto de los correos de Raúl.

Qué le informa el perito al abogado

Y una conclusión general: la cuenta [email protected] existió y fue usada por Martín durante la relación. Eso, en un dominio cuyo titular es el dueño del negocio, ya es un indicio fuerte. Hay jurisprudencia en esa línea: en el caso "Mel c/ M y S Management S.A.", la Cámara Nacional del Trabajo (Sala II) consideró que una casilla en el dominio de la empresa era un indicio de que la empresa se la había habilitado al trabajador, aunque la pericia no pudo verificar los correos.

Los puntos de pericia que propondría

El perito de parte no tiene acceso al servidor de la empresa, pero sí puede ayudar al abogado a pedir lo que hace falta. Algunos puntos de pericia y oficios:

1. Que el perito oficial verifique las firmas DKIM y ARC de los .eml acompañados, e informe qué prueban y qué no.
2. Que el titular del dominio y el proveedor de correo informen fecha de alta, titular y uso de la casilla [email protected].
3. Que el proveedor (Ferozo/DonWeb) informe si en sus registros constan las entregas con id 1xJaqE-00GiMv-HQ, 1xJapR-00GhTo-SV, 1xJany-00Gg0E-49 (y las demás), con fecha, hora, remitente y destinatario.
4. Que se cotejen los mensajes con Message-ID <179260650691…@luiszambrana.ar> (y los demás) contra las casillas del servidor, incluida la carpeta de enviados de encargado@.
5. Que se informe qué clave DKIM publicaba el dominio en la fecha de los correos.

Si hay riesgo de que la empresa borre la casilla o el dominio, conviene pedir prueba anticipada apenas empieza el reclamo: los registros de los proveedores no se guardan para siempre.

El marco legal, en corto

Repito el aviso del principio: esto depende de la jurisdicción y cambia; lo enmarca el abogado. Pero hay normas que conviene conocer:

• Código Civil y Comercial, art. 319. El valor probatorio de un correo lo aprecia el juez ponderando, entre otras pautas, "la confiabilidad de los soportes utilizados y de los procedimientos técnicos que se apliquen". Ahí entra el trabajo del perito: hashes, cadena de custodia y verificación.
• Río Negro, Ley 5631 de procedimiento laboral. El art. 51 nombra expresamente a los correos electrónicos como medio de prueba, permite la prueba anticipada sobre medios digitales y establece una presunción en contra del empleador si tiene los sistemas y no los exhibe o no los preservó intencionalmente, con juramento del trabajador sobre su contenido. El art. 45 tiene una regla parecida para los libros y registros laborales. El art. 48 dice que los peritos se designan de oficio, por sorteo. El art. 39 deja los originales en custodia de quien los acompaña.
• Río Negro, Código Procesal Civil y Comercial (Ley 5777), que se aplica en forma supletoria (art. 86 de la Ley 5631). El art. 405 dice que "cada parte tiene la facultad de designar un consultor técnico", y el art. 406 indica que se lo nombra al ofrecer la pericia, junto con los puntos de pericia.
• Ley de Contrato de Trabajo, art. 23, con la redacción de la Ley 27.802 (2026): la prestación de servicios en situación de dependencia hace presumir el contrato de trabajo. Por eso pesan tanto los correos con órdenes, horarios y pagos: muestran dependencia.
• El convenio. Un corralón suele encuadrarse en el de Empleados de Comercio (CCT 130/75), aunque depende de la actividad principal de la empresa y de la tarea (el chofer de reparto, por ejemplo, se puede discutir). De eso surgen la categoría y lo que se reclama, y es terreno del abogado. Al perito le toca otra cosa: que la prueba sea confiable.

Checklist

• Pedir los .eml (o el mbox), nunca capturas ni impresiones.
• Calcular el hash SHA-256 al recibirlos, trabajar sobre copias y labrar el acta (mejor, ante escribano).
• Consultar el titular del dominio en NIC.ar y cruzarlo con ARCA.
• Guardar con fecha MX, SPF, DMARC y la clave DKIM publicada.
• Leer la cadena Received y controlar horarios, servidores y coherencia.
• Verificar DKIM y ARC con herramientas propias.
• Recordar que DKIM válido no garantiza el texto citado, y que los correos internos no suelen estar firmados.
• Cruzar In-Reply-To/References entre todos los reenvíos: dos versiones del mismo original delatan una edición.
• Controlar asunto, cronología, estilo y contradicciones con el resto de la prueba.
• Informarle al abogado qué se sostiene y qué no, y proponer puntos de pericia, oficios y prueba anticipada.

En resumen

Una pericia de correos no se trata de decir "el DKIM dio pass". La firma prueba de dónde salió un mensaje y que no se tocó después; no prueba que lo que dice sea verdad. En este caso, cinco de los siete reenvíos de Martín se sostienen (y uno, el que mandó como adjunto, se puede cotejar byte a byte con el servidor), y dos no resisten un análisis serio aunque todas sus firmas sean válidas. Detectarlos a tiempo es justamente lo que hace útil al perito de parte: el abogado llega al juicio con la prueba que se sostiene, y sin la que lo podía hundir.

En la próxima entrada de esta serie: WhatsApp como prueba, y por qué una captura de pantalla no alcanza.