SPF・DKIM・DMARC：メール認証の完全ガイド

メールは、差出人アドレスが嘘かもしれないと誰も考えていなかった時代に設計されました。元のプロトコルには、インターネット上の任意のマシンがメールサーバーに接続して「自分はあなただ」と名乗るのを防ぐ仕組みがありません。この穴こそがフィッシングを成立させており、だからこそ今日ではSPF・DKIM・DMARCという3つのDNSベースの標準が、あなたのメールが受信トレイに入るか迷惑メールフォルダに落ちるかを決めています。

3つはいずれも自ドメインのDNSレコードに置かれます。つまり、自分のものを含めてどのドメインのメール認証設定も、DNSルックアップだけで確認できます。本ガイドでは各レコードの役割と読み方、そして自社の請求書を誤ってブロックすることなく厳格なDMARCポリシーへ到達する方法を説明します。

SPF のルックアップ数や DKIM 鍵の長さも含めて3つのレコードをまとめて確認するには、SPF・DKIM・DMARC チェッカーをご利用ください。

メール認証が重要な理由

ここ数年で2つのことが変わりました。攻撃者は信頼されたブランドの偽装がはるかに巧みになり、大手メールボックス事業者はそれに応じて認証を事実上の必須にしました。GmailとYahooは一括送信者にSPF・DKIM・DMARCを要求しており、Microsoftも追随しています。レコードが欠けていたり壊れていたりすると、影響はすぐに、しかも実務的な形で表れます。

• メールがフィルタされる。認証されていないメッセージは隔離される確率がはるかに高く、受信箱に届く前に拒否されることさえあります。
• 誰でもドメインを偽装できる。 DMARCポリシーがなければ、受信サーバーはあなたの名前をかたった偽メールを拒否する指示を持ちません。
• 不正利用に気づけない。 DMARCのレポートは、何者かがあなたの名前でフィッシングを送っていると知る唯一の手段です。
• 商談が止まる。セキュリティ質問票やベンダー審査ではDMARCポリシーが日常的に問われ、「none」は不備として扱われることが増えています。

3つのレコードの概要

これらは代替ではなく層です。SPFは送信サーバーを、DKIMはメッセージ自体を検証し、DMARCは両者を人が実際に目にするFromヘッダーのドメインに結び付け、失敗時の扱いを指定します。3つすべてが必要です。

SPF：自ドメインから送信できる相手

Sender Policy Frameworkは、自ドメインでメールを送ることを許可されたサーバーの公開リストです。受信サーバーは接続してきたIPアドレスを取り、あなたのSPFレコードを引いて、そのアドレスがリストにあるかを確認します。

SPFレコードの読み方

典型的なレコードは次のようになります。

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

左から右に読みます。v=spf1はバージョンで、必ず先頭に置きます。include:は別ドメインのSPFレコードを取り込むもので、Google Workspaceやトランザクションメール事業者を許可する方法です。ip4:とip6:は特定のアドレスや範囲、通常は自前のサーバーを許可します。最後の機構が包括ルールで、ここを取り違える人が最も多い部分です。

• -allはハードフェイル。リストにないものは許可されておらず、受信側は拒否することが期待されます。
• ~allはソフトフェイル。リストにない送信元は疑わしいものの受理され、通常は迷惑メール判定で不利になります。
• ?allは中立で受信側に何も伝えず、レコードを公開する意味自体を失わせます。

正規の送信元がすべて列挙されていることを確認する間は~allから始め、DMARCレポートがきれいになったら-allへ締めます。

10回のルックアップ制限

SPFはレコードの評価中に最大10回のDNSルックアップしか許しません。include:・a・mx・redirectはすべて数に入り、入れ子になったものも数えられます。超えると結果は恒久エラーとなり、多くの受信側はSPFが存在しないのと同じに扱います。メール事業者が3〜4社あれば超えてしまうことが多いので、送信サービスを追加するたびにレコードを点検し、使わなくなった事業者は削除してください。

もう一つ驚かれる規則があります。1つのドメインが公開できるSPFレコードは1件だけです。同じ名前にv=spf1のTXTレコードが2件あるのは恒久エラーであり、統合はされません。

DKIM：メールへの署名

DomainKeys Identified Mailは、送信するすべてのメッセージに暗号署名を付けます。メールサーバーが秘密鍵を保持し、選択したヘッダーと本文に署名します。対応する公開鍵はDNSで公開されます。受信側は公開鍵を取得して署名を検証し、2つのことを知ります。メッセージが実際にあなたのドメインで署名されたこと、そして署名が対象とした部分が途中で改変されていないことです。

公開鍵はセレクタから組み立てた名前、たとえばgoogle._domainkey.example.comやs1._domainkey.example.comに置かれます。セレクタがあるおかげで複数の鍵を同時に運用でき、鍵のローテーションが容易になります。新しいセレクタを公開し、署名をそちらへ切り替え、古いものは後で廃止すればよいのです。

