RFC 5585

DomainKeys Identified Mail (DKIM) Service Overview 💌

okay bestie, this is RFC 5585 🎀 It came out in July 2009 from the Network Working Group, and it's marked as Informational, so it's sharing info with the Internet community rather than setting a standard ✨ The authors are T. Hansen (AT&T Laboratories), D. Crocker (Brandenburg InternetWorking), and P. Hallam-Baker (Default Deny Security, Inc.) 🫶 The title block doesn't list any RFC that this one obsoletes or updates, so it's a standalone doc 🌸

Abstract 📝

okay so this doc is the big-picture tour of DomainKeys Identified Mail (DKIM) service and how it slots into a messaging service 💅 It also explains how DKIM vibes with other IETF message signature technologies ✨ It's for anyone adopting, developing, or deploying DKIM. DKIM lets an organization take responsibility for transmitting a message in a way a recipient can verify 🫶 That organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can carry multiple signatures from the same or different organizations involved with it. DKIM defines a domain-level digital signature authentication framework for email, using public-key cryptography, with the domain name service as its key server technology (RFC 4871). This lets you verify a responsible organization AND the integrity of the message contents 🔐 DKIM also enables a mechanism that lets potential email signers publish info about their email signing practices, which lets email receivers make additional assessments about messages 👀 And DKIM's authentication of email identity can help with the global control of "spam" and "phishing" 🙅‍♀️

Status of This Memo 📚

this memo is here to provide information for the Internet community 💜 It does not specify an Internet standard of any kind, so no, this isn't a standard, bestie 🙅 Distribution of this memo is unlimited 🌍

Copyright Notice ⚖️

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, because they describe your rights and restrictions with respect to this document 📖

Table of Contents 📑

1. Introduction ....................................................3
   1.1. DKIM's Scope ...............................................4
   1.2. Prior Work .................................................5
   1.3. Internet Mail Background ...................................6
2. The DKIM Value Proposition ......................................6
   2.1. Identity Verification ......................................7
   2.2. Enabling Trust Assessments .................................7
   2.3. Establishing Message Validity ..............................8
3. DKIM Goals ......................................................8
   3.1. Functional Goals ...........................................9
   3.2. Operational Goals .........................................10
4. DKIM Function ..................................................12
   4.1. Basic Signing .............................................12
   4.2. Characteristics of a DKIM Signature .......................12
   4.3. The Selector Construct ....................................13
   4.4. Verification ..............................................13
   4.5. Sub-Domain Assessment .....................................13
5. Service Architecture ...........................................14
   5.1. Administration and Maintenance ............................15
   5.2. Signing ...................................................16
   5.3. Verifying .................................................16
   5.4. Unverified or Unsigned Mail ...............................16
   5.5. Assessing .................................................17
   5.6. DKIM Processing within an ADMD ............................17
6. Considerations .................................................17
   6.1. Security Considerations ...................................17
   6.2. Acknowledgements ..........................................17
7. Informative References .........................................18
Appendix A.  Internet Mail Background .............................20
  A.1.  Core Model ................................................20
  A.2.  Trust Boundaries ..........................................20
Index .............................................................22

1. Introduction ✨

okay so this doc gives you the lowdown on the architecture and functionality of DomainKeys Identified Mail (DKIM), which is the core mechanism for signing and verifying messages 💅 It's for those adopting, developing, or deploying DKIM, and it'll be helpful for anyone thinking about extending DKIM, whether into other areas of use or to support additional features 🌸 This overview does not provide information on threats to DKIM or email, or details on the protocol specifics. You can find those in [RFC4686] and [RFC4871], respectively. Because the scope of this overview is restricted to the technical details of signing and verifying using DKIM, it does not explore operational issues, the details of services that DKIM uses, or those that, in turn, use DKIM. Nor does it discuss services that build upon DKIM for enforcement of policies or assessments. The document assumes a background in basic email and network security technology and services 🧚

DKIM lets an organization take responsibility for a message in a way that a recipient can verify 🫶 The organization can be a direct handler of the message, like the author's, the originating sending site's, or an intermediary's along the transit path. However, it can also be an indirect handler, like an independent service that's providing assistance to a direct handler. DKIM defines a domain-level digital signature authentication framework for email through the use of public-key cryptography, and it uses the domain name service as its key server technology [RFC4871]. It permits verification of the signer of a message, as well as the integrity of its contents. DKIM will also provide a mechanism that lets potential email signers publish info about their email signing practices, which lets email receivers make additional assessments of unsigned messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing" 🙅‍♀️

