Resumen

  • RFC 9991 permite que el dueño de un dominio solicite datos detallados sobre fallos DMARC; el receptor del correo decide si genera el informe y qué permite revelar su política.
  • La autorización DNS de un destino externo acepta una relación de recepción, pero no aprueba automáticamente el cuerpo, los destinatarios, la retención o el uso posterior.
  • El control correcto separa el fallo de autenticación, la petición, la divulgación, la reducción de datos, la entrega, la validación del informe y cualquier decisión contra una cuenta.

Un dominio publica una URI ruf que delega el informe a un proveedor externo. A partir de ese momento, cada proveedor que reciba un mensaje con ese Author Domain puede descubrir la petición. Si el mensaje falla DMARC, un informe individual puede viajar al proveedor externo.

La comodidad del modelo es evidente: el dueño del dominio no necesita integrar bilateralmente a cada receptor antes de expresar su interés. Pero una expresión global de interés no puede convertirse en una orden global de transferir conversaciones. El receptor atiende a sus usuarios, almacena el mensaje y responde por la salida de datos. La asimetría obliga a conservar dos actos separados.

Del fallo a la divulgación hay una decisión local

RFC 9991 apareció en mayo de 2026 como documento Standards Track del IETF. Define informes de fallo capaces de describir un mensaje concreto o varios que fracasan por la misma causa. Pueden llegar casi de inmediato y mostrar mucho más que una estadística diaria.

RFC 9989 aporta las etiquetas ruf y fo: dónde desea el Domain Owner recibir información y bajo qué combinación de fallos. Son parámetros de una solicitud publicada.

RFC 9991 conserva la decisión en el Mail Receiver. El informe se genera cuando el dominio lo pide y el receptor está dispuesto a proporcionarlo. Además, el receptor determina qué tipos de informe transmite, si transmite alguno, de acuerdo con su política, el fallo y las opciones publicadas.

Esa cláusula evita un traslado silencioso de responsabilidad. El dominio conoce su infraestructura de envío y necesita ver abusos. El receptor conoce al destinatario, el contenido recibido, sus compromisos y el coste de la transferencia. El estándar conecta ambos conocimientos sin declarar que uno gobierna al otro.

Un informe individual no es un agregado con más columnas

RFC 9990 organiza observaciones agregadas por periodos y tuplas: dirección fuente, recuento, resultados de alineación, política y motivos de excepción. Puede revelar tendencias sin replicar cada comunicación.

El informe de RFC 9991 usa el Abuse Reporting Format. RFC 5965 exige una parte humana, otra legible por máquina y el mensaje original o el bloque completo de cabeceras. RFC 6591 añade los campos de fallo de autenticación que RFC 9991 actualiza para DMARC.

El cambio no es cuantitativo, sino cualitativo. Una fila agregada dice que diez mensajes llegaron desde una IP. Un ARF puede revelar quién escribió, quién recibió, qué asunto se trató, por dónde fue reenviado y qué contenido activó el fallo. Puede copiar información empresarial no pública, PII, una cita médica o una notificación laboral.

También puede revelar relaciones que el dueño del dominio desconocía. Un reenvío muestra el destino final; una lista de correo deja visible a un miembro. El dominio puede ser víctima de una suplantación y aun así recibir información sobre terceros inocentes.

RFC 9991 recomienda limitar alcance y duración, validar las URI, reducir o censurar los datos y usar transporte seguro. Señala que muchos proveedores grandes restringen o desactivan estos informes, prefiriendo agregados. La negativa no contradice la petición: aplica la discreción que el documento reconoce.

Un tercero debe aceptar el flujo, no apropiarse de todos sus campos

Cuando ruf apunta fuera del Organizational Domain, RFC 9991 reutiliza el procedimiento de verificación externa de RFC 9990. El receptor comprueba que el dominio externo publica la autorización esperada para recibir informes en nombre del dominio solicitante.

La comprobación evita dos abusos. Un propietario no puede imponer a un tercero una carga de correo sin su participación. Un atacante tampoco debería poder usar la política de un dominio para reflejar informes hacia una víctima.

El resultado positivo tiene alcance limitado. Dice que el destino acepta informes para esa relación. No determina si necesita el cuerpo completo, si sus operadores pueden ver direcciones personales, si reenvía el buzón, si conserva datos durante años o si usa el contenido para entrenar sistemas.

