On 29/09/2026 3:28 am, John Levine wrote:
According to Richard Clayton<[email protected]>:
A very common arrangement is for the brand to set up a CNAME rather than
sharing key material.
Huh? It needs to share the private key so the ESP can sign the mail.
The main benefits of the CNAME is that it's a lot shorter than the full
public key and so more likely to work with provisioning crudware that
can't handle long text strings, and it's easier for the brand to revoke
if they have a falling out with the ESP.
Normally, only the ESP has the private key in this configuration. The
main benefit of a CNAME is the ability to rotate keys without involving
the customer.
Neither is any more complex to revoke, but entering text fields can be a
little trickier than a CNAME. Few are manually editing zone files
directly these days. The difficulty comes from poor interface design and
the common belief that there is a 255 byte limit on text records...
crudware with a responsive UI.
The suggestion that domain A could add a header field on a per-email
basis that says "Domain B can make any changes to this email it wishes"
might be workable. That is, give carte blanche permission rather than
only allowing specific modifications.
Nobody thought much of that idea when I proposed it a decade ago. Perhaps
times have changed.
I think there has been some quite significant change during that period.
Senders are more aware of the need for DKIM, but not the specifics. The
ill-informed may know they need DKIM for deliverability, but when
informed that creating a CNAME allows a third party to sign any e-mail
as if it had originated from their domain, they look very differently at
the requirement.
The ESP market has largely moved away from SMTP relay services, to
API-based transactional e-mail. There seemed to be new services popping
up every week when I was trialling these services to recommend to users.
Because an API arrangement always requires the ESP to sign for the
domain, use of SMTP services is often tied to DKIM-based domain
verification, even though the customer doesn't necessarily want or
require it.
Due to the requirements of receivers, users experiencing deliverability
issues feel they are being forced down the ESP route, even if they are
perfectly capable of signing and delivering their own e-mail. Regardless
of whatever role you believe DKIM should play in delivery, the power
imbalance between senders and receivers needs addressing. Giving senders
more say over what happens to their e-mail and relying less on
heuristics would be advantageous.
The pandemic in particular showed there was a need to support Appendix
B.1 Alternate Submission Scenarios in order for e-mail to be delivered
reliably. I added DKIM support to my client in support of this. I am
aware of no ESP requiring CNAME record verification that caters
specifically to those use cases.
In terms of what this might look like, I previously proposed adding a
one-time or limited public key for recipient binding independent of the
DKIM-Signature. That same approach, including an Ed25519 public key
signed by the (potentially PQ) DKIM-Signature, can be used to sign any
additional header, including one granting authority for change to a
specific domain.
Regards,
R. Latimer
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