Neither this document nor DKIM tries to solve the world's problems with spam, phishing, viruses, worms, joe jobs, etc. 😭 DKIM provides one basic tool, in what needs to be a large arsenal, for improving basic trust in the Internet mail service. However, by itself, DKIM is not sufficient to that task, and this overview doesn't pursue the issues of integrating DKIM into these larger efforts, beyond a simple reference within a system diagram. Rather, it's a basic introduction to the technology and its use 🌈

1.1. DKIM's Scope 🎀

a person or organization has an "identity", which is a constellation of characteristics that distinguish them from any other identity 💜 Associated with this abstraction can be a label used as a reference, or "identifier". This is the distinction between a thing and the name of the thing. DKIM uses a domain name as an identifier, to refer to the identity of a responsible person or organization. In DKIM, this identifier is called the Signing Domain IDentifier (SDID) and is contained in the DKIM-Signature header field's d= tag. Note that the same identity can have multiple identifiers 🦋

A DKIM signature can be created by a direct handler of a message, like the message's author, or by an intermediary. A signature also can be created by an independent service that is providing assistance to a handler of the message. Whoever does the signing chooses the SDID to be used as the basis for later assessments. Hence, the reputation associated with that domain name might be an additional basis for evaluating whether to trust the message for delivery. The owner of the SDID is declaring that they accept responsibility for the message and can thus be held accountable for it 👑

DKIM is intended as a value-added feature for email. Mail that is not signed by DKIM is handled in the same way as it was before DKIM was defined. The message will be evaluated by established analysis and filtering techniques. (A signing policy can provide additional information for that analysis and filtering.) Over time, widespread DKIM adoption could permit stricter handling of messages that are not signed. However, early benefits do not require this, and they probably do not warrant this 🍓

DKIM has a narrow scope. It is an enabling technology, intended for use in the larger context of determining message legitimacy. This larger context is complex, so it is easy to assume that a component like DKIM, which actually provides only a limited service, instead satisfies the broader set of requirements 🙈

By itself, a DKIM signature:

• Does not authenticate or verify the contents of the message header or body, such as the author From field, beyond certifying data integrity between the time of signing and the time of verifying.
• Does not offer any assertions about the behaviors of the signer.
• Does not prescribe any specific actions for receivers to take upon successful signature verification.
• Does not provide protection after signature verification.
• Does not protect against re-sending (replay of) a message that already has a verified signature. Therefore, a transit intermediary or a recipient can re-post the message (that is, post it as a new message) with the original signature remaining verifiable, even though the new recipient(s) might be different from those who were originally specified by the author 💀

1.2. Prior Work 🕰️

okay so historically, the IP Address of the system that directly sent the message (aka the previous email "hop") was treated as an identity for making assessments 👀. see [RFC4408], [RFC4406], and [RFC4407] for some current uses of the sending system's IP Address. the IP Address comes from underlying Internet information mechanisms, so it's trusted to be accurate. but bestie, addresses have some known security weaknesses AND a bunch of functional and operational problems 😩. so there's a widespread desire for an identifier that corresponds better to organizational boundaries, and domain names can totally satisfy that 💅

there have been four previous IETF Internet Mail signature standards 🎀. their goals were different from DKIM's goals. PEM and MOSS are only of historical interest now 🕯️

• Privacy Enhanced Mail (PEM) was first published in 1987 [RFC0989].
• Pretty Good Privacy (PGP) was developed by Phil Zimmermann and first released in 1991. A later version was standardized as OpenPGP [RFC1991] [RFC2440] [RFC3156] [RFC4880] 🔐
• PEM eventually transformed into MIME Object Security Services (MOSS) in 1995 [RFC1848].
• RSA Security independently developed Secure MIME (S/MIME) to transport a Public Key Cryptographic System (PKCS) #7 data object. It was standardized as [RFC3851].

development of both S/MIME and OpenPGP has continued 🌸. they've each achieved a significant user base, but neither one has hit ubiquity in deployment or use. not yet, anyway 🥹

to the extent that other message-signing services might have been adapted to do the job DKIM is designed for, it was felt that repurposing any of them would be more problematic than creating a separate service 🧁. that said, DKIM only uses cryptographic components with a long history, including use within some of those other messaging security services. lowkey iconic of DKIM to borrow the good stuff 🫶

DKIM is differentiated by its reliance on an identifier that is specific to DKIM use ✨

