サーバーでメールのなりすまし対策｜SPF・DKIM・DMARCをp=rejectまで設定した実体験

• なりすましは「特別に狙われた」のではなく、対策していない状態を放置していたこと自体が原因
• SPF / DKIM / DMARC は3点セット。DMARC を効かせるには SPF と DKIM が先
• DMARC ポリシーは none → quarantine → reject と段階的に上げるのが定石
• 日本の大手企業（日経225）で p=reject まで上げているのは15%（2026年・プルーフポイント調査）
• reject まで上げると「あなたのドメインを名乗るメールは、あなたのサーバー以外からは送れない」状態を作れる

こんな人に向いています

• 共用サーバー（Xサーバー等）で独自ドメインメールを運用している、フロントエンド・インフラ寄りのエンジニア
• 自社または顧客ドメインのメール認証（SPF / DKIM / DMARC）を適切に設定したい人
• 2023年2月以前から独自ドメインを利用しており、SPF / DKIM / DMARC の設定状況を確認していない人
• DMARC を p=none のまま運用しており、p=reject への移行を迷っている人

こんな人には向かないかもしれません

• 複数の外部メール配信サービスを併用する大規模な送信基盤を構築したい人（SPF の10ルックアップ制限などを考慮した別途設計が必要です）
• Google Workspace や Microsoft 365 など、共用サーバー以外のメール環境を利用している人（設定方法や管理画面が異なります）

 

なりすましの原因は、特別に狙われたからではなく、DMARC 未設定で「誰でも差出人を名乗れる状態」を放置していたためです。

メールの差出人アドレス（From）は、実は送信側が自由に書けるものです。何の認証もなければ、第三者が あなた@あなたのドメイン を名乗ってメールを送っても、受信側はそれを本物かどうか判定できません。
スパマーはこの性質を利用し、認証が未設定のドメインを機械的に探して、踏み台として大量のなりすましメールを送信します。

つまり起きていたのは「なりすまされた」というより、「なりすませる状態を放置していた」ということです。
鍵をかけていない家が空き巣に入られるのと同じで、狙い撃ちされた特別な理由があったわけではなく、対策していないこと自体が原因でした。

「設定した覚えがないのに未対策」はなぜ起きるのか？（特に古いドメイン）

古いドメインで認証設定が空白になりやすいのは、Xサーバーの DKIM 自動対応が2023年2月以降に始まったため、それ以前から運用しているドメインには自動適用されていないケースがあるからです。

現在のXサーバーでは、ドメイン追加時に SPF や DKIM がほぼ自動で有効になります。
しかし、DKIM の自動対応が始まったのは2023年2月以降で、しかもサーバーごとに順次適用される形でした。そのため、それ以前から利用しているドメインでは、DKIM が自動で有効になっていない場合があります。

新しく契約した人は SPF・DKIM が自動で有効になっていても、古くから使っているドメインほど「自分で設定した覚えがないし、自動でも入っていない」という空白が生まれやすい。

そして DMARC は現在でも利用者自身が有効化する必要があります。
サーバー側が勝手に p=reject を設定すると、正規のメールまで受信拒否される事故につながる可能性があるため、安全側に配慮した合理的な仕様です。

その結果、長期間運用しているドメインでは、SPF は設定済みでも DKIM は未対応、さらに DMARC は未設定という中途半端な状態になりがちです。
こうした状態は、なりすましメールの温床になりやすいため、心当たりがある場合は一度認証状況を確認することをおすすめします。

Xサーバーでの具体的な設定手順は、Xサーバー公式マニュアル（DMARC設定） が参考になります。

「うちは何も送ってないから関係ない」は危険です。メールを送っていないドメインこそ、認証が未設定のまま放置されがちで、踏み台にされやすい。
コーポレートサイトのドメインなどは特に要注意です。

 

2026年は、主要メールプロバイダや国の動きによって、DMARC 未設定だと「メールが届かない・取引で不利になる」方向へ進んでいるためです。

