Curso interactivo de email: protocolos, autenticación y phishing

El correo electrónico parece una herramienta sencilla: escribimos, pulsamos «Enviar» y el mensaje aparece en otro buzón. Sin embargo, detrás de ese gesto actúa una cadena de clientes, servidores, consultas DNS, cabeceras, firmas y decisiones antispam. El curso interactivo Básicos Email convierte esa infraestructura invisible en un recorrido visual y práctico. Está pensado para quien usa correo a diario, administra un dominio, investiga mensajes sospechosos o construye automatizaciones que envían email sin tener todavía un modelo mental completo del sistema.

Al terminar, no solo sabrás distinguir SMTP, IMAP, MIME o MX. Podrás separar el remitente visible del remitente técnico, interpretar resultados SPF, DKIM y DMARC, seguir una cadena Received de abajo arriba y valorar señales de phishing sin depender de una única luz verde o roja. El aprendizaje va de lo básico a lo profesional, pero evita exigir conocimientos previos de redes. La interacción permite tocar cada pieza, avanzar por una entrega, pegar cabeceras y recibir una lectura inmediata.

Esta materia es especialmente relevante porque el phishing sigue siendo una puerta de entrada decisiva para el robo de credenciales y el fraude. También lo es para equipos que incorporan agentes de IA capaces de redactar y enviar correos: automatizar el contenido no elimina la responsabilidad sobre la identidad del dominio, la entregabilidad ni la seguridad. Un agente puede escribir un mensaje excelente y aun así enviarlo desde una infraestructura con SPF incompleto, DKIM ausente o DMARC desalineado. El curso ayuda a entender por qué esos registros forman una sola cadena de confianza.

Anatomía del contenido: un recorrido sección a sección

Mapa del ecosistema

El primer espacio de trabajo organiza el correo como un sistema, no como una aplicación aislada. El mapa relaciona once componentes: MUA, MSA, DNS, MTA, MDA, buzón, formato RFC 5322, MIME, autenticación, cabeceras y TLS. Al seleccionar un nodo aparece su categoría, resumen, detalles y enlaces a RFC. Esta vista resuelve una confusión habitual: llamamos «correo» tanto al cliente que muestra un mensaje como al protocolo que lo transporta, al formato que lo representa y al almacén que lo conserva.

El MUA es el cliente o webmail en el que se redacta y lee. Crea campos visibles como From, To, Subject, Date y Message-ID, entrega el mensaje a un servidor de submission y recupera el buzón mediante IMAP, POP3 o una API. El MSA recibe el envío de un usuario autenticado, normalmente por el puerto 587 con STARTTLS; puede completar cabeceras, aplicar políticas y firmar con DKIM. La distinción entre MUA y MSA enseña que pulsar «Enviar» no equivale todavía a entregar el correo al dominio destinatario.

El MTA transfiere mensajes entre dominios con SMTP. Consulta el registro MX, abre la sesión con el servidor remoto y añade trazas Received. El MDA entra en juego tras la aceptación: puede aplicar filtros, clasificar el mensaje y depositarlo en el buzón. Desde allí, IMAP sincroniza mensajes, carpetas y estados entre dispositivos, mientras POP3 ofrece un modelo de descarga más simple. El mapa presenta así una cadena de responsabilidades donde cada agente observa y modifica elementos distintos.

DNS ocupa una posición central. MX indica qué servidores aceptan correo para el dominio; SPF, DKIM y DMARC se publican como registros TXT. El curso remarca que una configuración incorrecta puede perjudicar mensajes legítimos o facilitar la suplantación. También separa el mensaje RFC 5322 (cabeceras, línea vacía y cuerpo) de MIME, que añade tipos de contenido, HTML, adjuntos, codificación de transferencia y estructuras multiparte.

La seguridad se completa con autenticación y TLS. SPF relaciona la IP emisora con el dominio del envelope sender; DKIM verifica una firma aplicada a cabeceras y cuerpo con una clave publicada en DNS; DMARC exige que al menos una autenticación válida esté alineada con el dominio del From visible y aporta una política de manejo. TLS protege conexiones, pero el curso advierte que STARTTLS no autentica por sí solo el contenido. MTA-STS y TLS-RPT aparecen como mecanismos para endurecer y observar el transporte entre dominios.

