Wat is APRF? Uitleg over de nieuwe standaard voor feedback over de afleverbaarheid van e-mails

Huidige status: APRF is een actief voorstel in de IETF, maar afzenders kunnen nu al dagelijkse rapporten ontvangen. Comcast (Xfinity) verstuurt actief bètarapporten uit de productieomgeving naar afzenders die een APRF-DNS-record publiceren. Andere providers die aan het voorstel hebben meegewerkt (zoals Google) hebben de generatie van deze rapporten nog niet ingeschakeld.

Zolang organisaties al bulk-e-mails versturen, kampen deliverability-managers met een fundamentele blinde vlek: zodra een e-mailprovider een bericht accepteert, kan niemand met zekerheid zeggen waar het daadwerkelijk terecht is gekomen. Verzenders hebben in het verleden een geschat beeld van de plaatsing in de inbox samengesteld door middel van tests met kunstmatige seedlists of door het raadplegen van uiteenlopende postmaster-dashboards bij Google, Microsoft en Yahoo. Elke provider biedt verschillende statistieken aan in incompatibele formaten, waardoor verzenders geen enkele, uniforme bron van waarheid hebben.

Een nieuw voorstel voor een specificatie heeft tot doel dit al lang bestaande probleem in de sector op te lossen. Dit opkomende protocol, bekend als APRF (Aggregate Performance Reporting Format), stelt e-mailproviders in staat om gestandaardiseerde dagelijkse rapporten op te stellen over de plaatsing van berichten en de betrokkenheid van ontvangers, en deze rechtstreeks naar de afzenders te sturen. In plaats van te vertrouwen op schattingen op basis van seedlists, kunnen afzenders nu zien hoe hun geauthenticeerde e-mailstromen zijn geclassificeerd en hoe echte ontvangers erop hebben gereageerd.

Hier volgt een uitgebreide uitleg over wat APRF precies is, hoe het detectiemechanisme ervan werkt, hoe het zich verhoudt tot bestaande standaarden zoals DMARC, en hoe u uw eerste DNS-record kunt publiceren om vandaag nog te beginnen met het verzamelen van rapporten.

Wat is APRF (Aggregate Performance Reporting Format)?

Aggregate Performance Reporting Format (APRF) is een voorgesteld rapportageprotocol voor e-mail dat is ontworpen om afzenders gestructureerde, machinaal leesbare feedback te geven over de afleverbaarheid van e-mails en de interactie van gebruikers. Terwijl traditionele protocollen verslag doen van authenticatie- of verbindingsfouten bij de gateway, richt APRF zich volledig op wat er met berichten gebeurt nadat ze door de ontvangende server zijn geaccepteerd.

De specificatie is momenteel vastgelegd in de IETF-internetdraft met de titel „draft-brotman-aggregate-performance-reporting-00”. Het document, dat op 17 maart 2026 is gepubliceerd en bedoeld is voor de Standards Track, is opgesteld door drie veteranen uit de e-mailbranche:

• Alex Brotman (Comcast)
• Tom Corbett (Iterable)
• Emil Gustafsson (Google)

Volgens de officiële IETF Datatracker-statuspagina heeft de eerste -00-revisie een officiële vervaldatum van 18 september 2026. Als individuele inzending bevindt APRF zich nog in de allereerste evaluatiefase („I-D Exists“) en is het nog niet formeel aangenomen door een IETF-werkgroep of uitgegeven als RFC. Het feit dat APRF echter is opgesteld door een toonaangevende internetprovider, een grote zakelijke e-mailprovider en Google, maakt het tot een van de belangrijkste initiatieven op het gebied van e-mailbezorgbaarheid die de afgelopen jaren zijn voorgesteld.

Opmerking over terminologie: Buiten de e-mailtechnologie komt de afkorting „APRF“ vaak voor in medisch en biologisch onderzoek, waar het staat voor „Advanced Platelet-Rich Fibrin“ of „Acute-Phase Response Factor“. In de context van e-mailbeveiliging, infrastructuur en e-mailbezorgbaarheid verwijst APRF uitsluitend naar de specificatie „Aggregate Performance Reporting Format“.

APRF versus DMARC-rapporten versus feedbackloops: wat is nu eigenlijk het verschil?

