RFC 6651

Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting

📅 published June 2012, from ietf

RFC 6651: Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting 💌✨

okay bestie, this one is a Standards Track document from the IETF, so it's officially part of the Internet's protocol rulebook 👑 It was written by M. Kucherawy at Cloudmark, and it's dated June 2012. It's published under ISSN 2070-1721. The title block doesn't list any obsoletes or updates, so it isn't replacing or patching another RFC, it just stands on its own 🎀

Abstract 🦋

This document is all about extending the DomainKeys Identified Mail (DKIM) spec so you can get detailed reports when message authentication fails, and you can ask for them on demand 💅

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). More info on Internet Standards is in Section 2 of RFC 5741.

If you want the current status of this document, any errata, or a way to send feedback, check out http://www.rfc-editor.org/info/rfc6651.

Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document need to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License.

Table of Contents 🧚

1. Introduction ....................................................3
2. Definitions .....................................................3
   2.1. Key Words ..................................................3
   2.2. Notation ...................................................3
   2.3. Imported Definitions .......................................3
   2.4. Other Definitions ..........................................3
3. Optional Reporting for DKIM .....................................4
   3.1. Extension DKIM Signature Tag ...............................4
   3.2. DKIM Reporting TXT Record ..................................4
   3.3. DKIM Reporting Algorithm ...................................6
4. Optional Reporting Address for DKIM ADSP ........................8
5. Requested Reports ...............................................9
   5.1. Requested Reports for DKIM Failures .......................10
   5.2. Requested Reports for DKIM ADSP Failures ..................10
6. Report Generation ..............................................11
   6.1. Report Format .............................................11
   6.2. Other Guidance ............................................11
7. IANA Considerations ............................................11
   7.1. DKIM Signature Tag Registration ...........................11
   7.2. DKIM ADSP Tag Registration ................................12
   7.3. DKIM Reporting Tag Registry ...............................12
8. Security Considerations ........................................13
   8.1. Inherited Considerations ..................................13
   8.2. Report Volume .............................................13
   8.3. Deliberate Misuse .........................................13
   8.4. Unreported Fraud ..........................................14
9. References .....................................................14
   9.1. Normative References ......................................14
   9.2. Informative References ....................................15
Appendix A. Acknowledgements ......................................16
Appendix B. Examples ..............................................16
   B.1. Example Use of DKIM Signature Extension Tag ...............16
   B.2. Example DKIM Reporting TXT Record .........................17
   B.3. Example Use of DKIM ADSP Extension Tags ...................17

1. Introduction 🌸

okay so, DomainKeys Identified Mail [DKIM] brought in a way to sign and authenticate messages 🔐 It uses digital signing to tie a domain name to a message in a reliable way. Once that domain name is verified, you can do all sorts of things with it: check the sender policy that's been published, compare it against a known-good list, send it to a reputation service, and more 💖

Deployers of message authentication tech are increasingly hungry for visibility into two kinds of problems: DKIM verification failures, and conformance failures involving the published signing practices (like Author Domain Signing Practices [ADSP]) of an ADministrative Management Domain (ADMD; see [EMAIL-ARCH]) 👀

This document extends [DKIM] and [ADSP] so they can carry an optional reporting address plus some reporting parameters. The reports are generated using the format defined in [ARF-AUTHFAIL] ✨

2. Definitions 🎀

2.1. Key Words

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].

2.2. Notation

Certain properties of email messages described in this document are referenced using notation found in [EMAIL-ARCH] (for example, "RFC5322.From").

2.3. Imported Definitions

A bunch of DKIM-specific terms used here are defined in [DKIM]. The definitions of the [ABNF] tokens "domain-name" and "dkim-quoted-printable" live there too 📚

2.4. Other Definitions

report generator: A report generator is an entity that generates and sends reports. For the scope of this document, the term refers to Verifiers, as defined in Section 2.2 of [DKIM], with the added capability to generate authentication failure reports according to this specification 🧚

3. Optional Reporting for DKIM 💜