MUA → MSA → MTA emisor → [DNS: MX] → MTA receptor → MDA → buzón → MUA
       AUTH/TLS            SMTP            SPF · DKIM · DMARC       IMAP

Viaje de un email

La segunda sección convierte el flujo anterior en una simulación de siete pasos con botones para avanzar, retroceder o reiniciar. Cada paso identifica actor, artefacto, resumen, puntos clave y piezas técnicas. Empieza en «Redactar»: el MUA construye el mensaje RFC 5322 con From, To, Subject, Date y Message-ID. El contenido puede ser texto, HTML o multipart MIME; los adjuntos son partes MIME con tipo y nombre. Esta primera parada fija una idea fundamental: esos campos pertenecen al mensaje, no al sobre SMTP.

En «Entregar al servidor autorizado», el usuario presenta el mensaje al MSA. El curso muestra AUTH, TLS y DKIM como piezas separadas: la autenticación demuestra que el usuario puede enviar, TLS cifra el canal y DKIM firma determinadas partes antes del relay. El paso siguiente, «Resolver destino», explica que el MTA consulta los registros MX del dominio situado tras la arroba. Si existen varios, utiliza sus preferencias; una caída temporal suele generar reintentos, no pérdida instantánea.

«Transferir por SMTP» muestra el sobre técnico. MAIL FROM define el remitente usado para rebotes y como referencia de SPF; RCPT TO contiene los destinatarios reales; DATA transmite cabeceras y cuerpo. Esta separación explica por qué el From que ve una persona puede no coincidir con Return-Path y por qué un resultado SPF positivo no valida automáticamente el nombre o dominio destacado por la interfaz.

En «Comprobar autenticación», el receptor compara la IP con SPF, verifica DKIM mediante DNS y evalúa la alineación DMARC. Después, «Entregar al buzón» combina autenticación, reputación, contenido, malware y reglas para decidir bandeja de entrada, cuarentena o spam. El sistema puede añadir Authentication-Results dentro de su dominio de confianza. Finalmente, «Leer con contexto» devuelve el correo al MUA: la persona ve una versión simplificada, mientras las cabeceras completas contienen las pistas necesarias para investigar.

Anatomía del mensaje

La vista de anatomía ofrece un correo de ejemplo cuyas filas se seleccionan con ratón o teclado. From es el autor visible, pero no prueba quién envió el mensaje. To, Cc y Bcc describen destinatarios; Bcc no aparece para los demás. Subject es texto libre y fácil de manipular. Date es la fecha declarada por quien crea el mensaje y conviene compararla con Received. Message-ID debería ser único y su dominio puede aportar contexto, sin constituir una prueba definitiva.

El cuerpo puede incluir texto plano, HTML, imágenes remotas y adjuntos. MIME define Content-Type, Content-Disposition, codificaciones y límites multipart. La sección amplía además las piezas seleccionables a sobre SMTP, Received y Authentication-Results. Esta progresión es útil porque obliga a dejar de leer el mensaje como una captura de pantalla: una investigación real compara lo visible, lo transportado y lo añadido por la infraestructura.

Laboratorio de cabeceras

El laboratorio es el núcleo práctico. Incluye un área de texto y tres acciones: analizar, cargar un ejemplo o limpiar. La muestra contiene Return-Path, dos trazas Received con ESMTPS, Authentication-Results con SPF, DKIM y DMARC en pass, From, Reply-To, To, Subject, Date, Message-ID, MIME-Versión y Content-Type. También se pueden pegar cabeceras propias; el análisis se ejecuta localmente en el navegador.

El parser normaliza saltos de línea y despliega continuaciones: una cabecera larga puede ocupar varias líneas físicas, pero sigue siendo un único campo lógico. Agrupa valores por nombre y extrae dominios de From, Reply-To, Return-Path y Message-ID. Después localiza SPF, DKIM y DMARC dentro de Authentication-Results y cuenta las cabeceras Received.

El informe señala si faltan From, Date o Message-ID; advierte si no existe Authentication-Results; marca como correctos los métodos con pass y como alerta fail, softfail, permerror o temperror. Los resultados none y neutral quedan como información para revisar. Compara el dominio de Reply-To y Return-Path con From, comprueba si el Message-ID parece alineado, informa del número de saltos y reconoce ESMTPS como indicio de transporte cifrado en al menos una conexión. Si Content-Type contiene text/html, recuerda revisar enlaces y recursos remotos.

