2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【思っていたより】セキュアなメール送信に関わるDNS設定関連(SPF、DKIM、DMARC)【優しい世界】

2
Last updated at Posted at 2025-12-04

直近で苦手だった分野であるSPF、DKIM、DMARCに触れる機会があったため、整理を兼ねてまとめます。
SPF、DKIM、DMARCはメールの信頼性とセキュリティを三位一体で担保する技術ですが、私は長らくこの分野を苦手としていました。
どこが難しいと感じていたのかを振り返ると、 「メール送信側と受信側が、仕様を完全一致させなくても成り立つ仕組み」 である点が、私にとっての壁でした。

私のキャリアはネットワークエンジニアからスタートしています。
ルーターやファイアウォールのようなネットワーク機器、特にVPN設定においては「仕様と設定値が一致しない限り通信は成立しない」という厳格な世界です。
しかしメール(SMTPだけでなくDNSも含む)は違っていて「仕様が完全に一致しなくても、相互運用できること」が前提に設計されています。
その緩やかさが、柔軟性と引き換えに「仕様や設定の完全一致」をベースとした私にとっての“難解さ”を生み出していると感じました。

SPF、DKIM、DMARCって何なの?

3つともセキュアなメール送信を支える技術です。
メールにおけるセキュリティをそれぞれ別レイヤーで担保しています。
先にも記述した通りメールは送信側と受信側の相互運用で成り立っているため、送信側でセキュリティが担保されると、自ずとメール受信側もセキュリティが担保されます。
それぞれ個別に説明していきます。

SPFとは(送信元メールサーバ検証)

SPF(Sender Policy Framework) は、受信側のメールサーバが、送信ドメインのDNSに登録されたSPFレコードを参照し、そのドメインから送信を許可されたサーバ(IPアドレス情報を元に判断)かどうか正当性を確認する仕組みです。
SPFレコードはDNSサーバのレコード上ではTXTレコードとして登録されます。
この正当性の確認のために、送信元メールサーバの名乗り(HELO/EHLOやMAIL FROMの情報)と、メールドメインをホストする権威DNSサーバに登録されたSPFレコード間での情報の合致を確認します。
この送信元メールサーバの名乗りとSPFレコード間の情報合致の確認をSPF検証(Verified) といいます。

SPF検証の流れ

送信元メールサーバの名乗り(HELO/EHLOやMAIL FROMの情報)には、送信元メールサーバのグローバルIPアドレスやホスト名(DNS上でCNAMEやAレコードに対応する名称)が含まれています。
文章だけではイメージが湧きにくいため、以下の図にSPF検証の流れをまとめました。
image.png
つまり簡単に言うとSPFレコードとはメールドメインの権威DNSサーバに登録されたメールサーバIPアドレス許可リストのことです。
このサーバIPアドレス許可リスト(SPFレコード)に含まれているメールサーバは身元確認の担保が取れる、サーバIPアドレス許可リストに含まれていないメールサーバは身元確認ができない(≒ドメイン詐称しているメールサーバである確率が高い)という仕組みです。

SPFの意義

この送信元メールサーバのグローバルIPアドレスやホスト名と、メールドメインをホストするメールサーバにTXTレコードとして登録されている情報を参照する意義ですが、送信元メールサーバの持ち主(広義で利用者も含む)と、メールドメインのDNS権威サーバの設定変更権限を持つ者(=つまりSPFレコードを登録できる者)同一人物である確率が非常に高いからです。
このメールサーバとDNSサーバが同一人物によって運用されている(であろう)前提に立ってこの仕組みを考えると、SMTPサーバの名乗りとDNSレコードのSPFレコードの合致を確認する仕組みでメールの送信者がなりすましでないかどうかを確認する仕組みとして十分機能することはお判りいただけると思います。

SPFまとめ

以上のことからSPFでまずはメール送信元のサーバがドメインを詐称していない、なりすましていない、ということが証明されます。
つまりメールアドレスはメールドメインの管理下にあるものであることが証明されます。
完全ではないですがメールアドレスの信頼性が高まりますね。

DKIMとは(署名による改ざん防止)

メールアドレスの信頼性が高まったところで、次にメール本文や添付ファイルの改ざんを何某かの形で担保したいです。
メールアドレスは正しい持ち主が居て、メールの送信行為もその正しい持ち主(=個人)から送信されていたとしても、肝心のメールの中身が第三者に改ざんされていては意味がないですね。
このためSPFで担保されたメールアドレスの次の段階として、メール本文や添付ファイルの改ざんを防止する仕組みが DKIM (DomainKeys Identified Mail) です。

DKIMの仕組み

