AIでDMARCレポート分析：ClaudeでSPF・DKIM修復

結論から先に：ヘルプデスクのプラットフォーム、請求書ツール、メルマガ配信サービスが、認証とアライメントを済ませないまま自社ドメインでメールを送ると、受信側のサーバーはそのメールを迷惑メールに振り分けたり拒否したりすることがあり、社内では誰もエラーを目にしません。DMARC 集計レポートは、誰が自社ドメインで送信していて、何が認証に通ったかの記録そのものです。AI で DMARC レポートを分析するなら、その XML を現在の SPF と DMARC のレコードと一緒に Claude に貼り付ければ、送信元を「自社で認証に通っている」「自社だが失敗している」「見覚えがない」の三つに分類し、DNS の変更リストを下書きしてくれます。Claude が見られるのは貼り付けた内容だけで、誤ることもあるため、提案されたレコードは公開する前に必ず DNS の照会で確認してください。

従業員 80 名の香港の専門サービス会社で、IT も兼務する総務担当者を思い浮かべてください。会社は Microsoft 365 と Exchange Online を使っており、ドメイン（ここでは example.com とします）は長年安定していました。ここ四半期で三つが加わりました。support@example.com として返信する Zendesk のヘルプデスク、経理チームの名前で送られる Xero の請求書、マーケティング担当者が運用する Mailchimp のメルマガです。

そこへ苦情が届きます。ある顧客は、サポートチケットへの返信を受け取っていないと言います。別の顧客は、請求書のリマインドが「また迷惑メールフォルダに入っている」と言います。ヘルプデスクではすべて送信済み、Xero では請求書は配信済み、Mailchimp でも通常どおりの送信と表示されます。バウンスはなく、社内から見れば壊れているようには見えません。

Microsoft 365 への移行後、以前のコンサルタントが example.com に隔離ポリシーの DMARC レコードを公開し、rua アドレスを設定しました。それ以来、毎日の XML レポートが共有メールボックスにたまり続けています。テキストエディターでは読めないため、誰も開いたことがありません。

正当なメールが認証に失敗する理由（そして新しい送信ツールを追加した後に起きる理由）

受信側のメールサーバーは、メールに表示される From: アドレスを信用しません。誰でも好きな文字列を書けるからです。代わりに、送信サーバーがそのドメインの代理として送信を許可されているか、そしてメッセージに改ざんされていないことを示す署名が付いているかを確認します。自社ドメインで送信する新しいツールがこの確認に通るのは、誰かがそのように設定した場合だけで、ベンダーの標準設定は、自社ではなくベンダー自身のドメインとしてメールを認証することがよくあります。

この標準設定が典型的な失敗の原因です。メールは本物で送信者も自社ですが、受信側から見ると、見知らぬ人が example.com を名乗って送ったのと区別がつきません。DMARC ポリシーが、失敗したメールを隔離または拒否するよう受信側に求めていれば、受信側はそのとおりにします。送信側の画面には「送信済み」と表示され、受信者には届きません。

SPF、DKIM、DMARC アライメントを平易に言うと

SPF は、どのサーバーが送信してよいかを示します。ドメインの代理として送信を許可されたサーバーを列挙する DNS レコードで、人が目にする From: アドレスではなく、エンベロープ送信者（return-path やバウンスアドレスとも呼ばれます）に対して照合されます。送信サーバーが許可されていたことは証明しますが、内容が改ざんされていないことは証明せず、転送されると壊れることもよくあります。

DKIM は、メッセージに署名があることを示します。送信システムが d= タグで示されたドメインに結び付いた暗号署名を付け、受信側がそのドメインの DNS にある公開鍵で検証します。通信途中で改ざんされていないことは証明しますが、署名ドメインは送信側が管理していればどのドメインでもよく、ベンダー自身のドメインでも構いません。

DMARC は、From: ドメインが一致することを求めます。SPF または DKIM のどちらかが通り、通ったドメインが From: ドメインとアライメントしていれば、DMARC に合格します。d=vendor.com で署名するヘルプデスクは DKIM には通りますが、そのドメインは自社のものではないためアライメントせず、DMARC には通りません。DMARC は、ポリシーとレポートの送付先も公開します。

