ロリポップ固定IPアクセス byGMOペパボ
DMARCとは：SPF・DKIMと合わせて『なりすましメール』を減らす導入手順

DMARCとは：SPF・DKIMと合わせて『なりすましメール』を減らす導入手順

基礎知識

メール詐欺の被害額は年々増加しています。 ビジネスメール詐欺（BEC）により、数千万円から数億円の損失を被った企業の事例も報告されています。 その一般的な手口が「なりすましメール」です。

攻撃者は、信頼できる企業や取引先になりすまして、メールを送信します。 受信者は、そのメールが本物だと信じ込み、入金指示に従ったり、添付ファイルを開いたり、個人情報を提供してしまいます。

この悪質な脅威に対抗するため、業界では「送信ドメイン認証」という仕組みが導入されるようになりました。 その核となるのが「SPF」「DKIM」「DMARC」の3つの技術です。 本記事では、これらの仕組みを詳しく解説し、実装手順を紹介します。

⇒【ロリポップ！固定IPアクセス】 月額490円、すぐに使えて最大2ヶ月間無料！

なりすましメール被害の実態

まず、なりすましメールがどのような被害をもたらすのか、具体的な例を見てみましょう。

実例1：BEC（ビジネスメール詐欺）

経営企画部長になりすましたメールが、経理部に届きました。 「緊急案件で、至急この銀行口座に振込が必要だ。詳細は後で説明する」という内容です。

経理担当者は、部長からの指示と思い込み、即座に数千万円を海外口座に振込ました。 その直後、本物の部長から「そんなメールは送っていない」という連絡がきました。

このような被害は、日本国内でも多数報告されています。

実例2：フィッシングメール

「楽天」をかたったメールが届きました。 「セキュリティの問題が検出されました。以下のリンクから本人確認を行ってください」というリンク付きです。

ユーザーがリンクをクリックすると、本物そっくりの偽のログインページに誘導されます。 そこでユーザーがIDとパスワードを入力すると、攻撃者に認証情報が盗まれます。

実例3：マルウェア配布

「PayPal」をかたったメールで、「お支払い方法を更新してください」という内容の添付ファイル付きメールが送られます。 ファイルを開くと、ランサムウェアが自動的にインストールされます。

これらの被害は、全て「メールの送信元を詐称する」ことで成立しています。 つまり、送信元が本当に信頼できる企業なのかを確認できれば、被害の大部分を防げるのです。

SPF（Sender Policy Framework）とは

送信ドメイン認証の最初の層が「SPF」です。 「このドメインのメールは、どのメールサーバーから送信されるのか」という情報を、事前にDNSレコードに登録しておく仕組みです。

SPFの仕組み

SPFレコードの例と読み方

v=spf1 ip4:203.0.113.0 include:_spf.google.com ~all 各要素の意味：

最後の~allは、メール受信側にどう扱うかを指示するもので、以下のパターンがあります。

SPFの限界

SPFは有用ですが、完璧ではありません。 最大の問題は「メールヘッダを偽造する場合、SPFでは検出できない」という点です。

SPFはメール「エンベロープFrom」（実際のメール送信元）をチェックしますが、ユーザーが目にする「From」ヘッダ（表示名部分）はチェックしません。

つまり、攻撃者は以下のようなトリックを使えます：

このような限界を補うのが「DKIM」です。

DKIM（DomainKeys Identified Mail）とは

DKIMは、メールの「内容が改ざんされていない」ことを、電子署名で証明する仕組みです。

DKIMの仕組み

改ざん検出の例

攻撃者が途中でメール本文を改ざんしようとした場合：

SPFとDKIMの関係図

【メール送信企業】 ↓ 【秘密鍵でメール内容に署名（DKIM）】 ↓ 【登録済みIPアドレスから送信（SPF）】 ↓ 【メール受信企業】 ↓ 【SPF確認：送信元IPはホワイトリストか】 ↓ 【DKIM確認：メール内容は改ざんされていないか】 ↓ 【どちらも OK → メール受け取り】 【どちらか NG → スパム判定 / 警告表示】

DMARC（Domain-based Message Authentication, Reporting, and Conformance）とは

DMARCは、SPFとDKIMの「上位層」の仕組みです。 要するに「SPFとDKIMの検証結果に対して、どう対処するか」を指示するポリシーです。

DMARCが解決する課題

SPFとDKIMには、一つの弱点がありました。 それは「検証に失敗した時、受信側がどう扱うか、統一されていない」という点です。

例えば：

この「ゆらぎ」のせいで、なりすましメール検出の精度が低かったのです。

DMARCポリシーの3つのレベル

DMARCポリシーは、以下の3段階で段階的に導入できます。

レベル1：モニタリング（p=none）

「SPFとDKIMの検証結果を監視するが、メール処理には影響を与えない」という段階です。 初期段階として、問題がないことを確認します。

DMARCレコード例：

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com このポリシーで、検証結果は「rua」で指定したメールアドレスに日次レポートとして送られます。 企業側は、どれくらいの割合でSPF/DKIMに失敗しているのか、把握できます。

