SPF: その通りです。ベンダーはエンベロープをアドレスから組織のドメインに合わせて変更する必要があります。これを非常に簡単に行う人もいれば、難しい人もいれば、エンベロープをまったく変更しない人もいます。サードパーティにエンベロープの変更を依頼するときに覚えておくべき重要なことは、ほとんどの場合、変更によってバウンスが見えなくなるということです。サードパーティはリストの衛生管理などのためにバウンスを必要としますが、これは問題です。これを回避するには、組織ドメインのサブドメインを使用して、そこに MX をセットアップしてもらいます。たとえば、あなたが companyname.com でサード パーティが vendorname.com の場合、ベンダー バウンス.company.com のエンベロープ フロムを使用してから、ベンダー バウンス用に vendorname.com に戻る MX レコードを設定します。 company.com は、一致した方法で問題を解決します。
DKIM: DKIM 自体はどちらのアドレスもチェックしません。DKIM 署名を見ると、d=gmail.com のような aquate が表示されます。このドメインは、メッセージを検証するための公開鍵を取得するために使用されます。DKIM 自体にはそのような要件はありませんが、DMARC では、DKIM 署名の d= ドメインが from ヘッダーの組織ドメインと一致する必要があります。これは、RFC 7489 のセクション 3.1 で説明されているように、識別子の配置です ( https://www.rfc-editor.org/rfc/rfc7489#section-3.1) 実用的なレベルでは、DNS 名前空間で公開キーを公開する必要があり、署名するサード パーティは付随する秘密キーを使用してメッセージに署名する必要があります。特定の DNS 名前空間 (selector._domainkey.companyname.com など) で公開鍵を公開することにより、vendorname.com などの秘密鍵の所有者が会社名.com に DMARC 認証された電子メールを送信することを承認します。
1 つの注意: DMARC 自体は常に from ヘッダー、つまりユーザーに表示されるものをレコードのドメインとして使用します。識別子のアライメントでは、SPF や DKIM などの個々の認証プロトコルによって認証されるもの (それぞれエンベロープ from および d= ドメイン) を必要とし、from ヘッダー内のドメインと (基本的に一致するように) アライメントします。
それは役に立ちますか？