A domain name owner using [DKIM] for email signing and authentication might want to know when signatures that ought to be verifiable aren't verifying successfully. Right now, there's no mechanism defined for that 😭

This section adds optional "tags" (as defined in [DKIM]) to the DKIM-Signature header field and the DKIM key record in the DNS, using the formats defined in that specification 🌈

3.1. Extension DKIM Signature Tag

The following tag is added to DKIM-Signature header fields when a Signer wants to ask that reports of failed verifications be generated by a Verifier:

r= Reporting Requested (plain-text; OPTIONAL; no default). If present, this tag indicates that the Signer requests that Verifiers generate a report when verification of the DKIM signature fails. At present, the only legal value is the single character "y". A full description and illustration of how this gets applied can be found in Section 3.3 🦋

ABNF:

      sig-r-tag = %x72 *WSP "=" *WSP %x79
                ; "r=y" (lower-case only)

3.2. DKIM Reporting TXT Record

When a Signer wants to advertise that it wants to receive failed verification reports, it puts a TXT Resource Record (RR) in the DNS 📝 The RR holds a sequence of tag-value objects in a format similar to DKIM key records (see Section 3.6.1 of [DKIM]). It's entirely independent of those key records, though, and it lives at a different name. The tag-value objects here are the parameters used when generating the reports. A report generator will request the content of this record when it sees an "r=" tag in a DKIM-Signature header field 👀

Section 3.6.2.2 of [DKIM] gives guidance on handling a TXT RR made up of multiple distinct strings ("character-strings" in the parlance of [DNS]). The same process MUST be applied here 💅

Implementations MUST support all tags defined in this document. Any other tag found in the content of the record that an implementation doesn't recognize MUST be ignored. See Section 7.3 for details about finding or registering extension tags 🫶

The initial list of tags supported for the reporting TXT record is below ✨

ra= Reporting Address (plain-text; OPTIONAL). This is a dkim-quoted-printable string (see Section 2.11 of [DKIM]) containing the local-part of an email address that a report SHOULD be sent to when mail fails DKIM verification for one of the reasons enumerated below. The value MUST be interpreted as a local-part only. To build the actual address the report gets sent to, the Verifier just appends an "@" followed by the domain name found in the "d=" tag of the DKIM-Signature header field. So a Signer using this specification MUST ensure that an email address built this way can receive reports generated as described in Section 6 🎀

ABNF:

      rep-ra-tag = %x72.61 *WSP "=" *WSP dkim-quoted-printable
                 ; "ra=..." (lower-case only for the tag name)

rp= Requested Report Percentage (plain-text; OPTIONAL; default is "100"). The value is an integer from 0 to 100 inclusive, indicating what percentage of incidents of signature authentication failures, selected at random, are to cause reports to be generated. The report generator SHOULD NOT issue reports for more than the requested percentage of incidents. Report generators MAY make use of the "Incidents:" field in [ARF] to indicate that there are more reportable incidents than there are reports 📊

ABNF:

      rep-rp-tag = %x72.70 *WSP "=" *WSP 1*3DIGIT
                 ; "rp=..." (lower-case only)

rr= Requested Reports (plain-text; OPTIONAL; default is "all"). The value MUST be a colon-separated list of tokens representing the conditions under which a report is wanted. See Section 5.1 for a list of valid tokens 🧐

ABNF:

      rep-rr-type = ( "all" / "d" / "o" / "p" / "s" / "u" / "v" / "x" )
      rep-rr-tag = %x72.72 *WSP "=" *WSP rep-rr-type
                   *WSP *( ":" *WSP rep-rr-type )
                 ; "rr=..." (lower-case only for the tag name)

rs= Requested SMTP Error String (plain-text; OPTIONAL; no default). The value is a dkim-quoted-printable string that the publishing ADMD asks to be included in [SMTP] error strings if messages get rejected during the delivery SMTP session 💌

ABNF:

      rep-rs-tag = %x72.73 *WSP "=" dkim-quoted-printable
                 ; "rs=..." (lower-case only for the tag name)

