メール認証の仕組み SPF・DKIM・DMARC でなりすましメールを防ぐ

日々受信するメールの中には、取引先や有名企業のドメインを騙って送られてくるフィッシングメールが少なくないです。こうした「なりすましメール」を技術的に見分けるための仕組みが、SPF・DKIM・DMARC という3つのメール認証技術です。それぞれ単体でも一定の効果はありますが、3つを組み合わせることで初めて実用的な強度のなりすまし対策になります。この記事では、SPF・DKIM・DMARC のそれぞれがどのような仕組みでメールの正当性を検証しているのかを、DNS（Domain Name System、ドメイン名とサーバーの情報を対応づける仕組み）のレコード例を交えながら解説します。

メール認証がなぜ必要なのか

メールを送受信する基盤になっている SMTP（Simple Mail Transfer Protocol）は1980年代に設計されたプロトコルで、送信者が名乗る差出人アドレスが本当に本人やそのドメインのものかどうかを検証する機能を持っていないです。そのため、差出人欄に任意のメールアドレスを記載して送信することが技術的には可能で、これを悪用したなりすましメールが長年にわたって問題になってきました。

なりすましメールはフィッシング詐欺や標的型攻撃の入り口として使われることが多く、受信者本人だけでなく、名前を騙られた企業やブランドの信用も損なう原因になります。SPF・DKIM・DMARC は、こうした問題に対処するために策定されたメール認証の仕組みで、いずれも DNS にレコードを追加するだけで導入できます。専用のソフトウェアを新たに用意する必要がなく、既存のメール環境に後付けできる手軽さが、これらの技術が広く普及した理由の一つになっています。

SPF（Sender Policy Framework）の仕組み

SPF は、送信元のメールサーバーがそのドメインの正規の送信者かどうかを検証する仕組みです。ドメインの管理者は、そのドメインからメールを送信してよいサーバーの IP アドレスをあらかじめ DNS の TXT レコード（テキスト形式の情報を登録できる DNS レコードの一種）として公開しておきます。メールを受信したサーバーは、送信元の IP アドレスがこの一覧に含まれているかどうかを照合し、含まれていない場合は正規の送信元と異なると判断します。

SPF が検証する対象は、メールソフトの差出人欄に表示される「ヘッダー From」ではなく、SMTP 通信の中で使われる「エンベロープ From（メールの配送経路情報として使われる送信元アドレスで、通常は画面に表示されない）」です。この違いは、後述する DMARC のアライメント（整合性確認）を理解するうえで重要になるので覚えておきましょう。

SPF レコードの基本的な設定例は以下のようになります。自社のメールサーバーの IP アドレスを許可し、Google Workspace など外部サービス経由の送信も許可するケースです。

example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all"

各項目の意味は次の表のとおりです。

項目	意味
v=spf1	SPF のバージョンを表す固定の記述
ip4:	許可する送信元の IP アドレス
include:	他のドメインが公開している SPF レコードを取り込む指定で、外部のメール配信サービスを利用する際によく使われる
~all	一覧にない IP アドレスからの送信をソフトフェイル（正規の送信元ではなさそうだが、一応受信はしてマークだけ付ける、という緩やかな扱い）として扱う指定

一覧にない IP アドレスからの送信を明確に拒否したい場合は、以下のように -all（ハードフェイル、正規の送信元でないと断定する扱い）を使う設定もよく見られます。

example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

SPF には、1つのドメインに設定できる include の連鎖が DNS への問い合わせ10回までに制限されているという仕様上の制約があります。利用する外部サービスが多いと超えやすいので、レコードを設計する際は意識しておくとよいでしょう。

RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 | RFC Editor

Email on the Internet can be forged in a number of ways. In particular, existing protocols place no ...

www.rfc-editor.org

DKIM（DomainKeys Identified Mail）の仕組み

DKIM は、メールの本文とヘッダーの一部に電子署名（送信者だけが持つ秘密鍵を使って生成する、改ざんを検知できる符号）を付与する仕組みです。SPF が送信元の IP アドレスを検証するのに対して、DKIM はメールの中身そのものが送信時から書き換えられていないかを検証します。

