¿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
op=reject
. Conp=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?
- Política DMARC = none
Grandes proveedores como Hotmail, Yahoo o AOL mantienenp=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. - 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”. - 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
- 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
). - Implementa DKIM con clave rotada
Usa selector diferenciado (selector1._domainkey
) y rota la clave cada 6‑12 meses para mitigar filtraciones. - Activa DMARC en modo monitorizado
Empieza conp=none; rua=mailto:dmarc@tudominio.com
y analiza los informes XML. Ajusta servicios externos hasta lograr >98 % de pases. - Escala a
quarantine
y luegoreject
Sube gradualmente (pct=25
,pct=50
…) hasta cubrir el 100 %. Así bloquearás intentos en vivo. - 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ásspf=fail
odmarc=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
oquarantine
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.