Por qué existe Spoofhound
El correo se construyó sobre la confianza.
Internet no.
El protocolo que transporta tus facturas, contratos y restablecimientos de contraseña se diseñó en 1982 sin ningún control de seguridad — porque ninguno parecía necesario. Todo lo que ha venido después ha sido un parche. Esta página explica los problemas que esa historia te ha dejado y exactamente cómo los resuelve Spoofhound.
Breve historia de un protocolo sin seguridad
Nadie previó en qué se convertiría el correo.
Spoofhound ayuda a proteger tus correos.
SMTP se escribió para una pequeña red de instituciones que se conocían entre sí. Ninguno de sus diseñadores previó miles de millones de mensajes al día entre desconocidos — ni el spam, la suplantación y el phishing convertidos en industrias multimillonarias. Cada salvaguarda que tiene hoy el correo se añadió décadas después, y cada una existe para tapar un agujero concreto de aquel modelo de confianza original.
-
1978
El primer spam
Un comercial envía a unos 400 usuarios de ARPANET un anuncio de producto no solicitado. La reacción es furiosa — y no cambia nada. No hay ningún mecanismo para frenar al siguiente.
-
1982
Se estandariza SMTP (RFC 821)
El protocolo que aún transporta el correo del mundo se escribe para una red de unos pocos cientos de hosts de confianza, en su mayoría académicos. Cualquier servidor puede reclamar cualquier dirección de remitente; la línea From es solo texto. Sin autenticación, sin cifrado, sin verificación — nada de ello se consideró necesario entre colegas que se conocían.
-
1990s
El correo desborda sus supuestos
Internet se abre al público y el correo se convierte en su primera aplicación estrella. El modelo de confianza creado para cientos de hosts transporta ahora correo entre completos desconocidos, y el spam se industrializa casi de inmediato — a principios de los 2000 ya es la mayoría de todo el correo enviado.
-
1996
El «phishing» recibe su nombre
Los atacantes descubren el corolario de una línea From no autenticada: correo que dice venir de tu banco, tu proveedor, tu jefe. El término se acuña entre los ladrones de cuentas de AOL; la técnica ya no desaparece.
-
2002
STARTTLS (RFC 3207): cifrado, de forma oportunista
El correo entre servidores ya puede cifrarse — pero solo si ambas partes lo ofrecen, y la entrega prosigue igual si la negociación falla. Un atacante en la ruta puede simplemente retirar la oferta y leer el correo. A nadie se le avisa cuando eso ocurre.
-
2003–2007
SPF y DKIM añaden autenticación
SPF publica qué servidores pueden enviar por un dominio; DKIM añade una firma criptográfica. Ambos son un progreso real — y ambos verifican identificadores técnicos ocultos en lugar de la dirección From que una persona realmente lee. Un mensaje puede superar cualquiera de los dos mostrando el dominio de otra persona.
-
2012–2015
DMARC lo vincula a la línea From
DMARC exige que SPF o DKIM se alineen con el dominio From visible, permite al propietario publicar una política (monitorizar, poner en cuarentena o rechazar) y — lo crucial — obliga a los receptores a informar de quién envía en nombre del dominio. Por primera vez, un propietario de dominio puede ver el abuso y cortarlo.
-
2018
MTA-STS y TLS-RPT (RFC 8461/8460) cierran la brecha de cifrado
MTA-STS permite a un dominio exigir TLS verificado para el correo entrante en lugar de solo confiar en ello; TLS-RPT es su ciclo de retroalimentación — informes diarios de los remitentes sobre cada conexión fallida o degradada que, de otro modo, fallaría en silencio.
-
2019–2021
BIMI: una recompensa visible por terminar el trabajo
Brand Indicators for Message Identification coloca el logotipo verificado de un dominio junto a su correo en Gmail, Yahoo, Apple Mail y otros — pero solo para los dominios que han llevado DMARC hasta la aplicación, con un logotipo SVG validado y, en la mayoría de los proveedores, un Verified Mark Certificate que prueba que la marca es su dueña. Por primera vez, hacer bien la seguridad del correo se ve en un sitio que todos pueden ver.
-
2026
DMARCbis (RFC 9989) se convierte en el estándar
DMARC asciende a Estándar de Internet pleno, con orientaciones más precisas: un camino mesurado y por fases hacia la aplicación, y una política elegida según cómo se use realmente un dominio.
Por qué DMARC
La línea From que ve tu lector es la que importa.
SPF y DKIM autentican cosas reales — el servidor emisor, la firma del mensaje — pero ninguno de los dos tiene que coincidir con la dirección From que una persona realmente lee. Un phisher puede superar ambos en un dominio propio mientras muestra el tuyo. DMARC cierra esa brecha: exige que lo que superó la comprobación se alinee con el dominio From visible, y te permite decir a cada receptor del planeta qué hacer cuando no es así — entregarlo, mandarlo a la basura o rechazarlo de plano.
Igual de importante, DMARC informa. Cada gran receptor envía al propietario del dominio un parte diario de lo que decía ser él: qué fuentes, qué volúmenes, qué superó la comprobación, qué falló. Esos informes son la visibilidad sobre la que se construye todo lo demás — no puedes aplicar con seguridad una política contra remitentes que no has identificado, por lo que la RFC 9989 prescribe un camino mesurado y por fases: primero monitorizar, entender cada fuente y luego apretar.
Por qué TLS-RPT
El cifrado que no puedes verificar es cifrado que no tienes.
El correo entre servidores solo se cifra de forma oportunista: si el handshake TLS falla, o un atacante en la ruta retira sigilosamente la oferta, el mensaje se envía igual — en claro. El remitente no lo sabe. Tú no lo sabes. MTA-STS resuelve la mitad de la política, permitiendo que tu dominio exija TLS verificado en lugar de confiar en ello.
TLS-RPT es la mitad que nadie recuerda: el ciclo de retroalimentación. Los remitentes te informan, cada día, de cada conexión a tu dominio que falló o degradó su cifrado — lo que es a la vez tu alerta temprana de un ataque activo y tu única forma de saber que una política MTA-STS funciona en lugar de rechazar en silencio correo legítimo. Sin los informes, aplicas a ciegas.
Por qué BIMI
Tu logotipo, solo donde se demuestra que tu correo es real.
BIMI es la recompensa de todo lo anterior: una vez aplicado DMARC, los proveedores de buzones participantes — Gmail, Yahoo, Apple Mail, Fastmail — muestran tu logotipo verificado junto a tus mensajes. Son impresiones de marca diarias en el único lugar que tus clientes miran de forma fiable, y una señal visual que un phisher no puede reproducir, porque el logotipo solo aparece en el correo que superó la autenticación para tu dominio en aplicación.
Llegar ahí tiene aristas: el logotipo debe ser un archivo SVG Tiny P/S válido, la mayoría de los proveedores exigen un Verified Mark Certificate que pruebe que la marca es su dueña, y todo — registro, logotipo, caducidad del certificado — tiene que mantenerse correcto o el logotipo desaparece en silencio. Spoofhound supervisa los tres por dominio, y puede alojar por ti el logotipo validado y el certificado, para que BIMI siga siendo una recompensa y no otra cosa que vigilar.
Los problemas que resuelve Spoofhound
Cinco problemas que tiene cada propietario de dominio.
Lo sepan o no.
Los delincuentes envían correo en nombre de tu dominio
El problema: El fraude de facturas, el desvío de nóminas y el phishing dirigido a tus clientes y personal usan habitualmente tu dominio exacto en la línea From — porque hasta que DMARC no se aplica, los receptores lo entregan. El fraude del CEO (BEC) encabeza sistemáticamente las pérdidas de ciberdelincuencia notificadas al FBI, año tras año.
Cómo lo resuelve Spoofhound: Spoofhound establece una línea base de cada fuente de envío legítima en tus informes DMARC, de modo que una fuente totalmente nueva que falla la alineación — la firma clásica de la suplantación — dispara una alerta el mismo día, con una línea de runbook que te dice qué significa y qué hacer. Qué detiene y qué no detiene DMARC →
Tu correo legítimo acaba en spam — o en ninguna parte
El problema: Google, Yahoo y Microsoft ahora exigen autenticación (incluido DMARC para remitentes masivos) como condición de entrega. Una plataforma de marketing olvidada o un registro SPF mal configurado te cuesta en silencio la colocación en la bandeja de entrada, y nadie te dice qué mensaje falló ni por qué.
Cómo lo resuelve Spoofhound: Cada identidad de envío vista en tus informes se inventaría y clasifica — legítima, reenviadora, mal configurada o maliciosa — para que puedas corregir las mal configuradas y conseguir que cada remitente real supere la comprobación y quede alineado antes de apretar la política.
La evidencia existe, pero nadie puede leerla
El problema: Los informes DMARC y TLS llegan como adjuntos XML y JSON comprimidos, por receptor y por día, a un buzón. La visibilidad que necesitas ya se te está enviando técnicamente — en un formato que ningún ser humano leerá jamás.
Cómo lo resuelve Spoofhound: Spoofhound los ingiere y los lee todos, cada día, y se abre en una cola de triaje de cosas que realmente necesitan una decisión — no un muro de gráficos. Un resumen de los lunes recapitula la semana en frases.
Aplicar la política parece demasiado arriesgado para terminarlo
El problema: Pasar a cuarentena o rechazo es donde está la protección — pero un paso en falso tira a la basura tus propias facturas o nóminas. Así que la mayoría de los dominios se quedan atascados en p=none para siempre, monitorizados pero desprotegidos.
Cómo lo resuelve Spoofhound: El asistente de aplicación codifica el camino seguro: un umbral del 98 % de aprobación alineada sobre una ventana móvil más una comprobación de «todas las fuentes explicadas», con una recomendación por etapas en cada paso — la progresión mesurada que la propia RFC 9989 prescribe.
El cifrado del correo falla en silencio
El problema: STARTTLS es oportunista: si la negociación TLS falla — o un atacante la retira — el correo se entrega igual, en claro, y no se avisa a nadie. Sin MTA-STS y TLS-RPT no puedes saber que está ocurriendo.
Cómo lo resuelve Spoofhound: Spoofhound califica cada dominio de A a F en seguridad de transporte a partir de sus informes TLS, aloja tu archivo de política MTA-STS (certificado emitido y renovado por ti) y alerta sobre patrones de fallo con niveles de gravedad.
Míralo en tu propio dominio
La comprobación de dominio gratuita puntúa tu configuración de SPF, DKIM, DMARC, MTA-STS, TLS-RPT y BIMI en segundos — sin registro, sin agente, sin instalar nada.
Cómo está construido Spoofhound
Cloud-first, desde los cimientos.
La mayoría de las herramientas de monitorización son aplicaciones tradicionales que resulta que se ejecutan en un centro de datos — máquinas virtuales y contenedores que hay que dimensionar, parchear y pagar tanto si alguien los usa como si no. Spoofhound no. Se construyó para la nube desde los cimientos: sin máquinas virtuales, sin contenedores, sin racks de servidores. Se ejecuta como código serverless en una red edge global, cerca de dondequiera que lleguen tus informes.
Esa elección se nota en tres sitios que realmente percibes. Escala con la demanda — un día que trae diez veces el volumen habitual de informes se gestiona igual que cualquier otro, sin capacidad que aprovisionar. Está separado por diseño — cada jurisdicción es su propio despliegue autónomo con su propia base de datos y región, lo que permite que tus datos permanezcan en el país que elijas en lugar de en un único sistema compartido con una columna de país. Y como cuesta casi nada en reposo, es la razón por la que nuestros precios son como son: un precio por dominio bajo con todas las funciones incluidas, en lugar de niveles de funciones creados para recuperar el coste de servidores en marcha sin uso.