少し前までは DMARC を設定していなくても実運用で大きな問題が出ることは少なく、「後回し」で済んでいました。
しかし現在は Google・Yahoo・Apple・Microsoft などが大量送信者に対してメール認証（SPF / DKIM / DMARC）を求めるようになり、国内でも経済産業省がクレジットカード業界へ DMARC 導入を要請しています。
業種によっては、取引条件やセキュリティチェックシートの項目として導入を求められるケースも増えています。

一方で、知っておくと面白い事実があります。
DMARC を設定している会社は急増したものの、その大半が「効いていない設定」のまま運用されているということです。

DMARCの状態	挙動	位置づけ
未設定	なりすまし放題	一番危険
p=none（監視のみ）	レポートは届くが、なりすましは素通り	実は多数派
p=quarantine	認証失敗メールを隔離	中間段階
p=reject	なりすましメールを拒否	ここで初めて本格的な対策になる

2026年のプルーフポイントの調査によると、日本の大手企業（日経225）でも p=reject まで引き上げている企業は15%にとどまり、56%が p=none（監視のみ）で運用しています。

また、中小企業を含む東証上場企業を対象とした NRIセキュアの調査では、p=reject を設定している企業は1%未満という報告もあります。

裏を返せば、p=reject まで到達できれば、多くの企業がまだ実現できていない上位レベルのメール認証対策を実施できているということです。
DMARC は「設定しただけ」で終わりではなく、最終的に p=reject まで引き上げて初めて、なりすまし対策として機能します。

3つの役割を一言ずつで整理すると、SPF は送信元IPの認証、DKIM は電子署名による改ざん検知、DMARC はその結果をどう扱うかの指示とレポートです。なりすまし対策は、この3点セットで初めて成立します。

仕組み	役割	ざっくり言うと
SPF	送信元IPの認証	「このドメインのメールは、このサーバーから送るよ」という宣言
DKIM	電子署名による改ざん検知	メールに署名を付け、途中で書き換えられていないことを保証
DMARC	SPF/DKIMの結果をどう扱うか＋レポート	認証に失敗したメールを「監視・隔離・拒否」のどれにするか指示し、結果を報告させる

ポイントは、DMARC は SPF と DKIM が前提だということです。
SPF と DKIM が整っていない状態で DMARC を reject にすると、自分の正規メールまで弾かれてしまう可能性があります。
そのため、SPF → DKIM → DMARC の順番で整備することが重要です。

p=reject まで上げるなら SPF と DKIM の両方が事実上必須で、その理由はメール転送に対する強さが正反対だからです。DMARC は「SPF か DKIM のどちらかが pass すればよい」という緩やかな OR 判定なので、両方揃っていることで転送時のリスクを相互に補完できます。

• SPF は転送に弱い。
  SPF は「どのサーバーIPから送られたか」で正当性を判断します。
  メールが途中で転送（フォワード）されると送信元IPが転送サーバーのものに変わるため、SPF認証が壊れて fail します。
  例えば @独自ドメイン → @gmail に転送する構成では、正規メールであっても SPF が落ちることはよくあります。

• DKIM は転送に強い。
  DKIM は IP ではなく、メール本文やヘッダに付与された電子署名で正当性を判断します。
  署名はメールと一緒に運ばれるため、転送で経路が変わっても、本文やヘッダが改変されていなければDKIM は pass を維持できます。

つまり片方だけだと、転送経路の違いで認証が同時に崩れ、正規メールまで reject されるリスクがあります。
だからこそ、SPF と DKIM は両輪で設計する必要があります。

SPF は、送信に使うサーバーを TXT レコードで宣言します。Xサーバーのようにサーバー側で SPF を用意している場合は、その include を入れるのが基本です。

v=spf1 +a:sv****.xserver.jp +mx include:spf.sender.xserver.jp ~all

（sv**** の部分は契約サーバーによって異なります。Xサーバーの場合は管理画面の案内に従ってください。）

注意点が2つあります。

• 末尾は ~all（ソフトフェイル）か -all（ハードフェイル）
  最初は ~all で様子を見て、問題なければ -all に上げるとより厳格になります。