Om te begrijpen welke rol APRF speelt in de e-mailstrategie van een onderneming, is het nuttig om het te vergelijken met bestaande rapportagemechanismen op vier belangrijke vlakken: reikwijdte, gegevensformaat, identificatiesleutel en verzendmethode.

Authenticatie versus prestaties: het belangrijkste verschil

Het belangrijkste verschil tussen DMARC-geaggregeerde rapporten en APRF komt neer op authenticatie versus prestaties:

1. DMARC draait om authenticatie. De geaggregeerde rapporten van DMARC geven antwoord op de vraag: „Is deze e-mail correct geauthenticeerd via SPF en DKIM met behulp van mijn zichtbare domeinnaam, en heeft een onbevoegde afzender geprobeerd mijn merk te misbruiken?”
2. Bij APRF draait alles om prestaties. APRF-rapporten geven antwoord op de vraag: „Nu de e-mail de authenticatie heeft doorstaan en is geaccepteerd, waar heeft de e-mailprovider deze dan geplaatst en hoe hebben de ontvangers erop gereageerd?”

APRF is geen vervanging voor de geaggregeerde DMARC-rapporten of traditionele feedbackloops voor klachten. Het fungeert juist als een aanvullende laag. DMARC beschermt uw merkidentiteit tegen identiteitsfraude, terwijl APRF inzicht biedt in de manier waarop mailboxalgoritmen uw afzenderreputatie beoordelen.

Bovendien verschilt APRF van dashboards van providers zoals Google Postmaster Tools. Voor dergelijke dashboards moet u handmatig inloggen of gebruikmaken van op maat gemaakte API-integraties die specifiek op één provider zijn afgestemd. APRF introduceert een open, leveranciersonafhankelijke standaard die prestatiestatistieken rechtstreeks in uw inbox bezorgt in een gestructureerde JSON-payload.

Wat staat er in een APRF-rapport?

APRF-rapporten worden één keer per dag gegenereerd door deelnemende e-mailproviders. Elk rapport bestrijkt een volledige periode van 24 uur (UTC) (van 00:00:00 UTC tot 23:59:59 UTC). Het rapport wordt verzonden als bijlage bij een e-mail in JSON-formaat, met de bestandsindeling ‘application/json’ of ‘compressed application/gzip’.

De JSON-payload is onderverdeeld in twee afzonderlijke delen: de header en de body.

1. Metagegevens in de koptekst

De koptekst bevat administratieve gegevens over de rapportageperiode, de aanbieder die het rapport opstelt en de DKIM-identiteit van de afzender:

• versie: De versie van de APRF-specificatie (momenteel 1).
• bron: De naam of identificatiecode van de aanbieder van de mailbox waaruit de melding afkomstig is (bijvoorbeeld Comcast).
• dkim_domain: Het DKIM-domein (d=) dat in de uitgaande handtekening is geverifieerd.
• dkim_selector: De specifieke DKIM-selector (s=) die door de provider is herkend.
• report_start / report_end: Unix-epoch-tijdstempels die het exacte 24-uurs UTC-dekkingsvenster aangeven.
• contact_info: Een administratief e-mailadres of een URL die door de rapporterende entiteit is opgegeven.
• sdi_used: Geeft aan of door de ondertekenaar gedefinieerde identificatiecodes zijn geparseerd voor de segmentatie van substreams.

2. Metrische families (de hoofdtekst van het rapport)

Het rapport bevat geaggregeerde tellingen die zijn ingedeeld in twee hoofdgroepen van statistieken:

Classificatiestatistieken (plaatsing)

Classificatiestatistieken houden bij waar de ontvangende provider de geaccepteerde berichten naartoe heeft doorgestuurd:

• Inbox: Berichten die in de hoofdmap ‘Inbox’ zijn afgeleverd.
• ongewenst: berichten die naar de map ‘spam’, ‘junk’ of ‘bulk’ worden doorgestuurd.
• promotioneel: Berichten die zijn ondergebracht in secundaire promotietabbladen of -mappen.
• doorgestuurd: Berichten die automatisch worden doorgestuurd op basis van regels in de mailbox van de ontvanger.

Betrokkenheidsstatistieken (gebruikersgedrag)

Betrokkenheidsstatistieken geven een overzicht van de daadwerkelijke acties die ontvangers na de bezorging hebben ondernomen:

• Positief: gunstige acties van gebruikers, zoals het openen van berichten, het klikken op links, het verplaatsen van berichten uit de spammap (reddingsacties) of het markeren van berichten als belangrijk.
• Negatief: Ongewenste acties van gebruikers, zoals op ‘Als spam melden’ klikken, berichten verwijderen zonder ze te lezen of zich uitschrijven.
• Neutraal: Niet-beoordelende handelingen, zoals archiveren, opslaan in aangepaste mappen of handmatig doorsturen.

3. Door de ondertekenaar gedefinieerde identificatiecodes (SDI) voor gedetailleerde tracering

Standaard rapporteert APRF geaggregeerde gegevens op het niveau van de DKIM-selector. Grote ondernemingen versturen echter vaak meerdere soorten e-mails onder één enkele DKIM-selector. Om hierop in te spelen, bevat het ontwerp een optionele functie die bekendstaat als Signer-Defined Identifiers (SDI).

Door een sdi-tag in uw DNS-record op te nemen, kunt u e-mailproviders opdracht geven om een specifieke aangepaste header (zoals X-Campaign-ID of Signer-Info) te controleren die in uw DKIM-handtekening is opgenomen. De provider zal vervolgens de dagelijkse classificatie- en betrokkenheidsstatistieken uitsplitsen op basis van die sub-identificatoren, waarbij maximaal vier geneste segmentatieniveaus worden ondersteund. Hierdoor kunnen organisaties transactionele meldingen los van marketingcampagnes evalueren, terwijl ze een gestroomlijnde DKIM-sleutelarchitectuur behouden.

Voorbeeld met toelichting van een APRF JSON-payload

Hieronder volgt een voorbeeld van een JSON-rapport dat is opgebouwd volgens de specificatie `draft-brotman-aggregate-performance-reporting-00`:

[
  {
    "header": {
      "version": 1,
      "source": "Comcast/Xfinity",
      "dkim_domain": "example.com",
      "dkim_selector": "s1024",
      "report_start": 1773705600,
      "report_end": 1773791999,
      "contact_info": "[email protected]",
      "sdi_used": "none",
      "extra_info": "https://postmaster.comcast.net/aprf-info"
    },
    "body": [
      {
        "classification": {
          "inbox": 45000,
          "unwanted": 120,
          "promotional": 0,
          "forwarded": 15
        },
        "engagement": {
          "positive": 14200,
          "negative": 18,
          "neutral": 850
        }
      }
    ]
  }
]

Hoe APRF werkt: van DNS-detectie tot het versturen van rapporten

APRF maakt gebruik van een op DNS gebaseerd detectieproces dat is gebaseerd op gevestigde protocollen zoals DMARC en TLS-RPT. Omdat de rapportage rechtstreeks gekoppeld is aan de ondertekening van berichten, kan een e-mailprovider uw rapportagevoorkeuren vaststellen zonder dat daarvoor aangepaste portaalconfiguraties nodig zijn.

Het stapsgewijze proces

1. E-mailverzending: Uw infrastructuur verzendt uitgaande e-mails die zijn ondertekend met geldige DKIM-handtekeningen.
2. Controle van de handtekening: De ontvangende provider accepteert de e-mail, controleert de DKIM-handtekening en haalt het domein (d=example.com) en de selector (s=s1024) eruit. DNS-opvraging: De provider vraagt bij DNS een TXT-record op met de naam: s1024._aprf._domainkey.example.com
3. Parsen van records: De provider parseert het TXT-record om te controleren of de verplichte v=APRFv1-tag aanwezig is en om het e-mailadres van de ontvanger op te halen dat in de rua-tag is gedefinieerd.
4. Verzameling en verzending: In de komende 24 uur verzamelt de provider de plaatsings- en betrokkenheidsgegevens voor die selector. Aan het einde van de UTC-dag genereert hij het JSON-rapport en verstuurt hij dit via SMTP naar het opgegeven rua-adres.

Privacywaarborgen en volumedrempels

Om de privacy van individuele gebruikers te beschermen, wordt in het APRF-ontwerp uitdrukkelijk aanbevolen dat e-mailproviders drempels voor het beperken van het verzendvolume hanteren . Als een afzender op een bepaalde dag slechts een handvol berichten naar een provider verstuurt, zouden ruwe prestatiestatistieken de afzender in staat kunnen stellen de handelingen van specifieke personen af te leiden.