DKIM also has a distinctive approach for distributing and vouching for keys 🗝️. it uses a key-centric, public-key management scheme, rather than the more typical approaches based on a certificate in the styles of Kohnfelder (X.509) [Kohnfelder] or Zimmermann (web of trust) [WebofTrust]. for DKIM, the owner of the SDID asserts the validity of a key, rather than having a trusted third party attest to the key's validity (often bundled with other assertions, like a quality assessment of the key's owner). DKIM treats quality assessment as an independent, value-added service, beyond the initial work of deploying a signature verification service 💜

further, DKIM's key management is provided by adding information records to the existing Domain Name System (DNS) [RFC1034], rather than requiring deployment of a new query infrastructure 🧚. this approach has significant operational advantages. first, it avoids the considerable barrier of creating a new global infrastructure, so it leverages a global base of administrative experience and highly reliable distributed operation. second, the technical side of the DNS is already known to be efficient 🚀. any new service would have to go through a period of gradual maturation, with potentially problematic early-stage behaviors. by (re-)using the DNS, DKIM avoids those growing pains. no thanks to that drama 🙈

1.3. Internet Mail Background 📬

the basic Internet email service has evolved a lot over its several decades of continuous operation 🕰️. its modern architecture comprises a number of specialized components. a discussion about Mail User Agents (MUAs), Mail Handling Services (MHSs), Mail Transfer Agents (MTAs), Mail Submission Agents (MSAs), Mail Delivery Agents (MDAs), Mail Service Providers (MSPs), Administrative Management Domains (ADMDs), Mediators, and how they all relate can be found in Appendix A 📖

2. The DKIM Value Proposition 👑

the nature and origins of a message are often falsely stated 🙃. such misrepresentations may be employed for legitimate or nefarious reasons. DKIM provides a foundation for distinguishing legitimate mail, and thus a means of associating a verifiable identifier with a message 🔍. given that identifier, a receiver can make decisions about further handling of the message, based on assessments of the identity associated with the identifier.

receivers who successfully verify a signature can use information about the signer as part of a program to limit spam, spoofing, phishing, or other undesirable behaviors 🛡️. DKIM does not, itself, prescribe any specific actions by the recipient. it's an enabling technology for services that do 💖

these services will typically:

1. Determine a verified identity as taking responsibility for the message, if possible.
2. Evaluate the trustworthiness of this/these identities.

the role of DKIM is to perform the first of these. DKIM is an enabler for the second 🫶

2.1. Identity Verification 🕵️‍♀️

picture an attack made against an organization or against its customers 😰. the name of the organization is linked to particular Internet domain names (identifiers). attackers can leverage either a legitimate domain name, one without authorization, or a "cousin" name that's similar to a legitimate one but not controlled by the target organization 🙅‍♀️. an assessment service that uses DKIM can tell apart a domain (SDID) used by a known organization from a domain used by others. so DKIM performs the positive step of identifying messages associated with verifiable identities, rather than the negative step of identifying messages with problematic use of identities ✨. whether a verified identity belongs to a Good Actor or a Bad Actor is a question for later stages of assessment 🎭

2.2. Enabling Trust Assessments 💅

email receiving services face a basic decision: whether to accept and deliver a newly arrived message to the indicated recipient 📥. that is, does the receiving service trust that the message is sufficiently "safe" to be viewed? for the modern Internet, most receiving services have an elaborate engine that formulates this quality assessment 🧠. these engines take a variety of inputs, like reputation lists and accreditation services. as the engine processes information, it raises or lowers its trust assessment for the message 📈

to formulate reputation information, you need an accurate, stable identifier 🎯. otherwise, the information might not pertain to the identified organization's own actions. when using an IP Address, accuracy is based on the belief that the underlying Internet infrastructure supplies an accurate address. when using domain-based reputation data, some other form of verification is needed, since the infrastructure doesn't supply it independently 🙏

DKIM satisfies this requirement by declaring a valid "responsible" identity, referenced through the SDID, that the engine can make quality assessments about. it also uses a digital signature to ensure that use of the identifier is authorized 🔏. however, a valid DKIM signature by itself neither lowers nor raises the level of trust associated with the message. but it enables other mechanisms to be used for doing so 🦋

an organization might build on its use of DKIM by publishing information about its Signing Practices (SP) 📝. this could permit detecting some messages that purport to be associated with a domain but aren't. so an SP can cause the trust assessment to be reduced, or leave it unchanged 🥀

2.3. Establishing Message Validity ✅

man-in-the-middle attacks are historically rare in email, but it's still theoretically possible for a message to be modified during transit 😱. an interesting side effect of the cryptographic method DKIM uses is that it's possible to be certain that a signed message (or, if l= is used, the signed portion of a message) hasn't been modified between signing and verifying 🔐. if it's been changed in any way, the message won't verify successfully with DKIM 🚫

as described above, this validity neither lowers nor raises the level of trust associated with the message 🤷‍♀️. if it was an untrustworthy message when initially sent, the verifier can be certain that the message will be equally untrustworthy upon receipt and successful verification. no glow-up for the sketchy ones 💀

3. DKIM Goals 🎀

DKIM adds an end-to-end authentication capability to the existing email transfer infrastructure 💌. that means there can be multiple email relaying hops between signing and verifying. so it defines a mechanism that only needs to be supported by the signer and the verifier, rather than every functional component along the handling path 🧚‍♀️. this motivates functional goals about the authentication itself, and operational goals about its integration with the rest of the Internet email service 🌈

3.1. Functional Goals 🧩

3.1.1. Use Domain-Level Granularity for Assurance 🏢

DKIM provides accountability at the coarse granularity of an organization or, perhaps, a department. an existing construct that enables this granularity is the Domain Name [RFC1034]. DKIM binds a signing key record to a Domain Name as the SDID. further benefits of using domain names include simplifying key management, enabling signing by the infrastructure as opposed to the MUA, and reducing privacy concerns 🔒

contrast this with OpenPGP and S/MIME, which associate verification with individual authors using their full email addresses 👩‍💻

3.1.2. Implementation Locality 📍

any party, anywhere along the transit path, can implement DKIM signing 🌍. its use isn't confined to particular systems, like the author's MUA or the inbound boundary MTA, and there can be more than one signature per message 💜

3.1.3. Allow Delegation of Signing to Independent Parties 🤝

different parties have different roles in the email exchange. some are easily visible to end users and others are mostly visible to operators of the service 👀. DKIM was designed to support signing by any of these parties, and to let them sign with any domain name they deem appropriate (and for which they hold authorized signing keys) 🗝️. for example, an organization that creates email content often delegates portions of its processing or transmission to an outsourced group. DKIM supports this mode of activity in a manner that's not normally visible to end users 🫣. similarly, a reputation provider can delegate a signing key for a domain under the provider's control, to be used by an organization the provider is prepared to vouch for 🎁

3.1.4. Distinguish the Core Authentication Mechanism from Its Derivative Uses 🧠

an authenticated identity can be subject to a variety of assessment policies, either ad hoc or standardized. DKIM separates basic authentication from assessment 🧼. the only semantics inherent to a DKIM signature are that the signer is asserting some kind of responsibility for the message. any interpretation of that responsibility is the job of services building on DKIM, and the details are beyond the scope of that core 💅. one such mechanism might assert a relationship between the SDID and the author, as specified in the rfc5322.From: header field's domain identity. another might specify how to treat an unsigned message with that rfc5322.From: field domain 🌸

3.1.5. Retain Ability to Have Anonymous Email 🎭

okay so the ability to send a message that doesn't say who wrote it is a super valuable part of email, and it needs to stick around 🫶 DKIM is totally fine with that because it only proves the email system operator sent the message, not the actual person who typed it. like, if you can get effectively anonymous accounts at example.com, knowing a message came from example.com doesn't blow up the anonymity of whoever wrote it 🕵️‍♀️✨

3.2. Operational Goals 🛠️

3.2.1. Make Presence of Signature Transparent to Non-Supporting Recipients 🫥

bestie, DKIM is built so that people who don't support it can't even tell it's there 💅 that's how incremental adoption works! a DKIM signature does not "get in the way" for those recipients at all 🌸

compare that to S/MIME and OpenPGP, which mess with the message body itself 😬 so their presence can be visible to recipients, and their user software has to process those extra bits.

3.2.2. Treat Verification Failure the Same as No Signature Present 🙈

DKIM also has to stay invisible to existing assessment mechanisms, no cap 💀 so a DKIM signature verifier is to treat messages with failing signatures as if they were unsigned. the message just goes back to normal handling through the receiver's existing filtering mechanisms. so DKIM says an assessing site is not to take a message with a broken signature and treat it any differently than if the signature weren't there at all 🧚

Aside: OpenPGP and S/MIME were built for strong cryptographic protection, and they treated verification failure as message failure. DKIM does not do that. it's a whole different vibe 🦋

3.2.3. Permit Incremental Adoption for Incremental Benefit 📈

