Especificación · Entregabilidad

APRF: la nueva especificación del IETF que podría cambiar las reglas del juego del inbox placement

Comcast, Iterable y Google proponen un formato estandarizado mediante el cual los proveedores de correo transmitirían directamente a los remitentes informes agregados de ubicación y de interacción. Análisis técnico e impacto potencial.

¿Qué es APRF?

APRF es un formato de informe agregado que indica al remitente cómo se comporta realmente su correo en un proveedor de correo (Mailbox Provider, o MBP). El principio de descubrimiento se inspira en DMARC: el remitente publica un registro DNS que declara una dirección de destino, y todo MBP que admita APRF le envía diariamente un informe agregado que describe la ubicación de sus mensajes y cómo han reaccionado los usuarios.

La diferencia de fondo con DMARC: APRF no se apoya en el dominio From, sino en el dominio y el selector de la firma DKIM presentes en el mensaje enviado.

El problema que APRF pretende resolver

La industria del correo gira en torno a la noción de reputación. Los proveedores de correo la utilizan para decidir la ubicación, el volumen permitido y la forma de tratar un flujo. El punto ciego es que el remitente apenas tiene visibilidad sobre estos sistemas de reputación, aunque sean sus propias acciones las que los alimentan. El resultado: cuando algo se degrada, navega a ciegas y le cuesta tomar medidas correctivas específicas.

APRF pretende cerrar parte de esa brecha devolviendo al remitente métricas concretas que influyen en su reputación, directamente desde la fuente.

Cómo funciona APRF, en concreto

1. Publicar un registro DNS basado en DKIM

El generador del informe lee el dominio (d=) y el selector (s=) de la firma DKIM del mensaje recibido y luego consulta un registro TXT en la ubicación:

<selector>._aprf._domainkey.<dominio>

Un registro mínimo tiene este aspecto:

v=APRFv1; rua=mailto:aprf-reports@ejemplo.com;

• v siempre debe valer APRFv1; de lo contrario, el registro se ignora.
• rua indica la o las direcciones de destino de los informes (con el prefijo mailto:, separadas por comas si hay varias).
• Un comodín (*._aprf._domainkey.dominio) cubre todos los selectores, teniendo prioridad la definición explícita de un selector.

2. Segmentar con los SDI (Signer-Defined Identifiers)

El atributo opcional sdi permite al remitente solicitar un desglose de los datos según una cabecera interna que él mismo inyecta (un identificador de campaña, de marca o de cliente, etc.), con un máximo de cuatro niveles de granularidad. La cabecera en cuestión debe estar firmada con DKIM, y en el registro se define un carácter separador. El generador del informe puede ignorar este atributo.

Un punto de atención ya señalado en el borrador: unos nombres de segmento demasiado detallados pueden provocar una fuga de datos al aparecer tal cual en los informes.

3. Recibir los informes

Los informes se entregan por correo electrónico, como adjunto JSON (multipart/report, adjunto application/json, compresión gzip opcional), y abarcan un día UTC completo. La convención de nomenclatura sigue la forma <yyyymmdd>_<dominio DKIM>_<selector>_<fuente>.

Qué aspecto tiene un informe APRF

El formato es JSON legible, compuesto por una cabecera (metadatos: versión, fuente/MBP, dominio y selector DKIM, periodo, contacto) y un cuerpo que contiene uno o varios segmentos. Estructura representativa:

[
  {
    "header": {
      "version": 1,
      "source": "Proveedor MBP",
      "dkim_domain": "ejemplo.com",
      "dkim_selector": "sel1",
      "report_start": 1709164800,
      "report_end": 1709251199,
      "contact_info": "reports@mbp.net",
      "sdi_used": "N/A"
    },
    "body": [
      {
        "classification": { "inbox": 10000, "unwanted": 500 },
        "engagement": { "positive": 300, "neutral": 50, "negative": 200 }
      }
    ]
  }
]

Dos familias de métricas estructuran el cuerpo:

Se recomienda expresar los valores en forma de «tramos» (buckets) en lugar de cifras brutas. Un detalle importante para la interpretación: el borrador no fija la definición exacta de positivo / neutro / negativo. Cada proveedor decide qué incluye en cada categoría —su «receta secreta»— y puede, si lo desea, explicitarlo mediante un campo extra_info.