Binnen het APRF-privacyramwerk laten providers de rapportage volledig achterwege of passen ze voor stromen met een laag volume bucketing-algoritmen met ruis toevoeging toe. Als uw dagelijkse berichtenvolume naar een specifieke mailboxprovider onder hun privacydrempel komt, ontvangt u voor die dag geen rapport.

Hoe u vandaag nog kunt beginnen met het verzamelen van APRF-rapporten

Hoewel APRF nog steeds een actief IETF-ontwerp is en geen definitieve RFC-standaard, genereert Comcast (Xfinity) in de productieomgeving (in bèta) actief dagelijkse APRF-rapporten voor afzenders die het DNS TXT-record publiceren.

Het publiceren van een APRF-record duurt slechts enkele minuten en vereist geen software-installatie of aanpassingen aan uw e-mailinfrastructuur. Volg deze vier stappen om rapporten te gaan ontvangen.

Stap 1: Bepaal je actieve DKIM-selector

Bekijk de e-mailheaders van een recent verzonden bericht vanuit uw domein. Zoek de DKIM-Signature-header en noteer de selector (s=) en het domein (d=).

Als je header bijvoorbeeld d=example.com en s=s1024 weergeeft, wordt je APRF-record gehost op: s1024._aprf._domainkey.example.com

Ondersteuning voor jokertekens: Als u tientallen selectors beheert en niet voor elk daarvan een afzonderlijk record wilt aanmaken, kunt u volgens de specificatie een algemeen record publiceren met behulp van een asterisk (*): *._aprf._domainkey.example.com

Ontvangende providers zullen eerst controleren of er een specifiek selectorrecord bestaat. Als dat niet het geval is, vallen ze terug op het wildcardrecord.

Stap 2: Een speciale mailbox voor meldingen aanmaken

Maak een speciale mailbox of e-mailalias aan om inkomende rapporten te verzamelen (bijvoorbeeld [email protected]). Aangezien rapporten geautomatiseerde JSON-bestanden bevatten, voorkomt het verzenden ervan naar een speciale alias dat je primaire inbox dagelijks wordt overspoeld met bijlagen.

Stap 3: Publiceer het DNS-TXT-record

Log in op uw DNS-beheerconsole en voeg een nieuw TXT-record toe met de volgende parameters:

• Host / Naam: s1024._aprf._domainkey.example.com (of *._aprf._domainkey.example.com voor een jokerteken)
• Recordtype: TXT
• TTL: 3600 seconden (1 uur)
• Waarde: v=APRFv1; rua=mailto:[email protected];

Als je het bijhouden van substreams via door de ondertekenaar gedefinieerde identificatiecodes wilt inschakelen voor een header met de naam X-Campaign-ID en met een caret (^) als scheidingsteken, stel je de waarde dan als volgt samen:

v=APRFv1; rua=mailto:[email protected]; sdi=X-Campaign-ID,^;

Stap 4: Controleer de publicatie

Gebruik een DNS-opzoektool of een opdrachtregelprogramma (zoals `dig` of `nslookup`) om te controleren of je nieuwe record openbaar is:

dig TXT s1024._aprf._domainkey.example.com +short

Realistische verwachtingen voor de huidige situatie

Bij het implementeren van een APRF-record is het belangrijk om realistische operationele verwachtingen te stellen:

• Actieve bètastatus: Comcast (Xfinity) is momenteel de enige grote mailboxaanbieder die actief APRF-rapporten in de bètaversie genereert.
• De rol van Google: Google heeft meegewerkt aan het opstellen van het ontwerp, waarmee het bedrijf blijk geeft van een sterke langetermijnbelangstelling voor gestandaardiseerde prestatierapportage. Gmail genereert momenteel echter geen APRF-rapporten. Afzenders dienen de richtlijnen voor e-mailafzenders van Gmail te blijven raadplegen voor de huidige vereisten van Gmail.
• Geen publicatiekosten: Het publiceren van een APRF-record kost momenteel niets en brengt geen prestatieverlies met zich mee. Zodra het record is gepubliceerd, ontvangt uw domein automatisch rapporten van Comcast, evenals van eventuele andere providers die de standaard in de toekomst gaan toepassen.

