APRF Record Checker
Check the APRF record mailbox providers find for your DKIM signing domain: which of the three record names answers, whether rua and sdi are valid, and whether every external report address is authorized.
APRF records hang off your DKIM signing domain. Leave the selector empty to check the wildcard and the selector-less record.
What the APRF checker looks at
APRF (Aggregate Performance Reporting) is an email reporting protocol in
the IETF Internet-Draft
draft-ietf-mailmaint-aprf-00. A
mailbox provider that supports it emails the owner of a DKIM signing
domain a daily JSON report: how many messages reached the inbox, how many
were classed as unwanted, and how recipients engaged with them. It is
keyed to the DKIM d= domain and selector, not to the From
address. Comcast (Xfinity) sends beta reports today,
according to Spam Resource.
The provider finds where to send a report by looking up a TXT record under
your DKIM domain. The checker repeats that lookup, then validates what it
finds: v=APRFv1 must be present, rua= must hold
at least one mailto: address, and an optional
sdi= must name a header and a single separator character. A
record that breaks the first two rules is ignored by receivers.
Three places the record can live
| Form | Name | Covers |
|---|---|---|
| Selector record | s1._aprf._domainkey.example.com | Mail signed with selector s1 |
| Wildcard | *._aprf._domainkey.example.com | Every selector without its own record |
| Selector-less | _aprf._domainkey.example.com | Every selector, checked last |
The most specific name that answers wins (draft section 4.2). The checker reads the wildcard through a probe selector, because a DNS wildcard answers any selector name nobody published. Enter your own selector to see whether a selector record overrides the wildcard for it, and whether that selector has a DKIM key at all: reports only cover mail with a valid signature.
Report addresses outside your domain
When a rua= address sits on another domain, the provider
should first confirm that domain wants the reports (draft section 9). The
receiving domain publishes v=APRFv1 at
<selector>.<your domain>._aprf.<its domain>, or a wildcard that covers it. The checker looks that record up for
every external address. DMARCguard report addresses on
reports.dmarcguard.io already publish it, so DMARCguard
collects your APRF reports without extra DNS on its side.
No record yet? Build one in the APRF record generator. Once reports arrive, read them in the APRF report analyzer, and see the APRF guide for how the protocol works end to end.
Read the complete APRF guide to learn more.
Frequently asked questions
What is an APRF record?
A DNS TXT record under your DKIM signing domain, at _aprf._domainkey, that tells mailbox providers supporting Aggregate Performance Reporting where to email daily placement and engagement reports. It needs v=APRFv1 and at least one mailto: address in rua=. APRF is defined in an IETF Internet-Draft, not yet an RFC.
Which name does a mailbox provider look up?
The most specific one that answers: <selector>._aprf._domainkey.<domain> for the selector that signed the message, then the wildcard *._aprf._domainkey.<domain>, then the selector-less _aprf._domainkey.<domain>. The checker reads all three and marks the one a provider would use.
Why does the checker ask for a DKIM selector?
APRF reports are keyed to the DKIM selector as well as the domain. Without one, the checker reads the wildcard and the selector-less record. With one, it also finds a record published for that selector alone and confirms the selector has a DKIM key, since reports only cover validly signed mail.
Why is my report address shown as not authorized?
The address is on a different domain than your DKIM domain, and that domain does not publish v=APRFv1 at <selector>.<your domain>._aprf.<its domain> or a wildcard covering it. Providers should check this record before sending reports to an outside address, so ask the domain's owner to publish it.
Get the full picture with DMARCguard
Continuous monitoring, aggregate report parsing, and actionable insights for all your email authentication protocols.
Start Free