メールの送信元認証にはSPF、DKIM、DMARCがあります。ただし、3つは同じ情報を確認しているわけではありません。メールには「配送に使う送信元」「受信者に表示する送信元」「電子署名に使うドメイン」があり、この違いを理解しないと、SPFやDKIMがPassしているのにDMARCがFailする理由が分かりにくくなります。
この記事では、MAIL FROM、Fromヘッダー、DKIM-Signatureヘッダーのd=の役割と、誰がその値を設定するのか、途中で変更される可能性があるのか、DMARCがどのように送信元ドメインを判定するのかを整理します。
メールで使われる3つの送信元情報
| 項目 | 役割 | 主に確認する仕組み |
|---|---|---|
| MAIL FROM | SMTP配送で使う技術的な送信者。バウンスメールの戻り先 | SPF |
| Fromヘッダー | Outlookなどで受信者に表示される差出人 | DMARCの基準 |
| DKIMのd= | メールへ電子署名したドメイン | DKIM |
1．MAIL FROM（エンベロープFrom）
MAIL FROMは、メールサーバー間の配送で使われる技術的な送信者アドレスです。配信不能通知（NDR）やバウンスメールの戻り先として利用されます。
受信者に表示されるFromとは異なるアドレスやドメインが使われる場合があります。たとえば表示Fromがsales@company.exampleでも、メール配信サービスがMAIL FROMとしてbounce@service.example.netを使用する構成は珍しくありません。
MAIL FROMの値を設定する主体
MAIL FROMは、受信側メールサーバーへSMTP接続してメールを渡すシステムが、SMTPのMAIL FROMコマンドで指定します。一般的な社内メールであれば送信元メールサーバー、外部の一斉配信サービスを利用する場合はその配信サービスが設定主体になります。
利用者がOutlookの差出人欄へ入力したアドレスが、そのままMAIL FROMになるとは限りません。Microsoft 365やメール配信サービスは、バウンス処理や送信管理のために別のMAIL FROMを設定することがあります。
配送途中で変更される可能性
通常のSMTPリレーでは、受け取ったMAIL FROMを維持して次のサーバーへ渡すのが基本です。単に中継サーバーを通過しただけで、常に値が書き換えられるわけではありません。
一方、転送サービス、メーリングリスト、セキュリティゲートウェイなどがメールを新しいSMTPトランザクションとして再送信する場合は、MAIL FROMを変更できます。代表例がSRS（Sender Rewriting Scheme）で、転送後にSPFが失敗する問題を軽減するため、転送システムがMAIL FROMを書き換えます。このような変更は、後述するSPFおよびSPF alignmentの判定に影響します。具体的な影響は、後半の「配送途中で送信元情報が変更された場合」で説明します。
2．Fromヘッダー（表示From）
Fromヘッダーは、Outlookなどのメールソフトで受信者に差出人として表示されるアドレスです。受信者はこの値を見て「誰から届いたメールか」を判断します。
Fromヘッダーの値を設定する主体
基本的には、送信者がメールソフトや送信アプリケーションの差出人欄を通じて設定します。ただし、実際に指定できるアドレスはメールサービス側の権限設定に左右されます。Microsoft 365で共有メールボックスや別ユーザーのアドレスから送る場合は、「差出人を指定して送信」などの権限が必要です。
アプリケーションやメール配信サービスから送信する場合は、そのシステムに登録されたテンプレートや送信設定がFromヘッダーを生成します。ヘッダーへ文字列を記載するだけなら技術的には容易なため、Fromヘッダーの値だけでは正当な送信者かどうかを判断できません。
配送途中で変更される可能性
通常のメールサーバーはFromヘッダーをそのまま配送しますが、転送サービスやメールゲートウェイなどが、運用上の理由から書き換える場合があります。この段階では「Fromヘッダーは配送途中でも変更され得る」と押さえておけば十分です。変更が送信元認証へ与える影響は、後半の「配送途中で送信元情報が変更された場合」で説明します。
3．DKIM-Signatureヘッダーのd=
DKIMでは、送信側がメールに電子署名し、受信側がDNSに公開された鍵で署名を検証します。DKIM-Signatureヘッダーのd=には、その署名に責任を持つドメインが記録されます。
DKIM単体では、d=のドメインと表示Fromのドメインが同じである必要はありません。たとえば表示Fromがceo@company.example、DKIM署名がd=mailer.example.netでも、署名の検証自体はPassする可能性があります。
DKIMのd=を設定する主体
d=を設定するのは、秘密鍵を使ってDKIM署名を作成する「DKIM署名者」です。通常は組織の送信メールサーバー、Microsoft 365などのメールサービス、メール配信サービス、または送信経路上のメールゲートウェイが署名者になります。
管理者は、署名に使うドメインとセレクター、秘密鍵をメールサービスへ設定します。送信時にDKIM署名機能が、設定されたドメインをd=、使用する鍵を識別する名前をs=としてDKIM-Signatureヘッダーを生成します。
配送途中で変更される可能性
既存のDKIM-Signatureヘッダーに記載されたd=を途中で書き換えると、署名値との整合性が失われ、検証は失敗します。d=を含むDKIM-Signatureヘッダー自体が署名計算の対象になるためです。
ただし、中継サービスは既存のDKIM-Signatureヘッダーを削除したり、自身のドメインを使った別のDKIM署名を追加したりできます。1通のメールに複数のDKIM-Signatureヘッダーが付くこともあります。また、署名対象になっている本文やヘッダーが中継時に変更されると、元のDKIM署名はFailする可能性があります。
SPFが確認する対象
端的に言うと、SPFは「受信側へ接続してきたメールサーバーのIPアドレスが、MAIL FROMドメインからメールを送信することを許可されているか」を確認する認証方式です。
この確認によって得られるPassやFailなどの判定を、この記事ではSPFの認証結果と呼びます。具体的には、受信側が次の流れでSPF認証を行います。
SPF認証で確認する仕組み
SPFを確認する受信側メールサーバーは、まず自分へSMTP接続してきたサーバーの送信元IPアドレスを取得します。次に、SMTPのMAIL FROMに設定されたアドレスからドメイン部分を取り出し、そのドメインのDNSへTXTレコードを問い合わせます。
DNSには、次のようなSPFポリシーがTXTレコードとして公開されています。
v=spf1 ip4:192.0.2.10 include:spf.example.net -all
受信側は、SPFレコードに記載された条件を左から順番に確認します。この例には、次の3つの条件が記載されています。
ip4:192.0.2.10：接続元のIPv4アドレスが192.0.2.10の場合、その送信元を許可します。include:spf.example.net：spf.example.netで公開されている別のSPFレコードも確認します。外部のメール配信サービスやクラウドサービスに送信を任せる場合によく使われます。-all：それまでの条件に一致しなかった送信元を、許可されていないものとしてFailにします。
このように、受信側は実際の接続元IPアドレスが、MAIL FROMドメインのSPFレコードで許可されているか確認します。
SPFだけでは表示上の送信元を保証できない
SPFがPassして証明できるのは、「現在接続している送信元IPアドレスが、MAIL FROMドメインの所有者によって許可されている」ということです。受信者に表示されるFromヘッダーのドメインを直接認証した結果ではありません。
攻撃者が自分で管理するドメインをMAIL FROMに使い、そのドメインのSPFを正しく設定すれば、SPFをPassさせながらFromヘッダーに別組織のアドレスを記載できます。また、転送では受信側から見える接続元IPアドレスが転送サーバーへ変わるため、元の送信ドメインに対するSPFがFailしやすいという制約もあります。
DKIMが確認する対象
端的に言うと、DKIMは「メールがd=で示されたドメインの秘密鍵によって署名され、署名後に対象の本文やヘッダーが改変されていないか」を確認する認証方式です。
この署名検証によって得られるPassやFailなどの判定を、この記事ではDKIMの認証結果と呼びます。具体的には、受信側が次の流れでDKIM認証を行います。
DKIM認証で確認する仕組み
受信側は、メールに付与されたDKIM-Signatureヘッダーから、署名ドメインを示すd=と、鍵を識別するセレクターを示すs=を読み取ります。たとえばd=example.com、s=selector1なら、次の名前でDNSのTXTレコードを問い合わせます。
selector1._domainkey.example.com
受信側は、取得した公開鍵を使ってメールに付けられた電子署名を検証します。この検証により、署名したメールサーバーが対応する秘密鍵を持っていることと、署名対象の本文やヘッダーが署名後に変更されていないことを確認します。
検証に成功すればDKIMはPassします。電子署名が正しくない場合や、署名後に対象部分が変更されている場合はFailになります。なお、Fromヘッダーは必ず署名対象に含まれます。
DKIMだけでは表示上の送信元を保証できない
DKIMがPassして証明できるのは、「d=のドメインに対応する秘密鍵で署名され、署名対象部分が検証可能な状態で届いた」ということです。DKIM単体では、d=と表示Fromのドメインが一致している必要はありません。
また、DKIMが認証する中心的な単位はドメインであり、Fromに記載された個々の利用者が実際に送信操作を行ったことを証明する仕組みではありません。表示Fromのドメインとの関係を確認するためにはDMARCのDKIM alignmentが必要です。
DMARCは認証結果とalignmentを組み合わせる
ここでいう「認証結果」とは、前の章で説明したSPFの認証結果とDKIMの認証結果、つまりそれぞれの仕組みによって得られたPassやFailなどの判定を指します。
DMARCがメールに対して新たに署名を付けたり、送信元IPアドレスを別の方法で認証したりするわけではありません。SPFとDKIMによる認証結果を利用し、その認証で確認されたドメインが、受信者に表示されるFromドメインとalignment（アライメント）しているかを確認します。
DMARCがPassする条件は、前章の認証結果とalignmentを次のように組み合わせて表せます。
(SPFがPass かつ SPF alignmentが成立) または (DKIMがPass かつ DKIM alignmentが成立)
つまり、SPF経路とDKIM経路のどちらか一方が、認証とalignmentの両方を満たせばDMARCはPassします。両方の経路が条件を満たさない場合はDMARC Failです。
SPF alignment
SPF alignmentでは、SPF認証で使ったMAIL FROMのドメインと、Fromヘッダーのドメインを比較します。
SPFがPassしており、2つのドメインが一致していればSPF alignmentは成立します。ドメインが異なる場合は、SPF認証自体がPassしていてもSPF alignmentは成立しません。
MAIL FROM：bounce@example.com Fromヘッダー：user@example.com → ドメインが同じため、SPF alignmentは成立
MAIL FROMとFromヘッダーの両方を偽装した場合
MAIL FROMとFromヘッダーは、送信者側で同じドメインに設定できます。ただし、2つのドメインが一致するだけでは、DMARCはPassしません。SPFをPassさせるには、実際の送信元IPアドレスが、そのドメインのSPFレコードで許可されている必要があります。
攻撃者が他社のドメインをMAIL FROMとFromヘッダーの両方に設定した場合、ドメイン自体は一致します。しかし、攻撃者の送信元IPアドレスが他社ドメインのSPFレコードで許可されていなければ、SPFはFailするため、SPF経路ではDMARCをPassできません。
一方、正規の送信メールサーバーや、SPFで許可されているメール配信サービスが不正利用された場合は、SPFとSPF alignmentの両方が成立し、なりすましメールでもDMARCがPassする可能性があります。DMARC Passは、ドメインの利用が認証されたことを示すもので、メールの内容や実際の送信者が安全であることまで保証するものではありません。
DKIM alignment
DKIM alignmentでは、DKIM署名のd=ドメインと、Fromヘッダーのドメインを比較します。
DKIMがPassしており、2つのドメインが一致していればDKIM alignmentは成立します。ドメインが異なる場合は、DKIM認証自体がPassしていてもDKIM alignmentは成立しません。
DKIM署名のd=：example.com Fromヘッダー：user@example.com → ドメインが同じため、DKIM alignmentは成立
SPFまたはDKIMの認証がFailした場合は、比較に利用できる認証済みドメインがないため、対応するalignmentは「対象なし」となります。
DMARCの判定表
| SPF | SPF alignment | DKIM | DKIM alignment | DMARC |
|---|---|---|---|---|
| Pass | 成立 | Pass | 成立 | Pass |
| Pass | 成立 | Fail | 対象なし（認証Fail） | Pass |
| Fail | 対象なし（認証Fail） | Pass | 成立 | Pass |
| Pass | 不成立 | Pass | 不成立 | Fail |
| Pass | 不成立 | Fail | 対象なし（認証Fail） | Fail |
| Fail | 対象なし（認証Fail） | Pass | 不成立 | Fail |
| Fail | 対象なし（認証Fail） | Fail | 対象なし（認証Fail） | Fail |
「不成立」と「対象なし（認証Fail）」の違い
不成立は、SPFまたはDKIMの認証自体はPassし、認証済みドメインを取得できたものの、そのドメインが表示Fromドメインとalignmentしていない状態です。
対象なし（認証Fail）は、SPFまたはDKIMの認証に失敗したため、DMARCがalignmentの確認に利用できる認証済みドメインがない状態です。これは「ドメインを比較した結果、不一致だった」という意味ではありません。比較に使える認証結果が成立していないため、その経路ではDMARCをPassさせられないという意味です。
たとえばDKIMがPassしているのにDKIM alignmentが不成立の場合は、署名そのものは正しいものの、d=ドメインと表示Fromドメインがalignmentしていません。一方、DKIMがFailの場合は、署名ドメインをDMARCの認証済み識別子として扱えないため、DKIM alignmentは「対象なし」となります。
配送途中で送信元情報が変更された場合
ここまでに説明したSPF、DKIM、DMARCの関係を前提にすると、MAIL FROMやFromヘッダーが配送途中で変更された場合の影響を整理できます。
MAIL FROMが変更された場合
SPFは、受信側へ直接SMTP接続してきたサーバーのIPアドレスと、その時点のMAIL FROMドメインを使って評価します。転送システムがMAIL FROMを変更した場合、受信側は変更後のドメインのSPFポリシーを参照します。
変更後のMAIL FROMドメインが転送サーバーを送信元として許可していればSPFはPassできます。ただし、変更後のドメインと表示Fromドメインがalignmentしなければ、SPF経路ではDMARCをPassできません。SRSは転送後のSPFをPassさせるために有効ですが、それだけで表示FromとのSPF alignmentまで保証するものではありません。
Fromヘッダーが変更された場合
FromヘッダーはDKIMで必ず署名対象に含まれます。そのため、DKIM署名後にFromヘッダーが書き換えられると、元の署名データと一致しなくなり、通常はそのDKIM署名がFailします。
また、DMARCは受信時点の表示Fromドメインを基準にalignmentを確認します。Fromヘッダーが変われば比較の基準も変わるため、SPF alignmentとDKIM alignmentの結果が変わる可能性があります。書き換えを行った中継サービスが、変更後のFromドメインとalignmentする新しいDKIM署名を追加する場合もあります。
DMARC Fail後の処理は誰が決めるのか
DMARCのPass／Failを決める判定方法は仕様で定められており、受信側が自由に判定式を変更するものではありません。一方、Failしたメールを最終的にどう扱うかには、受信側の判断が入ります。
送信ドメインの所有者は、DNSのDMARCレコードにp=を記載して、Failしたメールに対する取り扱い方針を表明します。
| p=の値 | ドメイン所有者が表明する方針 |
|---|---|
| none | 特定の取り扱いを要求しない。通常の処理を継続する |
| quarantine | 疑わしいメールとして扱うことを求める |
| reject | 正当でないドメイン利用と判断していることを示す |
これらは受信側への絶対的な命令ではありません。最新のDMARC仕様であるRFC 9989では、最終的な処理は受信側のローカルポリシーに委ねられています。受信側は、転送経路、ARC、送信者評価、迷惑メール判定などの追加情報を考慮して、ポリシーを上書きする場合があります。
特にRFC 9989は、p=rejectだけを理由に受信メールを機械的に拒否しないよう求めています。そのため、DMARCがPassしても迷惑メール扱いや拒否になる場合があり、反対にDMARCがFailしても正当な転送メールなどが受信される場合があります。
まとめ
- MAIL FROMは、SMTP接続してメールを渡す送信メールサーバーや配信サービスが設定する
- Fromヘッダーは、送信者がメールソフトや送信アプリケーションを通じて設定する
- DKIMのd=は、秘密鍵を持つ送信メールサーバーやメールサービスなどのDKIM署名者が設定する
- SPFは、SMTP接続元IPアドレスがMAIL FROMドメインのDNS上のSPFポリシーで許可されているか確認する
- DKIMは、DNSで取得した公開鍵を使い、本文ハッシュと電子署名を検証する
- DMARCは表示Fromを基準に、SPFまたはDKIMの認証結果とalignmentを組み合わせる
- 判定表の「不成立」は認証済みドメインとの不一致、「対象なし」は認証Failにより比較対象がない状態を示す
コメント