ズバリ、送信メールサーバがメール生成時にメールサーバの持つ秘密鍵でメールに署名します。
具体的にはメールヘッダーにDKIM-Sgnatureヘッダーを追加します。
ではこの秘密鍵で署名されたメールに対して正当性を担保するための秘密鍵に対応する公開鍵が必要ですが、この公開鍵の設置場所がSPFレコードと同じくメールドメインの権威DNSサーバです。
公開鍵はCNAMEやTXTレコードとして登録されています。
この秘密鍵で署名された値は対応する公開鍵でしか検証できません。
受信側のメールサーバは公開鍵で署名を検証し、メール本文やFromの内容が途中で改ざんされていないことを確認します。
このためメール本文や添付ファイル、一部のFromのデータが改ざんされていないことを担保できます。
文章だけではイメージが湧きにくいため、以下の図にDKIM検証の流れをまとめました。
image.png
SPFと同じく、DKIMもドメインの権威DNSサーバに定義された情報を参照する仕組みです。
図の通りSPFレコードの検証もDKIMレコードの検証も、参照先権威DNSサーバが同じDNSサーバです。

DKIMの意義

同じDNSサーバを用いた検証でも、検証の結果保証できるデータに違いがありSPFは「送信元サーバの正当性」を確認するのに対し、DKIMは「メール内容の完全性」 を確認します。

DKIMまとめ

DKIMでは以下の2つを同時に証明できます。

  1. 公開鍵で正しく検証できた=送信元が秘密鍵を持っている(つまり正当なメールサーバ)
  2. ハッシュが一致=改ざんされていない

すごい仕組みですね。

これで三位一体のうち2つまでは説明できました。

DMARCとは(SPF、DKIMの結果をどう処理するか)

続いて最後のDMARC (Domain-based Message Authentication, Reporting and Conformance) です。
翻訳するとドメインベースのメッセージ認証、レポートと適合(について)という意味ですね。

DMARCの仕組み

これまでのSPF、DKIMを踏まえて、それぞれの判断でFail、Softfail、Pass、判断が分かれます。
このSPF、DKIMの結果から、受信メールサーバ側でメールを「拒否する」のか「隔離する」のか「受け入れる」のが1通ずつ判断します。
DMARCもSPFレコードと同じくTXTレコードをメールドメインのドメインをホストする権威DNSサーバに登録します。
テキストレコードの中身は

意味
v=DMARC DMARC設定を行っている
p=reject SPF、DKIMのどちらかを満たしていないと拒否する※
pct=100 100%拒否する
rua=mailto:[報告先メールアドレス] SPF、DMARCの結果本ドメインのメールがどれだけ詐称されているか、改ざんされているかの報告先メールアドレス

となっています。
p=rejectの部分ですが、SPFまたはDKIMが認証に失敗し、かつFromドメインと整合していない場合はメールを拒否という内容です。
このrejectをQuarantineにすると「隔離」になり、noneにすると「そのまま素通り」となります。
メール受信後、SPF、DKIMの検証を行い、更にその先でDMARCのパラメーター次第で受信したメール、特にSPF、DKIMの結果、ひっかかったメールを拒否するか否かを決めます。
更にDMARCでは、受信側メールサーバがSPF/DKIMの検証結果を集計し、定期的にドメイン管理者(ruaで指定したアドレス)へXML形式のレポートを送信します。これにより、自社ドメインを装ったなりすましメールの検出状況を可視化できます。
文章だけではイメージが湧きにくいため、以下の図にDMARCの流れをまとめました。
image.png

なんと、DMARCのレポーティング機能に関しては受信メールサーバがわざわざ送信メールサーバに報告してくれるのです!
なんて優しい世界なんでしょう!

DMARCまとめ

  1. SPF、DKIMの結果によって受信したメールの処理を受信メールサーバに依頼する
  2. 受信メールサーバにSPF、DKIMに引っかかったメールの件数を報告するように依頼する
    という仕組みです。
    とくに2.の報告依頼が秀逸だと思います。
    もちろん世界中にあるすべてのメールサーバがこのDMARCの依頼に従って報告してくれるかどうかという問題はありますが、それにしても相手を信頼して依頼する、しかも依頼された側はなるべく依頼に応答するというとてもやさしい世界でした。

参考:

SPF、DKIM、DMARCまとめ

メールというインターネット黎明期から存在する仕組み、しかも無くてはならないインフラになっている仕組みをセキュリティの面から支える技術です。
世界中に点在し、管理者の思考や思想も違う中、それぞれが「無理なくなるべく連携して」、「既存の周辺システムであるDNSの技術を利用しながら」、「可能な限りセキュリティを担保する」という仕組みです。
非常に優れた考え方、仕組み、まさにエコシステムだと思います。
ネットワークの世界だとゼロトラスト、つまりすべてを信頼しないという非常に厳しい判断、見方に立った考え方の実装が進んでいる中で、対照的な仕組みだなと感じました。

本日はここまで。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?