DMARCbis está llegando: cómo la próxima generación de autenticación de correo electrónico cambiará la seguridad, el cumplimiento normativo y la capacidad de entrega

¿Qué es DMARCbis y por qué es importante?

DMARCbis es la próxima generación de DMARC, una actualización reestructurada y mejorada del protocolo DMARC que se introdujo por primera vez en 2015. A diferencia del DMARC original (que se publicó como un RFC informativo), DMARCbis está en camino de convertirse en un estándar formal propuesto por la ETF en 2025. Esta elevación de estatus señala un amplio consenso en el sector e incorpora las lecciones aprendidas tras una década de implementaciones de DMARC. En la práctica, DMARCbis no supone un cambio radical con respecto a DMARC, pero aporta importantes mejoras en cuanto a claridad, seguridad y flexibilidad para que el protocolo sea más robusto y esté preparado para el futuro.

Mejoras clave en DMARCbis (frente al DMARC original)

DMARCbis se basa en años de experiencia real con DMARC. Algunas de las actualizaciones y mejoras más notables son:

• Descubrimiento refinado del dominio organizativo (DNS Tree Walk): La nueva especificación sustituye la dependencia de la Lista de Sufijos Públicos (PSL) por un algoritmo «DNS Tree Walk» para determinar el dominio organizativo de un dominio. Esto significa que, en lugar de utilizar una lista estática de sufijos públicos, los receptores de correo realizarán consultas DNS en la jerarquía de dominios para encontrar la política DMARC aplicable. Este método de recorrido del árbol hace que las comprobaciones de alineación sean más fiables en estructuras de dominio complejas (por ejemplo, subdominios de varios niveles o dominios delegados) y permite a los propietarios de dominios controlar qué dominio se trata como raíz organizativa en DMARC. Elimina las inconsistencias causadas por las diferentes versiones de PSL y mejora la interoperabilidad utilizando el propio DNS para descubrir los límites de la política.
• Nueva etiqueta «np» para políticas de subdominios: DMARCbis introduce una etiqueta np que permite a los propietarios de dominios especificar una política para subdominios inexistentes por separado de los subdominios existentes o del dominio principal. La política np se aplica cuando alguien intenta utilizar un subdominio que su organización no ha configurado (por ejemplo, una suplantación como does-not-exist.yourdomain.com). Esto proporciona flexibilidad para endurecer o relajar la aplicación en subdominios falsos sin afectar a los flujos de correo electrónico de los subdominios legítimos. Por ejemplo, una organización podría establecer np=reject para bloquear todos los correos electrónicos que pretendan provenir de cualquier subdominio no utilizado, reduciendo así el abuso, mientras utiliza una sp (política de subdominio) diferente para los subdominios delegados reales. Este control más preciso ayuda a evitar tanto la aplicación excesiva como la protección insuficiente en el manejo del tráfico de subdominios.
  
  
• Depreciación de la etiqueta «pct» (porcentaje): En el DMARC original, la etiqueta pct permitía a los propietarios de dominios aplicar su política solo parcialmente (por ejemplo, pct=50 para aplicar la política solo a la mitad de los mensajes fallidos). DMARCbis deja de utilizar la etiqueta pct, lo que refleja la expectativa de que los propietarios de dominios deben aplicar plenamente su política DMARC en lugar de aplicarla de forma gradual o parcial. En otras palabras, una vez que se pasa a una política de aplicación (cuarentena o rechazo), se debe implementar al 100 %. Este cambio fomenta una postura más decisiva en la autenticación del correo electrónico y simplifica el protocolo (los receptores de correo ya no tienen que gestionar el muestreo de la aplicación basado en porcentajes). Para las organizaciones, esto significa que, cuando se tenga confianza en la implementación de DMARC, normalmente se pasará directamente a la aplicación completa. (Cabe destacar que DMARCbis introduce una nueva bandera de prueba como alternativa, véase el siguiente punto, en lugar de utilizar porcentajes para una implementación lenta).
  
  
• Indicador de prueba «t»: Para facilitar una implementación y pruebas seguras, DMARCbis añade un indicador de prueba (t) que sustituye eficazmente al antiguo mecanismo pct para las implementaciones de prueba. Cuando se establece t=y (modo de prueba) en un registro DMARC, se indica a los receptores que el dominio está en fase de prueba y se solicita que la aplicación de la política se trate como un nivel inferior al especificado. Por ejemplo, si su registro DMARC dice p=reject pero t=y (modo de prueba), los receptores pueden interpretar esto como «tratarlo como cuarentena» (un paso por debajo de rechazar) en lugar de un rechazo total. Si p=cuarentena y t=y, trátelo como supervisión (ninguna). Esto ofrece a los propietarios de dominios una forma de probar una política de aplicación de forma segura, garantizando que los informes sigan llegando, sin afectar inmediatamente a la capacidad de entrega. La etiqueta t es consultiva (los receptores pueden elegir si la respetan), pero proporciona un mecanismo de prueba más claro que el pct. Por defecto (t=n), la política se aplica plenamente (equivalente a pct=100).
  
  
• Etiqueta de dominio de sufijo público (PSD): Se introduce otra nueva etiqueta, psd, para marcar explícitamente los registros publicados en dominios de sufijo público (como TLD o dominios controlados por registros) frente a los dominios organizativos normales. Un registro DMARC con psd=y indica a los receptores: «Este dominio es un sufijo público; no lo traten como un dominio de organización, sino como un límite». Por el contrario, psd=n indica: «Este dominio es definitivamente un dominio organizativo para sí mismo y sus subdominios». Esta etiqueta funciona junto con el algoritmo DNS Tree Walk para gestionar casos extremos en los que un registro (o una organización que actúa como registro) publica una política DMARC. Por ejemplo, un TLD de código de país o una asociación industrial podrían publicar un registro DMARC a nivel PSD para cubrir todos los dominios subordinados, algo para lo que el DMARC original tenía un soporte limitado. La etiqueta PSD permite que los entornos de dominios multinivel y los registros utilicen DMARC de forma más eficaz al controlar cómo el tree walk identifica el dominio de la organización.
  
  
• Especificación y orientación más claras: El documento DMARCbis se ha reestructurado para mayor claridad, con una terminología mejorada y más ejemplos para los implementadores. Se han abordado las ambigüedades de la especificación original para reducir la confusión. Por ejemplo, DMARCbis explica con detalle cómo funciona la herencia de políticas para los subdominios y cuándo detener el recorrido del árbol, para que todos los receptores lo implementen de forma coherente. Además, DMARCbis separa el protocolo central de los informes: los nuevos borradores dedicados a los informes agregados y los informes de fallos acompañan a la especificación principal, lo que garantiza que cada aspecto esté bien definido. Estratégicamente, el paso de DMARCbis a una vía estándar completa con una especificación más clara significa que a los proveedores de correo electrónico y a las organizaciones les resultará más fácil implementar y auditar DMARC, lo que aumentará su adopción e interoperabilidad. Es importante destacar que la etiqueta de versión de DMARC sigue siendo «v=DMARC1» para garantizar la compatibilidad con versiones anteriores, por lo que los registros DMARC existentes no se romperán. Sin embargo, con el tiempo, es de esperar que los proveedores de buzones de correo se adapten a la nueva especificación, y los propietarios de dominios deberían actualizar cualquier registro o práctica que la antigua especificación permitía pero que DMARCbis desaconseja (como el uso de pct). En general, DMARCbis ofrece más flexibilidad, precisión y orientación para que la autenticación del correo electrónico sea más sólida y eficaz.

