RFC 9991

Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting

📅 published May 2026, from ietf

Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting ✨

  • Internet Engineering Task Force (IETF) 🌸
  • Request for Comments: 9991 💖
  • Authors: S. Jones, Ed. (DMARC.org) and A. Vesely, Ed. (Tana) 👑
  • Obsoletes: RFC 7489
  • Updates: RFC 6591
  • Category: Standards Track 🦋
  • Date: May 2026 📅
  • ISSN: 2070-1721

Abstract 🎀

Okay so DMARC (Domain-based Message Authentication, Reporting, and Conformance) lets a Domain Owner ask for feedback about emails that use their domain in the From: address field 💌. This doc is all about "failure reports" (also called "failed message reports"), which give you the deets on individual messages that didn't pass DMARC authentication 🔍.

This doc updates RFC 6591 and obsoletes RFC 7489 🫶

Status of This Memo 📋

This is an Internet Standards Track document ✨

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further info on Internet Standards is in Section 2 of RFC 7841 📚

Info about the current status of this document, any errata, and how to give feedback on it can be found at https://www.rfc-editor.org/info/rfc9991 🔗

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date this document is published. Please read these carefully, because they spell out your rights and restrictions for this document 🧾. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License ⚖️.

1. Introduction ✨

Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC9989] is how a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting. A mail-receiving organization can use those to handle mail better 📬. This doc focuses on one type of reporting that can be requested under DMARC 💅.

Failure reports give detailed info about why a single message failed, or a group of similar messages that failed for the same reason 🔍. They have two jobs. First, they help when a Domain Owner wants to figure out why failures showed up in aggregate reports (see [RFC9990]) 📊. Second, they let the Domain Owner quickly spot and deal with harmful messages involving direct domain abuse 🚨.

Here's the tea: these reports can contain header fields, or sometimes the entire content of a failed message, which may include Personally Identifiable Information (PII) 🙈. So think about possible PII disclosure before you request failure reports as a Domain Owner, before you decide what to include or redact as a Mail Receiver, or before you decide whether to create failure reports at all. Section 7 has more on privacy considerations 🔐.

1.1. Terminology

There are a bunch of terms defined in Section 3.2 of [RFC9989] that this doc uses. Reading those definitions will make this doc way easier to follow 🧠.

The format of DMARC failure reports comes from "Authentication Failure Reporting Using the Abuse Reporting Format" [RFC6591], and the terms defined there are used here too 🎀.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📏.

1.2. Document Status

This document, partly along with [RFC9989] and [RFC9990], obsoletes and replaces [RFC7489] 🦋.

2. DMARC Failure Reports 💌

Besides the header fields or the entire contents of a failed message, failure reports share details about transmission and DMARC authentication. That can help a Domain Owner figure out what caused an authentication failure 🕵️‍♀️.

Failure reports are usually generated and sent almost right after the Mail Receiver detects a DMARC failure ⚡. Instead of waiting for an aggregate report, these are useful for quickly telling Domain Owners about an authentication failure 🚀. They also give more info about the failed message than an aggregate report does. That lets the failure report consumer better tell whether the message was one the Domain Owner meant to authenticate, or one where use of its domain wasn't authorized 👀.

These reports should include as much of the message header fields and body as possible, as long as it fits the reporting party's privacy policies. The goal is to help the Domain Owner diagnose the authentication failure 🩺.

When a Domain Owner asks for failure reports for forensic analysis, and the Mail Receiver is willing to provide them, the Mail Receiver generates and sends a message in the format described in [RFC6591]. This document updates that reporting format, as described in Section 4 💖.

The destination(s) where failure reports go, and the options for when they get sent, are defined by the ruf and fo tags, as provided in Section 4.7 of [RFC9989] 🎯.

When multiple Uniform Resource Identifiers (URIs) are given to receive failure reports, the report generator MUST make an attempt to deliver to each of them. External destinations MUST be verified (see Section 5). Report generators MUST NOT consider ruf tags in DMARC Policy Records that have a psd=y tag, unless there are specific agreements between the interested parties 🚫.

