Resumen

  • DMARC da pass cuando al menos un dominio autenticado por SPF o DKIM se alinea con el dominio de RFC5322.From. La prueba alcanza al uso autorizado del dominio autor, no a la parte local, el nombre visible, la persona ni el contenido.
  • Un fail tampoco demuestra por sí solo suplantación. Reenvíos, listas y mediadores legítimos pueden romper SPF o invalidar DKIM durante el trayecto.
  • p, sp y np son preferencias solicitadas. El receptor conserva la decisión local, puede aceptar un fallo o rechazar un aprobado, y debe combinar DMARC con reputación, análisis de contenido y contexto operativo.

El error de leer una cabecera como una sentencia

Las interfaces presentan resultados de autenticación junto al mensaje completo. Esa proximidad visual invita a una inferencia falsa: si el resultado dice pass, el mensaje ha pasado una prueba general. RFC 9989 define una prueba mucho más estrecha.

Publicado en mayo de 2026 como estándar de Internet, el documento sustituye a RFC 7489 y RFC 9091. Todd M. Herr y John Levine figuran como coeditores. En su introducción no promete identificar a un autor humano ni declarar inocuo un correo. Afirma que un pass valida como autorizado por el propietario el uso del dominio autor de RFC5322.From. No lleva ninguna valoración explícita o implícita sobre el mensaje o sobre ese propietario y no garantiza que la bandeja de entrada sea un destino seguro o deseable.

La precisión cambia la pregunta del operador. Ya no es «¿ha sido autenticado el mensaje?», sino «¿qué identificador autenticó este receptor y qué relación tenía con el dominio que se mostró como autor?».

Tres dominios pueden ocupar una sola pieza de correo

SPF observa la transacción SMTP. Comprueba si el host cliente está autorizado a usar el dominio del MAIL FROM —el identificador que DMARC toma de SPF—. DKIM observa una firma y valida el dominio d= que asumió responsabilidad por los campos y el cuerpo cubiertos. El dominio visible en RFC5322.From puede coincidir con uno de ellos o ser distinto.

DMARC convierte esa diferencia en una comparación explícita. Extrae el dominio autor del From. En alineamiento estricto exige identidad de dominios; en alineamiento relajado exige que compartan el mismo dominio organizativo. El propietario expresa el modo en aspf y adkim. Basta con un identificador autenticado y alineado: una firma DKIM válida puede decidir el pass aunque otra falle, y un SPF válido no sirve para DMARC si autentica un dominio que no se alinea.

Así aparece un recibo reproducible: mensaje recibido, identificador SPF o DKIM, modo de alineamiento y resultado. El recibo no contiene la biografía del remitente ni un análisis de sus intenciones.

Lo que queda fuera no es un detalle de implementación

La parte local de una dirección no se valida. Que el From combine la parte local tesoreria con el dominio example.com no prueba que exista esa cuenta, que esté bajo el control esperado o que una persona de Tesorería escribiera el mensaje. El nombre visible puede mencionar a un directivo real mientras la dirección apunta a otro dominio. Un atacante puede usar un dominio visualmente parecido. RFC 9989 excluye expresamente los ataques al nombre visible y los dominios similares.

También excluye el análisis de contenido y la autenticación de entidades que no sean dominios. Por eso un mensaje con enlace malicioso puede pasar; también una solicitud falsa enviada desde una cuenta comprometida o desde un dominio que el propio atacante administra correctamente. El éxito de DMARC en esos casos no es una vulnerabilidad del cálculo. Es una señal de que otro control debe juzgar otra cosa.

Confundir esas capas perjudica incluso a la investigación. Si se etiqueta un incidente como «fallo de DMARC» pese a que el dominio estaba correctamente autorizado, se pierde la causa real: apropiación de cuenta, abuso de servicio, reputación tardía o análisis de contenido insuficiente.

El correo legítimo que llega sin su prueba original

RFC 7960 documenta el problema del flujo indirecto. El correo puede salir correctamente autenticado y cambiar de condiciones antes del receptor final. Un reenviador que conserva MAIL FROM transmite desde una IP que quizá no aparece en el SPF original. Si sustituye MAIL FROM por su propio dominio, puede aprobar SPF pero dejar de estar alineado con el From original. Una lista que añade asunto, pie o cambios MIME puede invalidar la firma DKIM.