レベル2：検査（p=quarantine）

検証に失敗したメールを「スパムフォルダ」に隔離する段階です。 すなわち、受信者には届きますが、注意喚起の対象になります。

DMARCレコード例：

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com この段階で、重大な問題が起きていないか、監視します。 通常、p=noneで少なくとも数週間～1ヶ月監視してから、この段階に進みます。

レベル3：拒否（p=reject）

検証に失敗したメールを完全に拒否する段階です。 「なりすましメール」の可能性が高いものは、受信者に届きません。

DMARCレコード例：

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com この段階でも、意図しない拒否が起きないよう、ビジネスで使用している全てのメール送信元がSPF/DKIMに対応していることを確認します。

SPF/DKIM/DMARC導入の標準手順

企業がこれら3つの認証を導入する場合の、実践的な手順を紹介します。

ステップ1：現状把握（1～2週間）

まず、現在どのような送信元からメールが送信されているのか、把握します。

確認項目：

これらを全て「ホワイトリスト」として集計します。

ステップ2：SPFレコードの作成（1～2週間）

DNSプロバイダ（お名前.com、ムームードメイン、Route53等）にアクセスして、SPFレコードを登録します。

実例（Google Workspaceを利用する場合）：

example.com の TXT レコード

v=spf1 include:_spf.google.com ~all 実例（複数のメール送信元を利用する場合）：

v=spf1 ip4:203.0.113.0 include:_spf.google.com include:sendgrid.net ~all 最初は ~all（ソフトフェイル）にして、問題がないか確認してから、 -all（ハードフェイル）に変更します。

ステップ3：DKIMレコードの作成（2～3週間）

メールサーバー側で、公開鍵と秘密鍵のペアを生成し、公開鍵をDNSに登録します。

メールサーバーが「Google Workspace」の場合、Googleのコンソールで以下の手順を実行します。

DNS登録の例：

google._domainkey.example.com の TXT レコード

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb…（公開鍵） DKIMレコードは複数作成できます。 複数のメール送信元がある場合、各々に対応するDKIMレコードを作成します。

ステップ4：DMARCレコードの登録（初回は監視期間：2～4週間）

SPFとDKIMが正常に機能することを確認した後、DMARCレコードを登録します。

初期段階（p=none）で2～4週間、検証結果を監視します。

DMARCレコード登録例：

_dmarc.example.com の TXT レコード

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com ここで：

ステップ5：DMARC p=quarantine への移行（2～4週間）

レポートを分析して、問題がないことを確認してから、p=quarantineに変更します。

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com この段階でも、不正な拒否が起きていないか、監視します。

ステップ6：DMARC p=reject への移行

p=quarantineで問題がないことを複数サイクル確認した後、最終段階のp=rejectに移行します。

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com ただし、p=rejectに移行後も、定期的にDMARCレポートを監視し続けることをお勧めします。

Microsoft 2025年5月対応：メール送信ルール強化

Microsoft、Google、Yahoo等の大手メールプロバイダは、2025年5月から送信ドメイン認証の要件を厳格化しました。

Microsoftの新ルール（2025年5月1日以降）

Outlook.com、Hotmail.com、Live.com宛のメール送信について

以下の要件を満たさないメールは、スパムとして扱われます。

つまり、2025年5月以降、Microsoftのメールサーバーに送信されるメールで、SPF/DKIM/DMARCが設定されていないものは、受信箱に到達しない可能性が高いのです。

対応期限と優先度

2025年5月が迫っていることを考えると、現在の時点で以下の優先度で導入を進めるべきです。

最優先（すぐに実施）

高優先（1ヶ月以内）

中優先（3ヶ月以内）

組織別の導入シナリオ

企業規模や環境に応じた、現実的な導入シナリオを提示します。

シナリオA：小規模企業（従業員50名以下）

環境

導入手順

総工数：3～5時間（ほぼ自動化可能） コスト：0円（Google Workspaceの標準機能）

シナリオB：中規模企業（従業員100～500名）

環境

導入手順

v=spf1 include:_spf.google.com include:mailchimp.com include:slack.com ~all

総工数：2～3週間 コスト：0円（標準機能）

シナリオC：大企業（従業員1000名以上）

環境

導入手順

総工数：4～6ヶ月 コスト：10～50万円（外部監査、コンサルティング等）

DMARC実装時のよくあるトラブル

実装段階で直面しやすい問題と、対策を紹介します。

トラブル1：SPF・DKIMは設定したのに、DMARC検証で失敗する

原因：SPFとDKIMが「アライメント」していない可能性があります。

DMARCでは、単にSPFやDKIMが成功することだけでなく、「SPF/DKIMで確認したドメイン」と「メール内容に書かれた送信元ドメイン」が一致することが必須です。

例：

対策：

トラブル2：新しいメール配信サービスを導入したら、DMARC reject に引っかかる

原因：新サービスの IPアドレスや送信ドメインが、SPF レコードに含まれていない

対策： まず p=none か p=quarantine に戻して、新サービスからのメール送信を確認します。 その後、SPF/DKIM設定を追加して、新しいメール送信元に対応させます。