Report generators MUST implement a rate-limit on outgoing reports, so they don't flood Report Consumers with excessive reports. Flooding could allow a denial of service (see Section 8.1) 🌊.

3. Other Failure Reports 🧚

This doc only describes DMARC failure reports. DomainKeys Identified Mail (DKIM) failure reports and Sender Policy Framework (SPF) failure reports are described in [RFC6591] 📨. A Mail Receiver that generates DMARC failure reports MAY choose to issue failure reports of the type specific to the authentication mechanism that failed, instead of or in addition to the DMARC failure report type described here 🌈. The Receiver SHALL determine which failure report types, if any, to send based on its own policy, the failure in question, and the content of the fo tag in the retrieved DMARC Policy Record 🧐.

DKIM failure reports and SPF failure reports can also be requested using the methods described in [RFC6651] and [RFC6652], respectively. Report generators are free to follow any of the specifications 🫶.

4. Reporting Format Update ✨

Operators implementing this specification also implement an augmented version of the failure reporting described in [RFC6591], as follows 🦋:

  1. A DMARC failure report includes the following Abuse Reporting Format (ARF) header fields, with the indicated normative requirement levels:
    • Identity-Alignment (REQUIRED; defined below)
    • Delivery-Result (OPTIONAL)
    • DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED for DKIM failures of an aligned identifier)
    • DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL if reporting a DKIM failure)
    • SPF-DNS (REQUIRED for SPF failure of an aligned identifier)
  2. The Identity-Alignment field is defined to hold a comma-separated list of authentication mechanism names that failed to authenticate an aligned identity. Or it holds the keyword "none" if all of the attempted methods successfully authenticated an aligned identity 🎯. Here's the ABNF [RFC5234] (importing comments and/or folding white space (CFWS) from [RFC5322]) 📜:
      id-align     = "Identity-Alignment:" [CFWS]
                       ( "none" /
                         dmarc-method
                           *( [CFWS] "," [CFWS] dmarc-method ) )
                       [CFWS]

      dmarc-method = ( "dkim" / "spf" )
                       ; each may appear at most once in an id-align
  1. The Authentication Failure Type "dmarc" is defined for the Auth-Failure field 🏷️. It's used when a failure report is generated because some or all of the authentication mechanisms failed to produce aligned identifiers. A failure report generator MAY also independently produce an ARF message for any or all of the underlying authentication methods 💜.

5. Verifying External Destinations 🔍

It's possible to specify destinations for failure reports that are outside the Organizational Domain of the DMARC Policy Record that asked for the reports. These are commonly called "external destinations". They might be a different domain controlled by the same organization, a contracted report processing service, or some other arrangement 🌸.

For external destinations, a Mail Receiver who generates failure reports MUST use the Verifying External Destinations procedure described in Section 4 of [RFC9990], swapping the ruf tag in wherever the rua tag appears in that procedure 🔐.

This stops a bad actor from publishing a DMARC Policy Record that requests failure reports to an external destination, then deliberately sending messages that generate failure reports as a form of abuse 😈. It also stops a Domain Owner from unilaterally publishing a DMARC Policy Record with an external destination for failure reports. That would force the external destination to deal with unwanted messages and potential privacy issues 🙅‍♀️.

5.1. Transport 🚚

Email streams carrying DMARC failure reports SHOULD be DMARC-aligned 💅.

We recommend that reporters set a reasonable rate-limit for the number of failure reports sent to any recipient, so they don't overload recipient systems 🫶. Unaligned reports may in turn produce subsequent failure reports, which could cause mail loops 🔁.

6. IANA Considerations 🌈

Part 2 picks up right here 💖

6.1. Feedback Report Header Fields Registry Update ✨

okay so IANA gave the "Identity-Alignment" entry in the "Feedback Report Header Fields" registry a little glow-up 💅 Here's the updated entry, and yes, it's giving reference to RFC 9991 now 🎀

Field Name:  Identity-Alignment
Description:  a list of authentication mechanism names that failed to
   authenticate an aligned identity, or "none" if all were successful
Multiple Appearances:  No
Related "Feedback-Type":  auth-failure
Reference:  RFC 9991
Status:  current

