¿Te ha sorprendido ver un correo con tu propio nombre en el campo “De”? Tranquilo: la inmensa mayoría de estos mensajes no significan que tu cuenta haya sido hackeada; solo que alguien ha falsificado (spoofing) la cabecera From. En esta guía aprenderás por qué pasa, cómo funcionan SPF, DKIM y DMARC y qué medidas concretas tomar para bloquear futuros intentos.

¿Por qué recibes un correo que parece venir de tu propia dirección?

Problema planteado

Un usuario de @hotmail.com encuentra un correo de extorsión con asunto alarmista (“Has sido hackeado / Pegasus”) cuyo remitente coincide exactamente con su propia cuenta. El primer instinto es pensar que el atacante entró en el buzón, pero la explicación suele ser mucho más simple: el campo From es extremadamente fácil de falsificar.

La raíz del problema: SMTP sin autenticación nativa

El protocolo SMTP, diseñado en 1982, no exige autenticación en la capa más baja. Cualquier servidor —o programa que actúe como tal— puede fabricar un sobre de correo con la dirección que desee. Los mecanismos de seguridad actuales (SPF, DKIM y DMARC) se añaden “por encima” y requieren implantación voluntaria tanto por el dominio emisor como por el receptor. Mientras el dominio no exija un rechazo estricto, el spoofing sigue siendo técnicamente posible.

¿Cómo se falsifica la cabecera From?

Para ilustrarlo, basta configurar un servidor propio (Postfix, Exim, Sendmail…) o abusar de un relé abierto con un simple comando telnet smtp.ejemplo.com 25 y enviar los verbos SMTP:

HELO atacante.com
MAIL FROM:<cualquier@dominio>
RCPT TO:<victima@hotmail.com>
DATA
From: victima@hotmail.com
To: victima@hotmail.com
Subject: Has sido hackeado
...
.

El servidor receptor no “confirma” que From: coincida con MAIL FROM: y, salvo validaciones posteriores, entregará el mensaje. Así de fácil.

Mecanismos de autenticación modernos

Mecanismo	Qué verifica	Cómo lo hace	Resultado típico
SPF	Autoriza la IP emisora para el dominio indicado en MAIL FROM	El receptor consulta el registro TXT v=spf1 en DNS y contrasta la IP	Pass / Fail
DKIM	Prueba que el mensaje fue firmado y no se alteró en tránsito	El emisor añade una firma; el receptor verifica con la clave pública DNS	Pass / Fail
DMARC	Comprueba la alineación entre el dominio From: y los dominios autenticados por SPF y/o DKIM	El dominio publica v=DMARC1; p=...; el receptor actúa según la política	Pass / Fail + acción (none, quarantine, reject)

Detalles que marcan la diferencia

• SPF solo valida la dirección usada a nivel de sobre (Return‑Path), no el From visible. Por eso el atacante pone MAIL FROM: basura@servidorfraude.com y deja el From: con tu correo.
• DKIM agrega integridad. Si el atacante no posee la clave privada, no puede firmar en nombre de tu dominio. Sin embargo, si tu dominio no firma nada o la firma no alinea con From:, DMARC no tendrá prueba concluyente.
• DMARC toma la decisión final, pero solo si tu dominio publica p=quarantine o p=reject. Con p=none el receptor “observa” y suele mandar el correo a la carpeta Spam en lugar de bloquearlo.

¿Por qué el correo llega si SPF y DMARC fallan?

1. Política DMARC = none
   Grandes proveedores como Hotmail, Yahoo o AOL mantienen p=none porque su base de remitentes legítimos es tan diversa que el riesgo de falsos positivos es alto. Esto deja la decisión a filtros heurísticos de spam.
2. Tolerancia del servidor receptor
   Para evitar perder mensajes críticos (ej. facturas, recuperaciones de contraseña) muchos MX prefieren marcarlo como sospechoso en lugar de devolver un “550 Rejected”.
