はじめに
DKIMとは，メールの送信者の認証とメッセージの改ざんの検出を行う仕組みです。この記事では「DKIMにおける検証方式として，電子証明書ではなく，なぜDNSを採用したのか」という疑問に対する調査結果を紹介します。なお，DKIMの仕組みや最近話題に取り上げられることが多い背景は，この記事では扱いません。
結論
結論を先に述べると，電子証明書という新たなインフラがメール送受信の仕組みに関与することに起因する混乱を避けるためです。
電子証明書
電子証明書は，認証局によって発行された証明書で，公開鍵を含みます。第三者（認証局）から発行してもらう電子証明書によって公開鍵を証明し，ひいては暗号鍵の正当な持ち主であることを保証する仕組みです。認証局が関与することから，電子証明書を利用した暗号化や署名は（秘密鍵を正しく扱う場合においては）機密性や完全性を担保するために有効な仕組みです。
したがって，DKIMに電子証明書を適用して送信メールを認証する方式は優れたアイデアです。しかし，DKIMでは電子証明書ではなく，DNSのレコードに公開鍵を公開する方式を使っています。
RFCによると
DKIMの概要は，RFC5585に規定されています。このドキュメントでは以下のように述べられています（1.2. Prior Workより引用)。
Further, DKIM's key management is provided by adding information records to the existing Domain Name System (DNS) [RFC1034], rather than requiring deployment of a new query infrastructure. This approach has significant operational advantages. First, it avoids the considerable barrier of creating a new global infrastructure; hence, it leverages a global base of administrative experience and highly reliable distributed operation. Second, the technical aspect of the DNS is already known to be efficient. Any new service would have to undergo a period of gradual maturation, with potentially problematic early-stage behaviors. By (re-)using the DNS, DKIM avoids these growing pains.
意訳してみました。
DKIMの鍵管理では、新しいクエリインフラストラクチャの展開（訳注：電子証明書を採用したPKIなど？）を要求するのではなく、既存のDNSにレコードを追加することにより提供されます。このアプローチは運用上の利点があります。
1点目は，新しいグローバル基盤を構築する（訳注：メール基盤の再構築？）という障壁を避けることができます。そのため、グローバルな運営経験と信頼性の高い分散運営を基盤としています（訳注：すでに存在するメール基盤を活用できる？）。
2点目は、DNSの技術的側面はすでに効率的であることが知られています。どのような新しいサービスであっても、初期段階での動作に問題が生じる可能性があり、徐々に成熟していく期間を経なければならないけません。DNSを（再）利用することで、DKIMはこうした成長の痛みを回避することができます。
RFCの解釈
RFCを解釈すると，次の2点が挙げられます。
- 今までうまく動いていた仕組みはそのまま活用した方が良い（この仕組みにはDNSも含まれると解釈できます）
- DNSを活用することで，導入初期のトラブルを押さえることができる
つまり，DKIMの導入にあたっては，新しい仕組み（電子証明書）の導入ではなく枯れた技術（DNS）をできるだけ活用しながら，移行時の混乱を避けたい，ということのようです。
まとめ
メールのようにインターネット全体で分散・協調して動く仕組みを，ある日一斉に新しい仕組みに切り替えることはできません。新旧のシステムがあちこちで混在し，徐々に新しい仕組みに集約されていきます。プロトコルを設計する側（IETF）としては，相互運用性に加え，混在期間中・移行期間中に混乱を招かないような配慮も必要だったのでしょう。実際，DNSを使ったDKIMであっても，GoogleがGmailに適用することで大混乱したのは記憶に新しいところです（Googleは悪者ではない）。DKIMに電子証明書を導入したとすると，これ以上の混乱が起きることは想像に難くありません。
このような混乱を最小限に抑えるために，DKIMではDNSのレコードを採用したようです。
その他
「SMTPSやPOP3S，IMAP4Sでは以前から電子証明書（サーバ証明書）を使ってるのでは？」というツッコミもあろうかと思います。確かにこれらのプロトコルでは電子証明書を利用します。ただ，これらのプロトコルは下位層（トランスポート層相当）のTLSで電子証明書を利用しているだけで，その上位層であるメール送受信の仕組みに直接関与しているわけではありません。
また，私見ですがOpenSSLといったTLSライブラリを使わずに済むといった利点もあると考えます。TLSライブラリではX.509の証明書検証に関する脆弱性が見つかることがあり（最近だとCVE-2022-3602、CVE-2022-3786など），これらの脆弱性を悪用すると，受信側のメールサーバに悪影響を与えることも考えられます。電子証明書を使わなければ，TLSライブラリの脆弱性の影響を避けることができます。
その他に，電子証明書を使わない理由として，電子証明書のコストや処理負荷を理由として説明しているサイトも見受けられました。しかしながら，RFCにはコストや処理負荷を理由として電子証明書を採用しなかった，という記載は私には見つけられませんでした（もしかしたらどこかにあるかもしれませんが，その場合には是非教えてください）。以降は私見です。確かに電子証明書の費用や，電子証明書の処理に伴う処理負荷は，導入する側からしてみると考慮が必要な事項ではあります。ただ，HTTPSでの普及の実績を踏まえると，メール送受信に関してだけコストや処理負荷があるので除外というのは，標準化においては考えづらいと考えます。
参考文献
https://www.nic.ad.jp/ja/basics/terms/dkim.html
https://tex2e.github.io/rfc-translater/html/rfc5585.html