Es importante interpretar bien su alcance. El propio curso trata las discrepancias como pistas, no como sentencias. Un Return-Path diferente puede ser normal cuando se usa una plataforma de envío; una firma DKIM válida asocia el mensaje con un dominio firmante, pero no garantiza una intención benigna; y la ausencia de Authentication-Results puede deberse a cabeceras incompletas. El valor del laboratorio está en entrenar una lectura ordenada, no en reemplazar un sistema forense o antispam.

From visible:      soporte@empresa.com
MAIL FROM / SPF:   bounce@proveedor.net
DKIM d=:           empresa.com
DMARC:             pasa si SPF o DKIM válidos se alinean con From

Received más nuevo
↑ leer hacia arriba en la interfaz, pero reconstruir de abajo arriba
Received más antiguo (cerca del origen)

Detección de phishing

La sección de phishing presenta ocho señales seleccionables con peso. Un nombre visible convincente asociado a otro dominio suma riesgo, igual que un dominio visualmente parecido al legítimo. También se evalúan Reply-To hacia otro dominio, fallos SPF/DKIM/DMARC, presión económica o urgencia, discrepancia entre texto y destino de enlaces, adjuntos ejecutables, con macros, HTML o comprimidos, y una ruta Received incoherente.

Al marcar señales, el panel suma sus pesos y genera una evaluación orientativa. La autenticación fallida recibe el peso más alto; varias señales técnicas y de contenido valen tres puntos; otras, como urgencia o Reply-To distinto, aportan dos. Este diseño enseña una práctica sana: el phishing rara vez se decide con una sola característica. Hay que combinar identidad, infraestructura, contenido y contexto.

La guía de repaso refuerza los límites de cada mecanismo. SPF observa MAIL FROM o HELO, no el From visible. DKIM prueba integridad respecto de una firma y un dominio, no bondad; además, un reenvío puede romperla. DMARC añade alineación, pero no detecta dominios parecidos, ni analiza enlaces o adjuntos. Cuando hay dinero o credenciales en juego, el curso recomienda verificar por otro canal y reportar en lugar de reenviar cuando sea posible.

Quiz, guía, referencias y glosario

El quiz contiene ocho preguntas de opción múltiple sobre SPF, Authentication-Results, lectura de Received, DKIM, MX, alineación DMARC, IMAP y MIME. Tras responder, las opciones quedan deshabilitadas, la correcta se resalta, una elección errónea se distingue y aparece la explicación. Solo entonces se habilita «Siguiente pregunta». Al finalizar se muestran puntuación y porcentaje; con un 80 % o más aparece «Buen dominio del email», y por debajo se invita a reforzar. Se puede repetir desde cero.

La guía resume seis hábitos: separar sobre, mensaje e interfaz; leer Received de abajo arriba; no confundir SPF con validación del From; reconocer lo que DKIM no asegura; entender las fronteras de DMARC; y combinar técnica y contexto frente al phishing. La biblioteca de referencias se filtra por categorías y admite búsqueda por protocolo, cabecera o RFC. Incluye transporte, formato, acceso, autenticación, TLS, MTA-STS, TLS-RPT, ARC e internacionalización. El glosario desplegable cierra el recorrido con MUA, MTA, MX, envelope sender, Header From y alignment.

Cómo está construida la experiencia interactiva

El repositorio de Básicos Email contiene HTML, CSS y JavaScript plano. No necesita npm, backend, API externa ni plan de pago. La excepción es el mapa principal, que carga Cytoscape.js 3.34.1 desde jsDelivr; si la biblioteca no está disponible, el código representa un mapa alternativo mediante botones. Por tanto, la experiencia conserva acceso al contenido básico incluso sin el grafo.

Los contenidos se definen como estructuras de datos en script.js: listas de componentes, pasos, referencias, señales, guía y preguntas. Las funciones de renderizado convierten esas estructuras en controles HTML, escapan el texto introducido antes de insertarlo y conectan eventos. El mapa responde a selección de nodos; el viaje mantiene un índice limitado entre el primer y último paso; la anatomía admite clic, Enter y barra espaciadora; y el buscador de referencias filtra en tiempo real.