香港の環境での三つのレコードの一般的な入門については、香港企業のための SPF、DKIM、DMARC ガイドをご覧ください。

DMARC 集計レポートを分かりやすい言葉の診断に変える

集計レポートは、自社ドメインを名乗るメールについて、受信側が毎日まとめた集計です。機械可読の XML で、当初は RFC 7489、2026 年の DMARC 改訂以降は RFC 9990 で定められています。そのため、誰にも読まれないままになりがちです。

XML に実際に含まれているもの

各レポートには、送信元の組織名（大手のメールボックスプロバイダーなど）、対象の期間、そして受信側が見た DMARC ポリシーが書かれています。その後に、送信元 IP アドレスごとに一行ずつ並びます。メッセージ数、受信側の処理、DKIM と SPF の合否、そしてそれらの確認で認証されたドメインです。

メッセージ本文も件名もありません。含まれるのは送信元の IP アドレスと自社ドメインで、これは通信内容ではなく運用データですが、自社のプライバシーポリシーが IP アドレスをどう扱うかは確認してください。フォレンジックレポート（別種の ruf）には個々のメッセージの一部が含まれることがあり、これは別の問題です。

送信元を「自社で通っている」「自社だが失敗」「見覚えがない」に分けるプロンプト

この手順では、Claude は実際の DNS を照会せず、メールボックスも読まないため、すべてをこちらから渡します。レポートの XML か表のエクスポート、現在の SPF と DMARC の TXT 値を貼り付けたうえで、こう尋ねます。「これは example.com の DMARC 集計レポートと、現在の SPF および DMARC レコードです。すべての送信元 IP を三つのリストに分けてください。自社で DMARC に通っているもの、自社だが DMARC に通っていないもの、見覚えのないもの。失敗している送信元ごとに、SPF と DKIM のどちらが失敗したか、通ったドメインが example.com とアライメントしていたか、最も可能性の高い対処を示してください。このデータから判断できないものは、推測せず不明と記してください。」

実践例——DKIM 鍵のないまま自社ドメインで送信するヘルプデスクプラットフォーム

1. 一週間分のレポートと二つのレコードを集める。rua のメールボックスからレポートを取り出し、nslookup -type=txt や Resolve-DnsName などで example.com と _dmarc.example.com の現在の TXT レコードを調べ、その値を貼り付けます。レジストラや DNS のログイン情報は決して貼らないでください。

2. グループ分けのプロンプトを実行する。模擬的な結果は次のとおりです（実在のアドレスの代わりにドキュメント用の範囲のアドレスを使用）。192.0.2.10 は 1,140 通を送信し、SPF と DKIM が両方ともアライメントして通っています。これは Exchange Online で、健全です。198.51.100.61 は 205 通を送信し、DKIM がアライメントして通っています。これは Mailchimp のメルマガで、マーケティング担当が最初に送ったときに正しく設定されていました。

3. 失敗している行を読む。198.51.100.24 は 312 通を送信し、DMARC に失敗しました。SPF は通りましたが、通ったのはベンダーのバウンスドメインです。DKIM も通りましたが、署名は d=helpdesk-vendor.example.net でした。どちらも example.com ではないドメインで通っているため、どちらもアライメントせず、隔離ポリシーが適用されました。これがヘルプデスクであり、返信が届かない理由です。

4. 見覚えのない送信元を確認する。203.0.113.77 は 38 通を送信し、両方の確認に失敗しました。Claude はこれを見覚えのないものとして分類します。通すために SPF に追加してはいけません。誰がこのドメインで送る可能性があるかを尋ねてください。忘れられた CRM、複合機のスキャン to メール、あるいは誰かによるドメインの偽装かもしれません。分かってから決めます。

5. レポートが説明していないことを押さえる。Xero の請求書リマインドは失敗した送信元として現れていないため、「迷惑メール」という苦情には、メールの内容、受信者側のフィルター、あるいはレポートを送らない受信側など、別の原因があるかもしれません。

