On 1 Nov 2026, at 18:19, Richard Clayton wrote:
From: <[email protected]>
DKIM-Signature: d=esp.example.com ...
viz using the subdomain as the Signing Domain.
Do we have an understanding *why* they do this? The idea of selectors
was that if you had an ESP that you wanted to sign for you, you
published a selector record with their public key. I’m guessing now
that perhaps example.com delegates the entire esp.example.com zone to
the ESP so that it can rotate its own keys? Could this be done with
CNAME records instead?
Since DKIM2 has a consistent rule that says that a signing domain is
only allowed to sign things (there are 4 places we use a "relaxed
domain
match") at its own level or below this just does not work in DKIM2.
You
don't get a "Fully Verified DKIM2 Message" as a Verifier result.
DMARC dealt with this by means of "strict/relaxed" alignment and
(rather
holding our noses) we have now done something similar in the DKIM2
spec.
We looked at real data from $DAYJOB$ and use of subdomains is really
rather widespread and it has always been a design aim of DKIM2 that
customers of ESPs do not have to update their DNS to use DKIM2
(because
DNS updating is much harder than it has any right to be in 2026).
I think it might be worth questioning that design aim here…see below.
Anyway ... the spec now says that when deciding if a From header field
is Authentic (the other 3 uses of relaxed domain match are unaffected)
the matching algorithm in run in both directions, both "up" and
"down".
Hence using a subdomain as the Signing Domain now works OK.
Of course in some cases this is Not A Good Idea At All. Consider
ga.gov
that delegates primaryschool.ga.gov -- if the primary school is
compromised and their private keys stolen then the thieves can sign a
message with
"From: <[email protected]>"
and it will be believed to be Authentic.
There are worse examples. In this case, at least ‘primaryschool’ has
some administrative responsibility to the State of Georgia. But there
are lots of TLDs that delegate at a lower level and have little
relationship to eah other. .co.uk, for example. Now, I understand that
a.co.uk could sign for co.uk but not b.co.uk, but I’m still concerned
that this “reverse delegation” is not the way delegation works.
So we have added a "Domain Policy Record" which contains at "strict"
flag which says that subdomains cannot authenticate their parents. We
have put this flag at _domainkeys.example.com (i.e. above the
selectors
at the location that the original DomainKeys scheme (pre-DKIM1) used.
We
have of course ensured that ancient DomainKeys records don't
interfere.
So _domainkeys.ga.gov adds a record "v=DKIM1; f=strict;" and the
thieves
will be frustrated.
We are holding our noses, BTW, because people who want subdomains to
be
restricted have to act to add a new record -- we generally like
security
controls to fail closed, but in this case this is incompatible with
the
design aim of having existing DKIM1 keys continue to work.
Again, I think that the security aspect should take precedence over
inconveniencing the ESPs and their customers. And you are violating that
design aim anyway for domains that don’t use ESPs in this way and want
the current level of security (i.e., don’t want subdomains to sign
parent-domain emails).
-Jim
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]