La organización necesita un perfil adicional: finalidad, campos autorizados, muestreo, límites, localización, personal con acceso, transferencia posterior, retención y borrado. El registro DNS debe comprobarse contra esa relación real. Nunca debe ser su única prueba.

RFC 9991 refuerza el límite al prohibir considerar un ruf de una política psd=y sin acuerdos específicos. La posición del Public Suffix Domain le da alcance técnico, no derecho automático a recibir mensajes detallados de todos los nombres subordinados.

La etiqueta Identity-Alignment no identifica a una persona

La actualización introduce Identity-Alignment. El registro vigente de IANA MARF Parameters lo define como la lista de mecanismos que no autenticaron un identificador alineado, o none si ninguno falló.

Es un resumen exacto del cálculo DMARC: falló DKIM, SPF o ambos en relación con el Author Domain. No demuestra quién creó el mensaje, si hubo fraude ni si un reenvío legítimo rompió la autenticación.

Un sistema de casos debe guardar el nombre completo del campo, los dominios, los resultados, el evaluador y la hora. Mostrar “identidad fallida” sin “alineación” convierte un dato de protocolo en una conclusión personal que el emisor del informe nunca hizo.

Reducir datos sin fingir anonimato

RFC 6590 ofrece una técnica de censura consistente: transformar valores privados para que dos entradas iguales sigan siendo correlacionables. Así, un consumidor puede detectar una serie contra el mismo destinatario sin ver inicialmente la dirección.

La utilidad crea un nuevo control. Un seudónimo estable es una llave de correlación. Si la transformación, la clave y la ventana no cambian, puede convertirse en una identidad permanente entre campañas y clientes.

Además, los restos importan. Message-ID, hora, asunto excepcional, cadena Received y registros externos pueden reconstruir el dato original. Ningún filtro reconocerá todas las formas en que el lenguaje humano expresa información privada. RFC 6590 advierte precisamente ese límite.

Por eso el informe de cumplimiento debe nombrar versión, campos, algoritmo, época de clave, ámbito, pruebas y riesgo residual. redacted=true no basta. Si no es posible producir un artefacto proporcional, un agregado o la supresión son resultados legítimos.

Recibir un informe no concede autoridad para castigar

RFC 5965 dice que los campos del ARF son afirmaciones y no siempre se pueden verificar. El formato no autentica por sí solo el contenido. Un informe puede estar equivocado, manipulado o incompleto. Incluso un origen auténtico puede adjuntar malware o interpretar mal el mensaje.

El consumidor debe verificar la relación, el origen, la estructura, los límites de tamaño y la coherencia; aislar contenido hostil; y compararlo con sus registros de envío, claves y cuentas. RFC 6449 concibe los feedback loops como acuerdos operativos con responsabilidades, no como un canal automático de sentencia.

RFC 9991 exige rate limiting porque el propio reporting puede ser un vector. Un atacante puede enviar miles de mensajes que aparentan pertenecer a una víctima, hacer fallar SPF y DKIM y provocar informes hacia el dominio o su delegado. Los límites deben cubrir tanto el dominio como el destino y el servicio total; los fallos semejantes pueden consolidarse mediante Incidents.

Los informes pueden transportar enlaces de phishing y adjuntos maliciosos. RFC 9991 propone neutralizar los enlaces y retirar adjuntos; el consumidor debe aislar el flujo, usar sandbox, segmentar la red y restringir el acceso. El correo de informes debería pasar DMARC para no producir una cadena recursiva de fallos.

Siete realidades, no una automatización

La lectura de Heng Lu sobre capas de realidad evita la compresión: fallo, petición, decisión de revelar, bytes, entrega, interpretación y efecto son evidencias distintas.

La especificación inicial mínima y la decisión futura localizada sitúan en el estándar lo imprescindible para interoperar —etiquetas, formato, verificación, fallo seguro— y dejan finalidad y divulgación al operador responsable.

La primacía del código en ejecución obliga a mirar qué evaluador corrió, qué regla autorizó el informe, qué transformación se aplicó, qué respuesta DNS se vio, qué hash salió y qué decisión tomó el consumidor.

RFC 9991 no transforma a un Domain Owner en autoridad sobre el buzón receptor. Le da un lenguaje para pedir evidencia. La gobernanza comienza al responder con precisión quién puede revelar qué.