La evaluación del quiz vive solo en memoria durante la sesión. Lleva índice, puntuación y estado de respuesta, pero no guarda progreso académico en localStorage. Reiniciar devuelve las tres variables a cero. Esta precisión importa: el curso ofrece práctica autocorregida y feedback inmediato, no cuentas, certificados ni sincronización entre dispositivos. Lo único persistente es la preferencia de tema claro u oscuro, almacenada en el navegador bajo la clave básicos-email-theme. Si no existe, se respeta la preferencia del sistema.

El laboratorio tampoco envía las cabeceras a un servidor: toma el texto del área, lo interpreta y genera el informe en la propia página. Esa arquitectura estática reduce fricción para estudiar y evita depender de una cuenta. Aun así, si se trabaja con correo real conviene eliminar o anonimizar datos personales antes de compartir capturas o resultados con terceros.

SPF, DKIM y DMARC: tres piezas, no tres sinónimos

SPF responde a una pregunta concreta: ¿está autorizada esta IP para enviar usando el dominio declarado en MAIL FROM o HELO? El dominio pública una política en DNS y el receptor la evalúa. Esto ayuda a controlar la infraestructura legítima, pero deja intacta la posibilidad de que el From visible muestre otro dominio. Por eso un analista no debería leer spf=pass como «el remitente visible es auténtico».

DKIM aplica una firma criptográfica a cabeceras elegidas y al cuerpo. El mensaje incluye un selector y un dominio firmante; el receptor recupera la clave pública de DNS y verifica que las partes firmadas no cambiaron. Es útil para asociar el correo con un dominio y mantener integridad durante el trayecto, pero un atacante también puede firmar correctamente desde un dominio que controla. La firma no evalúa enlaces, intención ni reputación.

DMARC une la autenticación técnica con la identidad que ve el usuario. Toma el dominio del Header From como referencia y requiere que SPF o DKIM pasen con alineación. Además, permite al dominio expresar una política de manejo. Esta capa dificulta la suplantación directa del dominio protegido, siempre que los registros y las fuentes legítimas estén bien configurados.

Para un agente de IA que envía email, la secuencia operacional es clara. La herramienta puede conectarse a un proveedor autorizado y enviar mediante submission, pero el equipo propietario debe publicar SPF para ese proveedor, habilitar una firma DKIM con el dominio adecuado y configurar DMARC de forma coherente con el From que el agente utiliza. Si el agente cambia de plataforma, subdominio o dirección técnica, hay que revisar la alineación. La calidad del modelo no corrige una política DNS equivocada.

Por qué importa para profesionales que construyen con IA

Los agentes de IA ya redactan resúmenes, contactan clientes, notifican incidencias y envían resultados de procesos. Cada nueva automatización amplía la superficie operativa: aumenta el volumen, añade proveedores y puede crear mensajes convincentes a gran velocidad. Sin controles de dominio, esos envíos pueden acabar en spam, fallar políticas o hacer más difícil distinguir una automatización legítima de una suplantación.

El modelo mental del curso permite formular mejores preguntas antes de desplegar. ¿Qué MSA acepta el correo? ¿Qué dominio aparece en MAIL FROM? ¿Quién firma DKIM? ¿El d= de la firma se alinea con el From visible? ¿Qué incluyen Authentication-Results y las trazas Received? ¿Dónde se observan rebotes? Estas preguntas conectan desarrollo, operaciones, seguridad y marketing sin reducir el problema a «funciona en mi bandeja».

También mejora la respuesta a incidentes. Si un usuario reporta un mensaje generado por una supuesta automatización, el equipo puede comparar From, Reply-To, Return-Path, Message-ID, resultados de autenticación y ruta. El curso no convierte esa lectura en una certeza automática, pero enseña qué evidencia solicitar y cómo evitar conclusiones precipitadas.

Finalmente, ayuda a diseñar interfaces responsables. Una aplicación que incorpora un agente no debería ocultar la dirección real bajo un nombre demasiado persuasivo ni pedir credenciales por enlaces inesperados. Separar identidad visible, identidad técnica y contexto reduce el riesgo de reproducir patrones que los usuarios han aprendido a asociar con phishing.

Cómo usar el curso: plan de estudio en cinco sesiones

Sesión 1: construir el vocabulario

