「取引先からの請求書メール、本物かどうか判断できますか？」
ビジネスメールを悪用した詐欺（BEC: Business Email Compromise）の被害は年々増加しており、IPA（情報処理推進機構）の「情報セキュリティ10大脅威」でも常に上位にランクインしています。特に中小企業では、専任のセキュリティ担当者がいないケースも多く、なりすましメールへの対策が後回しになりがちです。
この記事では、メールのなりすましを防ぐ3つの認証技術「SPF」「DKIM」「DMARC」について、仕組みから設定手順、運用のポイントまでを現場目線で解説します。「DNSの設定なんて触ったことがない」という方でも理解できるよう、順を追って説明していきます。
メール認証とは？なぜ今、中小企業にも必要なのか
メール認証とは、「このメールは本当にそのドメインの持ち主が送ったものか？」を受信側が検証できる仕組みです。
普段何気なく使っているメールですが、実はSMTP（メール送信プロトコル）には送信者を確認する機能がもともと備わっていません。つまり、技術的には誰でも他人のメールアドレスを名乗ってメールを送れてしまいます。
これを悪用したのが「なりすましメール」です。自社のドメインを騙られると、以下のようなリスクがあります。
・取引先への詐欺: 自社を装った偽の請求書メールで、取引先が振込被害に遭う
・信用の失墜: 自社ドメインからスパムが大量送信され、ブランドイメージが傷つく
・メール到達率の低下: Googleなど大手メールサービスが認証なしのメールを迷惑メール扱いにする
2024年2月以降、GmailとYahoo!メールは送信者認証（SPF・DKIM・DMARC）を満たさないメールの受信を厳格に制限する方針を打ち出しました。つまり、メール認証は「やったほうがいい」ではなく「やらないとメールが届かない」時代に入っています。
SPF・DKIM・DMARCの仕組みを理解する
メール認証には3つの技術があり、それぞれ役割が異なります。3つを組み合わせることで、なりすまし対策の精度が大きく向上します。
SPF（Sender Policy Framework）
SPFは「このドメインからメールを送っていいサーバーはどれか」をDNSに宣言する仕組みです。
受信サーバーは、メールが届いたときに送信元IPアドレスとDNSのSPFレコードを照合します。一致しなければ「なりすましの可能性あり」と判定されます。
たとえるなら、会社の受付に「うちの社員はこの名簿に載っている人だけです」と伝えておくようなイメージです。名簿にない人が社員を名乗っても、受付で止められます。
DKIM（DomainKeys Identified Mail）
DKIMは、送信メールに電子署名（デジタル署名）を付与する仕組みです。
送信サーバーがメールのヘッダーと本文からハッシュ値を生成し、秘密鍵で署名します。受信サーバーはDNSに公開されている公開鍵で署名を検証し、メールが改ざんされていないかを確認します。
SPFが「誰が送ったか」を検証するのに対し、DKIMは「送信後に内容が書き換えられていないか」も検証できる点が強みです。
DMARC（Domain-based Message Authentication, Reporting and Conformance）
DMARCは、SPFとDKIMの検証結果をもとに「認証に失敗したメールをどう扱うか」を送信ドメイン側がポリシーとして宣言する仕組みです。
DMARCには3段階のポリシーがあります。
| ポリシー | 動作 | 推奨フェーズ |
|---|---|---|
| none | 何もしない（レポートのみ受信） | 導入初期・監視フェーズ |
| quarantine | 迷惑メールフォルダに振り分け | 設定確認後の移行期 |
| reject | 受信を拒否する | 本格運用フェーズ |
さらにDMARCは「アライメント」という概念を持っています。これは、メールの「From:ヘッダーに書かれたドメイン」とSPF/DKIMで認証されたドメインが一致しているかをチェックする仕組みです。SPFやDKIMが単体でPassしていても、Fromヘッダーのドメインと一致しなければDMARCはFailになります。
具体的な設定手順
ここからは、実際にDNSレコードを設定する手順を説明します。利用しているDNSサービス（お名前.com、さくらインターネット、AWS Route 53など）の管理画面からTXTレコードを追加します。
1. SPFレコードの設定
SPFレコードは、ドメインのDNSにTXTレコードとして追加します。
# SPFレコードの例（自社メールサーバー + Google Workspaceを使う場合） example.co.jp. IN TXT "v=spf1 ip4:203.0.113.1 include:_spf.google.com ~all"
各要素の意味は以下のとおりです。
・v=spf1: SPFのバージョン宣言（必須）
・ip4:203.0.113.1: この IPアドレスからの送信を許可
・include:_spf.google.com: Google Workspaceのサーバーからの送信を許可
・~all: 上記以外からの送信はソフトフェイル（疑わしいと判定するが拒否はしない）
設定後は、以下のコマンドで正しく反映されているか確認します。
# SPFレコードの確認 dig example.co.jp TXT +short | grep spf
2. DKIMの設定
DKIMの設定は、メールサーバーまたはメール配信サービス側で鍵ペアを生成し、公開鍵をDNSに登録する流れです。
Google Workspaceの場合は管理コンソールからDKIM署名を有効化すると、登録すべきDNSレコードが表示されます。表示された値をそのままDNSのTXTレコードに追加します。
# DKIMレコードの例（セレクタ名: google） google._domainkey.example.co.jp. IN TXT "v=DKIM1; k=rsa; p=MIIBIjAN..."
自社でPostfixなどのメールサーバーを運用している場合は、OpenDKIMパッケージを導入して鍵の生成と署名設定を行います。
# OpenDKIMで鍵ペアを生成する例 opendkim-genkey -s mail -d example.co.jp # mail.txt に公開鍵、mail.private に秘密鍵が生成される
3. DMARCレコードの設定
DMARCレコードもDNSにTXTレコードとして追加します。まずは「none」ポリシーから始めて、レポートで状況を把握することを推奨します。
# DMARCレコードの例（監視モードから開始） _dmarc.example.co.jp. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@example.co.jp; ruf=mailto:dmarc-report@example.co.jp; fo=1"
各要素の意味は以下のとおりです。
・v=DMARC1: DMARCのバージョン宣言
・p=none: ポリシー（まずはnoneで監視のみ）
・rua=mailto:…: 集計レポートの送信先
・ruf=mailto:…: 詳細レポート（フォレンジックレポート）の送信先
・fo=1: SPFまたはDKIMのいずれかが失敗した場合にレポートを送信
設定後の確認コマンドはこちらです。
# DMARCレコードの確認 dig _dmarc.example.co.jp TXT +short
中小企業でも今日からできること
「DNS設定なんて難しそう」と感じるかもしれませんが、段階的に進めれば問題ありません。以下のステップで取り組んでみてください。
ステップ1: 現状を確認する（所要時間: 5分）
まずは自社ドメインの認証状況を確認しましょう。無料のチェックツールで簡単に調べられます。
# 自社ドメインのSPF・DKIM・DMARCを一括確認 dig example.co.jp TXT +short dig _dmarc.example.co.jp TXT +short
何も表示されなければ、認証が未設定です。
ステップ2: SPFレコードを追加する（所要時間: 15分）
3つの中で最も設定が簡単なSPFから始めましょう。DNS管理画面にTXTレコードを1行追加するだけです。利用中のメールサービスのヘルプページに、設定すべきSPFレコードの値が記載されています。
ステップ3: DKIMを有効化する（所要時間: 30分）
Google WorkspaceやMicrosoft 365などのクラウドメールサービスを利用している場合は、管理画面の指示に従ってDNSレコードを追加するだけです。
ステップ4: DMARCをnoneで導入する（所要時間: 10分）
まずは「p=none」で導入し、レポートを受け取る体制を整えます。いきなり「reject」にすると、正規のメールまでブロックしてしまうリスクがあるため、必ず段階的に進めてください。
ステップ5: レポートを分析してポリシーを強化する（1〜3ヶ月後）
DMARCレポートを1〜3ヶ月分蓄積したら、内容を確認します。XML形式のレポートはそのままでは読みにくいため、DMARC Report Analyzerなどの無料ツールを使うと視覚的に把握できます。問題がなければ「quarantine」→「reject」と段階的にポリシーを強化していきます。
よくある誤解と注意点
「SPFだけ設定すれば大丈夫」は間違い
SPFだけでは、メール転送時に認証が壊れるケースがあります。また、SPFはエンベロープFrom（実際の送信元）を検証しますが、ユーザーが目にするヘッダーFrom（表示される送信元）は検証しません。DKIMとDMARCを組み合わせて初めて、実用的ななりすまし対策が成立します。
「DMARCをいきなりrejectにしたい」は危険
正規のメールが認証に失敗するケースは意外と多いです。メーリングリストの経由、メール転送サービスの利用、外部の配信サービス（メルマガ配信など）の設定漏れなどが原因になります。まずは「none」で監視し、レポートで問題がないことを確認してからポリシーを段階的に強化してください。
SPFレコードの「include」が10個を超えるとエラーになる
SPFにはDNSルックアップの上限が10回という仕様上の制限があります。複数のクラウドサービスを利用している企業では、includeを追加していくうちに上限に達してしまうことがあります。その場合は、IPアドレスの直接指定や、SPFフラットニングサービスの利用を検討してください。
メール配信サービスの設定を忘れがち
メルマガ配信やマーケティングオートメーションツールなど、自社ドメインでメールを送信する外部サービスがある場合は、そのサービスのSPF・DKIM設定も必要です。設定を忘れると、正規のマーケティングメールがDMARC認証に失敗し、迷惑メール扱いになります。
メール配信の基盤となるLinuxサーバーの管理手法については、姉妹サイトLinuxMaster.JPで詳しく解説しています。
本記事のまとめ
メール認証（SPF・DKIM・DMARC）は、なりすましメールから自社と取引先を守るための基本的な対策です。
| 認証技術 | 役割 | 設定場所 | 難易度 |
|---|---|---|---|
| SPF | 送信サーバーのIPアドレスを検証 | DNS（TXTレコード） | 低 |
| DKIM | メールの電子署名を検証 | DNS + メールサーバー | 中 |
| DMARC | 認証失敗時のポリシーを宣言 | DNS（TXTレコード） | 低〜中 |
2024年以降、GmailやYahoo!メールをはじめとする主要メールサービスがメール認証を要求するようになりました。設定していないと、自社からの正規メールが相手に届かないという実害が発生します。
まずはSPFの設定から始めて、DKIM、DMARCと段階的に進めていきましょう。DMARCは必ず「none」から開始し、レポートを確認しながらポリシーを強化するのが安全な進め方です。
自社のメール、なりすまされていませんか？
SPF・DKIM・DMARCの設定は、一度正しく行えば継続的に効果を発揮します。
正しいセキュリティ知識を体系的に身につけたい方へ、メルマガで実践的なセキュリティ対策ノウハウをお届けしています。
コメント