メールのなりすまし対策として、よく使われるのが次の3つです。

SPF
DKIM
DMARC

SPFとDKIMをすでに設定している環境では、

「SPFとDKIMがあれば、DMARCまで設定する必要はないのでは？」

と思うかもしれません。

しかし、SPFとDKIMにはそれぞれ重要な弱点があります。

その弱点を補い、普段ユーザーが目にするFromアドレスのドメインが本当に正当なのかを確認できるようにする仕組みがDMARCです。

今回は、なぜSPF・DKIM単体ではなくDMARCまで導入した方がよいのかを説明します。

---

SPFだけではFromのなりすましを防げない

まずSPFです。

SPFは簡単にいうと、

「このドメインのメールを、このIPアドレスから送ってよいか」

を確認する仕組みです。

例えば、

example.jp
  ↓
SPFレコード
  ↓
203.0.113.10 から送信OK

と公開しておけば、受信サーバーは送信元IPを確認できます。

一見すると、これだけでなりすまし対策ができそうです。

しかしSPFには大きなポイントがあります。

SPFが確認するドメインと、メールソフトでユーザーが見るFromのドメインは必ずしも同じではありません。

メールには大きく分けて、

Envelope From
Header From

があります。

SPFが認証するのは基本的にEnvelope From側です。

一方、Outlookなどでユーザーが、

From: support@example.jp

として目にするのはHeader Fromです。

そのため、攻撃者が自分で管理しているドメインをEnvelope Fromに使用し、

Envelope From:
attacker.example

Header From:
bank.example

のようなメールを作ったとします。

attacker.example に正しいSPFレコードが設定されていれば、

SPF = PASS

になる可能性があります。

しかし受信者に見えるFromは、

bank.example

です。

つまり、

SPF PASSだから、画面に表示されているFromも正しい

とは限りません。

---

DKIMなら大丈夫なのか

DKIMではメールに電子署名を付け、メールが署名後に改変されていないことや、その署名を検証できることを確認します。

例えば、

DKIM-Signature:
 d=example.jp;
 s=selector1;

なら、受信側はDNSから公開鍵を取得して署名を検証します。

しかしDKIMにもSPFと似た問題があります。

DKIMで検証される、

d=example.jp

と、

From: user@example.jp

が必ず同じドメインとは限りません。

例えば攻撃者が、

Header From:
president@company.example

DKIM-Signature:
d=attacker.example

というメールを送ったとします。

attacker.example のDKIM署名自体が正しければ、

DKIM = PASS

になり得ます。

それでもユーザーが見るFromは、

president@company.example

です。

つまり、

DKIM PASS = Header Fromのドメインが正しい

でもありません。

---

そこでDMARCが必要になる

DMARCの重要なところは、

ユーザーに表示されるHeader Fromのドメインと、SPFまたはDKIMで認証されたドメインとの関係まで確認する

ことです。

これを**アライメント（Alignment）**と呼びます。

例えば、

Header From
user@example.jp

      ↑
      │ ドメインの関係を確認
      │
SPF認証ドメイン
example.jp

なら、SPF側のアライメントが成立します。

DKIMについても、

Header From
user@example.jp

      ↑
      │ ドメインの関係を確認
      │
DKIM d=
example.jp

という関係を確認します。

ここがSPF/DKIM単体とDMARCの大きな違いです。

---

SPF PASSでもDMARC FAILになる

例えば次のメールです。

Header From:
president@company.example

Envelope From:
bounce@attacker.example

attacker.example のSPF設定が正常なら、

SPF = PASS

になります。

ところがDMARCでは、

Header From
company.example

       ≠

SPF認証ドメイン
attacker.example

となります。

SPF認証には成功していますが、SPF Alignmentは失敗です。

さらにDKIMも、

DKIM = FAIL

またはアライメントしていなければ、

SPF     PASS
DKIM    FAIL

でも

DMARC   FAIL

となり得ます。

これがDMARCを導入する大きな理由です。

---

DKIM PASSでもDMARC FAILになる

逆もあります。

例えば、

Header From:
president@company.example

DKIM-Signature:
d=attacker.example

だったとします。

攻撃者自身のドメインなのでDKIM署名は正常です。

したがって、

DKIM = PASS

になり得ます。

しかしDMARCでは、

Header From
company.example

       ≠

DKIM d=
attacker.example

となるため、DKIM Alignmentは成立しません。

SPF側もDMARCの条件を満たしていなければ、

DKIM    PASS
SPF     FAIL
DMARC   FAIL

となります。

つまり、

SPF PASSやDKIM PASSという文字だけを見て「このメールは正しい」と判断するのは危険

