― なりすましメール・迷惑メールを根本からブロックする完全ガイド ―
対象：ドメインを持ちメールを運用しているすべての方（エックスサーバー・お名前.com等）
はじめに ── なぜ今、SPF・DMARC設定が急務なのか
あなたのドメイン（例：example.com）から、あなたが送っていないメールが大量に送信されているとしたら、どう感じますか？ これは現実に起きていることです。「なりすましメール（スプーフィング）」と呼ばれるこの攻撃では、悪意のある第三者があなたのドメインを騙って、フィッシング詐欺や迷惑メールを世界中に送りつけます。
被害を受けた側のドメインはメールの信頼性を失い、送信したメールが相手の迷惑メールフォルダに入るようになったり、最悪の場合ブラックリストに登録されてメール自体が届かなくなります。
この問題を解決する技術が、SPF・DKIM・DMARCの3つです。特に2024年以降、GmailやYahoo!メールがDMARC設定のない大量送信ドメインのメールを制限し始めたことで、メールマガジンやビジネスメールを送っている方には必須の設定となりました。
本記事では、SPFレコードの書き方とDMARCの設定方法を、DNS知識がなくても理解できるよう丁寧に解説します。
📌 この記事でわかること：SPF・DKIM・DMARCとは何か → SPFレコードの書き方と各タグの意味 → DMARCレコードの設定手順 → エックスサーバーでの具体的な設定方法 → 設定後の確認ツールの使い方
第1章：SPF・DKIM・DMARC ── メール認証の「三種の神器」
まず、3つの技術の役割の違いを整理します。それぞれが異なる角度からメールの正当性を検証する仕組みです。
| 技術 | 何を検証するか | 仕組みのイメージ | DNS登録 |
| SPF | 送信元IPアドレスが正規か | 「このドメインはこのIPからしか送らない」と宣言 | TXTレコード |
| DKIM | メール本文が改ざんされていないか | デジタル署名でメールに「封印」を押す | TXTレコード |
| DMARC | SPF/DKIM失敗時の処理を指示 | 失敗したメールを「拒否・隔離・許可」のどれにするかポリシーを宣言 | TXTレコード |
3つの技術は連携して機能します。SPFとDKIMが「認証の実行」、DMARCが「認証結果を使って何をするか」の方針を定める、という関係です。
💡 最低限の優先順位：まずSPFを設定 → 次にDKIMを設定 → 最後にDMARCを設定、という順番が推奨されています。SPFとDKIMが整っていないとDMARCは正しく機能しません。
- 1-1. なりすましメールが届く仕組み
- 2-1. SPFレコードの基本構文
- 2-2. SPFレコードの各タグの意味
- 2-3. 実際のSPFレコードの書き方例
- 2-4. SPFレコード設定時の注意点
- 3-1. サーバーパネルからの設定手順
- 3-2. お名前.com・ムームードメインなどでの設定
- 4-1. DMARCレコードの基本構文
- 4-2. DMARCレコードの各タグ詳細
- 4-3. ポリシー（p=）の3段階を理解する
- 4-4. 実際のDMARCレコードの書き方例
- 4-5. エックスサーバーでのDMARC設定手順
- 5-1. エックスサーバーでのDKIM設定
- 6-1. DNSルックアップツールでレコードを確認
- 6-2. MXToolboxでの確認手順（SPF）
- 6-3. コマンドラインで確認（Windowsは要PowerShell、MacはTerminal）
- 6-4. DMARCレポートの読み方
1-1. なりすましメールが届く仕組み
そもそも、なぜ他人のドメインを騙ったメールが送れてしまうのでしょうか。それは、メールの基本プロトコルであるSMTPが「送信者アドレスを検証しない」設計になっているためです。
SMTPでは、メールの「差出人（From）」フィールドは自由に設定できます。つまり、悪意ある人物が「From: info@yourcompany.com」と書いたメールを送っても、受信側は技術的には区別できないのです。SPF・DKIM・DMARCはこの欠陥を補うために後から追加された技術です。
第2章：SPFレコードの書き方
SPF（Sender Policy Framework）は、「このドメインのメールは、どのIPアドレス・メールサーバーから送信されるか」をDNSに宣言する仕組みです。受信側のメールサーバーは、送信元IPがSPFレコードに記載されたものと一致するかを確認します。
2-1. SPFレコードの基本構文
SPFレコードはDNSのTXTレコードとして登録します。構文は以下のとおりです。
v=spf1 [メカニズム] [修飾子] [オールメカニズム]例：最もシンプルなSPFレコード
v=spf1 include:xserver.ne.jp ~allこの1行で「このドメインのメールはエックスサーバーから送られる。それ以外のサーバーからのメールはソフトフェイル（怪しいがとりあえず受け取る）」と宣言しています。
2-2. SPFレコードの各タグの意味
① v=spf1（バージョン宣言）
SPFレコードの先頭には必ず「v=spf1」を書きます。これがSPFレコードであることを示すバージョン宣言です。変更不要で、必ず先頭に記述します。
② メカニズム（送信を許可するサーバーの指定）
| メカニズム | 意味 | 書き方の例 | 使いどころ |
| ip4: | IPv4アドレスを直接指定 | ip4:203.0.113.1 | 固定IPの自社サーバー |
| ip6: | IPv6アドレスを直接指定 | ip6:2001:db8::1 | IPv6環境の自社サーバー |
| include: | 別ドメインのSPFを参照 | include:xserver.ne.jp | レンタルサーバー・外部サービス |
| a | ドメインのAレコードのIPを許可 | a | ドメイン自体がメールサーバーの場合 |
| mx | ドメインのMXレコードのIPを許可 | mx | MXサーバーからも送信する場合 |
| exists: | 動的な条件チェック（上級者向け） | exists:%{ir}.denylist.com | 特殊用途 |
③ 修飾子（オールメカニズム）── 最後に必ず書く
SPFレコードの末尾には必ず「all」（全サーバーへの最終判定）を書きます。この前に付ける修飾子（+/-/~/?）が最も重要です。
| 修飾子 | 意味 | 推奨度 | 受信側の処理 |
| +all（または all） | すべて許可 | ❌ 非推奨 | SPFを設定していないのと同じ。意味がない |
| -all | ハードフェイル：完全拒否 | ✅ 最も推奨 | リストにないIPからのメールを完全拒否 |
| ~all | ソフトフェイル：受け取るが疑わしいとマーク | 🔶 移行期に使用 | 迷惑メールフォルダに振り分けられることが多い |
| ?all | 中立（どちらとも言わない） | ❌ 非推奨 | 判定を放棄している状態 |
⚠️ 最終的な目標は「-all」（ハードフェイル）です。ただし、-allを設定すると正規のメールも誤ってブロックされる可能性があります。まず「~all」で様子を見て、問題がなければ「-all」に切り替えることを推奨します。
2-3. 実際のSPFレコードの書き方例
【ケース1】エックスサーバーのみで送信
v=spf1 include:xserver.ne.jp ~allエックスサーバーのメールサーバーだけを使ってメール送信している最もシンプルなケースです。
【ケース2】自社サーバー（固定IP）＋エックスサーバー
v=spf1 ip4:203.0.113.10 include:xserver.ne.jp ~all自社の固定IPサーバー（203.0.113.10）とエックスサーバーの両方から送信するケースです。
【ケース3】複数の外部メール配信サービスを使用
v=spf1 include:xserver.ne.jp include:sendgrid.net include:amazonses.com ~allSendGrid（メルマガ配信）、Amazon SES（トランザクションメール）、エックスサーバーの3つから送信するケースです。
【ケース4】Googleワークスペースを使用
v=spf1 include:_spf.google.com include:xserver.ne.jp ~allGoogle WorkspaceでメールをGmail経由で送り、エックスサーバーも使うケースです。
【ケース5】Microsoft 365（旧Office 365）を使用
v=spf1 include:spf.protection.outlook.com ~all2-4. SPFレコード設定時の注意点
① 「10回ルックアップ制限」に注意
SPFレコード内で「include:」を使うと、そのドメインのSPFも参照しに行きます（DNSルックアップ）。このルックアップの回数はRFC 7208で「最大10回」と定められています。includeを多用しすぎると「SPF PermError」になり、認証が失敗します。
📌 include:、a、mx、exists: を合計10回以内に収めること。ip4:・ip6:はカウントされません。外部サービスを多く使う場合は「SPFフラット化」ツールを使いましょう。
② 複数のSPFレコードは登録できない
1つのドメインにSPFレコード（TXTレコード）は1つだけです。複数のTXTレコードにSPFを書くとエラーになります。複数の送信元を許可したい場合は、1行の中にすべて書きます。
# ❌ 間違い：2行に分けて登録
v=spf1 include:xserver.ne.jp ~all
v=spf1 include:sendgrid.net ~all# ✅ 正しい：1行にまとめる
v=spf1 include:xserver.ne.jp include:sendgrid.net ~all第3章：エックスサーバーでのSPFレコード設定手順
エックスサーバーではサーバーパネルからDNSレコードを追加できます。以下の手順でSPFレコードを設定します。
3-1. サーバーパネルからの設定手順
- エックスサーバーのサーバーパネル（https://www.xserver.ne.jp/login_server.php）にログイン
- 「DNSレコード設定」メニューを選択
- 対象のドメインを選択
- 「DNSレコード追加」タブを選択
- 以下の通り入力して「確認画面へ進む」→「追加する」
| 設定項目 | 入力値 |
| ホスト名 | （空白のまま）← ドメイン直下に設定 |
| 種別 | TXT |
| 内容 | v=spf1 include:xserver.ne.jp ~all |
| TTL | 3600（デフォルトのままでOK） |
💡 エックスサーバーでは「ネームサーバーをエックスサーバーに向けている場合」のみサーバーパネルからDNSを設定できます。お名前.comなど外部でDNSを管理している場合は、そちらのDNS管理画面から設定してください。
3-2. お名前.com・ムームードメインなどでの設定
ドメインのネームサーバーをエックスサーバー以外に向けている場合は、そのDNS管理サービスのコントロールパネルからTXTレコードを追加します。設定画面はサービスごとに異なりますが、入力する値は同じです。
| サービス | 設定場所 |
| お名前.com | ドメインNavi → DNS設定 → DNSレコード設定 |
| ムームードメイン | コントロールパネル → ネームサーバー設定 → GMOペパボのDNS設定 |
| Cloudflare | ダッシュボード → DNS → レコード追加 |
| AWS Route 53 | ホストゾーン → レコード作成 → TXTタイプ |
第4章：DMARCの設定方法
DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPFやDKIMの認証が失敗したメールをどう処理するかを受信側に指示する仕組みです。また、認証結果のレポートをドメイン管理者に送信する機能も持っています。
4-1. DMARCレコードの基本構文
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"ポイントは、登録するホスト名が「_dmarc.（ドメイン名）」である点です。通常のドメイン直下ではなく、「_dmarc」というサブドメインに登録します。
4-2. DMARCレコードの各タグ詳細
| タグ | 必須/任意 | 意味 | 値の例 |
| v=DMARC1 | 必須 | DMARCバージョン宣言 | v=DMARC1（固定） |
| p= | 必須 | ポリシー：認証失敗時の処理 | none / quarantine / reject |
| rua= | 推奨 | 集計レポートの送信先メール | mailto:dmarc@example.com |
| ruf= | 任意 | 失敗レポートの送信先メール | mailto:dmarc-ruf@example.com |
| sp= | 任意 | サブドメインのポリシー | none / quarantine / reject |
| pct= | 任意 | ポリシーを適用するメールの割合（%） | 100（デフォルト） |
| adkim= | 任意 | DKIMアライメントモード | r（緩い）または s（厳しい） |
| aspf= | 任意 | SPFアライメントモード | r（緩い）または s（厳しい） |
| fo= | 任意 | 失敗レポートの生成条件 | 0 / 1 / d / s |
4-3. ポリシー（p=）の3段階を理解する
DMARCの設定で最も重要なのが「p=」（ポリシー）タグです。SPF・DKIMの認証が失敗した場合に、受信メールサーバーにどう処理させるかを3段階で指定します。
| ポリシー | 認証失敗時の動作 | 推奨フェーズ | 注意点 |
| p=none | 何もしない（監視のみ） | 導入初期・様子見 | rua=でレポートを受け取り分析できる。まずここから始める |
| p=quarantine | 迷惑メールフォルダへ | 中間段階 | 正規メールが誤判定されるリスクを確認しながら運用 |
| p=reject | 完全に拒否・削除 | 最終目標 | 正規メールが確実に届いていることを確認してから設定 |
⚠️ いきなり p=reject に設定するのは危険です。設定ミスや漏れがあった場合、自社の正規メールが相手に届かなくなります。必ず「p=none → quarantine → reject」の順に段階的に移行してください。
4-4. 実際のDMARCレコードの書き方例
【ステップ1】まず監視から始める（p=none）
v=DMARC1; p=none; rua=mailto:dmarc-report@example.com認証失敗しても何もしないが、レポートをdmarc-report@example.comに送信。まずこの設定でどんなメールが送られているかを2〜4週間監視します。
【ステップ2】隔離に移行する（p=quarantine）
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-report@example.com認証失敗したメールの10%を迷惑メールへ振り分ける。pct=10から始めて徐々に100に増やしていきます。
【ステップ3】完全拒否（p=reject）──最終形
v=DMARC1; p=reject; rua=mailto:dmarc-report@example.com; ruf=mailto:dmarc-fail@example.com; adkim=s; aspf=s認証失敗したメールを完全拒否。集計レポートと失敗レポートの両方を受信し、DKIMとSPFのアライメントを厳しいモード（s）に設定した最終形の例です。
4-5. エックスサーバーでのDMARC設定手順
- サーバーパネル →「DNSレコード設定」→ 対象ドメインを選択
- 「DNSレコード追加」タブを選択
- 以下の通り入力
| 設定項目 | 入力値 |
| ホスト名 | _dmarc |
| 種別 | TXT |
| 内容（最初はこれ） | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
| TTL | 3600 |
- 「確認画面へ進む」→「追加する」で完了
- DNSの反映には最大48時間かかります（通常は数分〜数時間）
💡 rua=で指定するメールアドレスは、同じドメインのものが最も簡単です。他ドメインのアドレスに送りたい場合は、受信側ドメインのDNSに「external-destination」レコードが必要です。
第5章：DKIM設定 ── DMARCを機能させるために必須
DMARCを有効に機能させるには、SPFだけでなくDKIMも設定されている必要があります。DKIMはメール本文にデジタル署名を付与し、改ざんされていないことを証明します。
5-1. エックスサーバーでのDKIM設定
エックスサーバーでは、2022年以降にDKIM設定機能が追加されました。サーバーパネルから簡単に設定できます。
- サーバーパネル →「メール」→「DKIM設定」を選択
- DKIMを有効にするドメインを選択
- 「DKIMを設定する」ボタンをクリック
- 自動的にDNSにDKIMレコードが追加される
手動で設定する場合のDKIMレコードのイメージ：
# DKIMレコードのDNS登録例（ホスト名の形式）
selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=（公開鍵の文字列）"💡 エックスサーバーの自動DKIM設定を使えば、公開鍵の生成・DNS登録をすべて自動で行ってくれます。手動での設定は不要です。
第6章：設定後の確認方法
SPF・DKIM・DMARCを設定したら、正しく反映されているかを確認しましょう。無料のオンラインツールを使えば数秒で確認できます。
6-1. DNSルックアップツールでレコードを確認
| ツール名 | URL | 特徴 |
| MXToolbox | https://mxtoolbox.com/ | SPF/DKIM/DMARC/MXをまとめて確認できる定番ツール |
| Google Admin Toolbox | https://toolbox.googleapps.com/apps/checkmx/ | Googleが提供。Gmail観点での診断に最適 |
| dmarcian | https://dmarcian.com/dmarc-inspector/ | DMARCの詳細分析に特化 |
| Mail Tester | https://www.mail-tester.com/ | 実際にメールを送ってスコアで採点してくれる |
6-2. MXToolboxでの確認手順（SPF）
- https://mxtoolbox.com/spf.aspx にアクセス
- ドメイン名（例：example.com）を入力して「SPF Record Lookup」をクリック
- 「SPF Record Found」と表示されれば設定成功
- 「Result」欄に「Pass」「SoftFail」「Fail」の判定が表示される
6-3. コマンドラインで確認（Windowsは要PowerShell、MacはTerminal）
# SPFレコードの確認
nslookup -type=TXT example.com
# DMARCレコードの確認
nslookup -type=TXT _dmarc.example.com
# DKIMレコードの確認（selectorはエックスサーバーの場合）
nslookup -type=TXT default._domainkey.example.com正しく設定されている場合、それぞれのコマンドで「v=spf1…」「v=DMARC1…」「v=DKIM1…」で始まるTXTレコードが表示されます。
6-4. DMARCレポートの読み方
DMARCのrua=で指定したメールアドレスには、受信側のメールサーバーから集計レポートが送られてきます。レポートはXML形式で読みにくいですが、専用ツールを使えば視覚的に確認できます。
- dmarcian（https://dmarcian.com）：XMLレポートをアップロードして可視化
- Postmark DMARC（https://dmarc.postmarkapp.com）：無料のDMARCレポート監視サービス
- Google Postmaster Tools：Gmailへの配信状況を分析
レポートで確認すべき主な項目：
- 自社ドメインを名乗って送信しているIPアドレスの一覧
- SPF認証の pass/fail の割合
- DKIM認証の pass/fail の割合
- 見知らぬIPからの不審な送信（なりすまし攻撃の証拠）
まとめ ── 設定手順のチェックリスト
本記事の内容を、実際の作業チェックリストとしてまとめます。
| 順番 | 作業内容 | 設定場所 | 完了 |
| 1 | SPFレコードを設定（~all から開始） | DNSのTXTレコード | □ |
| 2 | DKIMを有効化 | サーバーパネル→DKIM設定 | □ |
| 3 | DMARCを設定（p=none から開始） | DNSの_dmarcサブドメイン TXTレコード | □ |
| 4 | MXToolboxでSPF/DKIM/DMARCの確認 | https://mxtoolbox.com/ | □ |
| 5 | DMARCレポートを2〜4週間監視 | rua=で指定したメールを確認 | □ |
| 6 | 問題なければ p=quarantine に移行 | DMARCレコードを更新 | □ |
| 7 | 正規メールの配信を確認後 p=reject に移行 | DMARCレコードを更新 | □ |
| 8 | SPFを ~all から -all に変更（最終形） | SPFレコードを更新 | □ |
SPF・DKIM・DMARCの設定は、一度やれば終わりではありません。新しいメール配信サービスを追加した場合はSPFへの追記が必要ですし、DMARCレポートを定期的に確認して不審な送信がないかを監視することが重要です。
メールの信頼性はビジネスの信頼性に直結します。「自分のドメインからなりすましメールが送られている」という事態を防ぐためにも、今日から設定を始めましょう。※ DNS設定の変更は反映まで最大48時間かかる場合があります。設定後はMXToolbox等で確認してくださ
コメント