• SPF は「DNSルックアップ10回まで」という上限
  include を増やしすぎると上限を超えて SPF 全体が無効化される可能性があります。
  外部メール配信サービスを複数使う場合は特に注意が必要です。

DKIM は、Xサーバーの場合「管理画面から DKIM を有効化する」「指示された TXT レコードを DNS に入れる（同サーバーで DNS 管理している場合は自動反映）」の2点で完了します。

DKIM を有効化すると、署名用の鍵と DNS レコード（TXT）が自動で用意されることが多いです。設定後、送信したメールのヘッダには DKIM-Signature: が付与されます。これは電子署名であり、受信側がこれを検証することで「途中で改ざんされていない正規メールかどうか」を判断します。

つまり DKIM は「メールの中身が途中で書き換えられていないこと」を保証する仕組みで、SPF のように送信元IPを見るのではなく、内容ベースで正当性を確認するのが特徴です。

DMARC は、_dmarc サブドメインの TXT レコードとして設定し、ポリシーを none から段階的に上げるのが定石です。SPF と DKIM が揃ってから着手します。

DMARC の基本構造は「認証結果に応じてどう扱うか」を定義するもので、まずは監視から始めて挙動を確認し、その後に隔離・拒否へと移行します。

v=DMARC1; p=none; rua=mailto:report@example.com

ここから段階的にポリシーを強化していきます。

• none：監視のみ（レポート収集段階）
• quarantine：認証失敗メールを隔離
• reject：認証失敗メールを拒否

ポイントは、いきなり reject にしないことです。
SPF と DKIM の整合性を確認しながら段階的に引き上げることで、正規メールの誤判定を防ぎつつ安全に強化できます。

ポリシーは段階的に上げる

ポリシー	挙動	位置づけ
p=none	何もしない（監視・レポートのみ）	まず現状把握。正規メールが誤って失敗していないか確認
p=quarantine	認証失敗を迷惑メール扱い（隔離）	中間段階
p=reject	認証失敗を受信拒否	最も厳格。なりすましを受信側で弾く

none で自分の正規メールがすべて pass していることを確認してから、quarantine → reject と段階的に引き上げます。
いきなり reject にすると設定ミスがあった場合に正規メールまで届かなくなるため、慎重な移行が必要です。

実際に設定したレコード

最終的に、こういう形に落ち着きました。

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

各タグの意味です。

• v=DMARC1 — DMARC のバージョン宣言（固定）
• p=reject — 認証に失敗したメールは受信側で拒否
• rua=mailto:... — 集計レポート（aggregate report）の送り先。各メールプロバイダから、認証の成否を集計したXMLレポートが定期的に届く

この設定により、なりすましメールは受信段階でブロックされつつ、同時に rua によってドメイン全体の認証状況を継続的に監視できます。
つまり reject による防御と、レポートによる可視化を両立する構成です。

レポートは `rua` だけでよい

レポートには rua（集計レポート）と ruf（失敗レポート）の2種類がありますが、実運用では rua だけ入れれば十分です。

• rua（集計レポート）
  「このドメイン宛／名乗りのメールが何通、SPF/DKIM を pass/fail したか」という統計情報。
  自分の正規メールが失敗していないか、なりすましがどれだけ来ているかを把握できるため、基本的に必須です。
• ruf（失敗レポート）
  個別の失敗メールの詳細レポート。
  ただし最近はプライバシー配慮の観点から、ruf を送らない／対応しないプロバイダが増えており、設定しても届かないケースが多いのが実情です。

そのため実務では、rua のみで運用するのが一般的です。
まずは集計レポートで全体の傾向を把握し、必要に応じて対策を調整していきます。

p＝reject にしてしばらく経った頃、あるメールプロバイダ（携帯キャリア）から「あなたのドメインを名乗るメールを、DMARC の reject ポリシーに従って受信拒否した」という通知が届きました。これは設定ミスではなく、設定が正しく機能している証拠でした。

