RFC 5863
DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations
DomainKeys Identified Mail (DKIM): Development, Deployment, and Operations 🎀
okay bestie, this one is the RFC 5863 practical guide to DKIM, the thing that lets an org say "yep, we vouch for this email" 💌 and lets the recipient check it with DNS-published public keys. It's Informational, not a Standards Track spec, so it's tips and real-world know-how, not a rulebook 🧚
- RFC number: 5863
- Title: DomainKeys Identified Mail (DKIM): Development, Deployment, and Operations
- Authors: T. Hansen (AT&T Laboratories), E. Siegel (Consultant), P. Hallam-Baker (Default Deny Security, Inc.), and D. Crocker (Brandenburg InternetWorking)
- Category: Informational
- ISSN: 2070-1721
- Date: May 2010
- Obsoletes and updates: the title block doesn't list any RFCs it obsoletes or updates 🙈
Abstract
okay so DKIM lets an organization claim it's responsible for sending a message, and the recipient can actually verify that claim 🔐 the org could be the author's, the originating sending site, an intermediary, or one of their agents, and a single message can carry several signatures from the same org or different ones 🫶
it's a domain-level digital signature framework for email, built on public key crypto, with DNS acting as the key server 🌐 so you get to verify the responsible org AND that the message content hasn't been messed with ✨ DKIM also gives signers a way to publish their signing practices, so receivers can make extra calls about messages 👀 and it can help with the global fight against "spam" and "phishing" 🛡️
this doc covers implementation, deployment, operational, and migration stuff for DKIM 💖
Status of This Memo
this is NOT a standards track spec, it's published just for info 📚
it's a product of the IETF, reflecting consensus from the IETF community 🌸 it got public review and was approved by the IESG (Internet Engineering Steering Group) 💅 not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🧐
for the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5863 🦋
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date 📜 please actually read those, because they spell out your rights and restrictions 🙏 any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🎀
this doc may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008 🕰️ the people who control the copyright on some of that stuff might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😬 so unless you get a proper license from them, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either, except to format it as an RFC or translate it into languages other than English 🌈
Table of Contents
1. Introduction ....................................................4
2. Using DKIM as Part of Trust Assessment ..........................4
2.1. A Systems View of Email Trust Assessment ...................4
2.2. Choosing a DKIM Tag for the Assessment Identifier ..........6
2.3. Choosing the Signing Domain Name ...........................8
2.4. Recipient-Based Assessments ...............................10
2.5. Filtering .................................................12
3. DKIM Key Generation, Storage, and Management ...................15
3.1. Private Key Management: Deployment and Ongoing
Operations ................................................16
3.2. Storing Public Keys: DNS Server Software Considerations ...17
3.3. Per-User Signing Key Management Issues ....................18
3.4. Third-Party Signer Key Management and Selector
Administration ............................................19
3.5. Key Pair / Selector Life Cycle Management .................19
4. Signing ........................................................21
4.1. DNS Records ...............................................21
4.2. Signing Module ............................................21
4.3. Signing Policies and Practices ............................22
5. Verifying ......................................................23
5.1. Intended Scope of Use .....................................23
5.2. Signature Scope ...........................................23
5.3. Design Scope of Use .......................................24
5.4. Inbound Mail Filtering ....................................24
5.5. Messages Sent through Mailing Lists and Other
Intermediaries ............................................25
5.6. Generation, Transmission, and Use of Results Headers ......25
6. Taxonomy of Signatures .........................................26
6.1. Single Domain Signature ...................................26
6.2. Parent Domain Signature ...................................27
6.3. Third-Party Signature .....................................27
6.4. Using Trusted Third-Party Senders .........................29
6.5. Multiple Signatures .......................................30
7. Example Usage Scenarios ........................................31
7.1. Author's Organization - Simple ............................32
7.2. Author's Organization - Differentiated Types of Mail ......32
7.3. Author Domain Signing Practices ...........................32
7.4. Delegated Signing .........................................34
7.5. Independent Third-Party Service Providers .................35
7.6. Mail Streams Based on Behavioral Assessment ...............35
7.7. Agent or Mediator Signatures ..............................36
8. Usage Considerations ...........................................36
8.1. Non-Standard Submission and Delivery Scenarios ............36
8.2. Protection of Internal Mail ...............................37
8.3. Signature Granularity .....................................38
8.4. Email Infrastructure Agents ...............................39
8.5. Mail User Agent ...........................................40
9. Security Considerations ........................................41
10. Acknowledgements ..............................................41
11. References ....................................................42
11.1. Normative References .....................................42
11.2. Informative References ...................................42
Appendix A. Migration Strategies .................................43
A.1. Migrating from DomainKeys .................................43
A.2. Migrating Hash Algorithms .................................48
A.3. Migrating Signing Algorithms ..............................49
Appendix B. General Coding Criteria for Cryptographic
Applications .........................................501. Introduction 🌟
okay so DKIM lets an organization claim responsibility for sending a message, in a way a recipient can validate 🔏 this doc gives practical tips for a few crowds: people building DKIM software, mailing list managers, filtering strategies that use DKIM verification output, and DNS servers 💻 it's also for folks deploying DKIM software, keys, and mailing list software, and for anyone migrating from DomainKeys [RFC4870] 🚚 and for the people keeping an email infrastructure that has DKIM running day to day 🛠️
bestie, read the DKIM Service Overview document [RFC5585] first, it's giving foundation 🧱 for more detail on DKIM and Author Domain Signing Practices (ADSP), check out the protocol specs [RFC4871], [RFC5617], and [RFC5672] 📖
the doc is organized around the key DKIM concepts 🗂️ inside each section, extra notes about development, deployment, or ongoing operations get called out where they fit 💅 and it also talks about using DKIM results as input to a local reputation database 🔥
2. Using DKIM as Part of Trust Assessment ✨
2.1. A Systems View of Email Trust Assessment ✨
Okay so, DKIM is part of a trust-oriented upgrade to email delivery 📬 It helps the receiving side decide what to do with a message, like whether to deliver it or how to show it. 💅 Trust and the classic risk-and-abuse approach are super different vibes. With trust, a willing participant on the sending path and a willing participant at the recipient's site are working together. 🫶 Risk flips that. The recipient acts alone, and the sender might be unknown, hostile, and sneaky. 💀
That leads to a big technical difference. When the recipient is acting solo and the sender might be actively trying to trick them, risk-oriented tools rely on heuristics, which is basically guessing. 🙈 Guessing gives statistical answers with some false negatives and some false positives. Trust-based exchanges are all about the deterministic exchange of information. For DKIM, that information is the one identifier that stands for a stream of mail the signer wants independently assessed. 🎀
A trust-based service is built on a validated Responsible Identifier that labels a stream of mail and is controlled by an identity (a role, a person, or an organization). That identity is admitting it has some level of responsibility for the stream. If the recipient has a reason to believe the identifier is being used properly, they can make and use an assessment of the identity behind it. 🦋 One identity can use several identifiers, since different streams might earn different assessments. ✨ For example, even the best-run marketing campaigns will probably get a few complaints that can dent the reputation of that identifier, while a stream of transactional messages will likely have a much cleaner rep. 🧚
Here's the key distinction, bestie. Checking that an identifier is validly used is not the same as checking that message content is valid. 🔥 The first only means the identifier for the responsible role, person, or organization was legitimately attached to a message. The second means the content can be believed and, usually, that the claimed author of that content is correct. DKIM only validates that the signing identifier is present. 💜 Even when that identifier checks out, DKIM doesn't imply that any of the message content is valid, including the RFC5322.From field [RFC5322]. Honestly, this surprised me too: that limit still applies even when the validated signing identifier is the same domain name as the RFC5322.From field! 😭 DKIM's only claim about content is that the content covered by the h= tag of the DKIM-Signature: field was delivered without modification. So it asserts content integrity between signing and verifying, not content validity. 🌸
Check out Figure 1! This enhancement is a conversation between a responsible role, person, or organization that signs the message, and a recipient organization that assesses how much it trusts that signer. The recipient then makes handling decisions based on a whole bunch of assessments, and DKIM is only one piece of that. 👑 In this model, validation is just a middle step whose only job is handing a validated Responsible Identifier to the Identity Assessor. The communication carries a single Responsible Identifier that the Responsible Identity wants the Identity Assessor to use. That Identifier is the only formal input and output value of DKIM signing. The Identity Assessor uses that one value to consult whatever assessment databases the assessing entity thinks are appropriate. Then the Identity Assessor's output feeds into a Handling Filter engine, which weighs a range of factors along with that single output value. Those factors can include ancillary information from the DKIM validation. 💖
+------+------+ +------+------+
| Author | | Recipient |
+------+------+ +------+------+
| ^
| |
| +------+------+
| -->| Handling |<--
| -->| Filter |<--
| +-------------+
| ^
V Responsible |
+-------------+ Identifier +------+------+
| Responsible |. . . . . . . . . . .>| Identity |
| Identity | . . | Assessor |
+------+------+ . . +-------------+
| V . ^ ^
V . . | |
+------------------.-------.--------------------+ | |
| +------+------+ . . . > . +-------------+ | | | +-----------+
| | Identifier | | Identifier +--|--+ +--+ Assessment|
| | Signer +------------->| Validator | | | Databases |
| +-------------+ +-------------+ | +-----------+
| DKIM Service |
+-----------------------------------------------+
Figure 1: Actors in a Trust Sequence Using DKIMIdentity Assessment is a whole family of possible functions. 🍓 It can be as simple as checking whether the identifier is on some list, like authorized operators or participants in a group the recipient cares about. Or it can express a degree of trust (reputation) to give the actor using that identifier. How much the assessment actually changes handling is decided later, by the Handling Filter. ✨
2.2. Choosing a DKIM Tag for the Assessment Identifier 🎀
Okay, this part is important! The signer has to provide precise data and know exactly what that data will mean once it reaches the Assessor. 🧐 If the recipient side is ambiguous about which value it will pick, the sender can't know what basis for assessment will be used. DKIM has three values that carry identification info, and they're easy to mix up. Only one of them is the formal input and output of DKIM. The other two are for internal protocol work and side jobs like auditing and debugging. 🔍
The main ones are the s=, d=, and i= parameters in the DKIM-Signature: header field. To get the end-to-end determinism this collaboration needs, from the signer all the way to the assessor, the core model has to pin down what the signer must give the assessor. The update to RFC 4871 [RFC5672] says:
"DKIM's primary task is to communicate from the Signer to a recipient-side Identity Assessor a single Signing Domain Identifier (SDID) that refers to a responsible identity. DKIM MAY optionally provide a single responsible Agent or User Identifier (AUID)... A receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the User Agent Identifier (i=) if present.... To the extent that a receiver attempts to intuit any structured semantics for either of the identifiers, this is a heuristic function that is outside the scope of DKIM's specification and semantics."
So the single, mandatory value DKIM hands over as its output is d=. 👑 It's described as the "domain of the signing entity". It's a domain name, and it's combined with the selector to form a DNS query. A receive-side DKIM verifier needs to pass the Signing Domain Identifier (d=) to a consuming Identity Assessor module, and it can also pass along the User Agent Identifier (i=) if one is present. 💖
The adjunct values are:
s=: This tag specifies the selector. It's used to tell apart the different keys that can be used for the samed=domain name. As discussed in Section 4.3 of [RFC5585], "If verifiers were to employ the selector as part of an assessment mechanism, then there would be no remaining mechanism for making a transition from an old, or compromised, key to a new one". So the selector is not appropriate for use as part or all of the identifier used to make assessments. 🙅♀️i=: This tag is optional and provides the "[t]he Agent or User Identifier (AUID) on behalf of which the SDID is taking responsibility" [RFC5672]. The identity can be written as a whole email address or as just a domain name. The domain name can be the same as thed=one, or it can be a sub-name of it. 🦋
NOTE: Although thei=identity has the syntax of an email address, it is not required to have those semantics. That is, "the identity of the user" need not be the same as the user's mailbox. For example, the signer might wish to usei=to encode user-related audit information, such as how they were accessing the service at the time of message posting. Therefore, it is not possible to conclude anything from thei=string's (dis)similarity to email addresses elsewhere in the header.
So i= can have any of these properties:
- Be a valid domain when it is the same as
d= - Appear to be a subdomain of
d=but might not even exist - Look like a mailbox address but might have different semantics and therefore not function as a valid email address
- Be unique for each message, such as indicating access details of the user for the specific posting
This is why the tag has to be treated as opaque. It can represent any semantics, and only the signer knows what they are. 🔐
So i= works well as a token, kind of like a Web cookie, that gets returned to the signing Administrative Management Domain (ADMD). That's great for things like auditing and debugging. Of course, in some scenarios the i= string might be a useful adjunct value for extra (heuristic) processing by the Handling Filter. 🌈
2.3. Choosing the Signing Domain Name 🎀
okay so a DKIM signing entity can wear a bunch of different hats 🧢 It might be the author of the content, the operator of the mail service, or the operator of a reputation service that also signs stuff for its customers. Each hat changes what makes it sensible to split up your mail traffic. And for anyone making DKIM signatures, different chunks of mail probably deserve different levels of trust 💅 For example:
- Mail goes out for different reasons, like marketing versus transactional, and recipients react to those in totally different ways 📬
- If you run an email service, there are often sub-populations of users who deserve different levels of trust or privilege, like paid versus free users, or people in direct correspondence versus people sending bulk mail 🧁
- Mail that starts outside your system, like when a mailing-list service run by the operator passes it along, will have a different reputation from mail sent by users who authenticated with the operator 🌸
So it's likely useful for a signer to use different d= subdomain names for different message traffic streams, so receivers can make differential assessments ✨ BUT (and this is the tea 🫖), too much differentiation is a problem. If you slice things too finely, the receiver can't spot a stable enough pattern of traffic to build an accurate and reliable assessment 😭 So you gotta find a balance. Generally, in a trust system, legit signers have every reason to pick a small, stable set of identities, so recipients and others can actually attribute reputations to them 🦋 The set of identities a receiver trusts is likely to be quite a bit smaller than the set it sees as risky 👀
Now, the real challenge with adding more layers of subdomains is whether that extra granularity will even be useful for the Assessor 🤔 Honestly, too many levels just invite ambiguity. If the Assessor doesn't use all the granularity in the full domain name, they might decide on their own to only look at some rightmost part of the identifier, and the signer has no way of knowing which part that will be 🙈 That ambiguity drags the use of DKIM back into the land of heuristics, when the whole point is deterministic processing 💀
So the goal is figuring out a useful scheme for labeling different traffic streams 💖 The most obvious options are different types of content and/or different types of authors. Stability is essential, but the choices will probably change over time, so the scheme needs to be flexible 🌈
For people originating message content, the most likely subdomain naming scheme will be based on type of content, which can use content-oriented labels or service-oriented labels. For example:
transaction.example.com
newsletter.example.com
bugreport.example.com
support.example.com
sales.example.com
marketing.example.comThe best choices really depend on whether they let the Identity Assessor tell apart streams of mail that show significantly different degrees of recipient acceptance or safety 🧚 And again, the danger of going too fine is that related message streams labeled separately won't get to benefit from an aggregate reputation 😤
For those running messaging services for a variety of customers, an obvious scheme is giving each customer their own subdomain label. For example:
widgetco.example.net
moviestudio.example.net
bigbank.example.netIt can also make sense to label by class of service or class of customer, like this:
premier.example.net
free.example.net
certified.example.netBefore domain names took over for telling sources of data apart, IP Addresses were the basis for distinction 🫶 Service operators usually did this by dedicating specific outbound IP Addresses to specific mail streams, typically to specific customers. Like, a university might want to keep mail from the administration separate from mail from the student dorms 🎓 To make adopting a DKIM-based service easier, it can be reasonable to translate that same partitioning of traffic into domain names instead of the different IP Addresses 💜
2.4. Recipient-Based Assessments 💌
okay this part is giving main character energy 👑 DKIM gives the recipient site's Identity Assessor a verifiable identifier to analyze. The mechanism doesn't claim that the signer is a Good Actor or a Bad Actor, BUT it does make it possible to know that use of the identifier is valid 🥹 That's a big deal, because it's in marked contrast with schemes that have no authentication. Without verification, you can't know whether the identifier (whether it's taken from the RFC5322.From field, the RFC5321.MailFrom command, or the like) is being used by an authorized agent 🙃 DKIM solves that problem. So with DKIM, the Assessor can know that two messages with the same DKIM d= identifier are actually signed by the same person or organization ✨ That allows a way more stable and accurate assessment of mail traffic using that identifier 🔥
What makes DKIM distinctive is that it provides an identifier that isn't necessarily related to any other identifier in the message 🦋 So the signer might be the author's ADMD, one of the operators along the transit path, or a reputation service being used by one of those handling the services. Honestly, a message can even have multiple signatures, possibly from any number of these actors 🌸
Like we said above, the choice of identifiers needs to be based on differences the signer thinks will be useful to the recipient Assessor 🧁 Over time, industry practices set norms for these choices. Until those norms exist, here's the move:
Absent such norms, it is best for signers to distinguish among streams that have significant differences, while consuming the smallest number of identifiers possible. This will limit the burden on recipient Assessors. 🫶
A common view is that a DKIM signature carries a degree of assurance about some or all of the message contents, and in particular that the RFC5322.From field is likely to be valid. Plot twist 😭 DKIM only makes assurances about the integrity of the data, NOT about its validity. Presumptions about RFC5322.From field validity are still a concern, though. So a signer using a domain name that's unrelated to the domain name in the RFC5322.From field can reasonably expect that the disparity will warrant some curiosity 👀 at least until signing by independent operators has produced some established practice among recipient Assessors 🍓
With the identifier(s) DKIM supplies, the Assessor can consult an independent assessment service about the entity associated with the identifier(s) 💅 Another option is that the Assessor develops its own reputation rating for the identifier(s). Basically, over time the Assessor can watch the stream of messages tied to the identifier(s) and see how it develops a reaction to the associated content 📈 For example, if there's a high percentage of user complaints about signed mail with a d= value of "widgetco.example.net", the Assessor might include that fact in the vector of data it provides to the Handling Filter 🚨 This is also discussed briefly in Section 5.4 💖
2.5. Filtering ✨
okay so the Handling Filter is where the assessment of the signing identifier actually gets used 🎀 and it's built from local policies, which means your filter can weigh a whole bunch of different factors in different amounts. this section walks through some of the choices and weightings that make sense, plus the different actions you could take with each. and because authenticated domain names are basically a teamwork thing between the signer and the Assessor, sometimes the best move is literally contacting the signer 🫶
the vibe here is Organizational Trust versus Message Stream Risk 💅 Trust is how positive you feel about the DKIM-signing organization, and Risk is how much danger is hiding in the message stream that org signed. you'd think high trust automatically means low risk, but real-world operations have examples of every combo of the two, which is shown in Figure 2 🙈 each axis only gets three levels here so the discussion stays manageable. real filtering engines need finer distinctions and usually more axes than this, ngl 😭
for example, there are different types of risk, so an engine could tell spam risk apart from virus risk and do different things for each 🦋 for spam, a false negative (letting bad stuff through) does small damage, but a false positive (blocking good mail) does big damage 💀 for a virus it's the opposite vibe: a false negative is extremely dangerous, while modern detection tools make false positives extremely unlikely 🔥 for this discussion though, "risk" is treated as one single construct, so we're not getting into that.
here's the cute part 🌈 the DKIM d= identifier is independent of every other identifier in the message and can be a subdomain of the name the signer owns. that means you can make fine-grained, stable distinctions between different kinds of message streams, like transactional messages versus marketing messages from the same company ✨ so DKIM might actually let mail-receiving engines run a richer filtering model than they've usually been able to do 👑
real talk though: today's public Internet Mail environment makes a quite suspicious baseline handling model necessary 😤 which is why "strong" filtering rules are really the starting point, as you can see in the UNKNOWN cell 💜
the table shows the different handling for each combo, like how aggressive or broad the filtering could be 🍓 aggressiveness changes which kinds of wrong assessments are likely to happen, so the table looks at a few things: 1) whether an organization is unknown, known to be good actors, or known to be bad actors, and 2) how the messages themselves are assessed. it also gives advice on how much filtering to do and what else to do with the message. and here's the unexpected bit 👀 it lists a case where the receiving site might want to deliver problematic mail instead of redirecting or deleting it. the site might also want to contact the signing organization and try to get the problem resolved 🫶
+-------------+-----------------------------------------------+
| S T R E A M * O R G A N I Z A T I O N A L T R U S T |
| R I S K * Low Medium High |
| +***************+***************+***************+
| Low * BENIGN: | DILIGENT: | PRISTINE |
| * Moderate | Mild | Accept |
| * filter | filter | |
| +---------------+---------------+---------------+
| Medium * UNKNOWN: | TYPICAL: | PROTECTED: |
| * Strong | Targeted | Accept & |
| * filter | filter | Contact |
| +---------------+---------------+---------------+
| High * MALICIOUS: | NEGLIGENT: | COMPROMISED: |
| * Block & | Block | Block & |
| * Counter | | Contact |
+-------------+---------------+---------------+---------------+
Figure 2: Trust versus Risk Handling Tradeoffs Example[LEGEND] 📖
AXES
- Stream Risk: a measure of the recent history of a message stream and how severe the problems it has caused are 🌸
- Organizational Trust: this mixes longer-term history of possible stream problems from that organization with how responsive it is when problems come up 🧚
CELLS (indicating reasonable responses) 🎀
The cell labels are a general take on an organization that produces that kind of mail stream under that kind of circumstance 💖
- Benign: there's some history of sending good messages, with very few harmful ones received 🌈 this stream deserves filtering that doesn't hunt for problems super aggressively, so you don't rack up false positives 🦋
- Diligent: the stream has had a limited amount of problems, and the organization is consistently good at handling its abuse issues quickly ✨
- Pristine: a clean message stream with no problems, from an org with an excellent reputation 👑 the filter mainly needs to make sure messages get delivered, and catching the odd stray problem message is a smaller concern. basically, the biggest worry here is false positives 🫶
- Unknown: there's no history with the organization 🌸 apply an aggressive level of "naive" filtering, because of how the public email environment is 😬
- Typical: the stream has serious abuse issues, and the organization has a track record of struggling to fix them quickly, even when it's genuinely trying 💀 sadly this is the typical situation for service providers with easy, open subscription policies 🥲
- Protected: an organization with a good history and/or one that provides an important message stream for the receiving site is covered by a local policy saying messages are not allowed to be blocked 🛡️ but the stream is causing problems anyway. the receiver delivers the messages but works quickly with the organization to sort it out 💜
- Malicious: a persistently problematic stream is coming from an organization that seems to be contributing to the problem 😈 the stream gets blocked, and the org's role is troubling enough to be worth following up with others in the anti-abuse or legal communities, to limit or end their impact 🚫
- Negligent: a persistently problematic stream is coming from an organization that doesn't seem to be causing the problem, but also isn't working to get rid of it 🙄 at the very least, the stream needs to be blocked 🧱
- Compromised: an organization with a good history has a stream that changes and becomes way too problematic to deliver 😱 the receiver blocks the stream and works quickly with the organization to fix it 🔧
3. DKIM Key Generation, Storage, and Management ✨
okay so by itself, verifying a digital signature only lets the verifier conclude, with a very high degree of certainty, that the signature was made by someone who has access to the matching private signing key 🔐 which means a verifier needs ways to (1) get the public key so it can verify, and (2) figure out useful attributes about the key holder 🕵️♀️
in a traditional Public Key Infrastructure (PKI), key distribution and key accreditation are separate jobs 🎀 in DKIM [RFC4871], both of those jobs happen through the DNS 🌐
either way, being able to infer anything meaningful from a digital signature depends on assuming the matching private key is only accessible to a party with a particular set of attributes 🗝️ in a traditional PKI, a Trusted Third Party (TTP) vouches that the key holder has been validated for a specified set of attributes. so the range of attributes that can be attested is only as wide as the stuff a TTP can set up effective processes to validate 💅 in DKIM, there are no TTPs, and key distribution and accreditation are combined into one 🫶
so, there are only two types of inference a signer can make from a key published in a DKIM key record 👀
- That a party with the ability to control DNS records within a DNS zone intends to claim responsibility for messages signed using the corresponding private signature key.
- That use of a specific key is restricted to the particular subset of messages identified by the selector.
being able to draw any useful conclusion from verifying a digital signature relies on the assumption that the matching private key is only accessible to a party with a particular set of attributes 🔑 for DKIM, that means the party who created the matching DKIM key record in the specific zone intended to claim responsibility for the signed message 💖
ideally we'd love to draw a stronger conclusion 🥹 like, if we get a DKIM key record from the DNS zone example.com, then the legitimate holder of the DNS zone example.com claims responsibility for the signed message. for that conclusion to hold, the verifier has to assume that the operational security of the DNS zone and the corresponding private key is adequate 🔒 no cap, that's a big ask, bestie 😭
3.1. Private Key Management: Deployment and Ongoing Operations 🔐
okay bestie, access to signing keys needs to be super carefully managed so unauthorized people can't use them, and so the damage stays small if something ever goes wrong 🫶
While a DKIM signing key is signing messages for tons of mail users, the key itself needs to be under direct control of as few key holders as possible. If a key holder leaves the organization, every signing key they held needs to be withdrawn from service and, if it makes sense, replaced 🚪✨
If key management hardware support is available, it needs to be used. If keys are stored in software, appropriate file control protections need to be used. Any location where the private key sits in plaintext needs to be left out of regular backup processes, and it's best not reachable through any kind of network, including private local area networks 💾🙅♀️. Auditing software needs to be run periodically to check that the permissions on the private key files stay secure 🔍
Wherever possible, a signature key needs to exist in exactly one location and be erased when it's no longer used. Ideally, a signature key pair needs to be generated as close to the signing point as possible, and only the public key component gets passed to another party. If that's not possible, the private key needs to be transported in an encrypted format that protects the confidentiality of the signing key. A shared directory on a local file system does not provide adequate security for distributing signing keys in plaintext form, so no thanks 🙅♀️
Key escrow schemes are not necessary and are best not used. If a signing key gets lost (rare, but still), a new signature key pair can be generated just as easily as recovering from a key escrow scheme 🗝️
To enable accountability and auditing:
- Responsibility for the security of a signing key needs to ultimately vest in a single named individual.
- Where multiple parties are authorized to sign messages, each signer needs to use a different key to enable accountability and auditing.
Best practices for cryptographic keying material require that keying material be refreshed at regular intervals, especially where key management is done in software. While that's highly desirable, it matters way less than keeping the private key secret. An operational setup where the private key lives in tamper-proof hardware and gets changed once a year is way more desirable than one where the signature key changes every hour but lives in software 🔥
3.2. Storing Public Keys: DNS Server Software Considerations 🌐
To use DKIM, a DNS domain holder needs (1) the ability to create the necessary DKIM DNS records and (2) enough operational security controls to stop an attacker from inserting spurious DNS records 💅
DNS record management is often run by an admin staff that's different from the people who run the organization's email service. To keep DKIM DNS records accurate, that means careful coordination between the two ops groups 🤝 If the best practices for private key management above are followed, deployment is not a one-time event. DNS DKIM selectors will change over time as signing keys get terminated and replaced 🔄
At a minimum, a DNS server that handles queries for DKIM key records needs to let the server administrators add free-form TXT records. It would be better if DKIM records could be entered using a structured form that supports the DKIM-specific fields 📋
Ideally, DNS Security (DNSSEC) [RFC4034] needs to be employed in a configuration that protects against record insertion attacks and zone enumeration. In the case that NextSECure version 3 (NSEC3) [RFC5155] records are employed to prevent insertion attacks, the OPT-OUT flag needs to be clear. (See [RFC5155] section 6 for details.) 🧐
3.2.1. Assignment of Selectors 🏷️
Selectors are assigned according to the administrative needs of the signing domain, like rolling over to a new key or delegating the right to authenticate a portion of the namespace to a TTP. Examples include:
jun2005.eng._domainkey.example.com
widget.promotion._domainkey.example.comThe intent is that assessments of DKIM identities are based on the domain name, and not the selector. A signer's past practice might let a verifier infer extra properties of particular messages from the DKIM key selector's structure, but unannounced administrative changes, like swapping signing software, can break those heuristics at any time 🙈
3.3. Per-User Signing Key Management Issues 👤
While a signer can set business rules, like issuing individual signature keys for each end-user, DKIM makes no provision for communicating these to other parties. Out-of-band distribution of such business rules is outside the scope of DKIM. So external parties have no way to use those keys to attribute messages with any more granularity than a DNS domain 🙃
If per-user signing keys are assigned for internal purposes (e.g., authenticating messages sent to an MTA (Mail Transfer Agent) for distribution), the following issues need to be considered before using such signatures as an alternative to traditional edge signing at the outbound MTA:
- External verifiers will be unable to make use of the additional signature granularity without access to additional information passed out of band with respect to [RFC4871].
- If the number of user keys is large, the efficiency of local caching of key records by verifiers will be lower.
- A large number of end users is less likely to do an adequate job of managing private key data securely on their personal computers than is an administrator running an edge MTA.
3.4. Third-Party Signer Key Management and Selector Administration 🎪
A DKIM key record only asserts that the holder of the corresponding domain name makes a claim of responsibility for messages signed under that key. In some applications, like bulk mail delivery, it's desirable to delegate use of the key. That means letting a third party sign on behalf of the domain holder. The trust relationship is still between the domain holder and the verifier, but the private signature key is held by a third party 🤝
Signature keys used by a third-party signer need to be kept entirely separate from those used by the domain holder and other third-party signers. To limit potential exposure of the private key, the signature key pair needs to be generated by the third-party signer, and the public component of the key transmitted to the domain holder. That's better than the domain holder generating the key pair and sending the private component to the third-party signer 🔑
Domain holders need to adopt a least-privilege approach and grant third-party signers the minimum access necessary to perform the desired function. Limiting the access granted to third-party signers protects the interests of both parties. The domain holder minimizes its security risk, and the TTP signer avoids unnecessary liability 🛡️
In the most restrictive case, domain holders maintain full control over the creation of key records. They can use appropriate key record restrictions to enforce limits on the messages the third-party signer is able to sign. If those restrictions are impractical, the domain holder needs to delegate a DNS subzone for publishing key records to the third-party signer. It is best that the domain holder NOT allow a third-party signer unrestricted access to its DNS service for the purpose of publishing key records 🚫
3.5. Key Pair / Selector Life Cycle Management ♻️
Deployments need to establish, document, and observe processes for managing the entire life cycle of an asymmetric key pair.
3.5.1. Example Key Deployment Process 🚀
When it's determined that a new key pair is required:
- A Key Pair is generated by the signing device.
- A proposed key selector record is generated and transmitted to the DNS administration infrastructure.
- The DNS administration infrastructure verifies the authenticity of the key selector registration request. If accepted:
- A key selector is assigned.
- The corresponding key record is published in the DNS.
- Wait for DNS updates to propagate (if necessary).
- Report assigned key selector to signing device.
- The signer verifies correct registration of the key record.
- The signer begins generating signatures using the new key pair.
- The signer terminates any private keys that are no longer required due to issue of replacement.
3.5.2. Example Key Termination Process 🛑
When it's determined that a private signature key is no longer required:
- The signer stops using the private key for signature operations.
- The signer deletes all records of the private key, including in-memory copies at the signing device.
- The signer notifies the DNS administration infrastructure that the signing key is withdrawn from service and that the corresponding key records can be withdrawn from service at a specified future date.
- The DNS administration infrastructure verifies the authenticity of the key selector termination request. If accepted:
- The key selector is scheduled for deletion at a future time determined by site policy.
- Wait for deletion time to arrive.
- The signer either publishes a revocation key selector with an empty public-key data (
p=) field, or deletes the key selector record entirely.
- As far as the verifier is concerned, there is no functional difference between verifying against a key selector with an empty
p=field and verifying against a missing key selector. Both result in a failed signature, and the signature needs to be treated as if it had not been there. However, there is a minor semantic difference: with the emptyp=field, the signer is explicitly stating that the key has been revoked. The emptyp=record provides a gravestone for an old selector, making it less likely that the selector might be accidentally reused with a different public key 🪦
4. Signing ✍️
Creating messages that have one or more DKIM signatures requires support in only two outbound email service components:
- A DNS Administrative interface that can create and maintain the relevant DNS names -- including names with underscores -- and resource records (RR).
- A trusted module, called the signing module, which is within the organization's outbound email handling service and which creates and adds the
DKIM-Signature:header field(s) to the message.
If the module creates more than one signature, there needs to be the appropriate means of telling it which one(s) to use. If a large number of names are used for signing, it will help to have the administrative tool support a batch-processing mode 🔥
4.1. DNS Records 🎀
okay so when a receiver wants to verify a DKIM signature, they need the public key that goes with it 🔑. the DKIM-Signature: header has a d= tag with the basic domain name doing the signing, which also gets passed along as output to the Identity Assessor 👀, and an s= tag with the selector that gets added onto the name so you can find the specific key. so the <selector>._domainkey.<domain-name> DNS record needs to contain a DKIM-related RR that gives the public key info. bestie this is literally the treasure map 🗺️✨
the administrator of the zone containing the relevant domain name is the one who adds this info 🧑💻. initial DKIM DNS info lives in TXT RRs 📝. DNS admin software is kinda all over the place though 💀 some of it handles DKIM names with underscores super well and some of it really doesn't, and not all of it can add new types of DNS info easily.
4.2. Signing Module 💅
the module doing the signing can go anywhere inside an organization's trusted Administrative Management Domain (ADMD) 🏢. obvious picks include department-level posting agents, plus outbound boundary MTAs facing the open Internet 🌐. but honestly any other module is potentially acceptable too, including the author's MUA (Mail User Agent) 🤳, as long as the signature survives whatever handling happens inside the ADMD after that. so the choice depends on software development, administrative overhead, security exposures, and transit-handling tradeoffs 🧮. one way to think about it is flexibility (placing it at or close to the MUA) versus the streamlined admin and operation you get by putting the mechanism "deeper" into the org's email infrastructure, like at its boundary MTA 🍓.
check out Section 2.2 for the deal with the i= tag, it's giving important 👀.
the signing module uses the appropriate private key to create one or more signatures (see Section 6.5 for the multiple signatures tea ☕). how the signing module gets its private key(s) isn't specified by DKIM, so that part is totally up to you 🙈. since DKIM is meant for use during email transit rather than long-term storage, keys are expected to change regularly 🔄. and for admin convenience, it's best not to hard-code key info into software 🚫💻.
4.3. Signing Policies and Practices 📜
every organization (ADMD) has its own policies and practices for deciding when to sign messages (message stream), and with what domain name, selector, and key 🎯. examples of message streams include all mail sent from the ADMD, mail from particular types of user accounts, or mail with particular types of content 📬. given all that variability, and the fact that signing practices will probably change over time, it's super useful to represent these decisions through run-time configuration info instead of hard-coding them into the signing software ⚙️✨.
as Section 2.3 mentioned, picking the signing name granularity is a balancing act between admin convenience and usefulness for recipients ⚖️. too much granularity means higher admin overhead, and it might try to force more differential analysis on the recipient than they want to support 😵💫. in those cases, recipients are likely to use only a super-name (a right-hand substring) of the signing name. when that happens, the signer won't know which portion is being used 🫠. and that moves DKIM back into the non-deterministic world of heuristics, instead of the mechanistic signer/recipient collaboration that DKIM is going for 🥲.
5. Verifying 🔍
a message recipient can verify a DKIM signature to figure out whether a claim of responsibility was made for the message by a trusted domain 🛡️.
access control needs two components: authentication and authorization 🔐. by design, verifying a DKIM signature only gives you the authentication part of an access control decision, so it needs to be combined with other info (like reputation data) to actually reach a decision 🧠.
5.1. Intended Scope of Use 🎀
DKIM requires that a message with a signature found to be invalid be treated as if it wasn't signed at all 🚫✍️.
if a DKIM signature fails to verify, it's totally possible the message is fine and there's either a config error on the signer's side (like a missing key record) or the message got accidentally changed in transit 😬. so it's undesirable for mail infrastructure to treat messages with invalid signatures any worse than messages with no signatures at all 🙅♀️. but on the flip side, making an invalid signature takes basically zero effort for an attacker 💀. if invalid-signature messages got better treatment than unsigned ones, attackers would just stick bogus signature blocks on their mail to get that VIP treatment 👿. so messages with invalid signatures need to be treated no better and no worse than messages with no signature at all 🫶.
5.2. Signature Scope 📏
as with any other digital signature scheme, verifiers only need to consider the part of the message that's inside the scope of what the signature authenticates 🔎.
for example, if the l= option is used to specify a content length for the signature's scope, then only the part of the message within that content signature's scope would be considered authentic 🧐.
5.3. Design Scope of Use 🧁
public key cryptography gives an exceptionally high degree of assurance, bordering on absolute certainty, that whoever made a valid digital signature had access to the private key matching the public key in the signature 🔑💖.
to make useful conclusions from a valid signature, the verifier has to make assumptions that fall far short of absolute certainty 🫠. so just validating a DKIM signature is not proof positive that a valid claim of responsibility was made by the indicated party, that the message is authentic, or that the message isn't abusive 🚨. in particular:
- the legitimate private key holder might have lost control of their private key 🔑💨.
- the legitimate domain holder might have lost control of the DNS server for the zone the key record came from 🖥️😱.
- the key record might not have been delivered from the legitimate DNS server for that zone 📡👀.
- ownership of the DNS zone might have changed 🔀.
honestly, these limitations have little or no impact on the field of use DKIM is designed for 🙌. but they can matter if someone uses the DKIM message signature format or key retrieval mechanism in other specifications 👀.
in particular, the DKIM key retrieval mechanism is designed for ease of use and deployment, not to provide a high assurance Public Key Infrastructure for stuff that needs robust non-repudiation, like legally binding contracts 📄⚖️. developers who want to take DKIM beyond its design need to consider replacing or supplementing the DNS key retrieval mechanism with one built for those purposes 🛠️💅.
5.4. Inbound Mail Filtering 📥
DKIM is frequently used in mail filtering strategies to avoid doing content analysis on email from trusted sources 🧹. messages carrying a valid DKIM signature from a trusted source can be whitelisted, which skips the computation and the energy-intensive content analysis needed to decide what happens to the message ⚡🌱.
mail sources can be determined to be trusted through previously observed behavior and/or reference to external reputation or accreditation services ⭐. exactly how that's done is outside the scope of DKIM 🤷♀️.
5.4.1. Non-Verifying Adaptive Spam Filtering Systems 🤖
adaptive (or learning) spam filters that can't verify DKIM signatures need to, at minimum, be configured to ignore DKIM header data entirely 🙈🚫.
5.5. Messages Sent through Mailing Lists and Other Intermediaries 📬🔁
intermediaries like mailing lists are a particular challenge for DKIM implementations 😤, because the processing they do can change the message content in ways that stop the signature from passing verification 💔.
such intermediaries are strongly encouraged to deploy DKIM signing, so that a verifiable claim of responsibility stays available to anyone trying to verify the modified message 🫶🌈.
5.6. Generation, Transmission, and Use of Results Headers 🧾
in lots of deployments, it's desirable to separate signature verification from the application relying on it 🧩. a system can relay info about its message authentication results in various ways, and adding a "results header" to the message is one of them [RFC5451] 💌. for example, think about cases where:
- the application relying on DKIM signature verification can't do the verification itself 🙅♀️.
- the message can be modified after the signature verification is performed ✂️.
- the signature key can't be available by the time the message gets read 🔒.
in those cases, it's important that the communication link between the signature verifier and the relying application is secure enough to prevent someone from inserting a message with a bogus results header 🚨🛡️.
an intermediary that generates results headers needs to make sure relying applications can tell valid results headers it issued apart from ones introduced by an attacker 🕵️♀️. one way to do that is signing the results header ✍️. at a minimum, results headers on incoming messages need to be removed if they claim to have been issued by the intermediary but can't be verified as authentic 🗑️.
further discussion on trusting results relayed from a verifier to something downstream is in [RFC5451] 📖✨.
6. Taxonomy of Signatures 🦋
as Section 2.1 described, a DKIM signature tells the verifier that the owner of a particular domain name accepts some responsibility for the message 🙋♀️. it doesn't, on its own, say anything about the trustworthiness or behavior of that identity 🤷♀️. what it does give you is a verified identity to attach behavioral info to, so the people who collect and use that info can be confident it really pertains to the identity in question 🧠💜.
this section lays out a taxonomy of some of the different identities, or combinations of identities, that a DKIM signature might usefully represent 🌸✨.
6.1. Single Domain Signature 💖
Okay so the simplest situation is when an organization signs its own outbound email using its own domain as the SDID [RFC5672] of the signature 🎀. For example, Company A would sign the outbound mail from its employees with d=companyA.example. 🏢
In the most straightforward setup, the addresses in the RFC5322.From field would also be in the companyA.example domain, but that direct match is not required 🌸.
A special case of the single domain signature is an author signature, as defined by the Author Domain Signing Practices specification [RFC5617] ✨. Author signatures come from an author's organization and have an SDID value that matches an RFC5322.From address in the signed message 💅.
Okay, now the important part 🙈. An author signature might sometimes protect against spoofing the domain name in RFC5322.From, but DKIM and ADSP validation only check the exact address string. They don't check look-alike addresses, the human-friendly "display-name", or names and addresses used in the body of the message 💀. So it only protects a precise address string in RFC5322.From, and nothing else 🫶.
For example, a message from bob@domain.example with a valid signature where d=d0main.example would fail an ADSP check, because the signature domain is distinct, however similar it looks 😭. But a message from bob@d0main.example with a valid signature where d=d0main.example would pass an ADSP check, even though to a human it's obvious that d0main.example is likely a sneaky attempt to spoof the domain domain.example 🙃. This is the tea: ADSP, just like DKIM, can only validate a signing identifier. It still needs some external process to attach a meaningful reputation to that identifier 🔥.
6.2. Parent Domain Signature 🦋
Another approach an organization with multiple active subdomains might take is to apply the same (single) signature domain to mail from all of its subdomains 🌈. In this case, the signature would usually be the signature of a parent domain shared by all the subdomains 👑. For example, mail from marketing.domain.example, sales.domain.example, and engineering.domain.example might all use a signature where d=domain.example ✨.
This approach is super simple, but it's important to think about what that choice actually means 🧚. As discussed in Section 2.3, if the mail coming from different subdomains is significantly different, or if there's reason to believe the subdomains have different reputations, then it can be a good idea to acknowledge that and give each subdomain its own signature (d=marketing.domain.example, sales.domain.example, etc.) 💜. But if the mail and reputations are likely to be similar, then the simpler approach of using one common parent domain in the signature can work really well 🍓.
Another way to tell the streams apart while using a single DKIM key is to leverage the AUID [RFC5672] (i= tag) in the DKIM signature 🎀. For example, marketing email would be signed with i=@marketing.domain.example and d=domain.example 💖.
Here's the catch, though 😭. Under core DKIM semantics, the AUID is opaque to receivers. So it will only be an effective differentiator if there's an out-of-band agreement about what the i= semantics mean 🫶.
6.3. Third-Party Signature 💅
A signature whose domain doesn't match the domain of the RFC5322.From address is sometimes called a third-party signature 🌸. In certain cases, even the parent domain signature described above would count as a third-party signature, because it isn't an exact match for the domain in the RFC5322.From address 🙈.
People argue about the value of third-party signatures constantly, and honestly it's giving drama ☕. But here's the key thing: the DKIM specification doesn't attach any particular significance to the identity in a DKIM signature ([RFC4871], [RFC5672]) 👑. The identity in the signature is the one taking responsibility for the message, and it's only a given receiver's interpretation that makes one identity matter more than another ✨. Most independent reputation services assign trust based on the specific identifier string, not its "role" 🧚. In general, they don't distinguish between, say, an author signature and a third-party signature 💜.
For some people, a signature unrelated to the author domain (the domain in the RFC5322.From address) is less valuable, because they assume an author signature guarantees that using that address in RFC5322.From is authorized 🔥.
For others, the relevance depends strictly on the recorded behavioral data attached to the identity, meaning its trust assessment or reputation 🍓. The logic is that an identity with a good reputation won't keep that reputation if it's in the habit of vouching for unwanted or abusive messages 💀. In fact, doing that would quickly wreck its reputation, so future messages wouldn't get the benefit anymore 😭. So it's low risk to help deliver messages that contain a valid signature from a domain with a strong positive reputation, whether or not that domain is tied to the address in the RFC5322.From header field of the message 🦋.
Third-party signatures can come from a wide range of identities 🌈. Some of the most common ones are:
- Service Provider: When email is outsourced to an Email Service Provider (ESP), Internet Service Provider (ISP), or some other type of service provider, that provider can choose to DKIM-sign outbound mail with its own identifier (relying on its own aggregate reputation) 💅. Or it can use a subdomain of the provider that's unique to the message author but still part of the provider's aggregate reputation 🫶. These providers can also cover delegated business functions like benefit management, although those are more often treated as trusted third-party senders (see below) 👑.
- Parent Domain: As discussed above, organizations that apply a parent-domain signature to mail from subdomains can have their signatures treated as third party by some verifiers 🎀. Whether that happens depends on whether the "t=s" tag is used to limit the parent signature to apply only to its own specific domain ✨. The default is to consider a parent-domain signature valid for its subdomains 🌸.
- Reputation Provider: Another possible kind of third-party signature is the identity of a third-party reputation provider ⭐. A signature like that would tell receivers that the message is being vouched for by that third party 💖.
6.4. Using Trusted Third-Party Senders 🧚
So far, we've been assuming the signing agent was responsible for creating and maintaining its own DKIM signing infrastructure, including its own keys and signing with its own identity 🎀.
A different model shows up when an organization uses a trusted third-party sender for certain key business functions, but still wants that email to benefit from the organization's own identity and reputation 💜. In other words, the mail comes out of the trusted third party's mail servers, but the signature applied is the one belonging to the controlling organization 🔥.
This works by having the third party generate a key pair that's designated uniquely for its own use, then publishing the public key in the controlling organization's DNS domain 🍓. That lets the third party sign mail using the controlling organization's signature 🫶. For example, if Company A outsources its employee benefits to a third party, it can use a special key pair that lets the benefits company sign mail as "companyA.example" 👑. Since the key pair is unique to that trusted third party, Company A can easily revoke that authorization if needed, just by removing the public key from the companyA.example DNS 😭.
A more cautious approach is to create a dedicated subdomain (e.g., benefits.companyA.example) to segment the outsourced mail stream, and publish the public key there 🦋. The signature would then use d=benefits.companyA.example 🌈.
6.4.1. DNS Delegation 🌸
Another way to set up trusted third-party access, as discussed in Section 3.4, is for Company A to use DNS delegation and have the designated subdomain managed directly by the trusted third party 💅. In this case, Company A would create a subdomain benefits.companya.example and delegate DNS management of that subdomain to the benefits company, so it can maintain its own key records 💖. When revocation becomes necessary, Company A can simply remove the DNS delegation record 🙈✨.
6.5. Multiple Signatures 🎀
Okay, so the simplest setup for DKIM-signed mail is one signature on each message 💅 This works great for domains that run and send all their own email from single sources, or for cases where there are multiple email streams but each one has its own unique key pair. It also covers the case where only one of the participants in an email sequence can sign, whether that's the author or one of the operators ✨
So far the examples have looked at what happens when you use different identities in DKIM signatures, but each message only ever had one identity claiming it. Sometimes it totally makes sense for more than one identity to claim responsibility for the same message 🦋
There are a bunch of situations where putting more than one DKIM signature on the same message could make sense. A few examples:
- Companies with multiple subdomain identities: A company with several subdomains sending different categories of mail might sign with distinct subdomain identities so each subdomain can manage its own identity. But it might also want a shared identity that spans all of those subdomains. For example, Company A can sign mail for its sales department with a signature where
d=sales.companya.exampleand a second signature whered=companya.example💼 - Service Providers: As described above, a service provider can sign outbound messages with either its own identity or an identity unique to each of its clients (possibly delegated). But it can also do both: sign each outbound message with its own identity and with the identity of each individual client 🙌 For example, ESP A might sign mail for its client Company B with its service provider signature
d=espa.example, plus a second client-specific signature whered=is eithercompanyb.exampleorcompanyb.espa.example. The service provider signature could help cover a new client while it builds its own reputation, or help a very small-volume client who might never hit a volume threshold big enough to build an individual reputation 📈 - Forwarders: Forwarded mail is a real challenge for email authentication 😭 DKIM holds up pretty well around forwarders as long as the signature is designed to avoid message parts that are likely to get modified. However, some forwarders do make changes that can invalidate a DKIM signature.
Some forwarders, like mailing lists or "forward article to a friend" services, might choose to add their own signatures to outbound messages to vouch that the message legitimately came from the designated service. In this case the signature gets added even when a preexisting signature is already there, and both signatures are relevant to the verifier.
Any forwarder that modifies messages in ways that will break preexisting DKIM signatures needs to sign its forwarded messages.
- Reputation Providers: Third-party reputation providers today use a variety of protocols to share their info with receivers. But it's possible that they, or other organizations willing to put their "seal of approval" on an email stream, might choose to use a DKIM signature to do it 🌟 In nearly all cases, this "reputation" signature would be in addition to the author or originator signature.
One big caveat to using multiple signatures is that there's currently no clear consensus among receivers on how they plan to handle them 🤔 The opinions range from ignoring all but one signature (and which one gets verified differs from receiver to receiver), to verifying all signatures present and applying a weighted blend of the trust assessments for those identifiers, to verifying all signatures present and simply using the identifier with the most positive trust assessment. It's likely that the industry will evolve to accept multiple signatures using either the second or third of these, but it can take some time before one approach becomes pervasive ⏳
7. Example Usage Scenarios 🌸
Signatures are created by different types of email actors, based on different criteria. That includes where the actor sits in the sequence from author to recipient, whether they want different messages evaluated under the same reputation or a different one, and so on 🧚
This section gives some examples of usage scenarios for DKIM deployments. The selection isn't meant to be exhaustive. It's here to illustrate a set of key deployment considerations 💜
7.1. Author's Organization - Simple
The simplest DKIM configuration is to have some mail from a given organization (Company A) signed with the same d= value (e.g., d=companya.example). If there's a desire to associate additional information, the AUID [RFC5672] value can become uniqueID@companya.example, or @uniqueID.companya.example ✨
In this scenario, Company A only needs to generate a single signing key and publish it under their top-level domain (companya.example). The signing module would then tailor the AUID value as needed at signing time 🔑
7.2. Author's Organization - Differentiated Types of Mail
This is a slight twist on the one-signature case. Company A signs some of its mail, but it wants to tell different categories of its outbound mail apart by using different identifiers 🛍️ For example, it might separate marketing, billing or transactional, and individual corporate email into marketing.companya.example, billing.companya.example, and companya.example, respectively. Each category gets its own unique subdomain and its own unique signing keys.
7.3. Author Domain Signing Practices
7.3.1. Introduction
Some domains might decide to sign all of their outgoing mail. If all the legitimate mail for a domain is signed, recipients can be more aggressive in filtering mail that uses the domain but doesn't have a valid signature from it. In a setup like that, a missing signature means way more than it does in the general case 👀 It might be useful for these domains to advertise their intent to other receivers. That's the topic of Author Domain Signing Practices (ADSP) 📣
Note that ADSP is not for everyone 🚨 Sending domains that don't control all legitimate outbound mail purporting to be from their domain (i.e., with an RFC5322.From address in their domain) are likely to see delivery problems with some percentage of that mail. Administrators evaluating ADSP for their domains need to carefully weigh the risk of phishing attacks against the likelihood of undelivered mail.
This section covers some examples of ADSP usage. For the complete specification, see [RFC5617] 📖
7.3.2. A Few Definitions
In the ADSP specification, an address in the RFC5322.From header field of a message is defined as an "Author Address", and an "Author Domain" is defined as anything to the right of the '@' in an author address 🧐
An "Author Signature" is therefore any valid signature where the value of the SDID matches an author domain in the message.
It's important to note that, unlike the DKIM specification (which makes no correlation between the signature domain and any message headers), the ADSP specification applies only to the author domain. Basically, under ADSP, any non-author signatures get ignored (treated as if they aren't there) 🙈
Signers who want to publish an Author Domain Signing Practices (ADSP) [RFC5617] record describing their signing practices will want to include an author signature on their outbound mail to avoid ADSP verification failures 💖
7.3.3. Some ADSP Examples
An organization (Company A) can specify its signing practices by publishing an ADSP record with dkim=all or dkim=discardable. To avoid misdelivery of its mail at receivers that are validating ADSP, Company A first needs to have done an exhaustive analysis to figure out all the sources of outbound mail from its domain (companyA.example) and make sure they all have valid author signatures from that domain 🔍
For example, email with an RFC5322.From address of bob@companyA.example needs to have an author signature where the SDID value is companyA.example, or it will fail an ADSP validation ❌
Once an organization publishes an ADSP record using dkim=all or dkim=discardable, any email with an RFC5322.From address that uses the domain where the ADSP record is published, and that doesn't have a valid author signature, is at risk of being misdelivered or discarded. For example, if a message with an RFC5322.From address of newsletter@companyA.example has a signature with d=marketing.companyA.example, that message will fail the ADSP check, because that signature wouldn't count as a valid author signature 😬
Since the semantics of an ADSP author signature are more constrained than those of a "pure" DKIM signature, it's important to make sure the nuances are well understood before deploying an ADSP record 🧠 The ADSP specification [RFC5617] includes some fairly extensive lookup examples (in Appendix A) and usage examples (in Appendix B).
Specifically, to keep mail from being negatively impacted or even discarded at the receiver, it's essential to do a thorough survey of outbound mail from a domain before publishing an ADSP policy stronger than "unknown" 🚫 That includes mail that might be sent from external sources not authorized to use the domain signature, as well as mail that risks modification in transit in ways that might invalidate an otherwise valid author signature (e.g., mailing lists, courtesy forwarders, and other paths that could add or modify headers or modify the message body) 📬
7.4. Delegated Signing
An organization might choose to outsource certain key services to an independent company. For example, Company A might outsource its benefits management, or Organization B might outsource its marketing email 💼
If Company A wants to make sure all of the mail sent on its behalf through the benefits provider's email servers shares the Company A reputation (as discussed in Section 6.4), it has two options. It can publish keys designated for the benefits provider's use under companyA.example (preferably under a designated subdomain of companyA.example). Or it can delegate a subdomain (e.g., benefits.companyA.example) to the provider and let the provider generate the keys and manage the DNS for that designated subdomain 🤝
In both cases, mail physically goes out of the benefit provider's mail servers with a signature of, e.g., d=benefits.companya.example. Note that the RFC5322.From address isn't constrained. It could be affiliated with either the benefits company (e.g., benefits-admin@benefitprovider.example, or benefits-provider@benefits.companya.example) or the companyA domain 🎉
Note that in both of the above scenarios, as discussed in Section 3.4, security concerns dictate that the keys be generated by the organization that plans to do the signing, so there's no need to transfer the private key 🔐 In other words, the benefits provider would generate keys for both of the above scenarios. Security is not a vibe to skip, bestie 💀
7.5. Independent Third-Party Service Providers 🎀
okay so there's another way to handle the service provider setup: the provider signs the outgoing mail for its client, Company A, using its own (provider) identifier 💅 like, an Email Service Provider (ESP A) might wanna share its own mailing reputation with its clients, so it signs all outgoing mail from those clients with its own d= domain (e.g., d=espa.example) ✨
when the ESP wants to tell its clients apart, it has two options:
- share the SDID domain and use the AUID value to tell the clients apart. so a signature on behalf of client A would have
d=espa.exampleandi=@clienta.espa.example(ori=clienta@espa.example) 🦋 - extend the SDID domain so each client gets a unique value (and subdomain). so a signature on behalf of client A would have
d=clienta.espa.example🌸
and get this, the delegation scenario and this one aren't mutually exclusive 🫶 sometimes it's totally desirable to sign the same message with both the ESP and the ESP client identities. iconic, honestly 👑
7.6. Mail Streams Based on Behavioral Assessment 📬
so an ISP (ISP A) might wanna assign signatures to outbound mail from its users based on each user's past sending behavior (reputation) 👀 basically the ISP sorts its outbound traffic by its own read on message quality, so recipients can tell the different streams apart. the semantics of behavioral assessments aren't valid AUID values, though, so ISP A (ispa.example) can set up subdomains for each assessment category (e.g., good.ispa.example, neutral.ispa.example, bad.ispa.example) and use those subdomains in the d= value of the signature 💖
the signing module can also set the AUID to a unique user ID (different from the local-part of the user's email address), like user3456@neutral.domain.example. using a user ID that's separate from any given email alias is super useful where one user might register multiple email aliases 🧚
heads up though: in this case the AUID values are only partially stable 🥺 they're stable in the sense that a given i= value always represents the same identity, but they're unstable in the sense that a user can migrate between the assessment subdomains depending on how they send. so the same user might end up with multiple AUID values over the life of one account. the drama is real 💀
ISP A can generate as many keys as there are assessment subdomains (SDID values), so each assessment subdomain gets its own key ✨ the signing module then picks its signing key based on the assessment of the user whose mail is being signed, and, if desired, puts the user ID in the AUID of the signature. as we talked about earlier, verifiers can ignore the per-user granularity of the AUID, so orgs that use it oughtn't rely on it for receiver-side filtering results 🙈 some orgs might still find it handy for their own stuff, like processing bounces or abuse reports.
7.7. Agent or Mediator Signatures 🤖
another scenario is an agent, usually some kind of re-mailer, that signs on behalf of the service or organization it represents 🦋 examples include a mailing list manager, or the "forward article to a friend" service that loads of online publications offer. in most of these cases, the signature is saying the message originated with, or was relayed by, the service claiming responsibility. generally speaking, if the service is set up so its forwarding would break existing DKIM signatures, it needs to always add its own signature 🫶
8. Usage Considerations 💅
8.1. Non-Standard Submission and Delivery Scenarios 🌈
the whole robustness of DKIM's verification mechanism is based on the fact that only authorized signing modules can access the designated private key 🔐 the side effect is that submission and delivery scenarios that originate or relay messages from outside the authorized signing module's domain don't have access to that protected key, so they can't attach the expected domain signature to those messages. the usual suspects are mailing lists, courtesy forwarders, MTAs at hotels, hotspot networks used by traveling users, and any other paths that could add or modify headers or modify the message body 😭
for example, say Joe works for Company A and has the email address joe@companya.example. Joe also has an ISP-1 account, joe@isp1.example.com, and he uses ISP-1's multiple address feature to attach his work address, joe@companya.example, to email from his ISP-1 account. when Joe sends from his ISP-1 account with joe@companya.example as his designated RFC5322.From address, that email can't have a signature with d=companya.example, because the ISP-1 servers don't have access to Company A's private key. ISP-1 will put its own ISP-1 signature on it, but for other mail clients that offer the same multiple address feature, there might be no signature at all on the message 🙃
another example is the forward article to a friend service. most instances today let someone send an article with their email address in the RFC5322.From to the recipient they picked 💌 if Joe used either of his two addresses (joe@companya.example or joe@isp1.example.com), the forwarder would be equally unable to sign with a matching domain. same as the mail client case: the forwarder can either sign as its own domain or put no signature on the message ✨
a third example is privately configured forwarding 🧚 say Joe has another account at ISP-2, joe@isp-2.example.com, but he'd rather read his ISP-2 mail from his ISP-1 account. so he sets up his ISP-2 account to forward all incoming mail to joe@isp1.example.com. now say alice@companyb.example emails joe@isp-2.example.com. depending on how companyb.example set up its signature, and on whether ISP-2 modifies the messages it forwards, it's possible that when Alice's message lands in Joe's ISP-1 account, the original signature fails verification 💀
8.2. Protection of Internal Mail 🏰
one identity is especially easy to assess accurately: the organization's own identity 🫶 members of an organization tend to trust messages that claim to be from inside that organization. however, Internet Mail doesn't give a straightforward way to tell whether such mail really is from within the organization 🙈 DKIM can fix this exposure. if the organization signs all of its mail, then its boundary MTAs can look for mail that claims to be from the organization but doesn't have a verifiable signature.
most of the time, that kind of mail can be presumed spurious 🕵️♀️ but domain managers are advised to think about the ways mail processing can modify messages in ways that break an existing DKIM signature: mailing lists, courtesy forwarders, and other paths that could add or modify headers or modify the message body (e.g., MTAs at hotels, hotspot networks used by traveling users, and the other scenarios from the previous section). that breakage matters even more when Author Domain Signing Practices are in play 😤
8.3. Signature Granularity 🔍
DKIM's use of domain names is optimized for organization-level signing, but you can totally administer subdomains or otherwise adjust signatures to support per-user identification 💖 there are two ways to get user-level granularity: either share the signing identity and add an extension to the i= value that has per-user granularity, or create and sign with unique per-user keys.
a subdomain or local part in the i= tag needs to be treated as an opaque identifier, so it doesn't have to correspond directly to a DNS subdomain or be a specific user address 🧩
the main way to sign with per-user keys requires each user to have a distinct DNS (sub)domain, where each distinct d= value has a key published. (it's possible, though not advised, to publish the same key in more than one distinct domain.) 🙃
you can publish per-user keys within a single domain or subdomain by using different selector values. but this isn't advised, and Assessors are unlikely to treat it uniquely 🙅♀️ the main purpose of selectors is key management, and the DKIM specification recommends against using them to determine or assess identities.
in most cases, signing email at per-user granularity would be impractical 😩 it's likely to get ignored, and here's why:
- likely to be ignored: today, if receivers verify DKIM signatures, they're generally taking the simplest possible approach. a lot of the time, keeping reputation info per user isn't interesting to them, mostly because the per-user volume is too small to matter. so even if senders take on the complexity needed for per-user signatures, receivers are unlikely to keep anything more than the base domain reputation 🥲
- difficult to manage: any scheme that involves maintaining a big pile of public keys might need infrastructure upgrades or serious admin expertise 😵 for domains of any size, keeping a valid per-user keypair, knowing when keys need to be revoked or added as users leave or join, and the overhead of the signing engine constantly swapping keys can create major, and often unnecessary, complexity. it's also worth noting that there's no way within the scope of the DKIM specification for a receiver to infer that a sender intends per-user granularity.
that said, the infrastructure that enables finer signature granularity can be used to identify segments that are smaller than a domain but much bigger than per-user 🎀 for example, a university might want to split student, staff, and faculty mail into three distinct streams with different reputations. it can do that by creating separate subdomains for each segment, and then either specifying the subdomains in the i= tag of the DKIM Signature, or adding subdomains to the d= tag and signing with a different key for each subdomain 🌈
for those who want to represent user-level granularity in signatures, the performance and management considerations above suggest it's more effective to specify a local part or subdomain extension in the i= tag, rather than extending the d= domain and publishing individual keys 🫶
8.4. Email Infrastructure Agents 🏠
okay bestie, the most common place you'll find DKIM living is inside an org's email service, like a department's mail setup or a boundary MTA 💅. Here are some general recs for that email infrastructure 📬.
Outbound: An MSA (Mail Submission Agent) or an outbound MTA used for mail submission needs to make sure the message it sends actually complies with the advertised email sending policy ✨. It also needs to be able to generate an operator alert if it figures out that the messages don't comply with the published DKIM sending policy 🚨.
An MSA needs to be aware that some MUAs might add their own signatures 🫶. If the MSA has to perform operations on a message to make it comply with its email sending policy, it needs to do that in a way that won't break those signatures, if at all possible 🧵.
MUAs equipped with the ability to sign ought not to be encouraged 🙅♀️. Security-wise, MUAs are generally not under the direct control of the people in responsible roles within an organization, so they're way more vulnerable to attack and compromise. That could expose private signing keys to intruders and jeopardize the integrity and reputation of the organization 💀.
Inbound: When an organization deploys DKIM, it needs to make sure that its email infrastructure components without primary roles in DKIM handling don't modify messages in ways that prevent subsequent verification 🛡️.
An inbound MTA or an MDA can incorporate an indication of the verification results into the message, such as with an Authentication-Results header field [RFC5451] 🎀.
Intermediaries: An email intermediary is both an inbound and outbound MTA 🔁. Each of the requirements outlined in the sections relating to MTAs applies. If the intermediary modifies a message in a way that breaks the signature, the intermediary.
- needs to deploy abuse filtering measures on the inbound mail, and
- probably also needs to remove all signatures that will be broken.
In addition, the intermediary can:
- verify the message signature prior to modification.
- incorporate an indication of the verification results into the message, such as using an
Authentication-Resultsheader field [RFC5451]. - sign the modified message including the verification results (e.g., the
Authentication-Resultsheader field).
8.5. Mail User Agent 📱
the DKIM spec is expected to be used mainly between Boundary MTAs, or other infrastructure components of the originating and receiving ADMDs 🌐. BUT nothing in DKIM is specific to those venues. In particular, MUAs can also support DKIM signing and verifying directly 🦋.
Outbound: An MUA can support signing even if mail is going to be relayed through an outbound MSA. In this case, the signature the MUA applies is in addition to any signature added by the MSA. However, the warnings in the previous section need to be taken into consideration ⚠️.
Some user software goes beyond simple user functionality and also performs MSA and MTA functions 🧠. When this is employed for sending directly to a receiving ADMD, the user software needs to be considered an outbound MTA.
Inbound: An MUA can rely on a report of a DKIM signature verification that took place at some point in the inbound MTA/MDA path (e.g., an Authentication-Results header field), or an MUA can perform DKIM signature verification directly 🔍. A verifying MUA needs to allow for the case where mail has been modified in the inbound MTA path. If a signature fails, the message is to be treated the same as a message that does not have a signature 🙈.
An MUA that looks for an Authentication-Results header field needs to be configurable so it can choose which Authentication-Results header fields are considered trustable 🔐. The MUA developer is encouraged to re-read the Security Considerations of [RFC5451] 📖.
DKIM requires that all verifiers treat messages with signatures that do not verify as if they are unsigned 🚫.
If verification in the client is to be acceptable to users, it is essential that successful verification of a signature not result in a less than satisfactory user experience compared to leaving the message unsigned 😭. The mere presence of a verified DKIM signature cannot be used by itself by an MUA to indicate that a message is to be treated better than a message without a verified DKIM signature. However, the fact that a DKIM signature was verified can be used as input into a reputation system (i.e., a whitelist of domains and users) for presentation of such indicators 🌟.
It is common for components of an ADMD's email infrastructure to wreck a message, such that a DKIM signature might be rendered invalid 💥. So users of MUAs that support DKIM signing and/or verifying need a basis for knowing that their associated email infrastructure will not break a signature 🧚.
9. Security Considerations 🔒
The security considerations of the DKIM protocol are described in the DKIM base specification [RFC4871]. This part is seriously important, bestie, so go give the base spec a read 🚨.
10. Acknowledgements 🙏
The effort of the DKIM Working Group is gratefully acknowledged 💜.
11. References 📚
11.1. Normative References
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009.
[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
[RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update", RFC 5672, August 2009.
11.2. Informative References
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
Appendix A. Migration Strategies 🦋
There are three migration occasions worth noting in particular for DKIM 🎀:
- Migrating from DomainKeys to DKIM.
- Migrating from a current hash algorithm to a new standardized hash algorithm.
- Migrating from a current signing algorithm to a new standardized signing algorithm.
The case of deploying a new key selector record is described elsewhere (Section 3.5).
As with any migration, the steps required will be determined by who is doing the migration and their assessment of:
- the users of what they are generating, or
- the providers of what they are consuming.
Signers and verifiers have different considerations 🌸.
A.1. Migrating from DomainKeys
DKIM replaces the earlier DomainKeys (DK) specification. Selector files are mostly compatible between the two specifications ✨.
A.1.1. Signers
A signer that currently signs with DK will go through various stages as it migrates to using DKIM, not all of which are required for all signers. The real questions that a signer needs to ask are:
- how many receivers or what types of receivers are only looking at the DK signatures and not the DKIM signatures, and
- how much does the signer care about those receivers?
If no one is looking at the DK signature any more, then it's no longer necessary to sign with DK. Or if all "large players" are looking at DKIM in addition to or instead of DK, a signer can choose to stop signing with DK 🧁.
With respect to signing policies, a reasonable, initial approach is to use DKIM signatures in the same way that DomainKeys signatures are already being used. In particular, the same selectors and DNS key records can be used for both, after verifying that they are compatible as discussed below 🔍.
Each secondary step in all of the following scenarios is to be prefaced with the gating factor "test, then when comfortable with the previous step's results, continue" 🧪.
One migration strategy is to:
- ensure that the current selector DNS key record is compatible with both DK and DKIM
- sign messages with both DK and DKIM signatures
- when it's decided that DK signatures are no longer necessary, stop signing with DK
Another migration strategy is to:
- add a new selector DNS key record only for DKIM signatures
- sign messages with both DK (using the old DNS key record) and DKIM signatures (using the new DNS key record)
- when it's decided that DK signatures are no longer necessary, stop signing with DK
- eventually remove the old DK selector DNS record
A combined migration strategy is to:
- ensure that the current selector DNS key record is compatible with both DK and DKIM
- start signing messages with both DK and DKIM signatures
- add a new selector DNS key record for DKIM signatures
- switch the DKIM signatures to use the new selector
- when it's decided that DK signatures are no longer necessary, stop signing with DK
- eventually remove the old DK selector DNS record
Another migration strategy is to:
- add a new selector DNS key record for DKIM signatures
- do a flash cut and replace the DK signatures with DKIM signatures
- eventually remove the old DK selector DNS record
Another migration strategy is to:
- ensure that the current selector DNS key record is compatible with both DK and DKIM
- do a flash cut and replace the DK signatures with DKIM signatures
Note that when you have separate key records for DK and DKIM, you can use the same public key for both 💖.
A.1.1.1. DNS Selector Key Records
Okay bestie, the first step in some of the scenarios above is making sure your selector DNS key records work for both DK and DKIM 💖 The record format was meant to be backwards compatible between the two, but not necessarily upwards compatible. DKIM glammed up the DK record by adding several optional parameters, which DK just needs to ignore 💅 But there's one big difference, and it lives in the g fields 👀 Here's how they're defined:
- g= granularity of the key: In both DK and DKIM, this is an optional field used to constrain which sending address(es) can legitimately use this selector. Unfortunately, an empty field (
"g=;") is treated differently. DKIM allows wildcards where DK does not. For DK, an empty field is the same as a missing value, and it's treated as allowing any sending address. For DKIM, an empty field only matches an empty local part. In DKIM, both a missing value and"g=*;"mean to allow any sending address.
Also, in DomainKeys the g field has to match the address in From:/Sender:, while in DKIM it has to match i=. This might or might not affect your transition 🤷
If your DK record has an empty g field ("g=;"), your best move is to edit the record and remove the empty field. That way the DK semantics stay the same and the DKIM semantics match 🎀
If your record doesn't have an empty g field ("g=;"), it's probably fine to leave it alone. But the best move is still to make sure it has a v field. When you decide to stop supporting DomainKeys and only support DKIM, it's important to verify that the g field is compatible with DKIM, and typically have "v=DKIM1;" in it. It's strongly encouraged that if you're using an empty g field in the DKIM selector, you include the v field ✨
A.1.1.2. Removing DomainKeys Signatures
The main place DomainKeys shows up is at boundary MTAs 🌸 Since no operational transition is ever instantaneous, it's advisable to keep doing DomainKeys signing until it's determined that DomainKeys receive-side support is no longer used, or has dropped enough. So a signer needs to add a DKIM signature to a message that also has a DomainKeys signature, and keep it there until they decide it's no longer useful. The signer can transition in a straightforward way, or more gradually. Note that because digital signatures aren't free, there's a cost to performing both signing algorithms, so signing with both ought not be needlessly prolonged 💸
The tricky part is deciding when DK signatures are no longer necessary 🥺 The real questions are: how many DomainKeys verifiers are there that do not also do DKIM verification, which of those are important, and how can you track their usage? Most of the early adopters of DK verification have added DKIM verification, but not all yet. If a verifier finds a message with both DK and DKIM, it can choose to verify both signatures, or just one or the other.
Many DNS services offer tracking statistics, so you can figure out how often a DNS record has been accessed 📊 By using separate DNS selector key records for your signatures, you can chart the use of your records over time and watch the trends. An extra thing to track is the verifiers that check both the DK and DKIM signatures, and discount those from the counts of DK selector usage. When the number of DK selector accesses reaches a low-enough level, that's the time to consider discontinuing signing with DK.
Note, this level of rigor is not required 💜 It is perfectly reasonable for a DK signer to decide to follow the "flash cut" scenario described above.
A.1.2. Verifiers
As a verifier, there are several issues to think about 🧐
A.1.2.1. Ought DK signature verification be performed?
At the time of writing, there's still a significant number of sites that are only producing DK signatures. Over time, this number is expected to go to zero, but it might take several years. So for the foreseeable future, it would be prudent for a verifier to look for and verify both DKIM and DK signatures 🛡️
A.1.2.2. Ought both DK and DKIM signatures be evaluated on a single message?
For a period of time, there will be sites that sign with both DK and DKIM. A verifier receiving a message with both types of signatures can verify both, or just one. One downside of verifying both is that signers will have a harder time deciding how many verifiers are still using their DK selectors. One transition strategy is to verify the DKIM signature, then only verify the DK signature if the DKIM verification fails 🔁
A.1.2.3. DNS Selector Key Records
The format of the DNS key record was meant to be backwards compatible between DK and DKIM, but not necessarily upwards compatible. DKIM has enhanced the DK record format by adding several optional parameters, which DK needs to ignore. However, there's one key difference between DK and DKIM DNS key records. Here are the definitions of the g fields:
- g= granularity of the key: In both DK and DKIM, this is an optional field used to constrain which sending address(es) can legitimately use this selector. Unfortunately, an empty field (
"g=;") is treated differently. For DK, an empty field is the same as a missing value, and it's treated as allowing any sending address. For DKIM, an empty field only matches an empty local part. - v= version of the selector: It is advised that a DKIM selector have
"v=DKIM1;"at its beginning, but it is not required.
If a DKIM verifier finds a selector record that has an empty g field ("g=;") and doesn't have a v field ("v=DKIM1;") at its beginning, it has to decide whether the record came from:
- a DK signer that transitioned to supporting DKIM but forgot to remove the
gfield (so it could be used by both DK and DKIM verifiers); or - a DKIM signer that truly meant to use the empty
gfield but forgot to put in thevfield. It is advised that you treat such records using the first interpretation, and treat them as if the signer did not have agfield in the record.
A.2. Migrating Hash Algorithms
[RFC4871] defines the use of two hash algorithms: SHA-1 and SHA-256. The security of all hash algorithms is constantly under attack, and SHA-1 has already shown weaknesses as of this writing. Migrating from SHA-1 to SHA-256 is not an issue, because all verifiers are already required to support SHA-256 🙌 But when it becomes necessary to replace SHA-256 with a more secure algorithm, there will be a migratory period. In the following, "NEWHASH" is used to represent a new hash algorithm. Section 4.1 of [RFC4871] briefly discusses this scenario.
A.2.1. Signers
As with migrating from DK to DKIM, migrating hash algorithms depends on the signer's best guess about the usefulness of continuing to sign with the older algorithms, and on the expected support for the newer algorithm by verifiers. How useful it is to keep signing with the older algorithms is also based on how broken the existing hash algorithms are considered, and how important that is to the signers.
One strategy is to wait until there's a large enough base of verifiers that support NEWHASH, and then flash cut to the new algorithm.
Another strategy is to sign with both the old and new hash algorithms for a period of time. This is especially useful for testing the new code that supports the new hash algorithm 🧪 Verifiers will keep accepting the signature for the older hash algorithm, and ought to ignore any signature that fails because the code is slightly wrong. Once the signer has determined that the new code is correct AND that there's a large enough base of verifiers that support NEWHASH, the signer can flash cut to the new algorithm.
One advantage of migrating hash algorithms is that the selector can be completely compatible for all hash algorithms. The key selector has an optional h= field that can be used to list the hash algorithms being used; it also limits the algorithms a verifier will accept. If the signer isn't currently using the key selector h= field, no change is required. If the signer is currently using it, NEWHASH will need to be added to the list, as in "h=sha256:NEWHASH;". (When the signer is no longer using SHA-256, it can be removed from the h= list.)
A.2.2. Verifiers
When a new hash algorithm becomes standardized, it's best for a verifier to start supporting it as quickly as possible 🚀
A.3. Migrating Signing Algorithms
[RFC4871] defines the use of the RSA signing algorithm. Similar to hashes, signing algorithms are constantly under attack, and when it becomes necessary to replace RSA with a newer signing algorithm, there will be a migratory period. In the following, "NEWALG" is used to represent a new signing algorithm.
A.3.1. Signers
As with the other migration issues discussed above, migrating signing algorithms depends on the signer's best guess about the utility of continuing to sign with the older algorithms, and on the expected support for the newer algorithm by verifiers. How useful it is to keep signing with the older algorithms is also based on how broken the existing signing algorithms are considered, and how important that is to the signers.
As before, the two basic strategies are to 1) wait until there's a sufficient base of verifiers that support NEWALG and then do a flash cut to NEWALG, and 2) use a phased approach by signing with both the old and new algorithms before removing support for the old algorithm.
It's unlikely that a new algorithm would be able to use the same public key as "rsa", so using the same selector DNS record for both algorithms' keys is ruled out 🚫 Therefore, to use the new algorithm, a new DNS selector record would need to be deployed in parallel with the existing DNS selector record for the existing algorithm. The new DNS selector record would specify a different k= value to reflect the use of NEWALG.
A.3.2. Verifiers
When a new hash algorithm becomes standardized, it's best for a verifier to start supporting it as quickly as possible 🚀
Appendix B. General Coding Criteria for Cryptographic Applications ✨
Okay bestie, this is the coding-vibes appendix 💅 The authors left a little note at the top saying this section could maybe get turned into a reference to something else, like another RFC 🙈
Getting a cryptographic algorithm implemented correctly is necessary but not sufficient for writing cryptographic applications 💖 Writing crypto code needs close attention to security concerns that only show up in crypto applications, so it's a whole vibe 🔥
Obviously you still need the usual security coding stuff, like not letting buffers or integers overflow or underflow 🙄 But you also have to be super careful with how you manage cryptographic private keys and session keys, making sure they get correctly initialized and disposed of 🔐
Operating system mechanisms that protect the confidentiality of private keys from other processes ought to be used whenever they're available 🛡️ Be extra careful when you hand memory pages back to the operating system, so private key info doesn't leak out to other processes 😭
Also, certain implementations of public key algorithms such as RSA can be vulnerable to a timing analysis attack 😬 Yikes, that's a scary one, so keep it on your radar.
Support for cryptographic hardware that provides key management capabilities is strongly encouraged 🦋 Performance is a nice bonus, but a lot of these devices also give you robust and verifiable management of private keys, which is iconic.
Good news though: appropriately designed and coded cryptographic libraries are available for most operating system platforms, and their license terms are compatible with commercial, open source and free software licenses 🌈 Using standard cryptographic libraries is strongly encouraged 🫶 They've been extensively tested, they cut down development time, and they support a wide range of cryptographic hardware. Main character energy for your codebase 👑
Authors' Addresses 💌
Tony Hansen
AT&T Laboratories
200 Laurel Ave. South
Middletown, NJ 07748
USA
EMail: tony+dkimov@maillennium.att.com
Ellen Siegel
Consultant
EMail: dkim@esiegel.net
Phillip Hallam-Baker
Default Deny Security, Inc.
EMail: phillip@hallambaker.com
Dave Crocker
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale, CA 94086
USA
EMail: dcrocker@bbiw.net📦 where this page comes from
- ietf: rfc5863 2010-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms