DKIM署名にはどのドメイン名を含める必要がありますか？
これらの手順 に従ってOpenDKIMをPostfixでセットアップしましたが、宣伝どおりに機能します。私の送信メールには、DKIM-Signatureヘッダーが追加されています。次に例を示します。
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com; s=mail;
t=1398638300; bh=mk/7yYUxFCWz+ZHB0opJIA/S3J5ELoPZPfAO0KQdVg4=;
h=Date:From:To:Subject:From;
b=fPPfUliJUgA0re38nkJ2R18TeFgbamOv1U8nDb9958eTeAT6Mp7oq4WGrHPiPmc+b
mrLu9RuW0/S4d0ipkilNZDxgecwl7qttrDbTEkWxdhwwTSe5FL3OBaUoUxJFrMGjmY
RdBjY5ZWtvk29+gXZ+af5Of9OrY7COLlqGkFXRXw=
私の質問は、上記のd=パラメーターについてです。 1つのメールサーバーが複数の仮想ドメインの送信メールを処理する場合、d =にはメッセージを送信するメールサーバーを含める必要がありますか？または、From：アドレスに表示されるドメインである必要がありますか？
私はこの主題について RFC 6376 を読み込もうとしましたが、私が見つけた唯一の関連ビットは次のとおりです。
d= The SDID claiming responsibility for an introduction of a message
into the mail stream [...] The conventions and semantics used by a Signer to
create and use a specific SDID are outside the scope of this specification
ここにいる誰かが、d =パラメーターが実際にどのように使用されているかを知っていることを望んでいます。
送信者のドメインからのDKIM署名は最も信頼性が高く、送信者の電子メールポリシーで必要になる場合があります。 DMARCの導入により、ドメインは、ポリシーを満たさない電子メールに対して必要なアクションを含むポリシーを公開できるようになりました。
DKIMは、ヘッダーからの送信者と一致することを目的としていますが、エンベロープ送信者ではない可能性があります。 SPFは、送信サーバーを使用してドメインにメールを送信するためのエンベロープ送信者の許可を検証します。 DMARCは、より良いポリシーフレームワークを提供するために、2つを結び付けます。
3つのメカニズムはすべて、関連するドメインのDNSツリーにデータを公開する必要があります。
サードパーティからのDKIMは、署名されたコンテンツがそのドメインによる署名後に変更されたかどうかを示すだけです。これは否認には役立つ場合がありますが、送信者のレピュテーションには役立ちません。
あなたは間違った視点から質問を見ています-送信者のそれ。あなたはそれを受信機の観点から見ているべきです。
たとえば、person @ foo.comがmailserverrandom.com経由でメッセージを送信しているとします。どちらのドメインについても何も知りません。 [email protected]からの電子メールのfoo.comからの署名は、何かを教えてくれますか？ foo.comは、管理している電子メールアカウントについて何かを言う立場にあるため、明らかにそうです。 [email protected]からの電子メールのrandom.comからの署名は何を教えてくれますか？ごくわずか。 random.comはスパマーによって制御され、person @ foo.comから送信されたと主張するスパムを送信してフィルターを通過する可能性があります。したがって、random.comについて何も知らなければ、その署名も何の意味もありません。
また、電子メールに複数のDKIM署名を含めることが許可されていることを忘れないでください。したがって、メーリングリストを実行している場合、リストに送信されるメッセージのFromヘッダーにドメインからの署名が含まれている可能性があります。メーリングリストは、封筒に表示されているリストのドメインを使用して、署名する場合もあります。どちらも、メッセージを信頼するかどうかを決定するのに役立つ情報を受信者に提供します。
DKIMでは、 d=値（または関連するi=値） がメッセージ内の他のヘッダーと一致する必要はありません。 DKIM自体は、送信者ではなく署名者のみを認証し、この情報を有用にするためのポリシーを実装するために受信者に任せます。
DMARCを使用すると、送信者ドメインでDKIMのポリシーを指定できるため、受信者にとってDKIM署名がはるかに便利になります。 DMARCの場合 d=ヘッダーとFrom:ヘッダーは一致する必要があります （指定された厳密さに応じて、正確に、またはサブドメインを許可します）。
OpenDKIMの場合、複数のドメインを適切に処理するために SigningTableおよびKeyTable構成ディレクティブ を確認する必要があります。
DKIMはドメインベースです。電子メールの署名ドメインについてのみ通知します。 Eメールサービスプロバイダーのドメインであるd = esp.comを使用する場合、受信メールシステムはesp.comのレピュテーションを使用してEメールについて決定します。また、d = customer.com（From：addressのドメインなど）が使用されている場合は、customer.comのレピュテーションスコアが使用されます。したがって、esp.comの評判が高い場合は、d = esp.comを使用することをお勧めします。それ以外の場合は、d = customer.comに固執します
から RFC 8376 標準：
署名が検証されたら、その情報をID評価者（明示的な許可/ホワイトリストやレピュテーションシステムなど）および/またはエンドユーザーに伝達する必要があります。 SDIDがFrom：ヘッダーフィールドのアドレスと同じでない場合、メールシステムは実際のSDIDが読者に明確であることを確認するために苦労する必要があります。
SDID：署名ドメイン識別子（= d）
更新：
著者ベースの署名とサードパーティの署名の詳細 dkim.org仕様 ：
ドメインがRFC5322.Fromアドレスのドメインと一致しない署名は、サードパーティの署名と呼ばれることがあります。 ...サードパーティの署名の価値については、しばしば激しい議論がありますが...
一部のユーザーにとって、作成者ドメイン（RFC5322.Fromアドレスのドメイン）に関係のない署名は、作成者署名の存在によってRFC5322.Fromヘッダーのアドレスの使用が許可されることが保証されるという前提があるため、価値が低くなります。 。
他の人にとっては、その関連性は、問題のIDに割り当てられた記録された行動データ、つまり信頼性の評価または評判に厳密に関連付けられています...したがって、ドメインの有効な署名を含むメッセージの配信を容易にすることはリスクが低いです。そのドメインがメッセージのRFC5322.Fromヘッダーフィールドのアドレスに関連付けられているかどうかに関係なく、強い肯定的な評判。
Gmailからのいくつかのメールを見ると、dパラメータにエンベロープ送信者のドメインが含まれていることがわかりました。したがって、MAIL From SMTPコマンドで使用されるアドレスは、dパラメーターで使用されるアドレスです。
エンベロープ送信者を使用する以外に、ドメインを決定する他の方法を考えることはできません。