はじめに
前回の こちらの記事 では、メールメッセージの構造と、メールを送信するための SMTP プロトコルについて見てきました。
その中でも触れたように、SMTP は “配達人” であり、メールの差出人が本物かどうかは関知しません。
一方で現在のインターネットでは、なりすまし攻撃 も珍しくなく、差出人の正当性を確認できる仕組みが求められるようになりました。
そこで登場するのが、SPF・DKIM・DMARC に代表される「ドメイン認証」という仕組みです。
本記事では、その背景と仕組みを実際のメールの流れに沿って自分なりに整理してみます。
メールの登場人物と流れ
メールの配送では、いくつかの役割を持ったソフトウェア（≒ 登場人物）が連携しています。
| 登場人物（略語） | 正式名称 | 役割 |
|---|---|---|
| MUA | Mail User Agent | ユーザーが使うメールクライアント（Gmail 画面、Thunderbirdなど） |
| MSA | Mail Submission Agent | ユーザーから送られたメールを預かる送信受付サーバー |
| MTA | Mail Transfer Agent | メールを中継して相手サーバーへ配送する郵便局的存在 |
| MDA | Mail Delivery Agent | 受信したメールを最終的に受信者のメールボックスに格納する |
| IMAP/POP クライアント（MUA の一部） | MRA（Mail Retrieval Agent）＋MUA | MDA に格納されたメールを IMAP や POP で取得し、ユーザーが読むための画面に届ける（多くの場合、MUA に統合されている） |
今回フォーカスするのは、この中の…
受信側サーバーの MTA が「このメールの差出人は信じていいのか？」を判断するための仕組みです。
つまり、SPF・DKIM・DMARC といった「ドメイン認証」の話になります。
受信側 MTA が確認するタイミングと手段
受信側のメールサーバー（MTA）は、メール受信の完了直前（SMTP セッションの終了直前）に、「このメールは本当に差出人のドメインから送られてきたのか？」「途中で改ざんされていないか？」といったチェックをおこないます。
このとき、MTA は外部の DNS サーバーに問い合わせ をして、差出人ドメインが公開している認証情報を確認します。
メールの認証は「受け取る前にやる」のではなく、「受け取った後」（厳密には SMTP セッションが終了する前）に判断されます。
つまり、「一旦メールを受け取る→検査→（結果次第で）スパム扱い」のような流れになります。
受信サーバーが確認すること一覧
受信側の MTA（Mail Transfer Agent） は、メールを受け取った際、メールメッセージに含まれる次のような情報を元に DNS に問い合わせを行い、「信じていいメールかどうか？」を判断します。
| 検証種別 | 使う情報 | 参照するDNSレコード | 検証の目的 |
|---|---|---|---|
| SPF 検証 |
MAIL FROM のドメイン（SMTPエンベロープ）＋送信元IPアドレス |
example.com の TXTレコード（SPF） |
この IP アドレスは、ドメインの使用を許可されているか？ |
| DKIM 検証 |
DKIM-Signature ヘッダーの d= ドメイン（SMTPコンテンツのヘッダー部） |
selector._domainkey.example.com の TXTレコード |
署名が正しく、改ざんされていないか？ 誰が署名したか？ |
| DMARC 検証 |
From: ヘッダーのドメイン（SMTP コンテンツ） |
_dmarc.example.com の TXTレコード |
SPF/DKIM と From の整合性チェック。ポリシーに基づき処理。 |
認証に失敗したメールの行方は？
DMARC ポリシーで指定されている方法で処理されます。
DMARC ポリシーとは、認証に失敗したメールをどうするかを受信者に伝えるためのポリシーで、ドメイン所有者が DNS で DMARC レコードを公開することで指定します。
ポリシーは以下いずれかです：
- None (無し)： メッセージは受信者に配信され、DMARC レポートの送信先が指定されている場合、そこに送信されます。
- Quarantine (隔離)： メッセージは隔離フォルダに移動されます。
- Reject (拒否)： メッセージは配信されません。
なぜ検証には SPF・DKIM・DMARC と、3 つも必要なのか？
それぞれの検証技術には、たとえば以下のような弱点があります。
そのため、単体では十分な効果が得られず、組み合わせて使うことが前提になっています。
SPF の欠点：
- メールが転送されると、IP アドレスは転送サーバーのもので再配送されるため、元の
MAIL FROMドメインと一致せず、SPF 検証が失敗することがある - SPF はあくまで
MAIL FROM（Return-Path）を検証する仕組みのため、受信者が実際に目にするFrom:のなりすましを検出できない
DKIMの欠点：
- DKIM ドメインはエンドユーザーには見えず、メーラーに表示される目に見える
From:ドメインのなりすましを防ぐことはできない
DMARC は、SPF・DKIM の検証結果と From: ヘッダーの整合性をチェックし、その結果に基づいて「配送／隔離／拒否」のポリシーを適用する司令塔です。
SMTP はもともと、なりすましや改ざんの検出などを想定していないシンプルなプロトコルです。
現代のセキュリティ要件に対応するために、「後付けの防御レイヤー」として SPF・DKIM・DMARC が追加されている、という構造がポイントです。
おわりに
というわけで、SPF・DKIM・DMARC の役割と流れを俯瞰してみました。
「Return-Path とは？」や「転送時の SPF／DMARC」など、まだまだ気になる点はありますが、まずは “差出人を信じる仕組み” の基本構造について一度整理することができました。
なお今回は「本当にこのメールは正しい差出人から届いたのか？」という観点から、ドメイン認証に焦点をあてました。
一方で、SMTP は元来「平文通信」のプロトコル。通信経路の暗号化（STARTTLS など） もまた、別の脅威に対処するための重要な要素です。こちらについても、いずれ取り上げてみたいと思っています。
※ 内容について「ここ違うかも？」という点があれば、ぜひコメントで教えてください。学び直します！