DMARCレコードの公開は、1回で終わる作業です。モニタリングは、終わりのない部分であり、多くのドメインが静かに崩れていくのもここです。新しいマーケティングツールがあなたの名義で送信を始める、ベンダーが署名の設定を変える、DNSの編集でrua=アドレスが消える。そして、数か月間誰も気づきません。このガイドでは、レコードを公開した後の継続的な運用ルーティンを取り上げます。何を見るか、どのくらいの頻度で見るか、誰が担当するか、どのしきい値ならアラートに値するか、そして集計データでは何がわからないかを説明します。
結論#
DMARCモニタリングとは、メールボックスプロバイダーがrua=アドレスに毎日送ってくる集計レポートを集め、送信元ごとのビューにまとめ、そのビューを定期的に確認することです。見るべきものは4つあります。承認していない新しい送信元、次に成功率が下がった既知の送信元、さらにレポート件数の減少（rua=アドレスの不具合であることが多い）、そしてレコード自体のポリシーのずれです。週に1回10分のレビューと、急な失敗へのアラートがあれば、ほとんどのドメインはカバーできます。レポートファイル1件を読むだけなら、無料のDMARCレポート解析で十分です。XMLを開かずに見守り続けるには、代わりにレポートを受信してくれる仕組みが必要です。データは常に1〜2日遅れで、レポートを送ってくるプロバイダーの分しか含まれません。リアルタイムのフィードではなく、火災報知器のようなものと考えてください。
レポートを読むことと、モニタリングすることの違い#
DMARCレポートの読み方では、1つのXMLファイルに何が入っているかを説明しています。送信元IP、メール数、SPFとDKIMの結果です。このスキルは重要ですが、答えられるのは単発の問いです。つまり、この受信側が、この日に何を見たのか、ということです。
モニタリングは、時間の経過に沿った別の問いに答えます。
- 先月は成功していた送信元が、今週から失敗し始めていないか。
- これまであなたの名義で送信したことのない送信元が現れていないか。
- 報告されたメールの総数が半分に減っていないか。
- レコードは、自分たちが公開したままになっているか。
未開封の添付ファイルが溜まったフォルダーからは、これらに答えられません。送信量の多いドメインには、さまざまな受信側から1日に数十件のレポートが届き、それぞれが独自のIPリストを持っています。誰か、あるいは何かが、それらをドメインごとの1つの表にまとめ、今日と過去を比較する必要があります。レポート送信を有効にしたレコードをまだ公開していない場合は、DMARCの設定手順から始め、最初のレポートが届いてからお戻りください。通常は24〜48時間かかります。
優先度順に見るべきもの#
すべての数字に注意を払う必要はありません。次のシグナルは、実際のドメインで結果を変えたものです。おおよそ、緊急度の高い順に並べています。
| シグナル | 通常の意味 | 最初の対応 |
|---|---|---|
| 新しい送信元からのメールが失敗している | 忘れられたツール、転送、またはドメインのなりすまし | 送信元IPを特定する。不明な送信元のガイドを参照 |
| 既知の送信元の成功率が通常を下回る | ベンダーが署名ドメインを変更した、DKIMキーが削除された、またはSPFにそのベンダーが含まれなくなった | ベンダーの現在の認証設定とDNSを確認する |
| 報告された総数が急減する | rua=アドレスが壊れた、または送信元が送信を止めた | 公開中のレコードを確認する。レポートが届かない場合を参照 |
| 送信元は変わらないのに、失敗の割合が上がる | 転送やメーリングリスト、または受信側の評価方法の変化 | 受信側ごとに比較する。アライメントの失敗を参照 |
| レコードが変更された | 誰かがDNSを編集した：ポリシーが緩められた、rua=が削除された、2つ目のレコードが追加された | 最後に正常だったレコードと差分を取る |
2行目については、読み違えやすいので補足します。DMARCが成功するのは、SPFまたはDKIMのどちらかが成功し、かつ表示されるFromドメインとアライメントが一致している場合です。ある送信元がSPFのアライメントで毎日失敗していても、DKIMが支えているおかげで、DMARCの成功率は100パーセントと表示されることがあります。DKIMキーがローテーションされたり削除されたりするまでは問題ありませんが、その時点で、その送信元の成功率は一気に落ち込みます。送信元を確認するときは、合算した結果だけでなく、両方の列を見てください。
10分で終わる週次ルーティン#
日次のレビューは、ほとんどのチームにとってやりすぎで、月次では遅すぎます。週に1回が、ちょうどよい中間点です。調整して使えるルーティンを紹介します。
- 自分が所有するすべてのドメインについて、直近7日分を開く。 パーク中のドメインや、メールを送らないドメインも含めます。
- 送信元を件数順に並べ替える。 上位5件が想定どおりか確認します。
- 先週のリストになかった新しいIPや名前を探す。 それぞれ、初めて見た日付とあわせて書き留めます。
- DMARC成功率が100パーセント未満の送信元を確認する。 それぞれについて、修正するか、転送によるノイズとして受け入れるかを決めます。
- 総数を前の週と比較する。 急な減少があれば、何よりもまずレコードを確認します。
- ポリシー（
p=とsp=）を確認し、 最後に設定したとおりになっていることを確かめます。
正規の送信元ごとに1行ずつ、シンプルな一覧表を作っておいてください。サービス名、社内の担当者、送信するメールの種類、認証方法（お使いのドメインでのDKIM、SPFのinclude、またはその両方）です。レポートが教えてくれるのは、何が送信しているかです。それが送信してよいかどうかは、この表だけが教えてくれます。
Source Owner Mail type Authenticates via
Google Workspace IT Staff mail DKIM d=example.com
Newsletter tool Marketing Campaigns DKIM d=example.com, include in SPF
Billing system Finance Invoices DKIM d=example.com
誰が担当するか#
DMARCモニタリングが最も多く失敗する原因は、誰のものでもないことです。DNSはITが、送信ツールはマーケティング、プロダクト、サポート、経理がそれぞれ握っていて、レポートは、ある人が作って後に退職した共有メールボックスに届きます。
ドメインごとに担当者を1人決め、2つの権限を与えてください。すべてのレポートを見られること、そして、ほかのチームに送信元について問い合わせる権限です。新しい送信元は、ローンチの前にその担当者に届く依頼であるべきで、3週間後にレポートで発覚する驚きであってはいけません。会社で多くのドメインを運用しているなら、担当者は会社単位ではなくドメイン単位で決めてください。shop.example.comの名義で送信しているツールを知っている人は、example.comについて知っている人とは別であることが多いからです。
設定する価値のあるアラートのしきい値#
アラートは、人がきちんと読み続けられる程度にまれであるべきです。これらのしきい値は標準ではなく目安なので、ご自身の送信量に合わせて調整してください。
- 失敗したメールを送っている新しい送信元がある場合。 小さな下限（たとえば1日に失敗が5通）を超えたときだけ通知し、1通の転送で誰かが呼び出されることがないようにします。
- その日の失敗の合計が、一定の水準を超えた場合。 送信量が少ないドメインでは、たとえば10通です。大規模なドメインでは、代わりに送信量に対する割合を使ってください。
- 既知の送信元が、通常の成功率を2日連続で下回った場合。 1日限りのノイズを除けます。
- レポートの件数が、前週比で半分に減った場合。
アラートにしないほうがよいものもあります。1つの受信側から報告された少数の失敗、1〜2ポイント程度の成功率の揺れ、そして送信元を洗い出している間のp=noneによるノイズです。
QualisendのDMARCレポートは、この基本的な形をカバーしています。毎日、前日（UTC）を調べ、SPFとDKIMの両方に失敗したメールがドメインで10通以上あった場合、またはそのドメインで過去30日間に確認されていない送信元が、失敗したメールを5通以上送信した場合に、メールでお知らせします。これらの数字に届かない成功率の低下、ポリシーの変更、どのプロバイダーからも報告されなかったなりすましについてはアラートを出しませんので、週次のレビューも続けてください。
集計データの限界#
集計レポートは有用ですが、完全ではありません。判断の材料にする前に、限界を知っておいてください。
- 遅延があります。 プロバイダーは通常、1日に1回送信するため、見えるのは昨日か一昨日のものです。リアルタイムのビューではありません。
- レポートを送る受信側からしか届きません。 大手のメールボックスプロバイダーは送信しますが、多くの小規模な受信側は送信しません。数字が表すのは、レポートされた分だけであり、すべてのメールではありません。
- メッセージの内容は含まれません。 得られるのは送信元ごとの件数と認証結果だけで、件名や受信者は含まれません。これは意図的で、プライバシーに配慮した設計ですが、どのメールが失敗したのかを正確には見られないということでもあります。
- 誰も報告していないなりすましは見えません。 受信側がレポートを送らない場合、その受信側に向けたなりすましのメールは、あなたからは見えません。
- フォレンジック（失敗）レポートはほとんど利用できません。
ruf=タグはメール単位の失敗レポートを求めるものですが、大手プロバイダーの多くは送信しないため、集計データだけで計画を立ててください。DMARCレポートは、失敗レポートをまったく受信しません。 - 送信元ごとの数量は、受信者ではなくメールの件数です。 3通のうち3通が失敗した送信元と、30,000通のうち3通が失敗した送信元は、別の問題です。
こうした限界があっても、データの価値が下がるわけではありません。ダッシュボードがきれいだということは、「報告された範囲では問題なし」という意味であり、「問題なし」という意味ではありません。
安全対策全体の中でのモニタリングの位置づけ#
DMARCモニタリングは、1つの層です。レコードが完璧でも、別のDNSの問題によって台無しになることがあります。ルックアップの上限を超えたSPFレコードや、削除されたDKIMキーなどです。より広い運用ルーティンは、ドメイン診断の監視ガイドで説明しています。そこでは、DMARCが依存するレコードを扱っています。レポートがきれいで安定したら、次のステップはポリシーの強化で、p=noneからp=rejectへの移行で説明しています。収集を任せるツールを検討しているなら、DMARC監視ツールの選び方で、判断基準を整理し、実際の価格を比較しています。
これらが実務で重要になる背景のルールについては、GoogleとYahooの送信者要件を、認証済みのメールでも迷惑メールに入ってしまう理由の全体像については、メール到達性ガイドをご覧ください。
よくある質問
01DMARCモニタリングとは何ですか？
DMARCモニタリングとは、メールボックスプロバイダーがruaアドレスに送ってくる集計レポートを集め、送信元ごとのビューにまとめ、時間の経過に沿った変化を確認し続ける運用のことです。新しい送信元、成功率が下がった既知の送信元、レポート件数の減少、レコードの編集を見守ります。1つのXMLファイルを読むだけでは、1つの受信側の1日分しかわからないため、それとは異なります。
02DMARCレポートは、どのくらいの頻度で確認すべきですか？
ほとんどのドメインでは、10分ほどの週次レビューに、急な失敗へのアラートを組み合わせれば十分です。レポートは1日に1回届き、遅延もあるため、日次のレビューは、データが見合う以上の手間になることがほとんどです。送信元を洗い出している間や、ポリシーを厳格化する直前は頻度を上げ、その後は週次のリズムに落ち着かせてください。
03DMARCレポートで、なりすましをリアルタイムに確認できますか？
できません。プロバイダーは通常、集計レポートを1日に1回送るため、見えるのは昨日か一昨日のものです。レポートを送る受信側だけが含まれるため、レポートを送らない受信側に向けたなりすましのメールは見えません。レポートは、報告された範囲に対する火災報知器と考え、なりすましのメールを失敗させるにはrejectポリシーに頼ってください。
04DMARCでは、どのようなアラートのしきい値が適切ですか？
これらは標準ではなく目安です。失敗したメールを送る新しい送信元は、1日に失敗が5通などの小さな下限を超えたとき、送信量が少ないドメインでは1日の失敗の合計が10通などのとき、既知の送信元が通常の成功率を2日間下回ったとき、そしてレポートの件数が前週比で半分に減ったときに、アラートを出します。1つの受信側での小さな揺れは、アラートにしないでください。
モニタリングでわかるのは、誰があなたのドメインを名乗って送信しているかであり、そのメールの背後にあるリストが健全かどうかではありません。無料プラン（料金）から始めて、100クレジットを実際のリストに使い、バウンスのリスクを確認してください。しっかり監視されたドメインでも、受信箱にたどり着くには、きれいなリストが必要です。
