APRF : la nouvelle spécification IETF de la délivrabilité email

Spécification · Délivrabilité

Comcast, Iterable et Google proposent un format standardisé par lequel les fournisseurs de messagerie transmettraient directement aux expéditeurs des rapports agrégés de placement et d'engagement. Décryptage technique et impact potentiel.

Qu'est-ce que l'APRF ?

L'APRF est un format de rapport agrégé qui indique à un expéditeur comment son courrier se comporte réellement chez un fournisseur de messagerie (Mailbox Provider, ou MBP). Le principe de découverte est calqué sur DMARC : l'expéditeur publie un enregistrement DNS déclarant une adresse de destination, et tout MBP qui prend en charge l'APRF lui envoie quotidiennement un rapport agrégé décrivant le placement de ses messages et la façon dont les utilisateurs y ont réagi.

La différence de fond avec DMARC : l'APRF ne s'appuie pas sur le domaine From, mais sur le domaine et le sélecteur de la signature DKIM présents dans le message expédié.

Le problème que l'APRF cherche à résoudre

L'industrie de l'email tourne autour de la notion de réputation. Les fournisseurs de messagerie s'en servent pour décider du placement, du volume autorisé et de la manière dont un flux est traité. Le point aveugle, c'est que l'expéditeur n'a quasiment aucune visibilité sur ces systèmes de réputation, alors même que ce sont ses propres actions qui les alimentent. Résultat : quand quelque chose se dégrade, il navigue à vue et peine à prendre des mesures correctives ciblées.

L'APRF vise à combler une partie de ce fossé en restituant à l'expéditeur des métriques concrètes qui influencent sa réputation, directement depuis la source.

Comment fonctionne l'APRF, concrètement

1. Publier un enregistrement DNS basé sur DKIM

Le générateur de rapport lit le domaine (d=) et le sélecteur (s=) de la signature DKIM du message reçu, puis interroge un enregistrement TXT à l'emplacement :

._aprf._domainkey.

Un enregistrement minimal ressemble à :

v=APRFv1; rua=mailto:aprf-reports@exemple.fr;

• v doit toujours valoir APRFv1 ; à défaut, l'enregistrement est ignoré.
• rua indique la ou les adresses de destination (préfixées par mailto:, séparées par une virgule si plusieurs).
• Un caractère générique (*._aprf._domainkey.domaine) couvre tous les sélecteurs, la définition explicite d'un sélecteur restant prioritaire.

2. Segmenter avec les SDI (Signer-Defined Identifiers)

L'attribut optionnel sdi permet à l'expéditeur de demander une ventilation des données selon un en-tête interne qu'il injecte lui-même (identifiant de campagne, de marque, de client…), sur quatre niveaux de granularité maximum. L'en-tête concerné doit être signé par DKIM, et un caractère séparateur est défini dans l'enregistrement. Le générateur de rapport reste libre d'ignorer cet attribut.

Point de vigilance déjà signalé dans le draft : des noms de segments trop fins peuvent provoquer une fuite de données en apparaissant tels quels dans les rapports.

3. Recevoir les rapports

Les rapports sont livrés par email, en pièce jointe JSON (multipart/report, pièce jointe application/json, compression gzip optionnelle), et couvrent une journée UTC complète. La convention de nommage suit la forme <yyyymmdd>_<domaine DKIM>_<sélecteur>_<source>.

À quoi ressemble un rapport APRF

Le format est du JSON lisible, composé d'un en-tête (métadonnées : version, source/MBP, domaine et sélecteur DKIM, période, contact) et d'un corps contenant un ou plusieurs segments. Structure représentative :

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

Deux familles de métriques structurent le corps :

Les valeurs sont recommandées sous forme de « paliers » (buckets) plutôt qu'en chiffres bruts. Détail important pour l'interprétation : le draft ne fige pas la définition exacte de positif / neutre / négatif. Chaque fournisseur décide de ce qu'il range dans chaque catégorie — c'est sa « recette maison » — et peut, s'il le souhaite, l'expliciter via un champ extra_info.