送信側のメールサーバーは秘密鍵を使ってメールに署名を付け、対応する公開鍵を DNS の TXT レコードとして公開しておきます。受信側のサーバーは、メールに付与された署名を DNS から取得した公開鍵で検証し、署名の検証に成功し、かつ本文やヘッダーが送信時から変更されていなければ認証成功と判断します。転送経路の途中でメールの内容が書き換えられていた場合は署名の検証に失敗するため、改ざんを検知できます。

DKIM レコードの設定例は以下のようになります。selector1 の部分はセレクタと呼ばれ、同じドメインで複数の鍵を使い分けるための識別子です。

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

v=DKIM1 は DKIM のバージョン、k=rsa は使用する暗号方式、p= の後に続く長い文字列が公開鍵本体です。送信されたメールのヘッダーには DKIM-Signature という項目が追加され、その中にどのセレクタで署名したかという情報が含まれるため、受信側はどの DNS レコードを参照すればよいかを判断できます。

DKIM を導入する際は、秘密鍵を定期的に入れ替える鍵のローテーションも運用上の重要なポイントです。セレクタを複数用意しておけば、古い鍵から新しい鍵への切り替え中も両方の署名を有効な状態に保てます。

RFC 6376: DomainKeys Identified Mail (DKIM) Signatures | RFC Editor

DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing doma...

www.rfc-editor.org

DMARC（Domain-based Message Authentication, Reporting & Conformance）の仕組み

DMARC は、SPF と DKIM の検証結果を踏まえて、認証に失敗したメールをどう扱うかというポリシーを送信ドメイン側が指定できる仕組みです。SPF と DKIM は、それぞれ単体では検証の成否を判定するだけで、失敗した場合にメールを拒否するかどうかは受信側のサーバーの裁量に委ねられていました。DMARC はこの部分を送信側が明示的に指定できるようにしたものです。

DMARC のもう一つの重要な要素が、アライメントと呼ばれる整合性確認です。SPF や DKIM の検証自体に成功していても、その検証に使われたドメインが、メールソフトに表示されるヘッダー From のドメインと一致していなければ、DMARC の観点では認証失敗として扱われます。この仕組みによって、SPF や DKIM の検証はすり抜けつつヘッダー From だけを別ドメインに差し替えるという、より巧妙ななりすましの手口にも対応できます。

DMARC レコードの設定例は以下のようになります。

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100; adkim=s; aspf=s"

主な項目の意味は次の表のとおりです。

項目	意味
v=DMARC1	DMARC のバージョンを表す固定の記述
p=	認証に失敗したメールの扱い（none/quarantine/reject）
rua=	集計レポートの送付先メールアドレス
pct=	ポリシーを適用する対象メールの割合（%）
adkim= / aspf=	アライメントの厳格さ（s=厳格、r=緩やか）

p= に指定できる値は3種類あり、それぞれ次のような扱いになります。

指定値	認証失敗時の扱い
none	通常どおり配信するが、結果は記録として残す
quarantine	迷惑メールフォルダなどに隔離する
reject	メールそのものを拒否する

DMARC の設定でもう一つ有用なのが rua= で指定する集計レポートです。受信側のメールサーバーは、自社ドメイン宛にどれだけの送信が行われ、そのうち何件が SPF・DKIM の認証に成功したかを定期的にレポートとして送り返してくれます。このレポートを確認すれば、自社になりすましたメールがどの程度出回っているか、あるいは正規のメール配信サービスが認証に失敗していないかを把握できます。

RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) | RFC Editor

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by w...

www.rfc-editor.org

SPF・DKIM・DMARC が連携してなりすましを防ぐ流れ

3つの技術は、それぞれ検証する対象が異なります。SPF は送信元の IP アドレス、DKIM はメールの中身の改ざん有無、DMARC はその2つの結果とヘッダー From とのアライメントをまとめて評価し、最終的な扱いを決定するという役割分担です。1通のメールが受信されてから受信トレイに届くまでに、これらがどのような順序で検証されているかを図にすると以下のようになります。