6. ヘルプデスクを直す。ベンダーの、カスタム送信ドメインを認証するためのドキュメントを開きます。そこには DKIM レコード（通常は CNAME）が示され、SPF もアライメントできるように、カスタムの return-path やバウンスドメインが用意されていることも多くあります。これらを公開し、一つずつ照会で確認してから、ベンダーの設定画面で検証を有効にします。Exchange Online は別です。カスタムドメインの DKIM は Microsoft Defender ポータルで、selector1 と selector2 の二つの CNAME レコードを公開して有効にします。正確な手順は Microsoft の最新のドキュメントでご確認ください。

7. 次のレポートで同じプロンプトをもう一度実行する。レポートは通常毎日届くため、変更は一、二日で現れることが多いですが、受信側ごとに違い、保証はありません。ヘルプデスクの送信元は「自社で通っている」に移るはずです。そうならなければ、新しい行を貼り付けて、まだ何がアライメントしていないかを尋ねてください。

他のものを壊さずに直す

SPF の DNS 照会 10 回の上限と、ベンダーを一つ足すだけでレコードが静かに壊れる仕組み

RFC 7208 は、SPF の確認で行える DNS 照会を最大 10 回までと定めています。照会を発生させる仕組み、つまり include、a、mx、ptr、exists、redirect は、引用したベンダー自身のレコード内の照会も含めてカウントされます。ip4、ip6、all はカウントされません。10 回を超えると、受信側は恒久的なエラーを返し、多くの受信側はこれを SPF の失敗として扱います。

Microsoft 365 の include は照会 1 回分ですが、ベンダーの include はそれぞれ少なくとも 1 回分を加え、中にはさらに include を入れ子にしているベンダーもあるため、ヘルプデスクとメルマガ配信サービスだけで数回分増えることがあります。昨日まで動いていたレコードが、見た目には何も変わらないまま今日失敗することがあります。Claude に照会回数を見積もらせてもよいのですが、include は入れ子になっていて言語モデルが数え間違えることがあるため、専用の SPF チェッカーで確かめてください。

DMARC を p=none から隔離、拒否へ段階的に引き上げる

ポリシーは三段階です。p=none は監視のみで、何も実行しません。p=quarantine は、失敗したメールを疑わしいものとして、通常は迷惑メールフォルダに扱うよう受信側に求めます。以前のガイドでは pct タグで段階的に導入していましたが、2026 年の DMARC 改訂（RFC 9989）で pct は廃止され、代わりに t=y のテストフラグが加わったため、どちらかに頼る前に受信側とツールの対応状況を確認してください。p=reject は、失敗したメールを完全に拒否するよう求めます。引き上げることが目標です。なりすましメールを止められるのは強制適用だけだからですが、各段階はレポートがきれいになってから進めるべきです。

各段階で、自社の送信元がまだ失敗していないか、「見覚えのない」リストが短くなっているかを見てください。正当なシステムがアライメントに失敗している間は reject に進んではいけません。請求書が永久に消えるのはそのためです。この例では会社はすでに隔離の段階にあるため、最初の仕事は何かを厳しくすることではなく、失敗している送信元を直すことです。

Claude による診断 vs 専用の DMARC 監視サービス vs DNS を勘で触る

Claude による診断。一度きりの調査や少数のレポートに向いています。数分で XML を平易なグループ分けと変更リストにでき、新たな契約も要りません。レポートの収集はせず、実際の DNS は見えず、レポートを貼り直さない限りドメインの履歴を保持せず、SPF の照会数を数え間違えることもあります。正しい使い方は、最初の診断と、DNS を担当する人への説明です。
専用の DMARC 監視サービス。継続的な運用のために作られています。レポートを代わりに受け取り、多数の受信側を一つのダッシュボードにまとめ、送信元を時系列で追跡し、新しい送信元が現れると通知します。継続的な費用がかかり、各送信元が何かを判断する人は依然として必要です。正しい使い方は、強制適用を始めた後、送信元の一覧が変わり続けるときの常設ビューです。
DNS を勘で触る。速く、無料で、この分野の障害の大半がここから始まります。ブログにそう書いてあったからと include を足す、他社のレコードを写す、いきなり reject にする、といったことです。正しい使い方は、ありません。