3. Falta de alineación estricta
   Un dominio puede pasar SPF si la IP emisora está autorizada, pero si ese dominio no coincide con From y no hay DKIM alineado, DMARC lo ve como “fail”. Sin política estricta, la entrega continúa.

Cómo frenar el spoofing: pasos para propietarios de dominio

1. Publica un registro SPF minimalista y correcto
   Evita el comodín +all; especifica solo las IP y servicios que realmente envían correo (v=spf1 include:spf.proveedor.com -all).
2. Implementa DKIM con clave rotada
   Usa selector diferenciado (selector1._domainkey) y rota la clave cada 6‑12 meses para mitigar filtraciones.
3. Activa DMARC en modo monitorizado
   Empieza con p=none; rua=mailto:dmarc@tudominio.com y analiza los informes XML. Ajusta servicios externos hasta lograr >98 % de pases.
4. Escala a quarantine y luego reject
   Sube gradualmente (pct=25, pct=50…) hasta cubrir el 100 %. Así bloquearás intentos en vivo.
5. Usa BIMI para refuerzo visual
   Una vez DMARC=reject, publica un registro BIMI con tu logo SVG para que clientes compatibles muestren un sello de autenticidad.

Estrategias para usuarios de servicios gratuitos (@hotmail, @gmail, etc.)

• Habilita la autenticación multifactor (MFA) para cerrar la puerta a accesos reales.
• Marca como phishing el mensaje: los motores de reputación aprenden y mejoran los filtros globales.
• Analiza las cabeceras: en Outlook Web, abre “Ver origen del mensaje” y busca Authentication‑Results:. Notarás spf=fail o dmarc=fail; señal inequívoca de suplantación.

Caso práctico: interpretación de cabeceras

Ejemplo real acortado (líneas clave):

Received-SPF: Fail (protection.outlook.com: domain of attacker.com ...)
Authentication-Results: spf=fail smtp.mailfrom=attacker.com;
 dkim=none (message not signed);
 dmarc=fail action=none header.from=victima@hotmail.com;

El header.from coincide con tu dirección, pero ninguno de los controles lo avala. Resultado: Outlook lo envía a Spam o muestra la alerta “Este correo podría no ser seguro”.

Preguntas frecuentes

¿El atacante tiene mis contraseñas? No. Falsificar From no requiere acceso al buzón. Aun así, cambia la contraseña y activa MFA por prudencia. ¿Puedo bloquear todos los correos que no pasen SPF o DKIM? A nivel de cliente no. Solo el servidor receptor (Outlook.com, Gmail, etc.) puede aplicar políticas globales. ¿Es legal enviar correos con dominios ajenos? En la mayoría de jurisdicciones el spoofing con fines de engaño viola leyes anti-fraude y anti-spam. ¿PGP o S/MIME solucionan el problema? Son excelentes para integridad y cifrado punto‑a‑punto, pero requieren que cada destinatario posea tu clave pública. DMARC funciona a nivel de dominio y es transparente para el usuario final.

Checklist rápida de mitigación

• ☑ SPF publicado y probado con dig txt tudominio.com
• ☑ DKIM firmado para cada host que envía correo
• ☑ DMARC en modo reject o quarantine al 100 %
• ☑ MFA activado en todas las cuentas
• ☑ Revisión mensual de informes DMARC
• ☑ Educación interna sobre apertura de adjuntos y enlaces

Conclusión

La suplantación del remitente es una herencia de los primeros días de Internet, cuando la confianza era la norma. Hoy disponemos de protocolos robustos —SPF, DKIM y DMARC— que, bien configurados, impiden que un atacante use tu dominio sin permiso y reducen en gran medida el phishing. Ya seas administrador de sistemas o usuario final, seguir las recomendaciones de este artículo te permitirá identificar los correos falsos y endurecer tu postura de seguridad. La próxima vez que veas un mensaje “de ti para ti” podrás descartar el susto… o detectar a tiempo un ataque más serio.