Here's the big catch: without an "ra=" tag, the "rp=" and "rr=" tags MUST be ignored, and the report generator MUST NOT issue a report 🚫💀

3.3. DKIM Reporting Algorithm 🔥

okay bestie, report generators MUST apply the following algorithm (or one that's semantically equivalent to it 💅) for each DKIM-Signature header field whose verification fails for some reason. ngl this is only a reporting extension, so the outcome of the specified DKIM evaluation MUST be otherwise unaffected 🫶

  1. If the DKIM-Signature field did not contain a valid "r=" tag, terminate.
  2. Issue a [DNS] TXT query to the name you get by sticking the value of the "d=" tag from the DKIM-Signature field onto the end of "_report._domainkey.". For example, if the DKIM-Signature header field contains "d=example.com", issue a DNS TXT query to "_report._domainkey.example.com".
  3. If the DNS query returns anything other than RCODE 0 (NOERROR), or if multiple TXT records come back, terminate.
  4. If the resulting TXT is split into several string fragments, concatenate them as described in Section 3.6.2.2 of [DKIM].
  5. If the TXT content is syntactically invalid (see Section 3.2), terminate.
  6. If the reason for the signature evaluation failure doesn't match one of the report requests in the "rr=" tag (or its default value), terminate.
  7. If a report percentage ("rp=") tag was there, pick a random number between 0 and 99, inclusive. If the number you picked is not lower than the tag's value, terminate.
  8. If no "ra=" tag was present, skip this step and the next one. Otherwise, figure out the reporting address by taking the value of the "ra=" tag and adding an "@" plus the domain name from the "d=" tag of the DKIM-Signature header field.
  9. Build and send a report that follows Section 6 of this document, with the address you built in the previous step as its intended recipient.
  10. If the [SMTP] session where the DKIM signature was evaluated is still active, the SMTP server hasn't already replied to the DATA command that relayed the message, and an "rs=" tag was in the TXT record, the SMTP server SHOULD include the decoded string from the "rs=" tag in its SMTP reply to the DATA command.

so to stop report generators from getting turned into unwitting DoS attack participants 💀, a report generator SHOULD NOT send more than one report to any given domain from a single message. Also, a report generator SHOULD set an upper bound on how many reports one message can generate overall. For example, a message with three invalid signatures (two from example.com and one from example.net) would produce at most one report to each of those domains 🍓

this algorithm has some big advantages over earlier pre-standardization versions, like early versions of [OPENDKIM] 👑

  • a. If the DKIM signature fails to verify, there's no extra DNS check to see if reporting is requested. The request is still active because it's included in the DKIM-Signature header field. (Earlier versions put the reporting address in the DKIM key record, which doesn't get queried for certain failure cases. So for full reporting, the key record had to be fetched even when nothing else needed it. chaotic 😭)
  • b. The request gets confirmed by a matching TXT record in DNS, since the Signer is the one providing the parameters needed to build and send the report. That means a malicious Signer can't falsely claim someone else wants failure reports and spam them with unwanted mail 🙅‍♀️. It can cause extra DNS traffic against the domain in the "d=" signature tag, but negative caching of the requested DNS record will help with that.
  • c. A Signer can't direct reports to an email address outside its own domain, which blocks distributed email-based denial-of-service attacks 🛡️

see Section 8.4 for some considerations about the limitations of this mechanism 🔍

4. Optional Reporting Address for DKIM ADSP ✨

a domain name owner using Author Domain Signing Practices [ADSP] might also want to know when messages come in without valid author domain signatures. rn there's no mechanism defined for that 🥺

this section adds the following OPTIONAL "tags" (as defined in [ADSP]) to the DKIM ADSP records, using the form that specification defines:

ra= (Reporting Address, plain-text, OPTIONAL, no default) 💌: the value MUST be a dkim-quoted-printable string holding the local-part of an email address where a report SHOULD be sent when mail claiming to be from this domain fails the verification algorithm described in [ADSP]. That usually happens because a message showed up without a signature that validates, which contradicts what the ADSP record says. The value MUST be read as a local-part only. To build the actual address the report goes to, the Verifier just adds an "@" and then the domain whose policy was looked up to evaluate the sender's ADSP (the RFC5322.From domain of the message being evaluated). So a Signer using this extension tag MUST make sure the address built this way can receive reports generated as described in Section 6 🎀

adsp-ra-tag = %x72.61 *WSP "=" dkim-quoted-printable
            ; "ra=..." (lower-case only for the tag name)

rp= (Requested Report Percentage, plain-text, OPTIONAL, default is "100") 🌈: the value is a single integer from 0 to 100 inclusive, saying what percentage of ADSP evaluation failures (picked at random) should trigger reports. The report generator SHOULD NOT issue reports for more than the requested percentage of incidents. The one exception is some out-of-band arrangement between two parties to override it with a mutually agreed value. Report generators MAY use the "Incidents:" field in [ARF] to show that there are more reportable incidents than reports 💜

adsp-rp-tag = %x72.70 *WSP "=" *WSP 1*3DIGIT
            ; "rp=..." (lower-case only)

rr= (Requested Reports, plain-text, OPTIONAL, default is "all") 🧚: the value MUST be a colon-separated list of tokens for the conditions where a report is wanted. See Section 5.2 for the valid tokens 🫧

adsp-rr-type = ( "all" / "o" / "p" / "s" / "u" )
adsp-rr-tag = %x72.72 *WSP "=" *WSP adsp-rr-type
              *WSP *( ":" *WSP adsp-rr-type )
            ; "rr=..." (lower-case only for the tag name)

rs= (Requested SMTP Error String, plain-text, OPTIONAL, no default) 🍭: the value is a string the signing domain wants included in [SMTP] error strings when messages get rejected during a single SMTP session.

adsp-rs-tag = %x72.73 *WSP "=" dkim-quoted-printable
            ; "rs=..." (lower-case only for the tag name)

if there's no "ra=" tag, then the "rp=" and "rr=" tags MUST be ignored, and the report generator MUST NOT issue a report. no ra, no report, periodt 🙅‍♀️

5. Requested Reports 🎀

the "rr" tags above let a Signer say which kinds of errors it wants reports about. this section defines those error types and their token values 💅

Verifiers MUST NOT generate reports for incidents that don't match a requested report, and they MUST ignore requests for reports that aren't on this list.

5.1. Requested Reports for DKIM Failures

these are the report requests defined for DKIM keys:

  • all: All reports are requested.
  • d: Reports are requested for signature evaluation errors caused by DNS issues (for example, key retrieval problems).
  • o: Reports are requested for any reason related to DKIM signature evaluation that isn't covered by the other report requests listed here.
  • p: Reports are requested for signatures rejected for local policy reasons at the Verifier that relate to DKIM signature evaluation.
  • s: Reports are requested for signature or key syntax errors.
  • u: Reports are requested for signatures that include unknown tags in the signature field.
  • v: Reports are requested for signature verification failures or body hash mismatches.
  • x: Reports are requested for signatures the Verifier rejected because the expiration time has passed.

5.2. Requested Reports for DKIM ADSP Failures

these are the report requests defined for ADSP records:

  • all: All reports are requested.
  • o: Reports are requested for any [ADSP]-related failure reason not covered by the other report requests listed here.
  • p: Reports are requested for messages rejected for local policy reasons at the Verifier that relate to [ADSP].
  • s: Reports are requested for messages that have a valid [DKIM] signature but don't match the published [ADSP] policy.
  • u: Reports are requested for messages that have no valid [DKIM] signature and don't match the published [ADSP] policy.

6. Report Generation 🦋

this section covers how reports get generated and sent, following what the Signer and/or sender asked for above 🫶

6.1. Report Format

all reports made from requests in these extension parameters MUST be generated in compliance with [ARF] and its extension for this work, [ARF-AUTHFAIL]. Also, abuse reports from unverified sources might get side-eyed, so report generators are strongly advised to use [DKIM] to sign the reports they make 🔏

6.2. Other Guidance

more guidance on generating these reports is in [ARF-AS], especially Section 6 📚

7. IANA Considerations 👑

as [IANA-CONS] requires, this section has the registry info for the new [DKIM] signature tags and the new [ADSP] tags. It also creates a DKIM reporting tag registry 🗂️

7.1. DKIM Signature Tag Registration

IANA added the following item to the DKIM Signature Tag Specifications registry:

+------+-----------------+--------+
| TYPE | REFERENCE       | STATUS |
+------+-----------------+--------+
| r    | (this document) | active |
+------+-----------------+--------+

7.2. DKIM ADSP Tag Registration

IANA added the following items to the DKIM ADSP Specification Tags registry:

+------+-----------------+
| TYPE | REFERENCE       |
+------+-----------------+
| ra   | (this document) |
| rp   | (this document) |
| rr   | (this document) |
| rs   | (this document) |
+------+-----------------+

7.3. DKIM Reporting Tag Registry 📋

okay so IANA made a brand new sub-registry under the DKIM Parameters registry, and it's called "DKIM Reporting Tag Registry" 🎀 New entries follow the "Specification Required" rules, and every registration needs these columns:

  • Tag: the name of the tag used in reporting records
  • Reference: the document that specifies the tag being defined
  • Status: the status of the tag's current use, either "active" (in active use) or "historic" (discontinued or deprecated use)

the starter entries look like this 👇

             +-----+-----------------+--------+
             | TAG | REFERENCE       | STATUS |
             +-----+-----------------+--------+
             | ra  | (this document) | active |
             | rp  | (this document) | active |
             | rr  | (this document) | active |
             | rs  | (this document) | active |
             +-----+-----------------+--------+

8. Security Considerations 🙈

bestie, the security side of this is giving serious "handle with care" energy 😭 The security issues with these reports are pretty similar to the ones found in [DSN], so go read that too 🦋

8.1. Inherited Considerations 🌸

implementers are advised to look at the Security Considerations sections of [DKIM], [ADSP], [ARF-AS], and [ARF-AUTHFAIL] 🫶 A lot of the security stuff for this document is already covered in those, so you're not starting from zero, babe ✨

8.2. Report Volume 🌊

ngl, nobody can predict how many reports this facility is going to spit out once a receiver turns it on 💀 An implementer ought to plan for a substantial volume, because how much abuse happens at receivers can't be known ahead of time, and it can change super fast and in unpredictable ways 📈

8.3. Deliberate Misuse 😈

some threats from people deliberately misusing this error-reporting mechanism are covered in Section 3.3, but they're serious enough that they need more talk here too 🔥

the DNS record that says "yes, I'll accept reports" opens the recipient up to abuse. Basically, an attacker could try to cause a flood of reports toward the domain in a signature's d= tag in one of these ways:

  1. Alter existing DKIM-Signature header fields by adding an r=y tag (and possibly altering the d= tag to point at the target domain);
  2. Add a new but bogus signature bearing an r=y tag and a d= tag pointing at the target domain;
  3. Generate a completely new message bearing an r=y tag and a d= tag pointing at the target domain.

picture this 😭 an attacker sends out a multi-million-message spam run, and every message has a fake DKIM signature with d=example.com; r=y. It doesn't even matter that those signatures could never be real. Each one fails verification, and any implementations that support this specification will report those failures, in the millions and super fast, to example.com. Main character villain behavior, honestly 💀

so implementers are strongly advised not to advertise the DNS record specified in this document unless failure reports are actually wanted 🙅‍♀️ If they do advertise it, unexpected traffic volumes and attacks should be anticipated.

negative caching helps a little with this pattern of abuse 🧚 but only for as long as the negative time-to-live on the relevant SOA record in the DNS. Positive caching of this DNS reply also means that turning off the flow of reports by removing the record isn't likely to have an immediate effect, so a low time-to-live on the record needs to be considered 💜

8.4. Unreported Fraud 🕵️‍♀️

an attacker can craft fraudulent DKIM-Signature fields on messages without using r= tags, and then dodge being reported entirely 😤 The procedure described in Section 3.3 doesn't let anyone detect and report those cases.

it might be useful for some Signers to get reports like that, but the mechanism just doesn't support it. To offer that support, a Verifier would have to violate the first step in the procedure and keep going even when there's no r= tag. That would enable the report people want, but it would also open the door to a denial-of-service attack 🚨 Those Verifiers would always go look for the reporting TXT record, so a fraudulent message generator could just send a large volume of messages without an r= tag to a bunch of destinations. To avoid that outcome, reports of fraudulent DKIM-Signature header fields are not possible using the published mechanism 🔒

9. References 📚

9.1. Normative References 💖

  • [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008.
  • [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
  • [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
  • [ARF-AS] Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", RFC 6650, June 2012.
  • [ARF-AUTHFAIL] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, April 2012.
  • [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
  • [DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
  • [IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

9.2. Informative References 🧠

  • [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
  • [OPENDKIM] Kucherawy, M., "OpenDKIM -- Open Source DKIM Library and Filter", August 2009, <http://www.opendkim.org>.

Appendix A. Acknowledgements 🫶

the author wanted to thank the following people for reviewing this proposal and giving constructive criticism: Steve Atkins, Monica Chew, Dave Crocker, Tim Draegen, Frank Ellermann, J.D. Falk, John Levine, Scott Kitterman, and Andrew Sullivan 💜

Appendix B. Examples 🍓

this section has examples of each of the extensions defined by this document, so let's look at them together 👀

B.1. Example Use of DKIM Signature Extension Tag ✨

this example shows a DKIM-Signature field using the extension tag defined by this document:

    DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
            d=example.com; s=jan2012; r=y;
            h=from:to:subject:date:message-id;
            bh=YJAYwiNdc3wMh6TD8FjVhtmxaHYHo7Z/06kHQYvQ4tQ=;
            b=jHF3tpgqr6nH/icHKIqFK2IJPtCLF0CRJaz2Hj1Y8yNwTJ
              IMYIZtLccho3ymGF2GYqvTl2nP/cn4dH+55rH5pqkWNnuJ
              R9z54CFcanoKKcl9wOZzK9i5KxM0DTzfs0r8

Example 1: DKIM-Signature Field Using This Extension

this DKIM-Signature field has the r= tag, which means reports are requested on verification failure 🚩

say the public key pulled from DNS and processed according to [DKIM] shows the signature is invalid. Then a TXT query gets sent to _report._domainkey.example.com to grab a reporting address and other report parameters, as described in Section 3.3 📬

B.2. Example DKIM Reporting TXT Record 💌

here's an example DKIM Reporting TXT record as defined by this document:

    ra=dkim-errors; rp=100; rr=v:x

Example 2: Example DKIM Reporting TXT Record

this one picks up right where the last example left off 🎀 It's a message that might be found at _report._domainkey.example.com in a TXT record, and it makes these requests:

  • Reports about signature evaluation failures should be sent to the address "dkim-errors" at the Signer's domain;
  • All incidents (100%) should be reported;
  • Only reports about signature verification failures and expired signatures should be generated.

B.3. Example Use of DKIM ADSP Extension Tags 🧚

this example shows a DKIM ADSP record using the extensions defined by this document:

    dkim=all; ra=dkim-adsp-errors; rr=u

Example 3: DKIM ADSP Record Using These Extensions

this ADSP record makes the following assertions 🫧

  • The sending domain (i.e., the one advertising this policy) signs all mail it sends;
  • Reports about ADSP evaluation failures should be sent to the address "dkim-adsp-errors" at the Author's domain;
  • Only reports about unsigned messages should be generated.

Author's Address 💅

   Murray S. Kucherawy
   Cloudmark
   128 King St., 2nd Floor
   San Francisco, CA  94107
   US

   Phone: +1 415 946 3800
   EMail: superuser@gmail.com

and that's the whole spec, bestie! 🌈✨💖

📦 where this page comes from