En quoi l'APRF diffère des outils de seedlist

Le suivi du placement en boîte de réception n'a rien de nouveau : des plateformes comme Inbox Monster, Validity Everest ou GlockApps le font depuis longtemps. Mais ces outils reposent traditionnellement sur des listes d'adresses-sondes (seedlists) : on envoie le message à un panel de boîtes de test, et l'on estime le placement à partir de cet échantillon. L'APRF change de nature : il livre des données agrégées réelles, issues du comportement effectif des vrais destinataires chez le fournisseur lui-même.

Réflexion : quel impact pour les solutions SaaS d'Inbox Placement ?

Voici la question qui mérite d'être posée. Si l'APRF venait à être adopté par les gros acteurs — Gmail, Microsoft, Yahoo, Apple — une partie de la proposition de valeur des solutions SaaS de suivi du placement en boîte de réception pourrait s'éroder. Dès lors que les fournisseurs transmettent l'information à la source, en direct et à partir de trafic réel, le rôle d'un intermédiaire qui estime ce placement via des seedlists devient nettement moins évident.

Il faut toutefois nuancer, car ces plateformes ne se réduisent pas à la mesure du placement. Le test avant envoi (une seedlist teste une campagne pas encore partie ; l'APRF ne rapporte que sur du courrier déjà expédié), le test de rendu multi-clients, l'intelligence concurrentielle, l'historisation et la couverture des fournisseurs qui n'implémenteront pas l'APRF resteront pertinents. Le plus probable n'est donc pas une disparition, mais un déplacement : moins de valeur sur la mesure brute, davantage sur l'analyse, le pré-envoi et l'agrégation multi-sources.

Entre le dépôt d'un draft et son implémentation par les principaux fournisseurs, de l'eau va couler sous les ponts.

On parle ici d'un Internet-Draft individuel en version -00, non adopté par un groupe de travail, sans statut officiel dans le processus IETF, et pour l'instant implémenté par un seul fournisseur en bêta. La bonne nouvelle : la présence de Google au tour de table rend l'hypothèse d'une adoption plus large moins théorique qu'à l'accoutumée.

Où en est la standardisation ?

Autrement dit : un signal à suivre de près, pas encore un standard sur lequel bâtir sa production.

FAQ

Que signifie APRF ?

Aggregate Performance Reporting. C'est un format de rapport agrégé par lequel un fournisseur de messagerie communique à l'expéditeur des données de placement et d'engagement sur son courrier.

Quelle différence entre APRF et DMARC ?

Les deux utilisent la découverte par enregistrement DNS et une adresse rua. Mais DMARC porte sur l'authentification et l'alignement (et se base sur le domaine From), tandis que l'APRF porte sur la performance et la réputation et se base sur le domaine et le sélecteur DKIM.

L'APRF remplace-t-il Google Postmaster Tools ?

Non. Postmaster Tools est un tableau de bord propriétaire à Gmail. L'APRF est un format standardisé et interopérable que n'importe quel fournisseur peut implémenter et livrer par email — l'objectif est justement de sortir de la logique un-portail-par-fournisseur.

Comment recevoir des rapports APRF dès maintenant ?

En publiant un enregistrement TXT v=APRFv1; rua=mailto:… à l'emplacement sélecteur._aprf._domainkey.domaine, en signant son courrier en DKIM sur ce domaine, puis en collectant les pièces jointes JSON reçues. En pratique, vous ne recevrez aujourd'hui des rapports que des fournisseurs qui l'ont implémenté (Comcast en bêta).

L'APRF va-t-il tuer les outils de placement en boîte de réception ?

Pas à court terme. Il pourrait réduire la valeur de la mesure de placement par seedlist si les grands fournisseurs l'adoptent, mais le test avant envoi, le rendu, l'analyse et la couverture des fournisseurs non compatibles conservent leur intérêt. Et l'adoption à grande échelle prendra du temps.

Sources

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

— Fin de l'article · APRFv1 · MàJ juillet 2026