Duriva recibe este tipo de caso con una frecuencia que debería preocupar a cualquier director de recursos humanos en México.
Un empleado llega al despacho del abogado laboralista con una carta de rescisión. El motivo: un correo electrónico enviado desde su cuenta corporativa con contenido que justifica el despido. Insultos a un superior. Filtración de información confidencial a un competidor. Acoso a un compañero. Amenazas. Lo que sea. El correo está ahí, impreso, anexo a la carta, con el nombre del empleado en el campo «De:» y la hora de envío perfectamente documentada.
El empleado dice que él no lo escribió. Que él no envió ese correo. Que alguien más lo hizo. Que fue una trampa.
Y aquí es donde empieza el problema real. Porque cuando alguien dice «yo no fui» después de un despido, la reacción natural de todos los involucrados — del abogado de la empresa, del director de RH, del juez laboral, incluso del propio abogado del empleado — es escepticismo. Claro que va a decir que no fue él. Todos dicen eso. Es lo primero que dice cualquier persona señalada por cualquier cosa.
Les soy franco: ese escepticismo es comprensible. Pero es un error cuando se aplica sin verificación técnica. Porque la suplantación de correo electrónico corporativo no es una fantasía de película de hackers. Es una realidad técnica que ocurre todos los días, que es relativamente sencilla de ejecutar para alguien con conocimientos básicos de redes, y que es perfectamente demostrable — o refutable — mediante un análisis forense de los headers del mensaje.
Este artículo va dirigido a cuatro personas que en este momento están leyendo desde posiciones muy distintas, probablemente con un nudo diferente en el estómago cada una.
Empleado que fue despedido por un correo que jura no haber escrito: Duriva entiende la impotencia que se siente cuando la prueba en tu contra es algo que no hiciste y nadie te cree. Este artículo te va a explicar exactamente qué tiene que buscar tu abogado y qué tiene que analizar un perito para demostrar tu inocencia.
Abogado laboralista que lleva la defensa de ese empleado: lo que sigue en las próximas secciones es el arsenal técnico-jurídico que necesita para montar una defensa sólida. No retórica. Ciencia.
Director de recursos humanos que usó ese correo como base para la rescisión: a ver a ver a ver. Este artículo también es para usted. Porque si ese correo resulta ser falso, la empresa no solo perdió a un empleado inocente — se expuso a una demanda laboral con consecuencias económicas significativas. Y el responsable de haber tomado una decisión basada en un papel impreso sin verificación técnica fue usted.
Abogado corporativo de la empresa que avaló el despido: si su dictamen jurídico se sustentó en un correo impreso sin análisis de headers, sin verificación de autenticidad, sin peritaje informático, este artículo le va a mostrar exactamente por dónde va a entrar la defensa del empleado. Y le va a entrar con datos que un juez no puede ignorar.
Un correo impreso no es prueba. Es tinta en papel.
Duriva lo ha dicho en foros, en cursos, en dictámenes, en audiencias. Lo repite cada vez que ve un expediente laboral donde la «prueba» es una hoja impresa con un correo electrónico: un correo impreso no prueba nada.
La afirmación suena radical. Pero no lo es. Es técnica.
Un correo electrónico impreso es, literalmente, tinta depositada sobre papel. Nada más. Es una representación visual de algo que supuestamente existió en un servidor de correo en algún momento. Pero esa representación no contiene ningún mecanismo de verificación de autenticidad. No tiene firma digital. No tiene hash. No tiene metadatos verificables. No tiene nada que permita a un perito — ni a un juez — confirmar que ese correo fue realmente enviado por quien dice el campo «De:», desde el servidor que dice, a la hora que dice, con el contenido que muestra.
Clic derecho, propiedades, ver el nombre en el campo «De:» — es un error común, mas no justificable. Y menos cuando se usa como base para destruir la carrera profesional de una persona.
Cualquier persona con conocimientos básicos de edición puede abrir un programa de procesamiento de texto, diseñar algo que se vea exactamente como un correo electrónico, imprimirlo y presentarlo como «prueba.» Puede poner el nombre que quiera en el campo «De:», puede escribir el contenido que le convenga, puede inventar la hora de envío. Y si nadie lo cuestiona técnicamente, esa hoja impresa se convierte en la base de un despido, de una demanda, de una decisión jurídica que afecta la vida de una persona real.
Pero incluso cuando el correo impreso proviene de una impresión legítima de la bandeja de entrada — cuando no fue fabricado en Word sino que alguien abrió Outlook, seleccionó el correo y le dio «Imprimir» — sigue sin ser prueba suficiente. Porque lo único que demuestra es que ese correo existía en esa bandeja de entrada en el momento de la impresión. No demuestra quién lo envió realmente. No demuestra que el contenido no fue alterado. No demuestra que la cuenta del remitente no fue comprometida. No demuestra nada que un perito informático no pueda verificar — o refutar — en menos de una hora si tiene acceso al correo original en el servidor.
Director de RH que basó la rescisión en un correo impreso: Duriva no le dice esto para hacerlo sentir mal. Se lo dice para que entienda el riesgo jurídico que asumió. Si el abogado del empleado solicita un peritaje informático y ese peritaje demuestra que el correo fue suplantado, la empresa no solo va a perder la demanda laboral. Va a tener que pagar indemnización, salarios caídos y, dependiendo del caso, posibles daños morales. Todo porque la decisión se tomó con base en tinta sobre papel en lugar de evidencia verificable.
El artículo 210-A del Código Federal de Procedimientos Civiles establece tres criterios para valorar la información generada por medios electrónicos: la fiabilidad del método en que fue generada, la posibilidad de atribuir su contenido a una persona determinada, y la accesibilidad de la información para su consulta posterior. Un correo impreso no cumple ninguno de estos tres criterios. Ninguno. Es un documento que un juez informado puede — y debe — cuestionar.
Los headers: la huella dactilar real de un correo electrónico
Aquí es donde la ciencia entra al terreno y la opinión sale.
Cada correo electrónico que se envía a través de internet lleva consigo un conjunto de datos técnicos que el usuario común nunca ve. Se llaman headers — encabezados de correo. Y son, para un perito informático, lo que una huella dactilar es para un criminalista: la evidencia objetiva, verificable e irrefutable de la identidad real del mensaje.
Los headers contienen información sobre cada servidor por el que pasó el correo desde que salió del equipo del remitente hasta que llegó a la bandeja del destinatario. Contienen la dirección IP real de origen. Contienen los registros de autenticación. Contienen los timestamps de cada salto en la cadena de transmisión. Contienen la evidencia de si el correo es genuino o fue suplantado.
Y lo más importante: los headers no se imprimen cuando alguien le da clic a «Imprimir» en su cliente de correo. Se quedan en el servidor. Invisibles para quien no sabe buscarlos. Perfectamente visibles para quien sí sabe.
Un perito informático forense no analiza el cuerpo del correo — el texto que todos ven. Analiza los headers. Porque el cuerpo de un correo es lo que alguien quiso que se leyera. Los headers son lo que realmente pasó.
Abogado laboralista que lleva la defensa del empleado: esto es lo que tiene que solicitar. No una copia impresa del correo. No un screenshot. No un PDF que alguien generó desde Outlook. Necesita acceso al correo original en el servidor, con headers completos, para que un perito los analice. Si la empresa se niega a proporcionar ese acceso, eso en sí mismo es un argumento procesal poderoso: están sustentando un despido en una prueba cuya autenticidad se niegan a verificar.
SPF, DKIM, DMARC: los tres candados que delatan una suplantación
Vamos a hablar de tres protocolos de autenticación de correo electrónico. Suenan técnicos. Lo son. Pero Duriva los va a explicar de una manera que cualquier abogado, cualquier juez y cualquier director de RH pueda entender, porque de estos tres protocolos depende la diferencia entre un correo auténtico y uno suplantado.
SPF: Sender Policy Framework
Imagine que usted trabaja en una empresa que se llama CompañiaXYZ. El dominio de correo de la empresa es @companiaxyz.com. El servidor de correo de la empresa está en una dirección IP específica — digamos, para simplificar, 200.100.50.25.
El SPF es una lista pública que dice: «Los únicos servidores autorizados para enviar correos en nombre de @companiaxyz.com son los que están en las direcciones IP 200.100.50.25, 200.100.50.26 y 200.100.50.27. Cualquier correo que diga venir de @companiaxyz.com pero que salga de una IP diferente, no es nuestro.»
Es como si la empresa publicara un directorio que dice: «Nuestros mensajeros oficiales son Juan, Pedro y María. Si alguien más llega con un paquete diciendo que es de nuestra empresa, no lo acepten.»
Cuando un perito analiza los headers de un correo y encuentra que el registro SPF falló — es decir, que el correo dice venir de @companiaxyz.com pero salió de una IP que no está en la lista autorizada — tiene una evidencia objetiva de que ese correo no fue enviado desde los servidores legítimos de la empresa. Punto. No hay interpretación. No hay ambigüedad. El SPF es un registro público, verificable, que cualquier perito puede consultar en tiempo real.
DKIM: DomainKeys Identified Mail
El DKIM es un paso más allá del SPF. Si el SPF verifica que el correo salió del servidor correcto, el DKIM verifica que el contenido del correo no fue alterado en el camino.
Funciona así: cuando el servidor de correo de la empresa envía un mensaje, le agrega una firma digital criptográfica. Esa firma es como un sello de cera en una carta antigua — si alguien abre la carta y la modifica, el sello se rompe. El servidor que recibe el correo verifica esa firma contra una clave pública que la empresa publicó en sus registros DNS. Si la firma coincide, el correo no fue alterado. Si no coincide, algo cambió entre el envío y la recepción.
Un correo con firma DKIM inválida o ausente es un correo cuya integridad no puede verificarse. Si además el SPF falló, la evidencia acumulativa de suplantación se vuelve contundente.
DMARC: Domain-based Message Authentication, Reporting and Conformance
El DMARC es el protocolo que le dice al servidor receptor qué hacer cuando un correo falla las verificaciones de SPF y DKIM. Es la política de la empresa para correos sospechosos.
Una empresa puede configurar su DMARC en tres niveles: «none» (no hacer nada, solo reportar), «quarantine» (mandar a cuarentena los correos sospechosos) o «reject» (rechazar de plano los correos que no pasen la autenticación).
Para un perito, el registro DMARC de la empresa es información valiosa porque revela el nivel de seguridad que la organización implementó en sus comunicaciones por correo. Si la empresa tiene un DMARC en «none» — es decir, no hace nada con los correos que fallan la autenticación — eso significa que correos suplantados pueden haber pasado sin ser detectados. Y eso abre la puerta a que el correo usado para justificar el despido sea, precisamente, uno de esos correos suplantados que la propia infraestructura de la empresa dejó pasar.
Director de RH: si la empresa que usted dirige no tiene configurados correctamente SPF, DKIM y DMARC, cualquier persona con conocimientos básicos puede enviar un correo que aparente venir de cualquier cuenta de su organización. De cualquiera. Del director general. Del gerente de finanzas. Del empleado que usted despidió. Y ese correo va a llegar a las bandejas de entrada con el nombre y la dirección correctos, indistinguible a simple vista de un correo genuino. La única diferencia va a estar en los headers. Y si nadie revisa los headers, nadie se entera.
Abogado corporativo que avaló el despido: si el correo que sustenta la rescisión fue recibido en un servidor cuyo DMARC está en «none,» la defensa del empleado va a argumentar — con toda la razón técnica del mundo — que la empresa no tenía los controles mínimos para garantizar la autenticidad de sus propias comunicaciones internas. Y un juez que entienda esto va a cuestionar por qué la empresa usó como prueba un correo cuya autenticidad ella misma no estaba verificando.
La IP que delata el verdadero origen
Más allá de SPF, DKIM y DMARC, los headers de un correo electrónico contienen otro dato que para un perito informático es oro puro: la dirección IP de origen.
Cada dispositivo conectado a internet tiene una dirección IP. Es su identificador en la red. Cuando se envía un correo electrónico, la dirección IP del equipo que lo envió queda registrada en los headers del mensaje. No en el cuerpo del correo. No en el campo «De:». En los headers. En esa parte que nadie ve a menos que sepa dónde buscar.
Un perito forense extrae la IP de origen de los headers y la compara con la información de red de la empresa. Si el correo fue enviado desde la cuenta corporativa del empleado, la IP de origen debería corresponder a la infraestructura de la empresa — el rango de IPs de la oficina, la VPN corporativa, el servidor de correo interno. Si la IP de origen es una dirección que no pertenece a la red de la empresa, si proviene de otro país, de otro estado, de un servicio de correo anónimo, de una red TOR, de un servidor VPS contratado con datos falsos — la pregunta se vuelve inevitable: ¿cómo envió el empleado un correo corporativo desde una IP que no tiene ninguna relación con la empresa ni con el empleado?
La respuesta es simple: no lo envió.
Pero hay un matiz que el diablo está en los detalles exige analizar. Hay escenarios donde el correo sí salió de la infraestructura de la empresa pero no del equipo del empleado. Alguien pudo haber accedido a la cuenta del empleado desde otro equipo dentro de la red corporativa. Alguien pudo haber obtenido las credenciales — usuario y contraseña — y haber enviado el correo desde su propia estación de trabajo. Y en ese caso, la IP de origen va a pertenecer a la empresa, pero no al equipo asignado al empleado despedido.
Aquí es donde el análisis se vuelve fino. Un perito experimentado no solo identifica la IP de origen. Cruza esa IP con los registros del servidor de correo, con los logs del controlador de dominio de la empresa (Active Directory en la mayoría de los entornos corporativos Windows), con los registros de acceso VPN, con los logs del firewall. Toda esa información le dice exactamente desde qué equipo físico se envió el correo, qué usuario de red estaba autenticado en ese equipo al momento del envío, y si hubo alguna anomalía en el patrón de acceso.
Duriva ha visto casos donde el cruce de IP con Active Directory revela que el correo fue enviado a las 2:47 de la mañana desde una estación de trabajo que el empleado despedido nunca había utilizado, ubicada en un piso del edificio al que el empleado no tenía acceso con su tarjeta de proximidad. La convergencia de datos de red, datos de acceso físico y datos del servidor de correo construye una reconstrucción forense que no deja espacio para la interpretación: el empleado no envió ese correo. Alguien más lo hizo. Desde otro equipo. Con sus credenciales.
Y ahí entra la siguiente pregunta: ¿cómo obtuvo esa persona las credenciales?
Reglas de reenvío ocultas y acceso no autorizado a cuentas
Hay un vector de ataque que Duriva encuentra con una frecuencia preocupante en entornos corporativos y que la mayoría de los departamentos de TI no detecta hasta que un perito lo señala: las reglas de reenvío ocultas.
En la mayoría de los clientes de correo corporativo — Outlook, Exchange, Google Workspace — cualquier usuario puede crear reglas automáticas que reenvíen copias de ciertos correos a otra cuenta. Estas reglas se configuran en segundos, operan de manera silenciosa y, si se crean en la cuenta de otra persona mediante acceso no autorizado, permiten al atacante leer toda la correspondencia de la víctima sin que esta se entere.
Pero la variante más peligrosa no es el reenvío pasivo. Es la creación de reglas que permiten enviar correos en nombre de otra cuenta. En entornos Exchange mal configurados — y les soy franco, la mayoría de los entornos corporativos en México tienen deficiencias de configuración que harían palidecer a cualquier auditor de seguridad — es posible configurar permisos de «Enviar como» (Send As) que permiten a un usuario enviar correos que aparecen como si vinieran de otra cuenta. Sin dejar rastro visible para el destinatario. Sin que el titular de la cuenta suplantada reciba notificación alguna.
Un perito forense revisa los logs de administración de Exchange o del servidor de correo correspondiente para identificar si se otorgaron permisos de «Enviar como» en la cuenta del empleado despedido. Revisa si existen reglas de reenvío activas o recién eliminadas. Revisa los registros de modificación de permisos en Active Directory. Todo esto queda registrado en los logs del servidor, y esos logs tienen timestamps que el administrador de sistemas no puede alterar sin dejar, a su vez, evidencia de la alteración.
El diablo está en los detalles. Y en informática forense corporativa, el diablo vive en los logs de Exchange y en los permisos de Active Directory.
Empleado despedido que lee esto: si alguien en tu empresa tenía la intención de perjudicarte, no necesitaba ser un hacker sofisticado. Bastaba con conocer tu contraseña — o adivinarla, o verla escrita en un Post-it pegado al monitor, que es algo que Duriva ha documentado en inspecciones corporativas con vergonzosa frecuencia — para enviar un correo desde tu cuenta. Y si el departamento de TI no tiene los controles adecuados, ese correo pasó como si fuera tuyo.
Caso de referencia: 60 equipos bajo la lupa
Duriva ha realizado inspecciones forenses en entornos corporativos de todos los tamaños. Pero hay un caso — sin nombres, sin datos que identifiquen a la empresa, porque la confidencialidad es innegociable — que ilustra perfectamente lo que pasa cuando una organización toma decisiones disciplinarias basadas en correos electrónicos sin verificación técnica.
La empresa solicitó una inspección de 60 equipos de cómputo. Sesenta. No uno. No cinco. Sesenta estaciones de trabajo que debían ser analizadas en el contexto de una investigación interna por presunta filtración de información confidencial.
Lo que encontró el equipo de Duriva en esas 60 máquinas no fue lo que la empresa esperaba. Había equipos con sesiones de correo abiertas de usuarios que no eran los titulares de esas estaciones. Había contraseñas almacenadas en navegadores sin protección. Había permisos de administración local otorgados a usuarios que no debían tenerlos. Había políticas de contraseñas que permitían combinaciones como «empresa2024» o «password123.» Había equipos compartidos donde tres o cuatro personas usaban la misma sesión de Windows con el mismo usuario genérico.
En ese entorno — que no es atípico, es común en empresas mexicanas de tamaño mediano — atribuir un correo electrónico a un empleado específico basándose únicamente en el campo «De:» es, siendo generosos, ingenuo. Y siendo precisos, irresponsable.
La inspección de esos 60 equipos demostró que la empresa no tenía los controles necesarios para garantizar que un correo enviado desde la cuenta de Juan fue efectivamente enviado por Juan y no por Pedro que tenía acceso al equipo de Juan, o por Luisa que conocía la contraseña de Juan, o por el becario que usaba una sesión de administrador sin restricciones.
Abogado laboralista: ese escenario es su argumento. Si la empresa no puede demostrar que sus controles de acceso son suficientes para garantizar la atribuibilidad de un correo a un empleado específico, la prueba es impugnable. Y si el peritaje revela que el entorno corporativo tenía las deficiencias que Duriva encuentra en la gran mayoría de las inspecciones, la empresa va a tener muy difícil sostener que el correo lo envió su cliente.
Wireshark, tráfico de red y lo que no se ve a simple vista
Sin entrar en tutoriales ni detalles que no corresponden a un artículo de orientación, Duriva considera pertinente mencionar un nivel adicional de análisis que aplica en casos corporativos de alta complejidad: el análisis de tráfico de red.
Cuando una empresa tiene implementado un sistema de monitoreo de red — y muchas empresas de tamaño mediano y grande lo tienen, aunque no siempre lo usan de manera efectiva — los paquetes de datos que circulan por la red interna quedan registrados. Herramientas de análisis de tráfico permiten a un perito reconstruir la actividad de red de un equipo específico en un momento determinado: qué conexiones estableció, con qué servidores se comunicó, qué protocolos utilizó, qué volumen de datos transmitió.
En el contexto de un correo suplantado, el análisis de tráfico de red puede revelar que la conexión al servidor de correo para enviar el mensaje en cuestión provino de un equipo que no es el del empleado despedido. Puede revelar que hubo actividad anómala en la red — un intento de acceso remoto, una conexión VPN no autorizada, un patrón de tráfico inconsistente con el comportamiento habitual de la cuenta. Puede, incluso, revelar que alguien accedió a la cuenta del empleado desde fuera de la red corporativa utilizando credenciales robadas.
Este nivel de análisis no siempre es posible — depende de que la empresa tenga los registros de red disponibles, de que no hayan sido sobrescritos, de que el periodo de retención no haya vencido. Pero cuando los datos están disponibles, la reconstrucción forense alcanza un nivel de detalle que no deja espacio para la duda.
La autorización para leer correos del empleado: la cláusula que pocos leen
Hay un punto jurídico que cruza la línea entre lo técnico y lo legal, y que Duriva aborda porque tiene implicaciones directas en la estrategia de defensa y en la actuación de la empresa.
La pregunta es: ¿la empresa tenía autorización para acceder al correo del empleado?
En muchos contratos laborales existe una cláusula que establece que las herramientas tecnológicas proporcionadas por la empresa — incluyendo el correo electrónico corporativo — son propiedad de la empresa y que el empleador se reserva el derecho de acceder a su contenido en el marco de investigaciones internas. Si esa cláusula existe, está firmada por el empleado y cumple con los requisitos legales aplicables, la empresa tiene un marco contractual para haber accedido al correo.
Pero si esa cláusula no existe — y en una cantidad sorprendente de empresas mexicanas no existe, o está redactada de manera ambigua, o no fue firmada por el empleado, o no cumple con los requisitos de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares — el acceso al correo del empleado puede constituir una violación a su derecho a la privacidad.
Abogado laboralista: este es un flanco que merece exploración. Si la empresa accedió al correo de su cliente sin la autorización contractual correspondiente, la obtención de esa prueba puede ser impugnable por ilícita. Y una prueba obtenida de manera ilícita — independientemente de lo que diga su contenido — tiene un problema probatorio de origen que un juez debe considerar.
Abogado corporativo: si la empresa no tiene esa cláusula en sus contratos laborales, Duriva le sugiere que lo resuelva antes de que se convierta en un problema en el siguiente caso. Porque va a haber un siguiente caso. Siempre lo hay.
Timestamps de envío en headers vs zona horaria: el detalle que nadie revisa
Hay un elemento en los headers de correo que Duriva ha utilizado en múltiples dictámenes para demostrar inconsistencias en correos suplantados y que, por su naturaleza técnica, pasa desapercibido para quienes no tienen formación en informática forense: los timestamps y las zonas horarias.
Cada servidor por el que pasa un correo electrónico agrega un header con la hora en que recibió el mensaje. Estas marcas de tiempo incluyen la zona horaria del servidor. Un correo que se envió desde la Ciudad de México (UTC-6) debería tener timestamps consistentes con esa zona horaria en el servidor de origen.
Cuando un correo es suplantado desde otra ubicación geográfica — por ejemplo, desde un servidor ubicado en Europa, Asia o incluso en otra zona horaria de América — los timestamps revelan la discrepancia. El correo dice haber sido enviado a las 10:00 de la mañana hora de México, pero el primer servidor que lo recibió registra un timestamp de las 17:00 UTC+1, que corresponde a un servidor en Europa Central. Eso no cuadra con un empleado sentado en su escritorio en la oficina de Guadalajara.
Y hay una variante más sutil: los desfases de microsegundos entre los timestamps de los distintos servidores. Un correo genuino que viaja del servidor de la empresa al servidor del destinatario muestra una progresión lógica de timestamps — el servidor de origen lo registra primero, luego el servidor intermedio, luego el servidor de destino. Cada timestamp es posterior al anterior por un margen consistente con la velocidad de transmisión de datos. Un correo suplantado, inyectado artificialmente en la cadena, puede mostrar desfases anómalos: timestamps que no siguen la progresión lógica, intervalos que no corresponden a la latencia real de la red, o incluso timestamps retroactivos donde un servidor «recibió» el correo antes de que el servidor anterior lo «enviara.»
Esas anomalías son invisibles para cualquiera que lea el correo en la pantalla. Son perfectamente visibles para un perito que analiza los headers línea por línea.
«Me despidieron con un papel» — qué hacer paso a paso
Empleado que fue despedido por un correo que no escribió: lo que sigue es lo que Duriva recomienda, paso por paso, basado en la experiencia de haber analizado cientos de correos corporativos en contextos litigiosos.
Paso 1: No firme nada bajo presión.
Cuando RH le presenta la carta de rescisión con el correo impreso como evidencia, la reacción natural es el shock. Y en estado de shock, la gente firma cosas que no debería firmar. La carta de rescisión, la renuncia «voluntaria,» el acuerdo de confidencialidad que incluye una renuncia a acciones legales. No firme nada hasta que un abogado laboralista revise cada documento. Si le dicen que tiene que firmar en ese momento, sepa que no es así. Usted tiene derecho a buscar asesoría legal antes de firmar cualquier documento relacionado con la terminación de su relación laboral.
Paso 2: Documente todo antes de perder acceso.
En el momento en que lo despiden, la empresa va a desactivar su acceso al correo corporativo, a la red interna, a los sistemas de la empresa. Eso puede pasar en minutos. Antes de que ocurra — si todavía tiene acceso –, envíe a su correo personal los headers completos del correo que le imputan. No el correo impreso. Los headers. En Outlook: abra el correo, vaya a Archivo, Propiedades, y copie todo el contenido del campo «Encabezados de Internet.» Eso es lo que un perito necesita. Si no sabe cómo hacerlo, tome una fotografía clara de la pantalla con su teléfono personal. No es lo ideal — lo ideal es el acceso directo al servidor — pero es mejor que nada.
Si ya perdió acceso, no entre en pánico. Los datos están en el servidor de la empresa y pueden ser requeridos judicialmente.
Paso 3: Busque un abogado laboralista que entienda evidencia digital.
No cualquier abogado laboralista. Uno que entienda que la prueba no es el correo impreso sino los headers en el servidor. Uno que sepa solicitar un peritaje informático. Uno que comprenda la diferencia entre SPF, DKIM y DMARC, o que al menos tenga la humildad de asociarse con un perito que sí la entienda. La intersección entre derecho laboral y forensia informática es un territorio donde pocos abogados se mueven con soltura. Pero esos pocos son los que ganan estos casos.
Paso 4: Solicite formalmente los logs del servidor de correo.
A través de su abogado, solicite a la empresa — o mediante requerimiento judicial si la empresa se niega — los registros completos del servidor de correo relacionados con el mensaje en cuestión. No solo el correo. Los logs de acceso a la cuenta, los registros de autenticación, los logs de Active Directory que muestren qué usuario de red estaba autenticado al momento del envío, los registros de conexión VPN si aplica. Todo. Cada dato que la empresa tiene en sus servidores sobre ese evento es potencialmente relevante.
Paso 5: Contrate un peritaje informático formal.
No una «opinión técnica.» No un «análisis informal.» Un peritaje informático formal, realizado por un perito certificado, con metodología documentada, con cadena de custodia, con valor hash SHA-256, con un dictamen que cumpla los requisitos del artículo 210-A y que pueda ser presentado ante un juez con todo el peso probatorio que la ley le otorga.
El perito va a analizar los headers del correo, va a verificar SPF, DKIM y DMARC, va a identificar la IP de origen, va a cruzarla con los registros de red de la empresa, va a revisar si existen reglas de reenvío ocultas o permisos de «Enviar como» no autorizados, va a analizar los timestamps, va a documentar cualquier anomalía. Y va a emitir un dictamen que diga, con certeza técnica, si ese correo fue enviado por el empleado o fue suplantado.
Paso 6: Plantee la pregunta que cambia todo.
Cuando el peritaje está listo y los resultados demuestran la suplantación, su abogado necesita plantearle a la empresa — o al juez, si ya se llegó a ese punto — la pregunta que cambia la dinámica completa del caso: ¿van a proceder legalmente?
Porque si el correo fue suplantado, hay un delito. Alguien suplantó la identidad de un empleado para provocar su despido. Eso no es una travesura. Eso es un ilícito que puede tener consecuencias penales para quien lo cometió. Y la empresa tiene que decidir si quiere investigar quién lo hizo — lo cual implica abrir una caja de Pandora interna — o si prefiere llegar a un acuerdo con el empleado afectado.
Esa pregunta — ¿van a proceder legalmente? — obliga a la empresa a reconocer que el correo fue suplantado y que hay un responsable dentro de su organización. Y esa es una posición muy incómoda para cualquier empresa.
El onus probandi en el despido por correo electrónico
Hay un principio jurídico que aplica directamente a estos casos y que todo abogado laboralista debe tener presente: onus probandi. El que afirma, prueba.
Si la empresa afirma que el empleado envió un correo con contenido que justifica el despido, la empresa tiene que probar que el empleado efectivamente lo envió. No basta con mostrar un correo con su nombre en el campo «De:». Tiene que demostrar, con evidencia técnica verificable, que el correo fue enviado desde la cuenta del empleado, por el empleado, desde un equipo que el empleado utilizaba, sin que mediara suplantación, acceso no autorizado o manipulación.
Si la empresa no puede demostrar eso — y en la experiencia de Duriva, muchas empresas no pueden porque no tienen los controles técnicos necesarios para hacerlo — el despido carece de fundamento probatorio. El correo impreso que anexaron a la carta de rescisión no es más que tinta en papel. Y la carga de la prueba sigue recayendo sobre la empresa.
Abogado laboralista: el onus probandi es su columna vertebral en estos casos. La empresa despidió. La empresa alega que el correo es genuino. La empresa tiene que probarlo. Y para probarlo, necesita presentar un peritaje informático propio que demuestre la autenticidad del correo con análisis de headers, verificación de protocolos de autenticación, cruce de IPs y revisión de logs. Si no presenta ese peritaje, está pidiendo que el juez acepte como prueba un correo cuya autenticidad nadie verificó.
Y si la empresa presenta su propio peritaje y usted presenta el suyo, el juez tiene dos dictámenes periciales para evaluar. Y ahí gana el que tenga mejor fundamento técnico, mejor metodología, mejor documentación. Ahí gana la ciencia. Que es exactamente donde Duriva quiere que se diriman estos casos.
Preguntas frecuentes
¿Mi empresa me despidió por un correo y solo me mostraron una impresión. Eso es prueba suficiente?
No. Un correo impreso no cumple los requisitos del artículo 210-A para ser valorado como prueba electrónica. No demuestra fiabilidad del método de generación, no permite atribuir el contenido a una persona determinada sin verificación de headers, y su accesibilidad para consulta posterior depende del acceso al servidor original. Un peritaje informático sobre los headers del correo original es la única forma de determinar si el correo es genuino o fue suplantado.
¿Puedo demostrar que alguien más envió el correo desde mi cuenta?
Sí, mediante un peritaje informático forense. El análisis de headers identifica la IP de origen, verifica los protocolos SPF, DKIM y DMARC, y cruza los datos con los registros de red de la empresa para determinar desde qué equipo físico se envió el correo. Si la IP de origen no corresponde a su equipo de trabajo, si los timestamps muestran anomalías, si los logs de Active Directory revelan que otro usuario estaba autenticado en el equipo desde el cual se envió — la evidencia de suplantación se construye dato por dato, verificable e independiente.
¿La empresa se niega a darme acceso a los logs del servidor. Qué hago?
Su abogado puede solicitar al juez laboral un requerimiento judicial para que la empresa proporcione los registros del servidor de correo, los logs de Active Directory, los registros de acceso VPN y cualquier otra información técnica relevante. La negativa de la empresa a proporcionar estos datos, cuando ella misma basa el despido en un correo electrónico, puede ser considerada por el juez como una obstrucción a la verificación de la prueba. Y una prueba cuya autenticidad no se permite verificar es una prueba débil.
¿Qué pasa si la empresa no tiene configurados SPF, DKIM ni DMARC?
Eso fortalece significativamente la defensa del empleado. Si la empresa no implementó los protocolos básicos de autenticación de correo, significa que su infraestructura era vulnerable a suplantación. Cualquier persona — interna o externa — podía enviar correos que aparentaran provenir de cualquier cuenta corporativa. En ese escenario, la empresa no puede garantizar la atribuibilidad de ninguno de sus correos a un empleado específico. Es como si una empresa despidiera a un empleado por haber firmado un documento, pero la empresa no tuviera registro de firmas autorizadas. ¿Cómo saben que esa firma es de él?
¿Cuánto tiempo tiene la empresa para conservar los logs del servidor?
Esto varía según la política de retención de la empresa y no existe una obligación legal estandarizada para todos los sectores. Algunas empresas conservan logs por 30 días, otras por 90, otras por un año. Lo crítico es actuar rápido. Si la empresa sobrescribe sus logs cada 30 días y usted tarda tres meses en solicitar el análisis, esos registros pueden haberse perdido. La rapidez en la solicitud del peritaje es directamente proporcional a la disponibilidad de la evidencia.
¿Pueden despedirme por revisar correos de la empresa?
No en el sentido que la pregunta implica. Lo que la empresa puede hacer — si tiene la cláusula contractual correspondiente firmada por el empleado — es acceder al correo corporativo en el marco de una investigación interna. Pero ese acceso debe estar fundamentado, documentado, y realizarse conforme a la normatividad aplicable. Un acceso indiscriminado, sin causa justificada, sin cláusula contractual y sin respeto a la Ley Federal de Protección de Datos Personales puede ser impugnable y puede incluso generar responsabilidad para la empresa.
¿Qué diferencia hay entre que un perito analice el correo y que el departamento de TI de la empresa haga la revisión?
La diferencia es independencia y valor probatorio. El departamento de TI de la empresa trabaja para la empresa. Su análisis no es independiente. Un perito informático externo, certificado, que emite un dictamen formal con metodología documentada y cadena de custodia, produce una prueba con valor probatorio ante un juez. El reporte del departamento de TI de la empresa es, en el mejor de los casos, un documento interno. En el contexto de un litigio, la independencia del peritaje es fundamental para su credibilidad.
¿Es posible que el correo sea genuino pero alguien haya accedido a mi cuenta para enviarlo?
Sí. Y este es un escenario que Duriva analiza con tanta frecuencia como la suplantación externa. Si alguien obtuvo las credenciales de un empleado y envió el correo desde su cuenta, el correo va a pasar las verificaciones de SPF y DKIM porque técnicamente salió del servidor correcto con la autenticación correcta. Pero los logs de Active Directory, los registros de acceso y la IP de origen van a revelar que la sesión se inició desde un equipo diferente al del empleado, a una hora inusual, con un patrón de actividad inconsistente. La suplantación de credenciales es demostrable. Requiere un análisis más profundo que la suplantación externa, pero es demostrable.
La prevención que ninguna empresa quiere escuchar
Duriva considera necesario cerrar este artículo con un mensaje para las empresas. No porque sea el arquetipo principal de este contenido, sino porque la prevención es exponencialmente más barata que el litigio.
La implementación correcta de SPF, DKIM y DMARC no es un lujo. Es higiene digital básica. Tener políticas de contraseñas robustas, autenticación multifactor, logs de acceso con periodos de retención adecuados, control de permisos en Active Directory y cláusulas contractuales claras sobre el uso de herramientas tecnológicas no es paranoia corporativa. Es gestión de riesgos.
Cada caso de despido impugnado por correo suplantado que llega al laboratorio de Duriva empezó con una deficiencia de controles que la empresa pudo haber corregido antes de que el problema existiera. Pero no lo hizo. Y ahora está pagando abogados, peritos, indemnizaciones y daños reputacionales que cuestan diez veces más que la implementación de las medidas de seguridad que habrían evitado todo.
Cierre
El correo electrónico corporativo no es un documento sagrado. Es un registro digital que puede ser suplantado, alterado, inyectado, manipulado. Y la única forma de verificar su autenticidad es mediante el análisis forense de sus headers, sus protocolos de autenticación y sus registros de red.
Un empleado no debería perder su trabajo por un correo que no envió. Y una empresa no debería tomar decisiones disciplinarias basándose en tinta sobre papel cuando la ciencia le ofrece certezas verificables.
Duriva analiza correos electrónicos corporativos en el contexto de disputas laborales, investigaciones internas y procedimientos judiciales. Con más de 17 años de experiencia en informática forense, más de 1,300 peritos formados en todo México y un récord invicto en casos contra instituciones financieras, el equipo de Duriva sabe dónde buscar lo que otros pasan por alto.
Si fue despedido por un correo que no escribió, la evidencia está en los headers. Y los headers no mienten.