トラブル3：外部送信者が「なりすまし判定」を受ける

原因：DMARC reject が厳しすぎる、または SPF/DKIM の設定に問題がある

例：取引先が「example.com」ドメインを装ったメール送信システムを使用しているが、そのシステムからのメールが拒否される

対策： この場合、DMARCレコードに「外部送信を許可」する設定を追加する必要があります。 しかし一般的には「外部送信者には別ドメイン（例：mail-external.example.com）を使用する」よう指導します。

DMARC監視と報告

DMARCレコード登録後、定期的な監視は不可欠です。

DMARCレポートの読み方

rua で指定したメールアドレスに、毎日（または毎週）XML形式のレポートが送信されます。

レポートに含まれる主な情報：

レポート分析の例

レポートから「example.com をかたったメールが、中国のIPアドレス 123.45.67.89 から送信されている」という情報が得られた場合、企業はこのIPをブロックリストに追加したり、セキュリティ警告を発行したりできます。

外部ツールの活用

DMARCレポートの解析は複雑なため、以下のような外部ツールを使用すると、自動化できます。

業界別の実装ベストプラクティス

金融機関

ビジネスメール詐欺のターゲットになりやすいため、最高レベルのセキュリティが必須です。

推奨：

eコマース企業

顧客へのメール（注文確認、配送通知等）の信頼性が、ビジネスに直結します。

推奨：

SaaS / 通信企業

大量のシステムメール送信が発生するため、細かい管理が必要です。

推奨：

チェックリスト：導入前に確認すべき項目

実装前に、以下を確認してください。

ドメイン管理に関して

メール送信元の確認

実装環境の確認

組織体制の確認

よくある質問（FAQ）

Q1：小規模企業にとって、DMARC導入は本当に必要か？

A：2025年5月以降、Microsoft等への送信が拒否されるリスクがあるため、必須です。 特に、顧客向けメール（見積もり、請求書等）を送信する企業は、対応が必須です。

Q2：Gmail アドレスだけを使用している場合、何もしなくてよいか？

A：企業向けには不十分です。 企業ブランドを守るため、独自ドメイン（example.com）でのメール送信を推奨します。 その場合、SPF/DKIM/DMARCの設定が必要です。

Q3：複数の子会社がある場合、DMARC設定はどうするのか？

A：各子会社が独立したドメインを保有している場合、各ドメイン独立で設定します。 グループウェアで統一ドメインを使用している場合、中央集約管理をお勧めします。

Q4：DMARC で拒否したメール、受信者には何が起きるのか？

A：メール受信側の判断によって異なります。

Q5：DMARC導入後、レポートが届きません。

A：以下を確認してください。

まとめ：信頼のインフラをメールに

なりすましメール対策は、単なる「セキュリティ」ではなく、ブランド信頼の問題です。

顧客が「本当に企業から送信されたメールなのか」を確認できれば、フィッシング被害を減らせます。 企業間取引において、メールの真正性が保証されれば、BECのような詐欺を大幅に減らせます。

SPF、DKIM、DMARC—これら3つの技術は、単なる技術的な要件ではなく、企業のデジタル信頼基盤を構築するための必須投資です。

2025年5月の Microsoft新ルール対応を機に、多くの企業が対応を迫られています。 まだ導入していない企業は、早期の実装をお勧めします。

固定IPで安全なアクセス環境を実現するなら「ロリポップ！固定IPアクセス」

メール送信セキュリティをさらに強化したい場合、固定IPアドレスの活用も検討してください。

ロリポップ！固定IPアクセスは、今お使いのインターネット回線をそのまま活かして固定IPアドレスを利用できるVPNサービスです。 月額539円（税込）から、初期費用0円・最大2ヵ月無料で始められます。 WireGuardによる高速接続で、VPN特有の速度低下も気になりません。

メール配信サーバーに固定IPを割り当てることで、SPFレコードの設定がより明確になります。 また、メール送信時に常に同じIPアドレスから送信されることが保証され、SPF認証の信頼性がさらに高まります。

社内からのメール送信にIPアドレス制限を設定することで、不正アクセスのリスクも低減できます。

プロバイダの乗り換えも不要で、申し込んだその日から利用できます。

→ ロリポップ！固定IPアクセスの詳細はこちら

おすすめの記事

ゼロトラスト導入前に行うアクセス元の棚卸し：固定IP・SaaS・端末を可視化する方法
基礎知識

ゼロトラスト導入前に行うアクセス元の棚卸し：固定IP・SaaS・端末を可視化する方法

管理者アカウントを守るゼロトラスト：SaaS管理画面のIP許可リスト運用
基礎知識

管理者アカウントを守るゼロトラスト：SaaS管理画面のIP許可リスト運用

APIキー・シークレット管理の基本：漏えいリスクを減らすゼロトラスト運用
基礎知識

APIキー・シークレット管理の基本：漏えいリスクを減らすゼロトラスト運用

どこからでも簡単に
固定IPアドレスでアクセス

導入相談