7. Privacy Considerations 🔐

bestie, this section is SERIOUS 😭 Generating and sending DMARC failure reports brings up some major privacy concerns, and you need to think them through before you turn anything on.

Because of all that, lots of big providers limit failure reports or switch them off completely. They'd rather use aggregate reports, which give you the big-picture stats without exposing the actual sensitive stuff 📊 If an operator does decide to turn on failure reporting, they're strongly encouraged to:

  • Limit the scope and duration of use to targeted diagnostic activities;
  • Ensure that reporting URIs are carefully controlled and validated;
  • Apply minimization techniques, such as redaction of message bodies and header fields, to reduce sensitive data exposure;
  • Always transmit reports over secure channels.

tl;dr: failure reports can be genuinely useful for diagnosing stuff 🔍 but the privacy risks have made lots of operators restrict them. Aggregate reports are still the recommended way to see authentication results while keeping end-user communications private 🌸

Some specific privacy issues are broken down below 👇

7.1. Data Exposure Considerations 🕵️‍♀️

okay this part is a lot 😭 Failure reports can include PII and non-public information (NPI) from messages that failed to authenticate, because they might contain the message content plus trace header fields. They can reveal sender and recipient identifiers (for example, RFC5322.From addresses). The [RFC5965] format used for failed-message reporting does support redaction [RFC6590], but failed-message reporting can still expose the entire message to the Report Consumer 💀 That can also leak PII, sensitive business data, or confidential conversations to people who were never supposed to see them. The risks are real for both senders and receivers: think product launches, termination notices for employees, or calendar data. Even stuff that seems harmless, like a malformed or "broken" calendar invite, can end up leaking private communications 🙈

Domain Owners who request reports get info about mail sent using their domain, even mail they didn't actually cause to be sent. That can be valuable for spotting content used in abusive messages 👀 but it can also expose PII or NPI from legitimate messages that accidentally failed authentication.

Failure reports can also reveal where mail ended up when intermediate systems would otherwise hide that. A commonly cited example is a mailing list: when one member posts to the list, failure reports can be generated as the message gets delivered to the other members, exposing those members 📬 Those reports go to the Domain Owner of the member who posted, or to their delegated Report Consumer(s).

And when message forwarding is in play, Domain Owners who request reports may hear about mail forwarded to domains that weren't in the original recipient list. So destinations the Domain Owner didn't know about could suddenly become visible 🧚

7.2. Report Recipients 📨

A DMARC Policy Record can say that reports should go to a Report Consumer working on behalf of the Domain Owner. That might happen when the Domain Owner sends reports to a company that monitors mail streams for deliverability, performance problems, or abuse 📈 Whether third parties are allowed to receive that data may depend on the Mail Receiver's privacy policy, terms of use, and so on. Both Domain Owners and Mail Receivers should review and understand whether their own internal policies limit how DMARC reporting can be used and sent 🧐

There's also potential for Report Consumers to do traffic analysis, which could reveal metadata about the Mail Receiver's traffic 👁️ Besides checking compliance with policies, Mail Receivers need to think about that before sending reports to a third party. On the flip side, a Domain Owner might publish a destination address that looks like an Internal Report Consumer but is actually a forwarding address. In that case, the final destination of a report isn't guaranteed 🌀

7.3. Additional Damage 💥

Failure reports come with extra risk because of volume and content distribution concerns 😩 Partially or unredacted reports can spread lots of spam, phishing, or malware content, and Report Consumers or other recipients may need special handling to avoid incidents. That's why it's so important not to misconfigure the destinations in the ruf reporting URIs, and to follow the redaction suggestions in this document, for example using the method described in [RFC6590]. All of these concerns get even bigger for high-volume domains 📈 To help with that, the following steps should be considered:

By report generators:

  • Help prevent accidental access to potentially malicious URIs by substituting hxxp for http;
  • Remove attachments that could embed malicious payload.

By report consumers:

  • Isolate report streams from other mail streams;
  • Use sandboxes in evaluating failure reports;
  • Use network segmentation;
  • Limit access to failure reports to authorized individuals with appropriate security training.

8. Security Considerations 🛡️

