DMARCポリシーガイド:noneからrejectまでの4ステップ

DMARC(Domain-based Message Authentication, Reporting, and Conformance)は、SPFとDKIMを結びつけるポリシー層であり、認証に失敗したメッセージを受信サーバーがどのように扱うべきかを伝えます。DMARCがない場合、メールボックスプロバイダは独自の内部ルールに基づいて、認証されていないメールを通過させたり、隔離したり、拒否したりする可能性があります。DMARCを使えば、ドメインに対する処理ポリシーを明示的に定義できます。

このガイドでは、最初の監視専用レコードの公開から、rejectポリシーによる完全な強制までの、DMARC実装プロセス全体を順を追って解説します。

DMARCが重要な理由#

メールスプーフィングは、依然として最も一般的な攻撃手法の1つです。攻撃者はメールの「From」ヘッダーを偽装し、あなたのドメインから送信されたかのように見せかけることができます。DMARCがなければ、受信サーバーはそのようなメッセージに対するあなたの意図を確実に知る手段を持ちません。

DMARCは3つの問題を解決します。

• フィッシング防止: あなたのドメインから送信されたように見えるメールを攻撃者が送信するのを防ぎます。
• ブランド保護: あなたのドメインがレピュテーションを損なう詐欺キャンペーンに利用されるのを防ぎます。
• 可視性: DMARCレポートにより、あなたのドメインを使ってメールを送信しているのが誰なのかが正確に把握できます。忘れていた正規サービスや、知らなかった不正な送信者まで明らかになります。

Google、Microsoft、Yahooなどの主要メールボックスプロバイダは現在、大量送信者にDMARCを必須としています。2024年現在、Googleでは1日に5,000通以上のメールをGmailアドレス宛に送信するドメインに対し、DMARCポリシーの公開を求めています。

DMARCがSPFおよびDKIMと連携する仕組み#

DMARC自体は認証チェックを行いません。代わりに、SPFとDKIMの結果を評価し、アライメントと呼ばれる追加要件を適用します。

アライメント要件

DMARCをパスするには、以下のいずれかを満たす必要があります。

1. SPFがパスし、かつSPFで認証されたドメインが「From」ヘッダーのドメインとアライメントしている。 SPFはエンベロープ送信者(Return-Path)をチェックします。DMARCでは、このドメインが可視「From」ヘッダーのドメインと一致する(またはサブドメインである)ことが要求されます。

2. DKIMがパスし、かつDKIMで署名されたドメイン(d=タグ)が「From」ヘッダーのドメインとアライメントしている。 DKIM署名のドメインが「From」ヘッダーのドメインと一致する(またはサブドメインである)必要があります。

アライメントにはstrict(完全一致)とrelaxed(サブドメインを許可)があります。デフォルトはrelaxedで、ほとんどの構成に適しています。

アライメントが重要な理由

アライメントがない場合、攻撃者はattacker.comのSPFとDKIMを設定し、From: ceo@yourcompany.comとしてメッセージを送信できてしまいます。すると(attacker.comに対して)SPFとDKIMのチェックはパスしますが、受信者にはあなたのドメインから来たように見えます。DMARCのアライメントは、認証されたドメインがユーザーが目にするドメインと一致することを要求することで、このギャップを埋めます。

DMARCレコードの構文#

DMARCレコードは_dmarc.yourdomain.comに公開するDNS TXTレコードです。完全な例を以下に示します。

v=DMARC1; p=reject; rua=mailto:dmarc-agg@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; aspf=r; adkim=r; fo=1;

タグリファレンス

タグ	必須	説明	値
v	はい	プロトコルバージョン	常にDMARC1
p	はい	ドメインのポリシー	none、quarantine、reject
rua	いいえ*	集計レポートの送信先	mailto: URI
ruf	いいえ	フォレンジックレポートの送信先	mailto: URI
pct	いいえ	ポリシーを適用するメッセージの割合	1-100(デフォルト:100)
aspf	いいえ	SPFアライメントモード	r(relaxed、デフォルト)またはs(strict)
adkim	いいえ	DKIMアライメントモード	r(relaxed、デフォルト)またはs(strict)
sp	いいえ	サブドメインポリシー	none、quarantine、reject
fo	いいえ	失敗時のレポーティングオプション	0、1、d、s