正しく運用するために——レジストラや DNS の認証情報は決して貼らない、そして来年誰がレコードを持つか

認証情報は決して Claude に渡さない。必要なのはレポートの XML と二つの TXT 文字列だけで、それ以外は不要です。レジストラや DNS ホストのログイン情報、API トークン、管理者パスワードをチャットに入れてはいけません。DNS の編集は自分で行い、第二の担当者が一緒に確認してください。

公開する前に検証する。Claude は、ベンダーのレコード名、セレクターの形式、照会回数について、自信をもって誤ることがあります。提案されたレコードはすべてベンダーの最新のドキュメントと照らし合わせ、変更後は実際に反映された内容を照会で確認してください。数分で元に戻せるよう、古いレコードはメモに残しておきます。

来年誰がレコードを持つかを決める。認証に「完了」はありません。自社ドメインで送信する SaaS ツールが増えるたびに送信元が増え、レコードはずれていくからです。誰がレポートを確認するのか、どのチームが新しい送信ツールに登録する前に誰へ知らせるのか、総務担当者が退職した後は誰が DNS の権限を持つのかを決めておきましょう。DNS やメール設定を変更できる管理者アカウントには MFA も必要です。乗っ取られれば、攻撃者が自分のレコードを公開できてしまうからです。

Claude をメールの診断のどこに組み込むかを決め、その周りのプロンプトと確認手順を書くのは、AI+ Support の仕事です。DMARC の監視は当社のマネージドITサポートのすべてのプランに含まれています。当社のマネージドメールセキュリティサービスは、強制適用した DMARC ポリシーと組み合わせて働く、なりすまし送信者や偽装への防御を提供し、実際の DNS の変更やメールフローの修復は当社の IT サポートチームが担当します。同じ問題の逆方向、つまり不審なメールの受信については Claude によるフィッシングメールの判別を、同じテナント内での Claude のさらなる活用については Claude と Microsoft 365 のメール自動化をご覧ください。

よくある質問

Google や Microsoft は、大量送信者に DMARC を必須としていますか。

大規模な送信者についてはそうです。Google と Yahoo の大量送信者向け要件は 2024 年 2 月に始まりました。Google の基準は、個人の Gmail アカウントに一日 5,000 通以上を送る送信者で、SPF、DKIM、少なくとも p=none の DMARC ポリシー、アライメント、マーケティングメールのワンクリック配信停止が求められます。Google はその後、拒否を含むより厳しい適用に移りました。Microsoft は 2025 年 5 月から、その送信量を超える送信者に対し、Outlook.com、Hotmail、Live で同様のルールを適用しました。正確な基準値と日付は、両社の最新のページでご確認ください。多くの中小企業は一日 5,000 通未満の送信ですが、認証はそれでもメールの届き先に影響します。

いきなり p=reject にしてもよいですか。

公開することはできますが、裏付けがなければ危険です。ヘルプデスク、請求書ツール、忘れられたスキャナーなど、正当なシステムがまだアライメントしていない場合、reject にすると受信側はそのメールを破棄します。自社の送信元がすべて通っていることをレポートが示すまでは p=none か隔離で運用し、その状態がしばらく続いてから reject に進んでください。

DMARC レポートには個人データが含まれますか。

集計レポートに含まれるのは、送信元の IP アドレス、メッセージ数、合否の結果、自社ドメインで、メッセージ本文も件名もありません。大部分は運用データですが、法域によっては IP アドレスが個人データになり得るため、他のログと同様に扱ってください。

SPF の include を追加したのに、なぜまだ失敗するのですか。

多くの場合、そもそも SPF が問題ではないからです。DMARC は、SPF または DKIM が通ってアライメントしていれば合格します。include が役に立つのは、ベンダーの return-path ドメインも自社のものになっている場合だけで、そのためにはベンダーのカスタムバウンスドメインの設定が必要なことがよくあります。もう一つの原因は、10 回の照会上限を超えてレコード全体がエラーになることで、追加のたびに数え直してください。