Specifica · Deliverability

APRF: la nuova specifica IETF che potrebbe ridisegnare le regole dell'inbox placement

Comcast, Iterable e Google propongono un formato standardizzato con cui i provider di posta trasmetterebbero direttamente ai mittenti report aggregati di posizionamento e di engagement. Analisi tecnica e impatto potenziale.

Che cos'è APRF?

APRF è un formato di report aggregato che indica a un mittente come si comporta realmente la sua posta presso un provider di posta (Mailbox Provider, o MBP). Il principio di discovery si ispira a DMARC: il mittente pubblica un record DNS che dichiara un indirizzo di destinazione e ogni MBP che supporta APRF gli invia quotidianamente un report aggregato che descrive il posizionamento dei suoi messaggi e il modo in cui gli utenti hanno reagito.

La differenza sostanziale rispetto a DMARC: APRF non si basa sul dominio From, ma sul dominio e sul selettore della firma DKIM presenti nel messaggio inviato.

Il problema che APRF vuole risolvere

Il settore dell'email ruota attorno al concetto di reputazione. I provider di posta la usano per decidere il posizionamento, il volume consentito e il modo in cui trattare un flusso. Il punto cieco è che il mittente non ha quasi alcuna visibilità su questi sistemi di reputazione, anche se sono le sue stesse azioni ad alimentarli. Il risultato: quando qualcosa si degrada, naviga a vista e fatica ad adottare misure correttive mirate.

APRF punta a colmare in parte questo divario restituendo al mittente metriche concrete che influenzano la sua reputazione, direttamente dalla fonte.

Come funziona APRF, concretamente

1. Pubblicare un record DNS basato su DKIM

Il generatore del report legge il dominio (d=) e il selettore (s=) dalla firma DKIM del messaggio ricevuto, quindi interroga un record TXT nella posizione:

<selettore>._aprf._domainkey.<dominio>

Un record minimo si presenta così:

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

• v deve sempre valere APRFv1; in caso contrario il record viene ignorato.
• rua indica l'indirizzo o gli indirizzi di destinazione dei report (con prefisso mailto:, separati da virgola se più di uno).
• Un carattere jolly (*._aprf._domainkey.dominio) copre tutti i selettori, con priorità alla definizione esplicita di un selettore.

2. Segmentare con gli SDI (Signer-Defined Identifiers)

L'attributo opzionale sdi consente al mittente di richiedere una ripartizione dei dati in base a un header interno che inietta lui stesso (un identificativo di campagna, di brand o di cliente, ecc.), fino a un massimo di quattro livelli di granularità. L'header in questione deve essere firmato in DKIM e nel record viene definito un carattere separatore. Il generatore del report resta libero di ignorare questo attributo.

Un punto di attenzione già segnalato nella bozza: nomi di segmento troppo dettagliati possono provocare una fuga di dati comparendo così come sono nei report.

3. Ricevere i report

I report vengono consegnati via email, come allegato JSON (multipart/report, allegato application/json, compressione gzip opzionale), e coprono una giornata UTC completa. La convenzione di denominazione segue la forma <yyyymmdd>_<dominio DKIM>_<selettore>_<fonte>.

Che aspetto ha un report APRF

Il formato è JSON leggibile, composto da un header (metadati: versione, fonte/MBP, dominio e selettore DKIM, periodo, contatto) e da un body che contiene uno o più segmenti. Struttura rappresentativa:

[
  {
    "header": {
      "version": 1,
      "source": "Provider MBP",
      "dkim_domain": "esempio.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 }
      }
    ]
  }
]

Due famiglie di metriche strutturano il body:

I valori sono consigliati sotto forma di «fasce» (buckets) anziché di cifre grezze. Un dettaglio importante per l'interpretazione: la bozza non fissa la definizione esatta di positivo / neutro / negativo. Ogni provider decide che cosa inserire in ciascuna categoria — la sua «ricetta segreta» — e può, se lo desidera, esplicitarlo tramite un campo extra_info.

