Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

Matthäus Wander <> Sun, 02 May 2021 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDFDD3A0D19 for <>; Sun, 2 May 2021 08:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K8zENAAP2i3F for <>; Sun, 2 May 2021 08:31:14 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:13b:2048::113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83CEA3A0D18 for <>; Sun, 2 May 2021 08:31:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=cathay; h=Subject:Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Sender:Reply-To: Cc:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1F3NKFS3s0tWyX4W2LIt8Da/TvcClFZqxpjOpjwBV7g=; b=ldCDJuRlAFOFGENQQtxDBORh1o OdhPwktxwIRpLbbjPl8cDwm24l/pzOE018ZKm0sE9uPRZ31xaWc2clcBKMMvnNHA7dTWDujVRPLdn kbXgUNS7lmiuYfB2XCd0q7I1Q3tiF+UyIzHKSPwQEZ7IOIj4HvjCYCRl0KB8x0O2jPejl0LoEsThH 7kvj+JGEkjhyZQgI/jUazITRBojshZNwSyoav7zsPr2iSV1bei980IczWnVpoSlGY8hzcKX1/qKnB euL8TyTSvXGgps0EWhO7rn08DGHkh+cyvdK2DL07vjsgZ4tGcJdJMH8Lgd37sdT2NJAox68s6lSgz GM/Xl6ag==;
Received: from ([2a01:c23:6843:f00:152b:ffd6:cc06:4e04]) by with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1ldE3q-0007NQ-MJ for; Sun, 02 May 2021 17:31:11 +0200
References: <> <> <> <>
From: =?UTF-8?Q?Matth=c3=a4us_Wander?= <>
Message-ID: <>
Date: Sun, 2 May 2021 17:31:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 2a01:c23:6843:f00:152b:ffd6:cc06:4e04
X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000)
X-SA-Exim-Scanned: Yes (on
Archived-At: <>
Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 May 2021 15:31:20 -0000

I see the following use cases for the envelope_to.

Case 1: Identify mail flows along forwarders.

With an increased adoption of DMARC reporting, we will be getting
reports like this:

Report from $ForwarderOrg:
HeaderFrom=$OriginDomain + EnvFrom=$OriginDomain --> $ForwarderOrg
Report from $RecipientOrg:
HeaderFrom=$OriginDomain + EnvFrom=$ForwarderDomain --> $RecipientOrg

envelope_to allows you to automatically correlate these reports and
reconstruct the forwarding path. This helps to identify the culprit who
is breaking DKIM signatures, especially with longer forwarding chains.
Without envelope_to, reconstructing the mail flow requires guessing and
manual work.

Case 2: Get information for tracing errors.

Let's say you find a DKIM or SPF error from RUA reports and would like
to investigate, because you expect a different outcome. Two real-life
examples I've experienced:

a) We suspect a bug in either our DKIM signer or the recipient's DKIM
verifier (inferred from recipient's RUA report).
b) We are convinced a forwarder breaks DKIM signatures (inferred from a
third-party destination's RUA report).

If one of the involved parties is willing to investigate further, they
ask for the timestamp, sender address and recipient address to trace
their logs. I understand that this is the use case for RUF reports to
shine. I'm arguing that RUA reports suffice, if they contain the day,
sender domain and recipient domain.

Todd Herr wrote on 2021-04-29 14:44:
> I believe all of those things are already possible with the aggregate
> report as it is now, with no need to list the recipient domains. For any
> set of X domains hosted at provider Y, I would expect DMARC validation
> results (i.e., pass or fail) to be consistent across all X domains at
> that provider.

In theory, yes.

In practice:
a) Some forwarders (including large infrastructures) show a wildly
inconsistent behavior with DKIM signatures, which at least to some
degree seems to depend on the recipient domain. If these forwarders
start reporting, I'd need the recipient domain to make sense of their
reports. See also Case 1 above.
b) Some recipients report sporadic SPF or DKIM permerrors for some
messages, while other messages validate correctly. This behavior
probably does not depend on the recipient domain, but see Case 2 above.