Reserva 30 minutos para el mapa. Recorre todos los nodos y escribe una frase propia para MUA, MSA, MTA, MDA y buzón. Después dibuja el trayecto sin mirar. El objetivo es poder señalar quién crea el mensaje, quién lo acepta, quién lo transfiere y quién lo almacena, no memorizar siglas.

Sesión 2: separar mensaje y sobre

Avanza por los siete pasos del viaje. En cada uno, anota actor, protocolo o artefacto y dato producido. Detente especialmente en From frente a MAIL FROM y en To frente a RCPT TO. Usa la anatomía para revisar Date, Message-ID, cuerpo, sobre, Received y Authentication-Results. Termina explicando en voz alta por qué SPF puede pasar sin validar el From visible.

Sesión 3: autenticar un dominio

Estudia los nodos DNS y autenticación, junto con la guía. Crea una tabla con cuatro columnas: mecanismo, identidad evaluada, prueba ofrecida y límite. Incluye SPF, DKIM, DMARC y TLS. Si administras un dominio, compara conceptualmente esa tabla con tu proveedor, sin hacer cambios improvisados en producción.

Sesión 4: investigar cabeceras

Abre el curso Básicos Email, carga el ejemplo y sigue Received de abajo arriba. Localiza los tres dominios relevantes: From, Return-Path y firma DKIM. Luego modifica una copia de la muestra: cambia Reply-To, elimina Authentication-Results o sustituye pass por fail, y observa cómo varían los hallazgos. Recuerda que el analizador es educativo y orientativo.

Sesión 5: practicar phishing y evaluar

Crea dos escenarios ficticios con la lista de señales: uno con urgencia y un dominio parecido; otro con fallo de autenticación, adjunto inesperado y ruta incoherente. Compara sus puntuaciones y justifica qué verificarías por otro canal. Completa el quiz de ocho preguntas. Si no alcanzas el 80 %, vuelve a las secciones relacionadas con cada error y repite, en lugar de memorizar la opción correcta.

Como cierre, revisa las referencias oficiales desde el buscador del curso. Empieza por RFC 5321 y 5322 para distinguir transporte y formato; sigue con SPF, DKIM, DMARC y Authentication-Results. No necesitas leer cada RFC completo en una sesión: usa el curso como mapa para saber dónde profundizar cuando una configuración o incidente lo requiera.

Preguntas frecuentes

¿Necesito conocimientos de redes para empezar?

No. La secuencia comienza con clientes, servidores y el viaje de un mensaje, y después introduce autenticación y análisis. Quien ya tenga experiencia puede ir directamente al laboratorio, la guía y las referencias.

¿El laboratorio sube mis cabeceras a un servidor?

No. Según la implementación, el texto se analiza localmente con JavaScript en el navegador. El proyecto no usa backend ni API externa. Aun así, conviene tratar las cabeceras reales como datos potencialmente sensibles.

¿El curso comprueba mis registros DNS reales?

No. Explica el papel de MX, SPF, DKIM y DMARC y analiza valores presentes en cabeceras pegadas. No incluye una consulta o auditoría automática del DNS de un dominio introducido por el usuario.

¿Guarda mi progreso o la puntuación?

No guarda progreso educativo. La puntuación del quiz permanece en memoria durante la sesión y se reinicia al repetir o recargar. Solo la preferencia de tema claro u oscuro se persiste en localStorage.

¿Un resultado DMARC pass garantiza que el correo sea seguro?

No. DMARC valida autenticación y alineación respecto del From visible. No juzga la intención del remitente, ni inspecciona por sí solo enlaces, adjuntos o dominios visualmente parecidos.

¿Qué necesita un agente de IA para enviar correo correctamente?

Además de acceso autorizado al servidor de submission, necesita una arquitectura de envío cuyo SPF incluya las fuentes legítimas, cuya firma DKIM sea verificable y cuyo dominio se alinee con el From para DMARC. Es una responsabilidad de configuración del sistema, no del texto generado.

¿Funciona completamente sin conexión?

La página es estática, pero el mapa intenta cargar Cytoscape.js desde una CDN. Si no está disponible, aparece un mapa alternativo con botones. El README explica que, para funcionamiento totalmente offline con la biblioteca, se puede descargar el archivo y cambiar la etiqueta script.