In che cosa APRF si distingue dagli strumenti di seedlist

Il monitoraggio del posizionamento nella posta in arrivo non è una novità: piattaforme come Inbox Monster, Validity Everest o GlockApps lo fanno da tempo. Ma questi strumenti si basano tradizionalmente su liste di indirizzi sonda (seedlist): si invia il messaggio a un panel di caselle di test e si stima il posizionamento a partire da quel campione. APRF cambia natura: fornisce dati aggregati reali, derivanti dal comportamento effettivo di destinatari reali presso il provider stesso.

Riflessione: quale impatto per le soluzioni SaaS di inbox placement?

Ecco la domanda che vale la pena porsi. Se APRF venisse adottato dai grandi attori — Gmail, Microsoft, Yahoo, Apple — una parte della proposta di valore delle soluzioni SaaS di monitoraggio del posizionamento nella posta in arrivo potrebbe erodersi. Nel momento in cui i provider trasmettono l'informazione alla fonte, in tempo reale e a partire da traffico reale, il ruolo di un intermediario che stima tale posizionamento tramite seedlist diventa nettamente meno evidente.

Occorre però fare dei distinguo, perché queste piattaforme non si riducono alla misurazione del posizionamento. Il test pre-invio (una seedlist testa una campagna non ancora partita; APRF riporta solo sulla posta già inviata), il test di rendering su più client, l'intelligence competitiva, lo storico e la copertura dei provider che non implementeranno APRF resteranno rilevanti. Lo scenario più probabile non è quindi la scomparsa, ma uno spostamento: meno valore sulla misurazione grezza, più sull'analisi, sul test pre-invio e sull'aggregazione multi-fonte.

Tra il deposito di una bozza e la sua implementazione da parte dei principali provider, passerà molta acqua sotto i ponti.

Parliamo qui di un Internet-Draft individuale nella versione -00, non adottato da un gruppo di lavoro, privo di status ufficiale nel processo IETF e, per ora, implementato da un solo provider in beta. La buona notizia: la presenza di Google al tavolo rende un'adozione più ampia meno teorica del solito.

A che punto è la standardizzazione?

In altre parole: un segnale da seguire con attenzione, non ancora uno standard su cui basare la propria produzione.

Domande frequenti

Che cosa significa APRF?

Aggregate Performance Reporting. È un formato di report aggregato con cui un provider di posta comunica al mittente dati di posizionamento ed engagement sui suoi messaggi.

Qual è la differenza tra APRF e DMARC?

Entrambi utilizzano la discovery tramite record DNS e un indirizzo rua. Ma DMARC riguarda l'autenticazione e l'allineamento (e si basa sul dominio From), mentre APRF riguarda le performance e la reputazione e si basa sul dominio e sul selettore DKIM.

APRF sostituisce Google Postmaster Tools?

No. Postmaster Tools è una dashboard proprietaria di Gmail. APRF è un formato standardizzato e interoperabile che qualsiasi provider può implementare e consegnare via email; l'obiettivo è proprio uscire dalla logica di un portale per ogni provider.

Come posso ricevere i report APRF fin da ora?

Pubblicando un record TXT v=APRFv1; rua=mailto:… in selettore._aprf._domainkey.dominio, firmando la posta in DKIM su quel dominio e raccogliendo poi gli allegati JSON ricevuti. In pratica, oggi riceverai report solo dai provider che l'hanno implementato (Comcast in beta).

APRF ucciderà gli strumenti di inbox placement?

Non nel breve termine. Potrebbe ridurre il valore della misurazione del posizionamento basata su seedlist se i grandi provider lo adottano, ma il test pre-invio, il rendering, l'analisi e la copertura dei provider non compatibili conservano il loro interesse. E l'adozione su larga scala richiederà tempo.

Fonti

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

— Fine dell'articolo · APRFv1 · Aggiornato a luglio 2026