Resumen

  • Un pass de DMARC confirma el uso autorizado del Author Domain, no la veracidad, inocuidad ni conveniencia del mensaje.
  • p=reject expresa la preferencia del Domain Owner; RFC 9989 mantiene la disposición bajo la política local del Mail Receiver.

Una lista de distribución legítima puede romper la alineación y producir fail. Un emisor autorizado puede superar la alineación y enviar contenido abusivo. Estas dos situaciones bastan para mostrar por qué los resultados de identidad no son órdenes de entrega.

RFC 9989 se publicó en mayo de 2026 como Standards Track del IETF y sustituye a RFC 7489 y 9091. Su ficha, historial y erratas acreditan el documento, no una implantación.

SPF valida una fuente para una identidad de sobre; DKIM valida la firma de un dominio. DMARC exige además que al menos uno de esos identificadores autenticados se alinee con el Author Domain visible. Si existe, hay pass; si no, fail. El estándar añade de inmediato el límite: pass solo valida ese uso del dominio. No contiene una afirmación de valor sobre el mensaje ni sobre su dueño.

También limita el fail. Los recorridos indirectos descritos por RFC 7960 pueden alterar lo necesario para la autenticación o la alineación. Por eso un correo autorizado puede fallar, y un fallo no prueba autor humano, intención ni fraude.

El registro IANA DMARC documenta none, quarantine y reject. Son evaluaciones del Domain Owner sobre usos que no validan. Aportan conocimiento del emisor, pero no incluyen reputación local, contexto del destinatario ni coste de una decisión equivocada.

Las secciones 5.3.6 y 5.4 dejan el tratamiento bajo la política del receptor. Este puede aceptar un fail pese a p=reject, o rechazar un pass por otras pruebas. RFC 9989 aconseja no rechazar solamente por la política publicada, para evitar daños a listas y reenvíos legítimos. La excepción tampoco es gratuita: puede permitir abuso. La salida correcta es una razón atribuible.

Si falla DNS, no existe pass ni fail. La política del dominio no puede aplicarse y el receptor decide si difiere o trata el mensaje. Convertir «no se pudo saber» en «falló» borra una diferencia probatoria esencial.

La rendición de cuentas usa recibos distintos. RFC 9990 incorpora PolicyOverride en el informe agregado; RFC 8601 conserva Authentication-Results. RFC 9991 describe informes detallados opcionales. Observar, divulgar y disponer no son la misma función.

La especificación inicial mínima de Heng Lu permite coordinar mediante un vocabulario común sin apropiarse de la decisión local. Sus capas de realidad impiden convertir el símbolo reject en ejecución; la prioridad del código en funcionamiento obliga a comprobar qué hizo realmente el receptor.

Un registro honesto dice: estas pruebas produjeron esta alineación, el dominio pidió este tratamiento y el receptor actuó por estos motivos.