And sorry about the example formatting, which was randomly put together.
Here's a more accurate XSD version:
<record>
<row>
<source_ip>127.0.0.1</source_ip>
<count>1</count>
...
</row>
<identifiers>
<header_from>forwarder.example</header_from>
</identifiers>
<auth_results>
<dkim2>
<domain>sender.example</domain>
<result>pass</result>
<selector>rsa.sel</selector>
</dkim2>
<dkim2>
<domain>sender.example</domain>
<result>pass</result>
<selector>mldsa44.sel</selector>
</dkim2>
<dkim2>
<domain>forwarder.example</domain>
<result>pass</result>
<selector>rsa.sel</selector>
</dkim2>
<spf>
<domain>forwarder.example</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
-Wei
On Wed, Nov 11, 2026 at 2:36 PM Wei Chuang <[email protected]> wrote:
> In some offline discussions, there are two clarifications:
> 1) Todd points out that redacting DMARC report information would be pretty
> useful to spammers and phishers. So let's drop that idea.
> 2) Richard points out that the "feedback" and "feedhere" flags are for a
> feedback loop mechanism unrelated to DMARC reports. In that case, this
> proposes a new "dmarcreport" flag that notifies receivers that DMARC
> reports are requested.
> -Wei
>
> On Wed, Nov 11, 2026 at 12:41 PM Wei Chuang <[email protected]> wrote:
>
>> Hi,
>>
>> We need a way to get feedback for new algorithms bring-up and understand
>> deliverability with DKIM2. This proposes modifying RFC9990 DMARC reports
>> to support DKIM2 to leverage the existing DMARC reporting infrastructure.
>> Multiple DKIM2 signatures can be supported very similarly to DKIM
>> multisignatures. Another alternative is to create a new DKIM report
>> standard but this risks losing support of the existing base of DMARC report
>> senders. Further the ability to get reports from intermediaries exists in
>> the unexplored DKIM2 spec "feedback" and "feedhere" flags that we examine
>> later.
>>
>> Let's look at a forwarding example with multiple signatures at the
>> originator:
>>
>> From: [email protected]
>>
>> DKIM2-Signature: i=1; d=sender.example;
>> s=rsa.sel:rsa-sha256:rsa+sig,mldsa44.sel:mldsa44:mldsa+sig|ed25519.sel:ed25519-sha256:ed25519+sig
>>
>> DKIM2-Signature: i=2; d=forwarder.example; s=rsa.sel:rsa-sha256:rsa+sig
>>
>> Below is a snippet of the proposed DMARC report for DKIM2 that is sent to
>> the originator sender.example. As noted in the "DKIM2 / DMARC Sender
>> Policy Proposal" thread, the originator i.e. message author by default gets
>> a DMARC report. We see the multiple signature results designated by the
>> selectors "rsa.sel" and "mldsa44.sel" from signatures created by the
>> originator. Note that the "ed25519.sel" was not evaluated as that was
>> short circuited. (This is a strawman to see if that's the right evaluation
>> with "any" behavior i.e. '|'. Happy to see what feedback there is about
>> the short circuit idea) You can see that both the originator's and
>> forwarder's results are presented, though it's possible that the receiver
>> may choose to reduce the scope of the results
>>
>> record: {
>>
>> row: {
>>
>> Source_ip: "127.0.0.1"
>>
>> Count: 1
>>
>> ...
>>
>> }
>>
>> identifiers: {
>>
>> Header_from: "forwarder.example"
>>
>> }
>>
>> auth_results: {
>>
>> dkim2: {
>>
>> Domain: "sender.example"
>>
>> Result: "pass"
>>
>> Selector: "rsa.sel"
>>
>> }
>>
>> dkim2: {
>>
>> Domain: "sender.example"
>>
>> Result: "pass"
>>
>> Selector: "mldsa44.sel"
>>
>> }
>>
>> dkim2: {
>>
>> Domain: "forwarder.example"
>>
>> Result: "pass"
>>
>> Selector: "rsa.sel"
>>
>> }
>>
>> spf: {
>>
>> Domain: "forwarder.example"
>>
>> Result: "pass"
>>
>> }
>>
>> }
>>
>> }
>>
>> DKIM2 spec also has "feedback" and "feedhere" flags. This proposes that
>> forwarders who have "feedback" flag may get the DMARC reports. If so, the
>> receiver looks up the DMARC policy corresponding to the "d=" domain and
>> send reports to the "rua" and "ruf" addresses. "feedback" here provides a
>> privacy sensitive bounce. It can also be used as a privacy signal to
>> indicate the DMARC report redaction of the results of that domain that
>> would otherwise be sent to other domains.
>>
>> This example illustrates "feedback" and "feedhere" flags where the
>> forwarder requests DMARC reports.
>>
>> From: [email protected]
>>
>> DKIM2-Signature: i=1; d=sender.example;
>> s=rsa.sel:rsa-sha256:rsa+sig,mldsa44.sel:mldsa44:mldsa+sig|ed25519.sel:ed25519-sha256:ed25519+sig;
>> f=feedhere
>>
>> DKIM2-Signature: i=2; d=forwarder.example; s=rsa.sel:rsa-sha256:rsa+sig;
>> f=feedback
>>
>> A DMARC report can be sent to forwarder.example,but it is filtered to
>> excludes results from sender.example that have the feedhere flag.
>>
>> record: {
>>
>> row: {
>>
>> Source_ip: "127.0.0.1"
>>
>> Count: 1
>>
>> ...
>>
>> }
>>
>> identifiers: {
>>
>> Header_from: "forwarder.example"
>>
>> }
>>
>> auth_results: {
>>
>> dkim2: {
>>
>> Domain: "forwarder.example"
>>
>> Result: "pass"
>>
>> Selector: "rsa.sel"
>>
>> }
>>
>> spf: {
>>
>> Domain: "forwarder.example"
>>
>> Result: "pass"
>>
>> }
>>
>> }
>>
>> }
>>
>>
>> -Wei
>>
>>
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
