1通のメール、3つのID：SPF、DKIM、DMARCの解説

← 全記事 Insight 1通のメール、3つのID：SPF、DKIM、DMARCの解説 2026年8月10日・8分読了 1通のメールには、実際に配信されたIPアドレスに加えて、3つの独立したドメインIDが含まれており、それらのいずれかが一致することを要求するものは何もありません。SPF、DKIM、DMARCに関する混乱のほとんどは、チェックすべき「送信者」が1つだけであると仮定することから生じます。3つのIDがあり、それぞれ異なるメカニズムによってチェックされ、メッセージは3つのうち2つが異なる方向を指していてもDMARCをパスできます。ここでは、インボイスメールをメールサービスプロバイダー（ESP）経由で送信する、ほとんどのSaaS請求システムが実際にメールを送信する方法を示す構築された例（実際の顧客メッセージではありませんが、現実的で一般的な構成）を示します。 メッセージ内のID acme-example.comの顧客は、メールクライアントに「Acme Billing」からのインボイスを表示します。その下に、これらの値がメッセージの認証を決定します。 Return-Path: <bounces+4471-acmecorp=acme-example.com@bounce.esp-example.net> Received: from mta7.esp-example.net (mta7.esp-example.net [198.51.100.23]) From: "Acme Billing" <billing@acme-example.com> DKIM-Signature: v=1; a=rsa-sha256; d=acme-example.com; s=s2; ... Authentication-Results: mx.recipientdomain.com; spf=pass (sending IP 198.51.100.23) smtp.mailfrom=bounce.esp-example.net; dkim=pass header.d=acme-example.com header.s=s2; dmarc=pass (p=REJECT sp=REJECT) header.from=acme-example.com 3つのドメインIDと1つのサポートIP、1つのメッセージ： 表示されるFrom: billing@acme-example.com、Fromヘッダーから読み取られます。これは人間が見る唯一のIDであり、DMARCがアライメントを気にする唯一のIDです。 エンベロープ送信者: bounce.esp-example.net、Return-Path（同等のSMTP MAIL FROM）から読み取られます。バウンスはこちらに送られ、ESPのものであり、Acmeのものではありません。SPFはこのドメインをチェックし、表示されるFromではありません。 DKIMドメイン: acme-example.com、DKIM-Signatureヘッダーのd=から読み取られます。Acmeは、ESPのデフォルトを使用するのではなく、ESPでカスタム署名ドメインを設定しました。これは、エンベロープと表示されるFromの両方から独立したIDです。 送信IP: 198.51.100.23、ESPのプラットフォーム上の共有IP、Receivedヘッダーから読み取られます。これはドメインIDではなく、配信元です。SPFのジョブは、このIPがエンベロープドメイン（acme-example.comではなく）の送信を許可されているかどうかをチェックすることです。 チェックは実際にどのように実行されるか SPF（RFC 7208）は1つの質問をします：送信IP 198.51.100.23は、エンベロープドメインbounce.esp-example.netの送信を許可されていますか？ESPはそのサブドメインに独自の送信IPをリストしたSPFレコードを公開しているため、答えは「はい」です。このチェックにはacme-example.comはどこにも現れません。 DMARCはSPF認証されたMAIL FROM IDをアライメントに使用するため、エンベロープドメイン（送信IP自体ではなく）が何かに比較されるのは、常にエンベロープドメインです。 DKIM（RFC 6376）は異なる質問をします：DKIM-Signatureの暗号化署名は、s2._domainkey.acme-example.comで公開されている公開鍵と一致しますか？Acmeは、ESPでカスタムDKIMを設定したときにその鍵ペアを生成したため、一致します。このチェックはエンベロープまたは送信IPを見ることはありません。それは、署名されたメッセージの部分（署名でカバーされているヘッダーフィールドと本文コンテンツ）が、acme-example.comの秘密鍵の所有者が署名したものと一致し、転送中に変更されなかったことを証明するだけです。署名から除外されたフィールドは、それによって保護されません。 DMARC（RFC 9989）は3番目のチェックを追加しません。それは、すでに結果を生成した2つのうちのいずれかを取り、その結果のドメインが表示されるFromドメインacme-example.comと一致するかどうかを尋ねます。ここでは、SPFの認証されたMAIL FROMドメインはbounce.esp-example.netであり、これはDMARCアライメントモードのいずれの下でもacme-example.comと一致しないため、SPF自体がパスしても、DMARCのSPFレッグはアライメントで失敗します。DKIMの認証されたドメインは正確にacme-example.comであり、緩和および厳密なアライメントの両方で同一の一致であるため、DKIMレッグはパスします。DMARCはアライメントパスが1つあれば十分なので、メッセージはDKIM単独でDMARCをパスします。これが、上記のヘッダーブロックにAcmeのものではないドメインの隣にspf=passと表示され、それでもdmarc=passと表示される理由です。 flowchart TD M[Email] --> V[Visible From: acme-example.com] M --> E[Envelope sender: bounce.esp-example.net] M --> K[DKIM d=: acme-example.com] M --> I[Delivery IP: 198.51.100.23] E --> SPF{SPF authenticates envelope} I --> SPF SPF -->|pass, but envelope does not align to From| SPFALIGN[SPF leg: fails alignment] K --> DKIM{DKIM signature verifies} DKIM -->|pass, d= matches From exactly| DKIMALIGN[DKIM leg: passes alignment] SPFALIGN --> DMARC{Either leg aligned?} DKIMALIGN --> DMARC DMARC -->|yes, DKIM leg| PASS([DMARC pass]) 同じメッセージが2つの独立したレッグで評価されます。SPFはパスしますが、アライメントしません。DKIMはパスし、アライメントします。DMARCはどちらか一方を必要とします。 ここで問題が発生する この例で詳細を1つ変更すると、結果が反転します。AcmeがESPでカスタムDKIMを設定しなかった場合、メッセージはESPのデフォルト署名をd=esp-example.netで運ぶことになります。その署名は依然として検証され、ESPは正当にメールを送信しましたが、esp-example.netはacme-example.comと一致しません。今やどちらのレッグもアライメントせず、完全に正当なインボイスがDMARCに失敗します。これは、実際のESP統合がDMARCを壊す方法の1つです。偽造されたメッセージではなく、正しく認証されたメッセージであり、アライメントされた唯一のIDが設定されていなかったのです。メールクライアント側からは、正当なメール、正規のプロバイダーを通じて送信され、スパムに着信したり拒否されたりするのと全く同じように見えます。違いは完全にd=にあり、これは送信者のマーケティングチームが決して見ず、存在を知る理由がないフィールドです。それを診断するには、DKIM-Signatureヘッダーを直接読むか、DMARC集計レポートで、DKIM認証結果のドメインフィールドを、送信IPやエンベロープ（どちらも問題なく見える）ではなく、identifiers/header_fromの組織ドメインと比較する必要があります。集計レポート（RFC 9990）は実際には2つの別々の回答を運び、それらを混同することが、ほとんどの人がこれを誤読する原因です。auth_results要素は、SPFとDKIMの認証結果を、DMARCに関して解釈せずに、それ自身の用語で記録します：auth_results/dkim/domainは検証されたd=値であり、auth_results/spf/domainはチェックされたMAIL FROMドメインです。個別のpolicy_evaluated要素は、DMARCの目的でそれらの結果が表示されるFromドメインと一致したかどうかを記録します：policy_evaluated/spfおよびpolicy_evaluated/dkim。カスタムDKIMが設定される前は、そのESPの送信IPのレポートレコードは、auth_resultsの両方の基盤チェック（ESPのエンベロープドメインに対するSPF、ESP自身の署名ドメインに対するDKIM）がパスしたことを示すことができますが、policy_evaluatedは、認証されたドメインがacme-example.comと一致しないため、spfとdkimの両方が失敗したと示します。カスタムDKIMが設定された後、auth_results/dkim/domainはacme-example.comと読み取られ、policy_evaluated/dkimはパスに切り替わり、全体的な処理はそれに従います。送信IPやボリュームに関して、2つの間では何も変更されず、検証されたDKIMチェックの署名ドメインのみが変更されます。 緩和対厳密なアライメント この例のどちらのレッグも、サブドメインが親組織ドメインと一致すると見なされるDMARCのデフォルトの緩和アライメントの下でチェックされました。d=mail.acme-example.comからのDKIM署名は、緩和モードの下でもacme-example.comのFromと一致します。DMARCレコードにadkim=sまたはaspf=sを設定すると、アライメントは厳密な一致に締め付けられ、同じサブドメイン署名は失敗します。ほとんどの送信者は、そうする特別な理由がない限り、緩和モードのままにしておくべきです。厳密モードは、攻撃者が似たようなドメインを制御しても影響を受けないため、正規に構造化されたメール（親に代わって署名するサブドメイン）を壊すことが、何かを止めるよりも頻繁に起こります。 独自のESPをチェックする ESP経由でドメインを送信している場合は、市場