DMARCbis frente a SPF y DKIM: ¿En qué se diferencian?

SPF, DKIM y DMARC son piezas complementarias del rompecabezas de la autenticación del correo electrónico, cada una con un propósito distinto:

• SPF (Sender Policy Framework): SPF permite al propietario de un dominio publicar un registro DNS que enumera los servidores de correo autorizados para enviar correo electrónico en nombre de su dominio. Cuando un servidor de correo electrónico entrante recibe un mensaje que dice provenir de @sudominio.com, puede verificar el registro SPF de sudominio.com para ver si la IP del servidor remitente está en la lista aprobada. SPF es eficaz para abordar la cuestión de «quién puede enviar» al verificar la IP del remitente con la política del dominio. Sin embargo, SPF tiene limitaciones: comprueba el dominio del remitente del sobre (MAIL FROM), que puede ser diferente del dominio del encabezado «De:» que ven los usuarios, y no vincula de forma inherente ese resultado al remitente visible. Además, si un correo electrónico se reenvía a través de un intermediario, SPF puede fallar (ya que la IP del reenviador puede no estar en la lista SPF del remitente original).
  
  
• DKIM (DomainKeys Identified Mail): DKIM aborda la integridad del contenido y la autorización del dominio haciendo que el servidor de correo remitente adjunte una firma digital a los encabezados de los correos electrónicos. La firma está vinculada a un dominio a través de una clave criptográfica publicada en el DNS. El servidor receptor recupera la clave pública del remitente del DNS y verifica la firma, asegurándose de que el mensaje no ha sido manipulado y confirmando que ha sido firmado por el dominio declarado. DKIM es potente porque la firma sobrevive al reenvío (el contenido y la firma permanecen intactos), pero DKIM por sí solo no garantiza que el dominio firmante sea el mismo que el dominio del remitente: un remitente podría firmar con las claves de un dominio mientras que el correo electrónico afirma provenir de otro dominio, lo que podría confundir a los destinatarios.
  
  
• DMARC: La función de DMARC es vincular los resultados de SPF y DKIM al dominio que le importa al destinatario (la dirección que aparece en el encabezado «De:») y especificar una política para gestionar los fallos. En términos más sencillos, DMARC se sitúa por encima de SPF y DKIM y pregunta: «¿El correo electrónico procede realmente del dominio que dice proceder?». Para ello, exige la alineación de identificadores: el dominio de la dirección De debe coincidir (o ser un subdominio) con el dominio que ha superado el SPF o el dominio que ha firmado la firma DKIM. Si ni el SPF ni el DKIM superan la alineación, DMARC considera que el correo electrónico no está autenticado. El propietario del dominio puede indicar a los destinatarios qué hacer con los mensajes que no superan la verificación (supervisarlos, ponerlos en cuarentena como sospechosos o rechazarlos directamente) a través de la política DMARC (p=none/quarantine/reject). Esto es algo que ni SPF ni DKIM proporcionan por sí solos, ya que no transmiten la política del remitente al destinatario. Además, DMARC proporciona información a los propietarios de dominios: informes agregados (resumen de los resultados de la autenticación) e informes forenses opcionales. Estos permiten a las organizaciones supervisar quién envía correos electrónicos que pretenden provenir de su dominio y detectar abusos o configuraciones incorrectas. En resumen, SPF comprueba el servidor, DKIM comprueba el contenido y DMARC comprueba la identidad y la política del dominio. Juntos, estos tres forman una defensa por capas contra la suplantación de identidad y el phishing.
  
  
• DMARCbis y el ecosistema: Es importante señalar que DMARCbis no sustituye a SPF ni a DKIM, sino que sigue dependiendo de ellos como mecanismos de autenticación subyacentes. La lógica central de «un correo electrónico pasa DMARC si pasa SPF o DKIM (o ambos) y el dominio se alinea» sigue siendo la misma en DMARCbis. Por lo tanto, desde un punto de vista técnico, DMARCbis es compatible con la forma en que se autentican los correos electrónicos; cualquier correo electrónico que haya pasado DMARC bajo la especificación anterior también pasará bajo DMARCbis (los criterios para la alineación SPF/DKIM no han cambiado fundamentalmente). Lo que mejora DMARCbis es la fiabilidad y la coherencia a la hora de determinar con qué dominio se debe comprobar la alineación. Por ejemplo, con el antiguo DMARC, diferentes receptores podían tener interpretaciones ligeramente diferentes de los dominios organizativos en casos exóticos (debido a variaciones en la PSL). DMARCbis estandariza esto mediante el recorrido del árbol y las etiquetas psd, lo que significa que los resultados de SPF y DKIM se evalúan con respecto al dominio organizativo correcto de forma más coherente en todos los ámbitos. Esta coherencia refuerza la eficacia de SPF/DKIM al garantizar que DMARC comprueba el dominio previsto.
  
  
• En la práctica, las organizaciones deben seguir implementando SPF y DKIM para todos sus dominios de envío, ya que son requisitos previos para que DMARC (incluido DMARCbis) funcione. DMARCbis facilitará la gestión y la aplicación de políticas en esos dominios, especialmente si se tienen estructuras de dominio complejas o se utilizan remitentes externos. Otro punto a tener en cuenta es el reenvío de correo electrónico: aunque DMARCbis mejora muchos aspectos de DMARC, no resuelve directamente el problema de los reenviadores legítimos que incumplen SPF o DKIM. Soluciones como ARC (Authenticated Received Chain) siguen siendo complementarias para preservar la autenticación a través del reenvío. No obstante, DMARCbis garantiza que, siempre que un mensaje pueda autenticarse a través de SPF o DKIM, se alineará y gestionará correctamente de acuerdo con la política del dominio, lo que proporciona a los propietarios de dominios y a los destinatarios una forma clara y unificada de aplicar la autenticidad del correo electrónico que SPF o DKIM por sí solos no podrían lograr.