El resultado final dice qué evidencia sobrevivió. No reconstruye automáticamente lo que era válido antes de la transformación. RFC 9989 escogió con cuidado la expresión «no necesariamente asociado» para un fallo y permite que el receptor use conocimiento sobre listas y reenviadores.

Por eso fail no debe convertirse en «fraude» del mismo modo que pass no debe convertirse en «seguro». Uno carece de un vínculo alineado observado; el otro posee ese vínculo. Ninguno resuelve por sí solo el origen humano, la integridad de toda la ruta o el valor del contenido.

p=reject no contiene acceso de administrador

La búsqueda de política comienza en el dominio autor. Si allí no aparece un registro válido, continúa por el dominio organizativo y el sufijo público. El lugar y la existencia del subdominio determinan si corresponde p, sp o np. El registro de IANA los denomina políticas solicitadas para el dominio, los subdominios existentes o los no existentes.

Solicitar no es ejecutar. RFC 9989 deja el tratamiento final a la política local del receptor. Este puede poner en cuarentena un mensaje con pass cuando reputación o contenido lo aconsejan. También puede aceptar un fail aunque el dominio publique reject. El documento recomienda no rechazar únicamente por ese valor cuando otras observaciones pueden evitar pérdida de correo legítimo o daño a listas.

Si una consulta DNS necesaria falla, DMARC no produce ni aprobado ni fallo y no puede aplicarse la preferencia como si se hubiese leído. El receptor puede entregar, devolver temporalmente o tomar otra medida. En todos los casos debe quedar claro quién publicó la señal y quién tomó la decisión con efectos.

The Policy Mirror de Heng Lu propone reducir las reglas compartidas al invariante técnico que otra parte necesita verificar y mantener locales las decisiones de mayor alcance. Sin convertir ese ensayo en fuente normativa del RFC, la comparación aclara su arquitectura: el dominio publica una posición legible; no adquiere soberanía sobre la cola ajena.

La telemetría pedida no equivale a la telemetría recibida

DMARC permite solicitar informes agregados mediante rua e informes específicos de fallo mediante ruf. Los primeros ayudan a descubrir uso fraudulento y también errores propios de autenticación. Sin embargo, el receptor no está obligado a entregar todos los informes pedidos. RFC 9989 recomienda los agregados; deja los individuales como opcionales y reconoce los límites de privacidad.

La cadena debe distinguir el registro DNS, el informe enviado, el informe recibido, su periodo, el volumen cubierto y la acción posterior. Sin esa separación, una organización puede creer que ve todo su flujo cuando solo observa a algunos receptores, o endurecer una política basándose en una ausencia que en realidad es falta de cobertura.

El paso hacia cuarentena o rechazo merece pruebas con reenviadores, listas, proveedores y subdominios, además de un plan de reversión. La etiqueta t para modo de prueba y el historial de cambios son recibos de operación, no decoraciones.

Un perfil de Todd Herr, no una transferencia de autoridad

La ficha pública de IETF capturada el 1 de septiembre de 2026 vincula a Todd Herr con RFC 9989 y con el equipo de revisión ART. La foto oficial sirve para identificarlo. En el RFC aparece asociado a Valimail y comparte la edición con John Levine, de Standcore LLC. Los agradecimientos preservan las contribuciones del grupo DMARC y de quienes prepararon RFC 7489.

El mérito editorial está en hacer explícito un límite que las implementaciones suelen borrar. Pero Herr no es el inventor único, ni valida cada despliegue, ni controla los filtros receptores. Presentarlo como autoridad sobre esas acciones negaría la distribución de funciones que el documento describe.

Guardar la cadena y no solo el color

Una auditoría necesita el mensaje exacto y su From; todos los resultados SPF y DKIM con dominios, selectores y motivos; la comparación estricta o relajada; el registro DNS seleccionado y su baliza; los errores de consulta; las transformaciones indirectas conocidas; la puntuación de reputación y contenido; la decisión local; y el resultado para el usuario.

Cada línea tiene un dueño y un tiempo. El dominio autoriza. SPF o DKIM observa una base. DMARC alinea. El DNS solicita. El receptor decide. El usuario revela el resultado. Cuando esas líneas quedan separadas, DMARC reduce la suplantación exacta y fortalece la reputación de dominio sin fingir que puede leer personas, intenciones o adjuntos.

La seguridad no exige un veredicto universal. Exige que cada prueba conserve el tamaño de su objeto.

Fuentes