*ruaは技術的には任意ですが、必ず含めるべきです。集計レポートがなければ、何が起きているか把握する手段がないままポリシーを公開することになります。

ポリシー値の説明

• none: 監視のみ。DMARCに失敗したメッセージは通常通り配信されます。認証結果のレポートは届きますが、何もアクションは取られません。これが出発点です。
• quarantine: DMARCに失敗したメッセージは疑わしいものとして扱われます。通常は受信者の迷惑メールフォルダに振り分けられます。
• reject: DMARCに失敗したメッセージは完全に拒否されます。受信サーバーがエラーを返し、メッセージは配信されません。

失敗時のレポーティングオプション(foタグ)#

• 0(デフォルト): SPFとDKIMの両方がアライメントに失敗した場合のみレポートを生成。
• 1: SPFまたはDKIMのいずれかがアライメントに失敗した場合にレポートを生成。デバッグに有用で、推奨設定です。
• d: アライメントに関係なく、DKIMが失敗した場合にレポートを生成。
• s: アライメントに関係なく、SPFが失敗した場合にレポートを生成。

完全強制までの4ステップ進行#

準備なしにいきなりp=rejectへ移行するのは危険です。使っていることを忘れていたサービスからの正規メールをブロックしてしまうかもしれません。安全なアプローチは段階的な進行です。

ステップ1: p=noneでのデプロイ(監視)#

メール配信に影響を与えずにデータを収集するために、まずは監視のみのポリシーから始めます。

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

このフェーズで行うこと:

• レコードを公開し、十分なレポートデータを集めるために最低でも2〜4週間待ちます。
• 集計レポートを確認して、あなたのドメインから送信される正規メールの送信元をすべて特定します。プライマリのメールサーバー、マーケティングプラットフォーム(Mailchimp、SendGrid、HubSpot)、トランザクションメールサービス、CRMシステム、チケッティングシステム、あなたの代わりにメールを送信するすべてのSaaSツールが含まれます。
• 各正規送信元について、SPFが構成されている(サービスの送信IPがSPFレコードに含まれている)こと、DKIMが設定されている(サービスのDKIM公開鍵がDNSに公開されている)ことを確認します。
• 認識のない送信元は調査します。忘れていた正規サービスである場合もあれば、不正な送信者である場合もあります。

期間: 最低2〜4週間。複雑な送信インフラがある場合はさらに長く。

ステップ2: p=quarantineを25%に(ソフト強制)#

すべての正規送信元がDMARCをパスすることに自信が持てたら、トラフィックの一部から強制を開始します。

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

これにより受信サーバーは、DMARCに失敗したメッセージのうち25%を隔離(通常は迷惑メールへ送信)します。残りの75%はポリシーがnoneであるかのように扱われます。

このフェーズで行うこと:

• 正規送信元からのDMARC失敗が増加していないか、レポートを注意深く監視します。
• SPFまたはDKIMが欠けている新しい正規送信者が見つかった場合は、次に進む前に構成を修正します。
• 正規メールが迷惑メールフォルダに入っているとの報告がないか注視します。
• 1〜2週間経過しても問題がなければ、次のステップに進みます。

期間: 1〜2週間。

ステップ3: p=quarantineを100%に(完全隔離)#

割合制限を外して、隔離ポリシーを失敗したすべてのメッセージに適用します。

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

または、100がデフォルトなのでpctタグを省略するだけでも同じです。

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

このフェーズで行うこと:

• レポートの監視を続けます。
• 正規メールが隔離されていないことを確認します。
• メールの行方不明について報告する人がいないか、チームに確認します。
• 2〜4週間問題がなければ、最終ステップに進む準備が整います。

期間: 2〜4週間。

ステップ4: p=rejectで強制(完全保護)#

これが最終状態です。DMARCに失敗したメッセージは完全に拒否されます。

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1;

この時点で、適切な認証なしにあなたのドメインからメールを送信しようとする者のメッセージは拒否されます。あなたのドメインはスプーフィングから完全に保護されます。

継続的なメンテナンス:

• 集計レポートを少なくとも月次で確認し続けます。
• 新しいメール送信サービスを追加する際は、送信前にSPFとDKIMを構成します。
• DKIM鍵を定期的にローテーションし、新しい鍵がDMARCをパスすることを検証します。
• メールボックスが容量を許すなら、フォレンジックレポート用にrufの追加を検討します。

DMARCレポートの読み方#

集計レポート(rua)#

集計レポートは、受信サーバーから日次で送信されるXMLファイルです。以下が含まれます。

• 報告サーバーの組織名。
• カバーされる日付範囲。
• あなたが公開しているDMARCポリシー。
• あなたのドメインを使ってメールを送信した各ソースIPごとに、メッセージ数、SPF/DKIM/DMARCの結果、アライメントの結果。

集計レポートからの簡略化された抜粋は次のようになります。

<record>
  <row>
    <source_ip>198.51.100.10</source_ip>
    <count>1542</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

生のXMLは大量に読むのが困難です。多くの組織はDMARCレポート分析サービスやツールを使って、データを解析・可視化します。Postmarkの無料DMARC監視、dmarcian、EasyDMARCなどが役立ちます。

フォレンジックレポート(ruf)#

フォレンジックレポートには、DMARCに失敗した個々のメッセージに関する詳細(メッセージヘッダー、場合によっては部分的な内容を含む)が含まれます。特定のスプーフィング事案を調査するのに有用ですが、大量に発生することがあり、機密情報を含む可能性があります。プライバシー上の懸念から、多くの受信者はフォレンジックレポートをもう送信しなくなっています。

DMARCでよくある落とし穴#

1. 監視せずにp=rejectを公開する#

これは最も危険なミスです。SPFとDKIMが適切に構成されていない正規のメールサービスがあれば、それらのメッセージは拒否されてしまいます。必ずp=noneから始めてレポートを確認しましょう。

2. サードパーティ送信者を忘れる#

正規送信元からのDMARC失敗で最も多い原因は、あなたのドメインを使ってメールを送信しているSaaSツールを忘れることです。よくある原因は次のとおりです。

• マーケティングオートメーションプラットフォーム
• カスタマーサポートのチケッティングシステム
• あなたの代わりにメールを送信するCRMプラットフォーム
• 請求書・会計ソフトウェア
• 人事・採用ツール
• カレンダー・スケジューリングツール

p=noneを超える前に、ドメインに接続されたすべてのサービスを監査しましょう。

3. SPFレコードがDNSルックアップ10回を超える#

SPFにはinclude、a、mx、redirect、existsのDNSルックアップ機構が10回までというハード制限があります。SPFレコードがこの制限を超えると、SPF評価は「permerror」を返し、すべてのメッセージでSPFが実質的に失敗します。DMARCはSPFまたはDKIMのいずれかがアライメント付きでパスすることを要求するため、SPFのpermerrorはDKIMにより大きな負担をかけます。

送信サービスが多い場合は、SPFレコードのフラット化や、サービスごとに異なるサブドメインから送信するサブドメイン戦略を検討してください。

4. ruaを使わない#

集計レポートがなければ、ドメインのメールがどのように認証されているかの可視性がまったくありません。p=noneであっても、必ずruaタグを含めましょう。

5. sp=タグなしのサブドメイン#

spタグを設定しない場合、サブドメインはデフォルトで親ドメインのポリシーを継承します。サブドメインを目的別に使い分けている場合(例:marketing.yourdomain.com)は、明示的なサブドメインポリシーの設定や、サブドメインごとに別個のDMARCレコードを公開することを検討してください。

6. rejectに到達した後にDMARCを放置する#

DMARCは「設定して放置」できる構成ではありません。新しい送信サービスが追加されたり、鍵が期限切れになったり、SPFレコードが変更されたりします。回帰を捉えるために、毎月集計レポートの確認を続けましょう。

DMARC構成のチェック方法#

DNSをクエリすることで、現在のDMARCレコードを確認できます。

dig TXT _dmarc.yourdomain.com

DMARCをSPF、DKIM、MXレコード、ブラックリスト状況とあわせて包括的にチェックしたい場合は、Nova Uptimeの無料Email Health Checkerをご利用ください。100点満点のスコア、A〜Fの評価、DMARCポリシーを改善するための具体的な推奨事項を提供します。

このツールはスコアリングの一部としてDMARCポリシーの厳格さを評価します。集計レポート付きのp=rejectポリシーが最高得点を獲得し、p=noneやDMARCレコードが欠けている場合は大幅な減点となります。これにより、ドメインの現状と次に取るべきステップが明確になります。

DMARC実装のタイムライン#

DMARCを完全にデプロイするための現実的なタイムラインは次のとおりです。

週	アクション	DMARCレコード
1	監視レコードの公開、レポート処理のセットアップ	p=none; rua=mailto:...
2-4	レポートの確認、すべての正規送信者のSPF/DKIMを修正	p=none; rua=mailto:...
5-6	25%でのソフト強制	p=quarantine; pct=25; rua=mailto:...
7-8	完全隔離	p=quarantine; rua=mailto:...
9-12	完全強制	p=reject; rua=mailto:...
継続中	月次レポート確認、構成の維持	p=reject; rua=mailto:...

シンプルなメールインフラ(プライマリのメールサービス1つ、マーケティングツール1〜2個)の組織であれば、4〜6週間に圧縮できます。送信サービスが数十あるエンタープライズの場合は、3〜6か月を見込んでください。

重要なポイント

• DMARCは、ポリシー強制とアライメント要件を追加することで、SPFとDKIMの上に構築されます。
• 必ずp=noneと集計レポーティングから始めましょう。p=rejectに直接ジャンプしてはいけません。
• pctタグを使って強制を段階的に増やしましょう。
• 強制する前に、集計レポートを確認してすべての正規メール送信元を特定しましょう。
• p=rejectへの到達がゴールですが、それには準備が必要です。
• デプロイ後も監視を続けましょう。DMARCには継続的なメンテナンスが必要です。
• DMARC構成の検証と完全なメール認証評価にはNova UptimeのEmail Health Checkerをご利用ください。

適切に実装されたDMARCポリシーは、ドメインに展開できる最も強力な保護策の1つです。スプーフィングを防ぎ、メールボックスプロバイダとの信頼を築き、誰があなたの代理でメールを送信しているのかについて明確な可視性を提供します。

よくある質問

DMARCチェックとは何ですか?#

DMARCチェックは、ドメインに有効なDMARC DNSレコードがあるかを確認し、そのポリシー設定を評価します。DMARCレコードの構文が正しいこと、ポリシー(none/quarantine/reject)が適切に構成されていること、レポート用アドレスが機能していることを確認します。現在の構成を確認するには、無料のDMARCチェックをご利用ください。

無料のDMARC監視は可能ですか?#

はい。Nova UptimeはEmail Health Checkerの一部としてDMARC監視を提供しています。SPF、DKIM、ブラックリスト状況とあわせてDMARCレコードを設定可能なスケジュールでチェックし、変化があれば通知します。無料プランでは最大5ドメインまでカバーされます。

p=rejectに到達するまでどのくらいかかりますか?#

ほとんどの組織では、p=noneからp=rejectまでの進行に2〜4か月かかります。タイムラインは、特定して認証する必要がある正規のメール送信元の数によって変わります。DMARCレポートを確認せずにrejectへ急ぐと、自分の正規メールをブロックしてしまうリスクがあります。

SPFやDKIMなしでDMARCをrejectに設定したらどうなりますか?#

メールは受信サーバーに拒否されます。DMARCの強制では、SPFまたはDKIMの少なくとも一方がパスし、かつFromドメインとアライメントすることが要求されます。まずSPFとDKIMを設定し、それからDMARCをnoneからrejectへと段階的に進めてください。

関連記事

• SPF、DKIMとDMARC:完全ガイド — 3つのプロトコルが連携する仕組み
• DMARCテストと構成ガイド — 高度なDMARCポリシー構成
• メールブラックリストのチェックと解除ガイド — 認証問題がブラックリスト登録につながった場合の対処
• メール配信チェックリスト — 受信トレイ到達を改善する15ステップ
• 無料Email Health Checker — DMARC、SPF、DKIM、ブラックリストを1回のスキャンで確認