はじめに
自社のドメインを悪用した「なりすましメール」を完全に防止する方法がDMARCのp=rejectです。しかし、いきなりp=rejectに設定するとメール不達事故が発生するリスクがあります。
本記事では、p=noneから始めて、安全にp=rejectまで到達するためのロードマップを解説します。
SPF/DKIM/DMARCの関係
SPF（Sender Policy Framework）
「このドメインからメールを送信できるサーバーはこれだけ」とDNSに宣言する仕組みです。受信側はSPFレコードを確認し、許可されていないサーバーからのメールを判定します。
DKIM（DomainKeys Identified Mail）
メールに電子署名を付与し、送信元の正当性と内容の改ざんがないことを証明します。送信時にメールヘッダーに署名を追加し、受信側がDNSに公開されている公開鍵で検証します。
DMARC（Domain-based Message Authentication）
SPFとDKIMの認証結果に基づき、認証に失敗したメールの処理方法を送信者側が指定する仕組みです。
- p=none：何もしない（レポートだけ受信）
- p=quarantine：隔離（受信者の迷惑メールフォルダに振り分け）
- p=reject：拒否（受信サーバーがメールを受け取らない）
4フェーズのロードマップ
Phase 1：SPF/DKIMの設定＋DMARC p=none（1〜2ヶ月）
まずはSPFとDKIMが正しく設定されていることを確認し、DMARCをp=noneで設定します。
SPFの設定
DNSにTXTレコードを追加します。M365の場合は以下の通りです。
v=spf1 include:spf.protection.outlook.com -all
GWSの場合：
v=spf1 include:_spf.google.com -all
外部のメール配信サービス（SendGrid、Amazon SES等）を利用している場合は、それらのincludeも追加する必要があります。SPFはDNSルックアップの上限が10回であることに注意してください。
DKIMの設定
M365では、Exchange管理センター→メールフロー→DKIM で対象ドメインのDKIMを有効化し、DNSにCNAMEレコードを2つ追加します。GWSでは管理コンソール→アプリ→Gmail→メールの認証 でDKIMキーを生成し、DNSにTXTレコードを追加します。
DMARCの設定（p=none）
DNSにTXTレコードを追加します。
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
ruaに指定したメールアドレスにDMARCレポートが届きます。このレポートを分析して、正規のメール送信元がすべてSPF/DKIMに対応しているかを確認します。
Phase 2：レポート分析と修正（2〜4週間）
DMARCレポートを分析し、正規のメール送信元がすべて認証に合格しているかを確認します。レポートはXML形式で読みにくいため、DMARCレポート分析サービス（DMARC Analyzer、Postmark DMARC等、無料のものもあり）を利用すると便利です。
確認ポイントは以下の通りです。
- 自社のメールサーバー（M365/GWS）からのメールがSPF/DKIM両方に合格しているか
- マーケティングツール（HubSpot、Mailchimp等）からのメールが合格しているか
- 請求書発行システム等からの自動メールが合格しているか
- 合格していない送信元があれば、SPFにincludeを追加するか、DKIMを設定する
Phase 3：DMARC p=quarantine（1〜2ヶ月）
正規の送信元がすべて認証に合格していることを確認したら、p=quarantineに変更します。
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
この設定では、認証に失敗したメールが受信者の迷惑メールフォルダに振り分けられます。正規のメールが迷惑メールに入ってしまっていないか、1〜2ヶ月間モニタリングします。
問題が発生した場合は、p=noneに戻してSPF/DKIMの設定を修正します。
Phase 4：DMARC p=reject（最終段階）
p=quarantineで問題がないことを確認したら、最終段階としてp=rejectに変更します。
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
p=rejectでは、認証に失敗したメールは受信サーバーが完全に拒否します。これにより、自社ドメインを悪用したなりすましメールを完全にブロックできます。
よくある落とし穴
SPFのDNSルックアップ上限（10回）に引っかかる
includeを追加しすぎると10回の上限を超え、SPFが無効になります。SPFフラットニングツールを使って、includeをIPアドレスに展開する方法があります。
転送メールがSPFに失敗する
メールが転送されると、送信元IPが変わるためSPFに失敗します。DKIMは転送されても有効なため、DKIM対応が重要です。
社内の誰かが独自にメール配信サービスを契約している
マーケティング部門や営業部門が独自にメール配信サービスを使っている場合、SPFに含まれていないとDMARCに失敗します。社内の全メール送信元を棚卸しすることが重要です。
まとめ
DMARC p=rejectは「メールセキュリティのゴール」です。Phase 1からPhase 4まで段階的に進めれば、3〜6ヶ月で安全に到達できます。
いきなりp=rejectにせず、p=none → レポート分析 → p=quarantine → p=rejectの順で進めましょう。焦りは禁物です。
筆者について
株式会社BTNコンサルティング 代表取締役 亀田 英佑
中小企業に特化した情シスアウトソーシングサービス「情シス365」を運営。M365/GWS環境の設計・構築50件以上、IT PMI（M&A後IT統合）5件の実績。
情シス365（情シスアウトソーシング）
https://www.josis365.com
AI365（AI実装・自動化支援）
https://www.aidev-365.com
BTNコンサルティング（会社HP）
https://www.btncon.com