Waarom APRF belangrijk is (en wat het niet zal oplossen)

De reacties uit de sector op APRF zijn overwegend positief. In een analyse op Spam Resource prees Al Iverson, expert op het gebied van deliverability, APRF omdat het „echte, geaggregeerde gegevens op basis van daadwerkelijk gebruikersgedrag“ levert in plaats van kunstmatige schattingen op basis van seedlists. Iverson benadrukte dat APRF een aanvullend hulpmiddel is dat samen met bestaande platforms werkt om meer duidelijkheid te bieden in de bedrijfsvoering.

De belangrijkste voordelen

7. Echte gegevens van ontvangers: Seedlists maken gebruik van kunstmatige accounts die geen realistische interactiegeschiedenis hebben. APRF geeft de werkelijke bezorgresultaten weer op basis van echte gebruikersaccounts.

8. Gestandaardiseerd open formaat: Afzenders kunnen JSON-statistieken van meerdere aanbieders in één interne analysepijplijn verwerken, waardoor het niet meer nodig is om op maat gemaakte webscrapers of API-connectoren voor verschillende postmasterportalen te ontwikkelen.

9. Granulariteit op substreamniveau: Door gebruik te maken van de SDI-tag kunnen technische teams problemen met de afleverbaarheid die betrekking hebben op specifieke soorten transactionele berichten isoleren, zonder hun hoofdarchitectuur voor DKIM-sleutels op te splitsen.

Bekende beperkingen

Ondanks de voordelen ervan kent APRF duidelijke beperkingen:

• Beperkte ondersteuning voor providers op dit moment: Aangezien momenteel alleen Comcast rapporten genereert in de bètaversie, biedt APRF nog geen volledig inzicht in de afleverbaarheid wereldwijd.
• Geen diagnostische gegevens over de onderliggende oorzaak: Uit een APRF-rapport blijkt dat een bepaald percentage berichten in de spamfolder terecht is gekomen, maar er wordt niet aangegeven waarom. Het rapport geeft geen uitsluitsel over de vraag of het probleem werd veroorzaakt door een slechte IP-reputatie, het op de blokkeerlijst plaatsen van een URL of triggers in de inhoud van het spamfilter.
• Specificatieontwerp in ontwikkeling: Aangezien het hier om een actief IETF-ontwerp gaat, kunnen de tagsyntaxis en de velden van het JSON-schema nog worden herzien voordat de definitieve standaard wordt vastgesteld.

Authenticatie blijft een voorwaarde

APRF-statistieken worden pas berekend nadat een ontvangende server een e-mail heeft geaccepteerd. Als uw uitgaande berichten niet voldoen aan de basiscontroles voor authenticatie, kunnen ontvangende servers deze bij de gateway blokkeren, waardoor rapportage over de plaatsing van de berichten niet meer relevant is.

Voordat u feedback over de afleverbaarheid gaat verzamelen, moet u ervoor zorgen dat uw primaire authenticatiemaatregelen correct zijn geconfigureerd:

• Stel geldige DKIM-records in voor alle legitieme verzendbronnen.
• Controleer of uw domein wordt beschermd door DMARC, met bijbehorende SPF- en DKIM-handtekeningen.
• Gebruik een gecentraliseerde DMARC Report Analyzer om de authenticatiestatus en de voortgang bij het doorvoeren van een handhavingsbeleid (p=reject) te monitoren.

Moet je nu een APRF-record publiceren?

Ja, voor afzenders met een hoog verzendvolume. Als uw organisatie grote hoeveelheden e-mails verstuurt naar consumentenadressen bij Comcast/Xfinity, levert het publiceren van een APRF-record onmiddellijk voordeel op. U krijgt toegang tot actuele dagelijkse plaatsingsgegevens en kunt een geautomatiseerde rapportagestroom opzetten nog voordat andere grote providers zich bij de standaard aansluiten.

