1

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 <alice@sub.example.com> 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 <alice@sub.example.com> 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 <alice@sub.example.com> 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.

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 <alice@example.com> must have a signature with d=example.com, and not e.g. d=example.net, correct? – Jivan Pal Jan 7 at 8:04
  • Or similarly, if sub.example.com has a DMARC policy with adkim=s, then mail from <alice@sub.example.com> must be signed with d=sub.example.com, not e.g. d=example.com or d=example.net, correct? – Jivan Pal Jan 7 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 <alice@sub.example.com> 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 Jan 7 at 8:12
  • Ahhh...sorry, I misread the question. – Steve Jan 8 at 0:40
0

Re the first question: I still do not know whether DKIM inheritance occurs, but I will test this with some mail providers and feed back. I have still not figured out whether the specification explicitly allows/forbids inheritance, but if I do, I'll edit this answer and mark the question as solved.


Re the second question: I've now realised that DKIM doesn't specify which SDIDs are permitted for particular email addresses. Thus, mail from <alice@sub.example.com> or <alice@example.com> 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 policy 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 policy with an adkim rule suffices to prevent the impersonation tactic I described.

On mail from <alice@sub.example.com>, if sub.example.com has no DMARC policy, but example.com has a DMARC policy with:

  • adkim=r, then only signatures with d=sub.example.com or d=example.com are permitted;
  • adkim=s, then only signatures with d=sub.example.com are permitted.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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