4

Suppose no DKIM keys are defined for sub.example.com, but a key with selector mykey is defined for example.com; that is, a DKIM record exists at mykey._domainkey.example.com in the DNS. Can <[email protected]> send mail that is signed using the key described in that DNS record? That is, does sub.example.com inherit the keys defined for its parent, example.com, if it has no keys defined for itself? I can't seem to find any info about this, neither online in general nor in the RFCs.


A separate, but related concern: For now, I am using the parent domain as the SDID; that is, email sent from <[email protected]> has a DKIM-Signature header with d=example.com. Receiving mail servers state that it passes the DKIM test, as well as the DMARC test when example.com has a DMARC policy of p=reject;sp=reject;adkim=r. Despite this passing the tests, is this good practice? Would it be better from the perspective of receiving mail servers if sub.example.com had its own DKIM record as well, and then mail from that domain had d=sub.example.com in the DKIM-Signature header?

I ask this because email for sub.example.com which has d=example.com seems to be flagged as spam, and it occurred to me that, for example, email from <[email protected]> or whatever domain could be signed by a key for example.net and pass the DMARC test as long as the DKIM-Signature header has d=example.net. Is this correct, and if so, is this a common/valid spam tactic? If so, are there any measures I can take to prevent spammers from abusing this vulnerability in order to appear as if they are sending mail from domains (or subdomains thereof) that I administer?

It looks like I would have to explicitly define SPF/DKIM/DMARC policies for all domains/subdomains that I intend to send mail from in order to achieve utmost authenticity, but this is undesirable because it is time consuming to maintain. Even then, the DKIM vulnerability described above could still be taken advantage of.

4 Answers 4

2

There is no inheritance.

RFC 6376 §3.6.2.1:

All DKIM keys are stored in a subdomain named "_domainkey". Given a DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag of "foo.bar", the DNS query will be for "foo.bar._domainkey.example.com".

That is all. There is no "climbing" up the root.

1

From rfc-editor

3.10. Signing by Parent Domains

In some circumstances, it is desirable for a domain to apply a signature on behalf of any of its subdomains without the need to maintain separate selectors (key records) in each subdomain. By default, private keys corresponding to key records can be used to sign messages for any subdomain of the domain in which they reside; for example, a key record for the domain example.com can be used to verify messages where the AUID ("i=" tag of the signature) is sub.example.com, or even sub1.sub2.example.com. In order to limit the capability of such keys when this is not intended, the "s" flag MAY be set in the "t=" tag of the key record, to constrain the validity of the domain of the AUID. If the referenced key record contains the "s" flag as part of the "t=" tag, the domain of the AUID ("i=" flag) MUST be the same as that of the SDID (d=) domain. If this flag is absent, the domain of the AUID MUST be the same as, or a subdomain of, the SDID.

1
  • Welcome to webmasters. You have provided a quote, but have you answered the question ? Commented Apr 10, 2023 at 3:09
1

Re the first question: As mentioned in Patrick's answer, there is no inheritance.


Re the second question: I've now realised that DKIM doesn't specify which SDIDs are permitted for particular email addresses. Thus, mail from <[email protected]> or <[email protected]> can be signed with d=example.net, and it is an issue for the administrator(s) of sub.example.com and example.com to say whether such signatures are legitimate for those domains or not.

DMARC solves this issue, though it assumes legitimate signatures will at least always come from the same organisational domain: having a DMARC rule in place with an adkim rule specified (whether adkim=r or adkim=s) means that signatures with d=example.net will fail the DMARC test. Thus, a DMARC record with an adkim tag suffices to prevent the impersonation tactic I described. Indeed, since there is a default adkim value of r, simply having any DMARC record at all suffices for this purpose.

On mail from <[email protected]>, if sub.example.com has no DMARC record, but example.com has a DMARC record with:

  • adkim=r (default), then signatures with d=sub.example.com or d=example.com are valid, as are signatures whose SDID is any other subdomain of the organisational domain (example.com), such as d=sub2.example.com or d=some.other.subdomain.of.example.com;

  • adkim=s, then only signatures with d=sub.example.com are valid.

As such, I will be sticking with my current practice, as it means I don't have to manage individual DKIM/CNAME records for each subdomain.


In response to @GermanJablo's comment, here is a further clarification of the behaviour:

If sub.example.com lacks a DMARC record (that is, a DNS query for _dmarc.sub.example.com TXT returns no records), then it inherits its DMARC rules from its parent, example.com, meaning that the rules in _dmarc.example.com TXT will apply to both example.com and sub.example.com. The only possible difference in rules between the two domains is that the DMARC policy ("none", "quarantine", or "reject") for sub.example.com can differ from that of example.com if the DMARC tag sp ("subdomain policy") is used to override the value of the p tag, which would otherwise also apply to sub.example.com.

Regardless of which domain's DMARC record the email domain's DMARC rules are taken from: if the DMARC rules specify adkim=s ("strict"), then this means that mail from <[email protected]> is only valid if DKIM-signed with SDID d=example.com, and mail from <[email protected]> is only valid if DKIM-signed with SDID d=sub.example.com. If you want mail from <[email protected]> to also be considered valid if DKIM-signed with SDID d=example.com (or SDID equal to any other subdomain of example.com, for that matter, e.g. d=sub2.example.com or d=some.other.subdomain.of.example.com), then you need to use adkim=r ("relaxed") instead.

For the technical details, see RFC 7489 §6.3, which in turn references §3.1.1. In particular, §3.1.1 states:

To illustrate, in relaxed mode, if a validated DKIM signature successfully verifies with a "d=" domain of "example.com", and the RFC5322.From address is "[email protected]", the DKIM "d=" domain and the RFC5322.From domain are considered to be "in alignment". In strict mode, this test would fail, since the "d=" domain does not exactly match the FQDN of the address.

4
  • confused with the 2 bullet points. Didn't you mean the following? - adkim=r, signatures with d=sub.example.com or d=example.com are permitted; - adkim=s, only signatures with d=example.com are permitted. Commented Jan 29 at 17:16
  • @GermanJablo The point relates to the validity of emails for sub.example.com (not example.com) when sub.example.com lacks its own DMARC record, but example.com has a DMARC record. I've edited the answer to provide additional clarification; hopefully that helps you!
    – Jivan Pal
    Commented Jan 30 at 1:46
  • Ok I'm confused, everyone is starting to talk about DMARC, but the OP's question is about DKIM?
    – Dan Chase
    Commented Mar 18 at 18:35
  • 1
    @DanChase The summary is: 'DKIM selectors don't have the "inherit from parent domain" property that you asked about, but you can achieve the security property you asked about (that is, instruct people to ignore signatures from other organisational domains or all other domains) by using an appropriate DMARC policy.'
    – Jivan Pal
    Commented Mar 19 at 10:04
0

The DMARC standard defines a lookup rule for DNS records, which explains how the relevant DMARC policy DNS record is determined. The rule is as follows:

  • Extract the email domain from the human-readable From address
  • Look up a DMARC record on the ‘_dmarc’ subdomain of the email domain terminate the lookup process
  • If no record is found, and the email domain is not an organizational domain, then look up the ‘_dmarc’ subdomain of the corresponding organizational domain. If a record is found on this subdomain, use that record to determine the DMARC policy.
  • If no record is found, then the process terminates and DMARC is not enforced for the message. A key takeaway from this process is that it is generally sufficient to define a single DMARC record on the organizational domain. Even if an email service provider or domain owner is using a subdomain to send email, they don’t need to create separate DMARC records for each subdomain.
4
  • Thanks for taking the time to answer. However, my question is about DKIM inheritance, if it exists, and not about DMARC inheritance. The only relevance I think DMARC has to this question is if adkim=s is set on example.com, in which case mail from <[email protected]> must have a signature with d=example.com, and not e.g. d=example.net, correct?
    – Jivan Pal
    Commented Jan 7, 2021 at 8:04
  • Or similarly, if sub.example.com has a DMARC policy with adkim=s, then mail from <[email protected]> must be signed with d=sub.example.com, not e.g. d=example.com or d=example.net, correct?
    – Jivan Pal
    Commented Jan 7, 2021 at 8:07
  • To clarify, in my question, sub.example.com has no published DMARC policy, so of course it will delegate to that of example.com, which has p=reject;sp=reject;adkim=r. The question is whether mail from <[email protected]> can be signed with s=mykey; d=sub.example.com given that the only DKIM record that exists is mykey._domainkey.example.com, not mykey._domainkey.sub.example.com.
    – Jivan Pal
    Commented Jan 7, 2021 at 8:12
  • Ahhh...sorry, I misread the question.
    – Steve
    Commented Jan 8, 2021 at 0:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.