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]

Reply via email to