この流れからわかるように、SPF と DKIM はそれぞれ独立に検証が行われ、その結果を DMARC が受け取ってアライメントを確認したうえで最終的な扱いを決定します。SPF か DKIM のどちらか一方でもアライメントを含めて認証に成功していれば、DMARC としては認証成功と判定される点も押さえておきたいポイントです。つまり、SPF が何らかの理由で認証に失敗しても、DKIM の署名が正しくヘッダー From と一致していれば、そのメールはなりすましとは判定されないです。

3つの認証技術の比較

ここまで解説した内容を整理すると、3つの技術の役割の違いは以下のようにまとめられます。

項目	SPF	DKIM	DMARC
検証対象	送信元の IP アドレス	メール内容の改ざん有無	SPF・DKIM の結果とアライメント
使用する DNS レコード	TXT レコード	TXT レコード（セレクタ単位）	TXT レコード（_dmarc）
単体導入の効果	限定的	限定的	SPF・DKIM の結果を前提とする
失敗時の扱いの決定権	受信側の裁量	受信側の裁量	送信側が明示的に指定できる
転送メールへの耐性	転送で失敗しやすい	比較的耐性がある	DKIM の成功で救済されやすい

表からもわかるとおり、SPF はメーリングリストや転送サービスを経由すると送信元 IP アドレスが変わってしまうため、認証に失敗しやすいという弱点があります。一方 DKIM の署名は、本文やヘッダーが書き換えられない限り転送後も有効なままなので、転送されるメールに対しては DKIM のほうが検証に強い性質を持っています。DMARC はこの2つを組み合わせて評価することで、どちらか一方の弱点を補い合う設計になっています。

導入時によくある設定ミスと注意点

メール認証の導入では、いくつか共通してつまずきやすいポイントがあります。導入を検討する際の参考にしましょう。

1つ目は、DMARC のポリシーをいきなり p=reject から始めてしまうことです。自社で把握していないメール配信経路（例えば営業部門が個別に契約している配信サービスなど）が SPF や DKIM の認証に対応していない場合、正規のメールまで拒否されてしまいます。まずは p=none でレポートを収集し、認証の成功率を確認しながら quarantine、reject の順に段階的に強化していくのが実務上の定石です。

2つ目は、SPF レコードを1つのドメインに複数登録してしまうミスです。SPF の仕様上、有効な SPF レコードは1ドメインにつき1つだけで、複数存在すると検証自体が正しく行われなくなります。外部サービスを追加するたびに新しいレコードを追加するのではなく、既存のレコードに include を追記していく必要があります。

3つ目は、サブドメインに対するポリシーの設定漏れです。DMARC レコードには sp= という項目でサブドメイン用のポリシーを個別に指定できますが、これを省略するとメインドメインの p= の値が引き継がれます。使われていないサブドメインがなりすましに悪用されるケースもあるため、運用していないサブドメインも含めて意識しておくとよいでしょう。

なお、メールを何度も転送する構成では DKIM の署名すら壊れてしまうことがあり、これを補うために ARC（Authenticated Received Chain、転送経路ごとの認証結果を鎖のように積み重ねて伝える仕組み）という技術も登場しています。メーリングリストを運用している場合などは、あわせて検討するとよいでしょう。

RFC 8617: The Authenticated Received Chain (ARC) Protocol | RFC Editor

The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a m...

www.rfc-editor.org

まとめ

SPF・DKIM・DMARC の仕組みと、それぞれの DNS レコードの設定例、3つが連携してメールを検証する流れについて解説しました。なりすましメール対策として導入を検討する際は、以下のポイントを押さえておきましょう。

• SPF は送信元の IP アドレスを検証する仕組みで、エンベロープ From のドメインが許可されたサーバーから送信されたかどうかを確認する
• DKIM は電子署名によってメールの内容が改ざんされていないかを検証し、転送されたメールに対しても比較的強い耐性を持つ
• DMARC は SPF と DKIM の結果に加えてヘッダー From とのアライメントを確認し、認証に失敗したメールの扱いを送信ドメイン側が指定できるようにする
• DMARC のポリシーは配信状況を確認しながら段階的に強化し、いきなり拒否に設定すると正規のメールまで届かなくなる恐れがある
• 集計レポートの仕組みを活用すれば、自社になりすましたメールの発生状況や自社配信の認証成功率を継続的に把握できる