署名はメッセージとともに移動するため、SPFが通らない転送でもDKIMは生き残ります。メーリングリストが中継すると接続元IPが変わりSPFは失敗しますが、リストが署名対象のヘッダーや本文を書き換えていなければDKIM署名は有効なままです。この頑健さこそ、SPFを設定済みでもDKIMが重要である主な理由です。

DMARC：受信側への指示

SPFとDKIMはそれぞれ合否を出しますが、受信側が何をすべきかは示さず、受信者が実際に読むFromアドレスも見ません。DMARCはその両方を埋めます。レコードは次のようになります。

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=r

p=がポリシーで、none（監視のみ）、quarantine（失敗を迷惑メール扱い）、reject（入口で拒否）のいずれかです。rua=は日次の集計レポートを受け取るアドレスで、レコードの中で最も価値のある部分です。pct=は展開期間中にポリシーを一定割合のメールへ適用します。

アラインメント、見落とされがちな要点

DMARCはSPFやDKIMが通るだけでは足りません。通ったドメインが、表示されるFromヘッダーのドメインとアラインしていることを求めます。あるメッセージがmailer.vendor.comでSPFを通過しても、example.comとしてはDMARCに失敗することがあります。両者が一致しないからです。一見正しい設定なのに失敗する原因として、これが最も多いものです。

adkimとaspfは一致の厳しさを決めます。relaxed（r、既定）はmail.example.comのようなサブドメインを許し、strict（s）は完全一致を求めます。まずはrelaxedから。DMARCはSPFとDKIMのいずれかが通りかつアラインしていれば合格なので、アラインしたDKIM署名が1つあれば十分です。

ポリシーを安全に適用する

1. レポート用アドレスを添えてp=noneを公開する。メールの流れは何も変わりませんが、レポートが届き始めます。
2. 2〜4週間レポートを読む。忘れていた送信サービス、CRM、ヘルプデスク、請求ツール、古いマーケティング基盤などが明らかになります。
3. 穴をふさぐ。正規の送信元をすべてSPFに追加し、アラインしたドメインでDKIM署名を有効にし、次のレポートで変更を確認します。
4. p=quarantineへ移る。大量に送る場合はpct=で段階的に引き上げます。
5. p=rejectで仕上げる。レポートに正規メールの失敗が出なくなってからです。なりすましを実際に止めるのはこのポリシーだけです。

自分のレコードを確認する方法

3つとも公開のTXTレコードなので、確認は数秒で済みます。

1. SPF。 DNSルックアップツールでサブドメインなしのドメインにTXTクエリを実行し、v=spf1で始まる文字列を探します。ちょうど1件であることを確かめ、ルックアップ数を数えます。
2. DMARC。 _dmarc.＋自ドメインにTXTクエリを実行します。何も返らなければ、ポリシーもレポートもありません。
3. DKIM。 selector._domainkey.＋自ドメインにTXTクエリを実行します。使用するセレクタはメール事業者のドキュメントに記載されています。
4. 端から端まで検証する。大手事業者のアカウント宛にメールを送り、受信したヘッダーを確認します。Gmailの「メッセージのソースを表示」は、今送ったメッセージのSPF・DKIM・DMARCの結果を示し、連鎖全体を覆う唯一のテストです。

DNSを開いたついでに、メール設定の残りも確認しましょう。MXレコードが想定どおりの宛先を指しているか、サーバー証明書のホスト名が一致しているかは、SSL証明書チェッカーで検証できます。

よくある間違い

• SPFレコードが2件ある。 1件に統合してください。2件は恒久エラーです。
• DMARCをp=noneのまま放置する。監視は出発点であって到達点ではありません。なりすましを防ぐのはquarantineかrejectだけです。
• レポート用アドレスがない。 rua=のないDMARCレコードは、ポリシーを安全に強化するために必要な情報を捨てています。
• パーキングドメインを忘れる。メールを送らないドメインこそv=spf1 -allとp=rejectを公開すべきです。攻撃者は未使用のドメインを好むからです。
• いきなりstrictアラインメントにする。レポートがきれいになる前にadkim=sやaspf=sにすると、サブドメインからの正規メールが壊れます。
• TTLを無視する。 TXTレコードのTTLが長いと、修正の反映に何時間もかかります。移行前に下げ、完了後に戻してください。

今日からメール認証を始める

メール認証は、見返りが明確な数少ないセキュリティ作業のひとつです。到達率が上がり、不正利用が見え、ドメインを簡単にはなりすませなくなります。しかも外部から完全に読み取れるので、自分の設定を推測で語る理由はありません。無料のDNSルックアップで自ドメインにTXTクエリを実行し、実際に公開されている内容を読み、上の手順を一段ずつ進めてください。

関連ツールとガイド：

• DNSルックアップ — 任意のドメインのTXT・MX・SPFなど全レコードを照会。
• DNSルックアップ：完全ガイド — 各レコード種別をやさしく解説。
• SSL証明書チェッカー — メールサーバーやWebサーバーの証明書を確認。
• HTTPステータスコード — すべての応答コードのクイックリファレンス。
• SPFレコードが何度も失敗する理由と直し方 - 10 回の照会制限、壊れた include など SPF が失敗する原因。

よくある質問