最初は「何かエラーか？」と身構えたのですが、中身を読むと逆でした。なりすまし犯がこちらのドメインを名乗ってメールを送ろうとし、それを受信側が DMARC のポリシーに従って拒否してくれた——つまり、なりすましメールが設定どおりに弾かれたという通知でした。

設定して終わりではなく、その設定が実際に攻撃を防いでいる瞬間を観測できた、という意味で、これが一番の収穫でした。

DMARC レポートやプロバイダからの通知は、一見エラーに見えて実は「正常動作の報告」であることがよくあります。
慌てて設定を戻す前に、それが失敗の通知なのか、防御成功の通知なのかを読み分けるのが大事です。

実体験から、要点を整理します。

1. SPF / DKIM / DMARC は3点セット。 DMARC を効かせるには SPF と DKIM が先。順番を守る。
2. DMARC ポリシーは段階的に。
   none で自分の正規メールが pass していることを確認してから
   quarantine → reject。
   いきなり reject はリスク。
3. rua は入れる、ruf は無理に入れなくてよい。
   集計レポートで運用状況が見える。
4. reject 後の通知は「防御成功」のことがある。
   エラーと早合点せず中身を読む。

なりすまし被害は「ある日突然」起きます。まだ DMARC が none のままだったり、そもそも設定していない場合は、この機会に reject までの道筋を引いておく価値があります。実装自体は、思っているより重くありません。

Q. SPFだけ、あるいはDKIMだけではダメですか？

A. 仕様上はどちらか一方でも DMARC は成立しますが、p=reject まで上げるなら両方が事実上必須です。SPF は転送でIPが変わると fail し、DKIM は署名が壊れなければ転送に強い、という正反対の性質があるためです。両方あれば、転送で SPF が落ちても DKIM が拾い、正規メールの巻き込み拒否を防げます。

Q. いきなり p=reject にしてはいけませんか？

A. 避けるべきです。SPF / DKIM に漏れがある状態で reject にすると、自分の正規メールまで受信拒否されてしまいます。まず p=none で集計レポートを見て、自分の送信メールがすべて pass していることを確認してから、quarantine → reject と段階的に上げます。

Q. ruf（失敗レポート）は設定すべきですか？

A. 無理に設定する必要はありません。近年はプライバシー配慮により ruf を送信しないプロバイダが増えており、設定しても届かないケースが多いためです。運用状況の把握は rua（集計レポート）だけで十分です。

Q. メールを送っていないドメインも DMARC は必要ですか？

A. 必要です。むしろ送信していないドメインほど、認証が未設定のまま放置されてなりすましの対象になりやすくなります。送信予定がなくても p=reject で DMARC を設定しておけば、第三者がそのドメインを名乗っても受信側で拒否され、踏み台化のリスクを下げられます。

Q. 古いドメインで DKIM が有効になっているかどう確認すればいいですか？

A. 自分のドメインから送ったメールのヘッダに DKIM-Signature: があるかを確認するのが手早い方法です。Xサーバーの DKIM 自動対応は2023年2月以降に開始されているため、それ以前から運用しているドメインでは未設定の可能性があり、管理画面での確認が推奨されます。

Q. p=none のままでもなりすまし対策になりますか？

A. なりません。p=none は集計レポートが届くだけで、なりすましメール自体は素通りします。実際に防御として機能するのは quarantine 以上で、確実に遮断するのは reject です。DMARC は「設定していること」と「防御として効いていること」が別物です。

• プルーフポイント「日本は詐欺メール防止の有効な設定で18カ国中最下位」プルーフポイント公式発表（参照日：2026-06-25）
• NRIセキュア「DMARCとは」NRIセキュア解説記事（参照日：2026-06-25）
• Xサーバー公式マニュアル「DMARC設定」Xサーバー公式マニュアル（参照日：2026-06-25）

※本記事は筆者が自身のドメインで実際に対応した記録です。サーバーやドメインの構成によって設定方法・レコードの書式は異なるため、適用時は各サービスの公式ドキュメントを確認し、まず p=none から段階的に進めてください。