En qué se diferencia APRF de las herramientas de seedlist

El seguimiento de la ubicación en la bandeja de entrada no es nada nuevo: plataformas como Inbox Monster, Validity Everest o GlockApps lo hacen desde hace tiempo. Pero estas herramientas se apoyan tradicionalmente en listas de direcciones sonda (seedlists): se envía el mensaje a un panel de buzones de prueba y se estima la ubicación a partir de esa muestra. APRF cambia de naturaleza: entrega datos agregados reales, procedentes del comportamiento efectivo de destinatarios reales en el propio proveedor.

Reflexión: ¿qué impacto para las soluciones SaaS de inbox placement?

Esta es la pregunta que merece plantearse. Si APRF llegara a ser adoptado por los grandes actores —Gmail, Microsoft, Yahoo, Apple—, parte de la propuesta de valor de las soluciones SaaS de seguimiento de la ubicación en la bandeja de entrada podría erosionarse. En cuanto los proveedores transmiten la información en origen, en directo y a partir de tráfico real, el papel de un intermediario que estima esa ubicación mediante seedlists resulta mucho menos evidente.

No obstante, conviene matizar, porque estas plataformas no se reducen a medir la ubicación. La prueba previa al envío (una seedlist prueba una campaña que aún no ha salido; APRF solo informa sobre correo ya enviado), la prueba de renderizado en varios clientes, la inteligencia competitiva, el histórico y la cobertura de los proveedores que no implementarán APRF seguirán siendo pertinentes. Lo más probable, por tanto, no es la desaparición, sino un desplazamiento: menos valor en la medición bruta y más en el análisis, la prueba previa al envío y la agregación de múltiples fuentes.

Entre la presentación de un borrador y su implementación por los principales proveedores, correrá mucha agua bajo el puente.

Hablamos aquí de un Internet-Draft individual en la versión -00, no adoptado por un grupo de trabajo, sin estatus oficial en el proceso del IETF y, por ahora, implementado por un único proveedor en beta. La buena noticia: la presencia de Google en la mesa hace que una adopción más amplia sea menos teórica de lo habitual.

¿En qué punto está la estandarización?

Dicho de otro modo: una señal que conviene seguir de cerca, todavía no un estándar sobre el que construir tu producción.

Preguntas frecuentes

¿Qué significa APRF?

Aggregate Performance Reporting. Es un formato de informe agregado mediante el cual un proveedor de correo comunica al remitente datos de ubicación e interacción sobre sus mensajes.

¿Cuál es la diferencia entre APRF y DMARC?

Ambos utilizan el descubrimiento por registro DNS y una dirección rua. Pero DMARC trata de la autenticación y la alineación (y se basa en el dominio From), mientras que APRF trata del rendimiento y la reputación y se basa en el dominio y el selector DKIM.

¿APRF sustituye a Google Postmaster Tools?

No. Postmaster Tools es un panel propio de Gmail. APRF es un formato estandarizado e interoperable que cualquier proveedor puede implementar y entregar por correo electrónico; el objetivo es precisamente salir de la lógica de un portal por proveedor.

¿Cómo puedo recibir informes APRF ahora mismo?

Publicando un registro TXT v=APRFv1; rua=mailto:… en selector._aprf._domainkey.dominio, firmando tu correo con DKIM en ese dominio y recopilando después los adjuntos JSON recibidos. En la práctica, hoy solo recibirás informes de los proveedores que lo hayan implementado (Comcast en beta).

¿APRF acabará con las herramientas de inbox placement?

No a corto plazo. Podría reducir el valor de la medición de ubicación basada en seedlists si los grandes proveedores lo adoptan, pero la prueba previa al envío, el renderizado, el análisis y la cobertura de los proveedores no compatibles conservan su interés. Y la adopción a gran escala llevará tiempo.

Fuentes

1. Al Iverson, «APRF: A New Standard for Deliverability Feedback», Spam Resource, 19 de julio de 2026 — spamresource.com
2. A. Brotman, T. Corbett, E. Gustafsson, «Aggregate Performance Reporting», draft-brotman-aggregate-performance-reporting-00, IETF, 17 de marzo de 2026 — datatracker.ietf.org

— Fin del artículo · APRFv1 · Actualizado en julio de 2026