DKIM works between any two organizations that exchange email and implement it. it does not need adoption across the whole open Internet's email infrastructure to be useful 🌈 the benefits follow the usual "network effects" pattern, meaning they grow as more people adopt it 🔥 assessment services can work with DKIM, but they aren't required in order to get early benefit.

for example, DKIM lets (possibly large) pairwise sets of email providers and spam filtering companies tell apart mail that's tied to a known organization from mail that might be pretending to be from them 👀 that makes "whitelist" schemes possible, where authenticated mail from a known source with a good reputation gets to skip some anti-abuse filters. iconic 👑

the email receiver can also use its own set of known relationships to build its own reputation data 💖 this works especially well for traffic between large sending providers and large receiving providers. it also works well for any operator, public or private, whose mail is mostly swapped among a stable set of organizations.

managing email delivery problems is currently a huge pain point for email admins at every single point on the mail transit path 😭 so admins who have deployed DKIM verification have a real reason to encourage senders (who might later complain that their email isn't getting delivered) to use DKIM signatures 🍓

3.2.4. Minimize the Amount of Required Infrastructure 🧩

so early adopters can get early wins, DKIM doesn't change the core Internet Mail service at all ✨ it can be useful for any single pair of signers and verifiers who are swapping mail. and since DKIM leans on the Domain Name System, it cuts down a lot on the new admin infrastructure needed across the open Internet 🎀

3.2.5. Permit a Wide Range of Deployment Choices 🎛️

DKIM can be deployed in a bunch of different places inside an organization's email service 💅 that gives flexibility over who runs it and which traffic gets a DKIM signature. for example, if you deploy DKIM at an outbound boundary MTA, it gets administered by the organization's central IT department, and internal messages aren't signed 🏢🫣

---

4. DKIM Function ⚙️

DKIM is very constrained in what it can do, and it mostly targets email while it's in transit from an author to a set of recipients 🚚 it attaches verifiable information to a message, especially a responsible identity 🪪 when a message doesn't have a valid signature tied to the author, a DKIM SP will let the author's domain name be used to look up information about their signing practices 🔍

4.1. Basic Signing ✍️

with the DKIM signature mechanism, a signer picks an SDID, digitally signs the message, and adds the signature info in a DKIM header field 💌 a verifier grabs the domain name and the "selector" from that header field, fetches the public key tied to that name, and checks the signature 🔐

DKIM lets any domain name be used as the SDID, and it supports extensible choices for different algorithms 🌸 as is typical for Internet standards, there's a core set of algorithms that all implementations are required to support, so basic interoperability is guaranteed 🫶

DKIM also lets you restrict a signature key to signing messages for particular types of services, like just one source of email 🎯 that's super helpful when you're delegating signing authority, such as to a specific department or a third-party outsourcing service 💼

with DKIM, the signer explicitly lists which headers get signed, like From:, Date:, and Subject: 📝 if you pick the minimal set of headers you need, the signature is way more likely to survive the handling quirks of intermediary MTAs 💪

4.2. Characteristics of a DKIM Signature 🔏

a DKIM signature covers the message body and selected header fields 💫 the signer computes a hash of the selected header fields and another hash of the body. then it uses a private key to cryptographically encode that information, along with other signing parameters 🗝️ the signature info goes into DKIM-Signature:, a new [RFC5322] message header field 🎀

4.3. The Selector Construct 🧁

the key for a signature is tied to an SDID 🪄 that domain name gives the complete identity used for making assessments about the signer. (the DKIM specification doesn't give any guidance on how to do an assessment 🤷‍♀️) however, that name isn't enough to make a DNS query for the key needed to verify the signature 😤

a single SDID can have multiple signing keys and/or multiple potential signers 👯 so DKIM identifies a particular signature by combining the SDID with an extra field called the "selector". the selector goes in a separate DKIM-Signature: header field parameter 🎟️

NOTE: the semantics of the selector (if any) are strictly reserved to the signer, and every other party must treat it as an opaque string 🔒 if verifiers used the selector as part of an assessment mechanism, there would be no remaining way to move from an old, or compromised, key to a new one. 💀

4.4. Verification 🔎

after a message has been signed, any agent in the message transit path can verify the signature and check that the owner of the SDID took responsibility for the message 🫡 message recipients can verify it too, by querying the DNS for the signer's domain directly to get the right public key, which confirms the message was signed by someone holding the private key for the SDID 🗝️✨ usually, verification gets done by an agent in the Administrative Management Domain (ADMD) of the message recipient 🏰

4.5. Sub-Domain Assessment 🌷

signers often need multiple assessments about their organization, like telling one type of message apart from another, or one part of the org from another 🧠 to keep those assessments independent, one method is to use different sub-domains as the SDID tag. for example, "transaction.example.com" versus "newsletter.example.com", or "productA.example.com" versus "productB.example.com" 🛍️ these can be totally separate from the rfc5322.From header field domain 💅

5. Service Architecture ✨

okay so DKIM needs some outside help 🫶 like looking up keys and relaying email. This spec picks a starter set, DNS and SMTP, so everything can basically talk to each other from day one 🌸

                                  |
                                  |- RFC5322 Message
                                  V
     +--------+    +--------------------------------+
     | Private|    |  ORIGINATING OR RELAYING ADMD  |
     | Key    +...>|  Sign Message with SDID        |
     | Store  |    +---------------+----------------+
     +--------+                    |
      (paired)                 [Internet]
     +--------+                    |                     +-----------+
     | Public |    +--------------------------------+    | Remote    |
     | Key    |    |  RELAYING OR DELIVERING ADMD   |    | Sender    |
     | Store  |    |  Message Signed?               |    | Practices |
     +----+---+    +-----+--------------------+-----+    +-----+-----+
          .              |yes                 |no              .
          .              V                    |                .
          .        +-------------+            |                .
          +.......>|  Verify     +--------+   |                .
                   |  Signature  |        |   |                .
                   +------+------+        |   |                .
                      pass|           fail|   |                .
                          V               |   |                .
                   +-------------+        |   |                .
                   |             |        |   |                .
          +.......>| Assessments |        |   |                .
          .        |             |        V   V                .
          .        +-----+--+----+      +-------+              .
          .              |  |          / Check   \<............+
          .              |  +-------->/  Signing  \
          .              |           /   Practices \<..........+
          .              |          +-------+-------+          .
          .              |                  |                  .
          .              |                  V                  .
     +----+--------+     |            +-----------+     +------+-----+
     |Reputation/  |     |            | Message   |     | Local Info |
     |Accreditation|     +----------->| Filtering |     | on Sender  |
     |Info         |                  | Engine    |     | Practices  |
     +-------------+                  +-----------+     +------------+

Figure 1: DKIM Service Architecture

so as the diagram shows 🦋 message processing gets split between a signing ADMD and a verifying ADMD. The simplest version is the originating ADMD talking to the delivering ADMD, but other ADMDs can totally jump into the handling path too 💅

Signing: signing is done by an authorized module inside the signing ADMD, and it uses private info from the Key Store (more on that below) ✨ inside the originating ADMD, that could be the MUA, the MSA, or an MTA.

Verifying: verifying is done by an authorized module inside the verifying ADMD 👑 inside a delivering ADMD, that could be an MTA, an MDA, or an MUA. The module checks the signature, or figures out whether a certain signature was even needed. Checking the signature uses public info from the Key Store. If the signature passes, reputation info gets used to assess the signer, and that info goes to the message filtering system 💖 if the signature fails, or there's no signature from the author's domain, info about that author's signing practices can be pulled remotely and/or locally, and it also goes to the filtering system 🙈

ngl this one's a bit of a rule: if a message has more than one valid signature, the DKIM spec doesn't define the order the signers get assessed in, or how their assessments interact 🤷‍♀️

5.1. Administration and Maintenance

a bunch of tables and services provide outside info, and each one comes with its own admin and maintenance chores 🧚

Key Store: DKIM uses public/private-key (asymmetric) crypto 🔐 the signer uses a private key and the verifier uses the matching public key. The current DKIM Signing spec lets a verifier grab the public key by querying the Domain Name Service (DNS). So the signing org needs a way to add a key to DNS for every selector/SDID combo 💅 and they also need policies for handing out and rotating keys.

Reputation/Accreditation: if a message has a valid signature, the verifier can check the reputation of the associated domain name, to decide how to deliver or display that message 💜 quality info tied to a domain name comes in lots of forms from lots of sources, and DKIM doesn't define any assessment services. what DKIM does is give them a verified domain name to make their assessments on, and that's it, bestie 🎀

Signing Practices (SP): this is separate from checking whether a signature is valid, and separate from judging the reputation of the org behind the signed identity. there's a chance to figure out what organizational practices apply to a domain name 🌈 those can be all over the place. they might be published by the domain owner, or maintained by the site doing the evaluating. they can be about how the domain gets used, like whether it's used for signing messages, whether all mail with that domain in the author rfc5322.From: header field gets signed, or even whether the owner recommends tossing messages that don't have a proper signature 💀 these practice statements are made at the domain-name level, which makes them different from the per-message assessments that happen in a Message Filtering Engine. still, practice assessments can be really useful input for the Filtering Engine when it decides how to handle a message ⭐ as practices get defined, every domain owner has to think about what info to publish 🍓 and whether checking practices happens at all, plus how much, is optional for the evaluating site. it's purely a local policy call 🦋

5.2. Signing

signing can happen in whichever component of the ADMD creates the message, and/or in any ADMD along the relay path 🌸 the signer uses the right private key tied to the SDID, obviously 🔥

5.3. Verifying

verification can be done by any functional component along the relay and delivery path ✨ verifiers grab the public key based on the parameters stored in the message itself 🧚

5.4. Unverified or Unsigned Mail

messages that don't have a valid author signature (meaning a signature tied to the message's author, not one tied to some intermediary) can kick off a query for any published "signing practices" info 💅 that helps figure out whether the author info got used without permission 🙈

5.5. Assessing

Figure 1 shows the verified identity getting used to assess an associated reputation, but it could also be used for other stuff, like tracking mail for management 🎀 local policy might make signing practices get checked, or the message might go straight to the message Filtering Engine ✨

a popular use of reputation info is as input to a Filtering Engine, which decides whether to deliver a message, and maybe whether to specially mark it 💖 Filtering Engines have gotten complex and sophisticated, but their details are outside DKIM's scope 🙄 the only expectation is that the verified identity DKIM produces can build up its own reputation, and then get tossed into the big soup of rules the engines use 🍲 those rules can cover signed messages, and they can also handle unsigned messages from a domain, if that domain has published info about its practices 👑

5.6. DKIM Processing within an ADMD

the most common place a DKIM implementation will live is inside the authoring org's outbound service and the receiving org's inbound service, like a department or a boundary MTA 🏢 DKIM can also be built into an author's or recipient's MUA, but that's expected to be less typical, since it costs more to administer and support 💜

a Mediator is an MUA that receives a message and can repost a modified version of it, like to a mailing list 🦋 a DKIM signature can survive some kinds of modifications during that process 🌈 and the Mediator can add its own signature too. that signature can come from the Mediator software itself, or from any outbound component in the Mediator's ADMD ✨

---

6. Considerations 🎀

6.1. Security Considerations

okay this part is SERIOUS 😭 the security considerations of the DKIM protocol are described in the DKIM base specification [RFC4871], and they're based on [RFC4686] 🔐 go read them, bestie, they matter 💀

6.2. Acknowledgements

so many people helped build DomainKeys Identified Mail, and the DKIM Working Group gets a huge thank-you 🫶 extra special shoutout to Jim Fenton, who gave extensive, diligent feedback on every single version of this document 👑🌸

7. Informative References ✨

okay bestie, here are the receipts 🧾💅 these are the extra reads the spec points to, and every single one is listed with all its details 🫶

• [Kohnfelder] Kohnfelder, L., "Towards a Practical Public-key Cryptosystem", May 1978.
• [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures", RFC 989, February 1987.
• [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
• [RFC1113] Linn, J., "Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures", RFC 1113, August 1989.
• [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME Object Security Services", RFC 1848, October 1995.
• [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996.
• [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
• [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
• [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
• [RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
• [RFC4407] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
• [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
• [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006.
• [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
• [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
• [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
• [WebofTrust] Network Associates, Inc. and its Affiliated Companies, "How PGP works, in Introduction to Cryptography", 1999, <http://www.pgpi.org/doc/pgpintro/>.

---

Appendix A. Internet Mail Background 🦋

A.1. Core Model

okay so Internet Mail is split into two worlds 🌏 there's the user side, made of Mail User Agents (MUA), and the transmission side, called the Mail Handling Service (MHS), which is built out of Mail Transfer Agents (MTA). The MHS takes a message from one user (the author) and delivers it to one or more other users (the recipients), so from the users' point of view it feels like a direct MUA-to-MUA chat 💌 The first piece of the MHS is the Mail Submission Agent (MSA), and the last piece is the Mail Delivery Agent (MDA).

An email Mediator is both an inbound MDA and an outbound MSA. It receives a message, tweaks it to fit its service, and then reposts it for further distribution. Usually the new message keeps the original rfc5322.From: header field 📨 A mailing list is the classic example of a Mediator.

Internet Mail is run by tons of independent operators, with lots of different components serving users and lots more doing the actual transfer 🧩 So it's important to tell apart the administrative boundaries around groups of components that follow one coherent set of operational policies.

As we'll see below, every MSA is a candidate for signing with DKIM, and every MDA is a candidate for doing DKIM verification 🔐

A.2. Trust Boundaries

Running Internet Mail services is split up between different providers (or operators). Each one can be its own independent ADministrative Management Domain (ADMD) 👑 Every ADMD has its own set of policies, and it deals with other ADMDs based on different levels and kinds of trust 🤝 Some examples: an end user with a desktop client connecting to an independent email service, a department running a submission agent or a local Relay, an organization's IT group running enterprise Relays, and an ISP running a public shared email service.

Each of these can be arranged into tons of combinations of administrative and operational relationships, and each ADMD might have a complicated mix of functional components inside 🌀 Figure 2 shows how the ADMDs relate to each other. The most salient thing about an ADMD is that differential trust, which sets its policies for what happens inside it versus what happens when it talks to other ADMDs 👀

The basic types of ADMDs are:

• Edge: independent transfer services sitting at the edge of the Internet Mail service 🌐
• User: end-user services. These might be folded under an Edge service, which is common for web-based email access.
• Transit: Mail Service Providers (MSP) that add value for Edge ADMDs, like aggregation and filtering ✨

Heads up: Transit here is not the same as packet-level transit. Packet routers handle end-to-end packet transfers in the middle, but email across the open Internet often goes straight from one Edge ADMD to another at the email level 📬

       +--------+                            +--------+    +--------+
       | ADMD#1 |                            | ADMD#3 |    | ADMD#4 |
       | ------ |                            | ------ |    | ------ |
       |        |   +----------------------->|        |    |        |
       | User   |   |                        |--Edge--+--->|--User  |
       |  |     |   |                   +--->|        |    |        |
       |  V     |   |                   |    +--------+    +--------+
       | Edge---+---+                   |
       |        |   |    +----------+   |
       +--------+   |    |  ADMD#2  |   |
                    |    |  ------  |   |
                    |    |          |   |
                    +--->|-Transit--+---+
                         |          |
                         +----------+

        Figure 2: ADministrative Management Domains (ADMD) Example

So in Figure 2, ADMDs 1 and 2 are candidates for DKIM signing, and ADMDs 2, 3, and 4 are candidates for DKIM verification 🔍

The Transit versus Edge split matters mainly because it flags where you need to worry about interaction and protection between independent administrations 🛡️ Stuff between components inside one ADMD follows that domain's own policies. Any pair of ADMDs can agree on whatever policies they like, but Internet Mail is designed so they can interoperate without any prior arrangement 💕

Common ADMD examples include:

• Enterprise Service Providers: operators of an organization's internal data and/or mail services 🏢
• Internet Service Providers: operators of the underlying data communication services that Relays and Users rely on. Email isn't necessarily their job, but they can provide an environment where those functions get done 🛜
• Mail Service Providers: operators of email services, like the ones for end users or mailing lists 📮

---

Index 📇

   A
      ADMD  6
      Administrative Management Domain  6
      assessment  7

   D
      DKIM-Signature  12-13
      DNS  6, 13-15

   I
      identifier  4-8
      identity  3-7, 9, 12
      infrastructure  5-6, 8-11, 17

   M
      Mail Delivery Agent  6
      Mail Handling Service  6
      Mail Service Provider  6
      Mail Submission Agent  6
      Mail Transfer Agent  6
      Mail User Agent  6
      MDA  6
      MHS  6
      MIME Object Security Services  5
      MOSS  5
      MSA  6
      MSP  6
      MTA  6
      MUA  6

   O
      OpenPGP  5

   P
      PEM  5
      PGP  5
      Pretty Good Privacy  5
      Privacy Enhanced Mail  5

   S
      S/MIME  5

   T
      trust  3, 7-8, 20

   V
      verification  4, 7-8, 10-11, 13, 16, 20-21

   W
      Web of Trust  6

   X
      X.509  6

Authors' Addresses 💌

   Tony Hansen
   AT&T Laboratories
   200 Laurel Ave.
   Middletown, NJ  07748
   USA

   EMail: tony+dkimov@maillennium.att.com


   Dave Crocker
   Brandenburg InternetWorking
   675 Spruce Dr.
   Sunnyvale, CA  94086
   USA

   EMail: dcrocker@bbiw.net


   Phillip Hallam-Baker
   Default Deny Security, Inc.

   EMail: phillip@hallambaker.com

and that's a wrap, bestie 🌈✨ the whole spec, slay 👑💖