okay bestie, security is a full-on main character moment here 💀 While you're going through this document and its security considerations, you also need to review the privacy considerations above, plus the privacy and security considerations in Sections 10 and 11 of [RFC9989] and in Sections 7 and 8 of [RFC9990]. No skipping!! 🙅‍♀️

8.1. Denial of Service 🚨

Failure reports can be abused for a denial-of-service attack 😱 Here's how it goes: an attacker sends tons of messages that pretend to be from the intended victim Domain Owner but fail both SPF and DKIM. That makes participating Mail Receivers send failure reports to the Domain Owner or its delegate(s), and it could be a LOT of them. So participating Mail Receivers are encouraged to aggregate these reports as much as is practical, using the Incidents field of the ARF [RFC5965] 🧠 The goal isn't to count every single failure. It's to report different failure conditions ✨ There are a few pruning techniques, including:

  • Store reports for a period of time before sending them, allowing detection, collection, and consolidation of like incidents;
  • Apply rate-limiting, such as a maximum number of reports per minute that will be generated (and the remainder discarded).

9. References 📚

9.1. Normative References 🔗

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.

[RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, DOI 10.17487/RFC5965, August 2010, <https://www.rfc-editor.org/info/rfc5965>.

[RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of Potentially Sensitive Data from Mail Abuse Reports", RFC 6590, DOI 10.17487/RFC6590, April 2012, <https://www.rfc-editor.org/info/rfc6590>.

[RFC6591] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591, April 2012, <https://www.rfc-editor.org/info/rfc6591>.

[RFC6692] Clayton, R. and M. Kucherawy, "Source Ports in Abuse Reporting Format (ARF) Reports", RFC 6692, DOI 10.17487/RFC6692, July 2012, <https://www.rfc-editor.org/info/rfc6692>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9989] Herr, T., Ed. and J. Levine, Ed., "Domain-Based Message Authentication, Reporting, and Conformance (DMARC)", RFC 9989, DOI 10.17487/RFC9989, May 2026, <https://www.rfc-editor.org/info/rfc9989>.

[RFC9990] Brotman, A., Ed., "Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting", RFC 9990, DOI 10.17487/RFC9990, May 2026, <https://www.rfc-editor.org/info/rfc9990>.

9.2. Informative References 💡

[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting", RFC 6651, DOI 10.17487/RFC6651, June 2012, <https://www.rfc-editor.org/info/rfc6651>.

[RFC6652] Kitterman, S., "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652, DOI 10.17487/RFC6652, June 2012, <https://www.rfc-editor.org/info/rfc6652>.

[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.

Appendix A. Example Failure Report 🧚

okay bestie, here's the full sample failure message, header and all 💌 It's the whole thing, so you can see exactly how every piece sits together ✨

Received: from gen.example (gen.example [192.0.2.1])
  (TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
  by mail.consumer.example with ESMTPS
  id 00000000005DC0DD.0000442E; Tue, 19 Jul 2022 07:57:50 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=gen.example; s=mail; t=1658210268;
  bh=rCrh1aFDE8d/Fltt8wbcu48bLOu4OM23QXqphUZPAIM=;
  h=From:To:Date:Subject:From;
  b=IND9JkuwF9/5841kzxMbPeej0VYimVzNKozR2R89M8eYO2zOlCBblx507Gz0YK7mE
   /h6pslWm0ODBVFzLlwY9CXv4Vu62QsN0RBIXHPjEXOkoM2VCD5zCd+5i5dtCFX7Mxh
   LThb2ZJ3efklbSB9RQRwxcmRvCPV7z6lt/Ds9sucVE1RDODYHjx+iWnAUQrlos6ZQb
   u/YOUGjf60LPpyljfPu3EpFwo80mSHyQlP/4S5KEykgPQMgCqLPPKvJwu1aAIDj+jG
   q2ylO3fmc/ERDeDWACtR67YNabEKBWtjqCRLNxKttazViJTZ5drcLfpX0853KoougX
   Rltp7zdoLdy4A==
From: DMARC Filter <DMARC@gen.example>;
To: dmarcfail@consumer.example
Date: Tue, 19 Jul 2022 00:57:48 -0500 (CDT)
Subject: FW: This is the original subject
Mime-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
  boundary="=_mime_boundary_"
Message-Id: <20220719055748.4AE9D403CC@gen.example>;

This is a MIME-formatted message.  If you see this text it means that
your E-mail software does not support MIME-formatted messages.

--=_mime_boundary_
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

This is an authentication failure report for an email message
received from IP 192.0.2.2 on Tue, 19 Jul 2022 00:57:48 -0500.

--=_mime_boundary_
Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit

Feedback-Type: auth-failure
Version: 1
User-Agent: DMARC-Filter/1.2.3
Auth-Failure: dmarc
Authentication-Results: gen.example;
  dmarc=fail header.from=consumer.example
Identity-Alignment: dkim
DKIM-Domain: consumer.example
DKIM-Identity: @consumer.example
DKIM-Selector: epsilon
Original-Envelope-Id: 65E1A3F0A0
Original-Mail-From: author=gen.example@forwarder.example
Source-IP: 192.0.2.2
Source-Port: 12345
Reported-Domain: consumer.example

--=_mime_boundary_
Content-Type: message/rfc822; charset=utf-8
Content-Transfer-Encoding: 7bit

Authentication-Results: gen.example;
  dkim=permerror header.d=forwarder.example header.b="EjCbN/c3";
  dkim=temperror header.d=forwarder.example header.b="mQ8GEWPc";
  dkim=permerror header.d=consumer.example header.b="hETrymCb";
  dkim=neutral header.d=consumer.example header.b="C2nsAp3A";
Received: from mail.forwarder.example
  (mail.forwarder.example [IPv6:2001:db8::23ac])
  by mail.gen.example (Postfix) with ESMTP id 5E8B0C159826
  for <x@gen.example>; Sun, 14 Aug 2022 07:58:29 -0700 (PDT)
Received: from mail.forwarder.example (localhost [127.0.0.1])
  by mail.forwarder.example (Postfix) with ESMTP id 4Ln7Qw4fnvz6Bq
  for <x@gen.example>; Tue, 19 Jul 2022 07:57:44 +0200
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed;
  d=forwarder.example; s=ed25519-59hs; t=1658210264;
  x=1663210264; bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=;
  h=Message-ID:Date:List-Id:List-Archive:List-Post:List-Help:
   List-Subscribe:List-Unsubscribe:List-Owner:MIME-Version:Subject:
   To:References:From:In-Reply-To:Content-Type:
   Content-Transfer-Encoding:autocrypt:cc:content-transfer-encoding:
   content-type:date:from:in-reply-to:message-id:mime-version:
   openpgp:references:subject:to;
  b=EjCbN/c3bTU4QkZH/zwTbYxBDp0k8kpmWSXh5h1M7T8J4vtRo+hvafJazT3ZRgq+7
   +4dzEQwUhl+NOJYXXNUAA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=forwarder.example; s=rsa-wgJg; t=1658210264; x=1663210264;
  bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=;
  h=Message-ID:Date:List-Id:List-Archive:List-Post:List-Help:
   List-Subscribe:List-Unsubscribe:List-Owner:MIME-Version:Subject:
   To:References:From:In-Reply-To:Content-Type:
   Content-Transfer-Encoding:autocrypt:cc:content-transfer-encoding:
   content-type:date:from:in-reply-to:message-id:mime-version:
   openpgp:references:subject:to;
  b=mQ8GEWPcVpBpeqQ88pcbXpGHBT0J/Rwi8Zd2WZTXWWneQGRCOJLRcbBJpjqnrwtqd
   76IqawH86tihz4Z/12J1GBCdNx1gfazsoI3yaqfooRDYg0mSyZHrYhQBmodnPcqZj4
   /25L5278sc/UNrYO9az2n7R/skbVZ0bvSo2eEiGU8fcpO8+a5SKNYskhaviAI4eGIB
   iRMdEP7gP8dESdnZguNbY5HI32UMDpPPNqajzd/BgcqbveYpRrWCDOhcY47POV7GHM
   i/KLHiZXtJsL3/Pr/4TL+HTjdX8EDSsy1K5/JCvJCFsJHnSvkEaJQGLn/2m03eW9r8
   9w1bQ90aY+VCQ==
X-Original-To: users@forwarder.example
Received: from mail.consumer.example
  (mail.consumer.example [192.0.2.4])
  (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
   key-exchange ECDHE (P-256) server-signature ECDSA (P-384)
   server-digest SHA384)
  (Client did not present a certificate)
  by mail.forwarder.example (Postfix) with ESMTPS id 4Ln7Qs55xmz4nP
  for <users@forwarder.example>;
  Tue, 19 Jul 2022 07:57:41 +0200 (CEST)
Authentication-Results: mail.forwarder.example;
  arc=none smtp.remote-ip=192.0.2.4
Authentication-Results: mail.forwarder.example;
  dkim=pass (512-bit key; secure) header.d=consumer.example
   header.i=@consumer.example header.a=ed25519-sha256
   header.s=epsilon header.b=hETrymCb;
  dkim=pass (1152-bit key; secure) header.d=consumer.example
   header.i=@consumer.example header.a=rsa-sha256
   header.s=delta header.b=C2nsAp3A
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed;
  d=consumer.example; s=epsilon; t=1658210255;
  bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=;
  h=Date:Subject:To:References:From:In-Reply-To;
  b=hETrymCbz6T1Dyo5dCG9dk8rPykKLdhJCPFeJ9TiiP/kaoN2afpUYtj+SrI+I83lp
   p1F/FfYSGy7zz3Q3OdxBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=consumer.example; s=delta; t=1658210255;
  bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=;
  h=Date:To:References:From:In-Reply-To;
  b=C2nsAp3AMNX33Nq7nN/StPo921xE3XGF8Ju3iAKdYB3EKhsril0N5IjWGlglJECst
   jLNKSo7KWZZ2lkH/dVZ9Rs1GHT2uaKy1sc/xmNIC5rHdhrxammiwpTSo4PsT8disfc
   3DVF6Q62n0EsdLFqcw1KY8A9inFqYKY2tqoo+y4zMtItqCYx3xjsj3I0IFLuX
Author: Message Author <author@consumer.example>
Received: from [192.0.2.8] (host-8-2-0-192.isp.example [192.0.2.8])
  (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3,128bits,
  ECDHE_RSA_AES_128_GCM_SHA256)
  by mail.consumer.example with ESMTPSA
  id 00000000005DC076.00004417; Tue, 19 Jul 2022 07:57:35 +0200
Message-ID: <2431dc66-b010-c9cc-4f2b-a1f889f8bdb4@consumer.example>
Date: Tue, 19 Jul 2022 07:57:33 +0200
List-Id: <users.forwarder.example>
List-Post: <mailto:users@forwarder.example>
List-Help: <mailto:users+help@forwarder.example>
List-Subscribe: <mailto:users+subscribe@forwarder.example>
List-Unsubscribe: <mailto:users+unsubscribe@forwarder.example>
List-Owner: <mailto:users+owner@forwarder.example>
Precedence: list
MIME-Version: 1.0
Subject: This is the original subject
Content-Language: en-US
To: users@forwarder.example
Authentication-Results: consumer.example; auth=pass (details omitted)
From: Message Author <author@consumer.example>
In-Reply-To: <20220718102753.0f6d9dde.cel@example.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

[ Message body was here ]
--=_mime_boundary_--

The Source-Port field definition is given by [RFC6692] 📚

In the final MIME entity, the local-parts of To and From addresses are reported unredacted 👀 Since we know that the local parts are PII, we can reduce the privacy risk by redacting them 🔒 In the example, the report generator could have replaced "users" with lRLxexey and "author" with RT47aVey throughout the entity 🫶

If the body of the message is not included, the last MIME entity would have Content-Type: text/rfc822-headers instead of message/rfc822 🦋

Authors' Addresses 🌸

Steven M. Jones (editor)

DMARC.org

Email: smj@dmarc.org

Alessandro Vesely (editor)

Tana

Email: vesely@tana.it

📦 where this page comes from