ということです。

---

逆にDKIM FAILでもDMARC PASSになることがある

ここも非常に重要です。

前回の記事で説明したように、正常メールでも配送途中で本文が変更され、

DKIM = FAIL

になることがあります。

例えば、

正規送信者
 ↓
DKIM署名
 ↓
中継サービス
 ↓
本文変更
 ↓
DKIM FAIL

となったとします。

これだけを見て、

DKIM FAIL
    ↓
隔離

としてしまうと、正常メールを隔離する可能性があります。

しかしSPF側が、

SPF = PASS

で、さらにSPFで認証されたドメインがHeader Fromとアライメントしていれば、

SPF
PASS + Alignment PASS
       ↓
DKIM
FAIL
       ↓
DMARC
PASS

と判定できます。

---

SPFとDKIMは「両方PASS」がDMARCの条件ではない

ここはDMARCを理解するときによく混乱するところです。

DMARCは、

SPF PASS
+
DKIM PASS
=
DMARC PASS

という単純な仕組みではありません。

基本的には、

        Header From
             │
      ┌──────┴──────┐
      ▼             ▼
     SPF           DKIM
      │             │
 認証成功？      認証成功？
      │             │
Alignment？      Alignment？
      │             │
      └──────┬──────┘
             │
   どちらか一方が
   DMARC条件を満たす
             │
             ▼
        DMARC PASS

です。

したがって、

SPF  PASS + Alignment PASS
DKIM FAIL

→ DMARC PASS

もありますし、

SPF  FAIL
DKIM PASS + Alignment PASS

→ DMARC PASS

もあります。

---

SPF・DKIM・DMARCの役割を整理すると

3つを非常に単純化すると、次のように考えると分かりやすいです。

認証	主に確認すること
SPF	この送信元IPは、そのドメインから送信を許可されているか
DKIM	DKIM署名を正しく検証できるか
DMARC	SPF/DKIMの認証結果と、ユーザーが見るHeader Fromのドメインが適切に結び付いているか

つまりDMARCは、SPFやDKIMの代わりになるものではありません。

SPF ──┐
      ├──→ DMARC
DKIM ─┘

という関係です。

SPFとDKIMという材料を、Header Fromとの関係まで含めて評価するのがDMARCと考えると理解しやすいでしょう。

---

DMARCにはもう一つ大きなメリットがある

DMARCでは送信ドメインの管理者が、

認証に失敗したメールを受信側にどう扱ってほしいか

というポリシーをDNSで公開できます。

代表的なのが、

p=none
p=quarantine
p=reject

です。

例えば、

v=DMARC1; p=none;

なら、まず監視中心で始められます。

運用状況を確認したうえで、

p=quarantine

さらに、

p=reject

へ強化できます。

そのためDMARCは、単に認証方式を一つ追加するだけではなく、自ドメインを騙ったメールを受信側でどう扱ってほしいか表明できる仕組みでもあります。

---

最初からrejectにする必要はない

DMARCを導入する場合、いきなり、

p=reject

にする必要はありません。

特にメールシステムが複雑な組織では、

Microsoft 365
業務システム
Webサーバー
複合機
メーリングリスト
外部メール配信サービス

など、自分たちが把握していなかった正規の送信経路が存在することがあります。

最初は、

v=DMARC1; p=none; ...

としてレポートを収集し、

誰が自ドメインを使っているか
        ↓
SPFは正常か
        ↓
DKIMは正常か
        ↓
Alignmentは正常か
        ↓
正規送信経路を整理
        ↓
quarantine / rejectを検討

と段階的に進める方が安全です。

---

まとめ

SPFとDKIMは重要なメール認証技術ですが、それぞれ単体のPASSだけでは、ユーザーが実際に目にするFromドメインが正当であることまでは保証できません。

そこでDMARCを利用します。

             Header From
                  │
          「本当にこのドメイン？」
                  │
        ┌─────────┴─────────┐
        ▼                   ▼
       SPF                 DKIM
   認証＋Alignment     認証＋Alignment
        │                   │
        └─────────┬─────────┘
                  ▼
            DMARC判定
                  │
        ┌─────────┴─────────┐
        ▼                   ▼
       PASS                FAIL

そのため、

「SPFとDKIMを導入したから終わり」ではなく、DMARCまで含めて設計する

ことが重要です。

特に、

SPF PASS ≠ Fromが正しい
DKIM PASS ≠ Fromが正しい
DKIM FAIL ≠ 不正メール

という3点を理解すると、DMARCを導入する意味がかなり分かりやすくなります。