Voor verzenders met een laag verzendvolume of die uitsluitend B2B-berichten versturen, is het publiceren van een APRF-record optioneel, maar wel aanbevolen. Hoewel je vanwege privacydrempels dagelijkse rapporten mogelijk niet onmiddellijk ontvangt, kost het publiceren van een wildcard-TXT-record (*._aprf._domainkey.example.com) minder dan vijf minuten, brengt het geen enkel veiligheidsrisico met zich mee en zorgt het ervoor dat je domein klaar is voor de toekomstige bredere toepassing van deze technologie binnen de sector.

Veelgestelde Vragen

Waar staat APRF voor in e-mails?

APRF staat voor Aggregate Performance Reporting Format. Het is een voorgestelde open standaard die is ontworpen om gestandaardiseerde dagelijkse prestatiegegevens en gegevens over de betrokkenheid van ontvangers van e-mailproviders terug te sturen naar e-mailverzenders.

Is APRF inmiddels een officiële IETF-standaard?

Nee. APRF is momenteel een actieve individuele internet-draft (draft-brotman-aggregate-performance-reporting-00). Het is nog niet officieel goedgekeurd door een IETF-werkgroep of gepubliceerd als RFC-standaard.

Waarin verschilt APRF van de geaggregeerde DMARC-rapporten?

DMARC-geaggregeerde rapporten (RUA) meten de mate waarin e-mailauthenticatie (SPF- en DKIM-validatie) overeenkomt met het zichtbare ‘Van’-domein. APRF meet de prestaties na acceptatie (plaatsing in de inbox en gebruikersbetrokkenheid) ten opzichte van het DKIM-ondertekeningsdomein en de selector.

Welke e-mailproviders ondersteunen APRF op dit moment?

Comcast (Xfinity) is momenteel de enige e-mailprovider die APRF-rapporten in bètaversie verstuurt in de productieomgeving. Hoewel Google mede-opsteller was van de specificatie, ondersteunt Gmail momenteel het genereren van APRF-rapporten niet.

Heb ik DKIM nodig om APRF-rapporten te ontvangen?

Ja. APRF-ontdekkingsrecords worden gepubliceerd onder de DKIM-domeinsleutelnaamruimte (_domainkey), en de rapportage is rechtstreeks gekoppeld aan de DKIM-selector die wordt gebruikt om uitgaande berichten te ondertekenen.

Vervangt APRF de traditionele feedbacklussen (FBL's)?

Nee. Bij traditionele feedbackloops worden bijna in realtime ARF-rapporten verzonden wanneer een individuele gebruiker een bericht als spam markeert. APRF biedt dagelijkse geaggregeerde statistieken die een overzicht geven van de algehele plaatsing en gebruikersbetrokkenheid binnen uw gehele e-mailstroom.

Volgende stappen: Controleer de basis van je domein

APRF biedt waardevolle inzichten in de aflevering van berichten, maar is volledig afhankelijk van een goed functionerende e-mailinfrastructuur. Als uw authenticatiegegevens verkeerd zijn geconfigureerd of niet op elkaar zijn afgestemd, zullen e-mailproviders uw berichten weigeren voordat de afleveringsstatistieken kunnen worden geregistreerd.

Om ervoor te zorgen dat uw domein klaar is voor APRF:

• Controleer of alle uitgaande e-mailstromen zijn ondertekend met geldige, afgestemde DKIM-sleutels.
• Controleer uw DMARC-beleid met behulp van de PowerDMARC Domain Analyzer om na te gaan of de authenticatie op orde is.
• Publiceer een algemene APRF-record (*._aprf._domainkey.yourdomain.com) om prestatiefeedback te gaan ontvangen zodra deelnemende providers online komen.

• Over
• Laatste berichten

Yunes Tarada

Expert op het gebied van domein- en e-mailbeveiliging bij PowerDMARC

Yunes is teamleider Operations bij PowerDMARC en heeft expertise in e-mailauthenticatie en -beveiliging. Hij is een door Microsoft gecertificeerde Azure Administrator Associate en beschikt over certificeringen zoals CompTIA A+ en vele andere.

Laatste berichten van Yunes Tarada (Bekijk alle berichten)

• Wat is APRF? Uitleg over de nieuwe standaard voor feedback over e-mailbezorgbaarheid - 4 september 2026
• Handleiding voor het instellen van DKIM, DMARC en SPF van Network Solutions - 2 september 2026
• Handleiding voor e-mailverificatie van Simply.com: SPF, DKIM en DMARC - 1 september 2026