Implicaciones de DMARCbis para las empresas (seguridad, cumplimiento y aplicación)

Desde una perspectiva empresarial, DMARCbis es más que una simple actualización técnica; tiene implicaciones estratégicas para la seguridad del correo electrónico, el cumplimiento, la interoperabilidad y la aplicación de políticas. Las organizaciones, desde las grandes empresas hasta las pequeñas, que dependen del correo electrónico para la comunicación o el marketing deben comprender estas implicaciones:

• Mayor seguridad y protección de la marca: Las mejoras de DMARCbis contribuyen directamente a reforzar las defensas contra la suplantación de identidad, el phishing y el compromiso del correo electrónico empresarial. Al perfeccionar la alineación de dominios y cerrar las lagunas (como los ataques a través de subdominios similares), DMARCbis ayuda a garantizar que solo los remitentes autorizados puedan utilizar su dominio. Esto protege a sus clientes, socios y empleados de los correos electrónicos de phishing que pretenden provenir de su empresa. Una implementación exitosa de DMARC (o DMARCbis) protege la reputación de su marca al evitar que los atacantes utilicen indebidamente su dominio en fraudes. Las actualizaciones de DMARCbis están diseñadas explícitamente para reforzar la protección contra la suplantación de identidad y el phishing, lo que a su vez aumenta la confianza de los clientes en los correos electrónicos que reciben de usted. Muchas iniciativas del sector también están vinculadas a la aplicación de DMARC; por ejemplo, para mostrar logotipos verificados con BIMI, debe tener una política DMARC totalmente aplicada. Adoptar DMARCbis significa que su organización se mantiene a la vanguardia de las mejores prácticas de seguridad del correo electrónico, lo que reduce el riesgo y demuestra a los clientes y socios que se toma en serio la seguridad del correo electrónico.
  
  
• Cumplimiento normativo y alineación regulatoria: La autenticación del correo electrónico forma parte cada vez más de los marcos normativos y de cumplimiento de la industria. En algunas regiones y sectores, se recomienda o incluso se exige a determinadas organizaciones que implementen DMARC (a menudo como política de aplicación) (por ejemplo, se ha exigido a las agencias federales de EE. UU. que implementen DMARC en p=reject)