DMARCレポートが届かない？原因を調べるチェックリスト

rua=アドレスを指定したDMARCレコードを公開して数日待ったのに、メールボックスが空のまま。レポートもエラーも届かず、レコードが壊れているのか、単に早すぎるのかも分かりません。原因は数えるほどしかなく、確認する順番さえ分かれば簡単に調べられます。このガイドでは、いちばん手間のかからない確認（待つこと）から、外部の宛先の承認といった技術的なものまで、チェックリストを順に説明し、それぞれの失敗がどう見えるかも紹介します。

結論#

DMARCレポートが届かない原因は、ほぼ次の7つのどれかです。まだ24〜48時間待っていない、レコードが誤ったDNS名にある、DMARCレコードが複数ある、rua=の値が不正（mailto:で始まる必要がある）、レポートの宛先が承認のない別ドメインにある、ドメインの送信量が少なすぎて受信側がレポートを作らない、あるいはメールボックスが圧縮された添付ファイルをフィルターで除外している。この順番で確認してください。_dmarc.yourdomain.comをその場で引けば最初の4つは1分以内に判明します。dig TXT _dmarc.yourdomain.com +shortなら2件目のレコードも見つかります。無料のSPF・DKIM・DMARCチェッカーは最初に見つかった1件しか表示せず、rua=の構文も確認しないためです。レコードに問題がなく、数日たっているなら、宛先のメールボックスを調べましょう。

ステップ1：時間を置く。そしてレポートを送る側を知る#

プロバイダーは1日分の観測結果をまとめ、ドメインごとに1通のレポートを送ります。そのため、最初のレポートが届くのはレコードの公開から24〜48時間後で、それより遅れることもあります。初日には何も届きません。

もう2点、期待値を合わせておきましょう。

• すべての受信側がレポートを送るわけではありません。 大手のメールボックスプロバイダーは送ります。小規模なところの多くは決して送りません。集まるのはプロバイダーのサンプルであって、完全なログではありません。
• 受信側は、あなたからのメールを受け取った場合にのみレポートを送ります。 昨日あるプロバイダーにメールを1通も送っていなければ、そのプロバイダーには報告するものがありません。

丸3日待ったなら、次はレコードを確認しましょう。

ステップ2：レコードが正しい場所にあることを確認する#

DMARCレコードがあるべき名前は1つだけで、ドメインの前に_dmarc.を付けたものです。ドメイン直下やdmarc.example.comに公開したレコードは無視されます。実際に何が公開されているかを調べます。

dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:reports@example.com"

結果で確認するポイントは次のとおりです。

• そもそもレコードが存在すること。DNSホストによっては、ホスト欄に完全な名前ではなく_dmarcだけを入力する必要があります。完全な名前を入力すると、ドメインが二重に付加されてしまいます。ホスト別の手順は、CloudflareやGoDaddyなどのガイドにあります。
• v=DMARC1で、前に何も付かずにそのまま始まっていること。
• p=タグが含まれていること。RFC 9989では、有効なp=がなくても有効なrua=があればp=noneとして扱われ、レポートは届くため、これがレポートが届かない原因になることは通常ありませんが、それでもタグは明示的に公開してください。
• タグがセミコロンで区切られていること。

DNSのキャッシュにも注意してください。レコードを編集した直後は、TTLが切れるまで受信側が古いコピーを使うことがあります。

ステップ3：DMARCレコードが1つだけであることを確認する#

ドメインが公開できるDMARCレコードは1つだけです。_dmarcにある2つのTXTレコードがどちらもv=DMARC1で始まっていると、受信側は通常どちらも無視し、レポートは止まります。古いレコードを削除せずに新しいレコードを追加した場合や、DNSの移行でレコードが二重にコピーされた場合に起こります。

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:old@example.com"
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:new@example.com"

片方を削除してもう片方を残し、アドレスは1つのrua=リストにまとめます。複数のレポート宛先は、レコードを増やすのではなく、1つのレコード内でカンマで区切ります。

ステップ4：ruaの構文を確認する#

rua=の値はURIのリストで、それぞれがmailto:で始まっている必要があります。よくある間違いは次のとおりです。

最後の行で引っかかる人は多くいます。集計レポートはruaから届きます。rufだけを設定しても、ほとんど何も届きません。タグの一覧はDMARCの設定方法にあります。

ステップ5：別ドメインへのレポート送信を承認する#

最も見落とされやすい原因です。rua=のアドレスが、レコードが保護しているドメインとは別のドメインにある場合、受信側は、その別ドメインがレポートの受け取りに同意しているかを確認します。そうしないと、誰でも被害者のメールボックスにレポートを大量に送りつけられてしまうからです。

example.comの次のレコードを例にします。

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:reports@thirdparty.example.net"

アドレスがexample.comの外にあるため、受信する側のドメインは、あなたのドメインから組み立てた名前の承認レコードを公開しておく必要があります。

example.com._report._dmarc.thirdparty.example.net.  TXT  "v=DMARC1;"

このTXTレコードがなければ、仕様に準拠した受信側はレポートを破棄します。次のコマンドで確認できます。

dig TXT example.com._report._dmarc.thirdparty.example.net +short

実務上の注意が2点あります。

• 両方のドメインを管理している場合は、宛先側に承認レコードを追加するだけです。ベンダーがあなたの代わりにレポートを受け取る場合は、通常ベンダーがこれを公開してくれるか、公開するよう案内してくれます。
• レポートをあなた自身のドメインのメールボックスに送れば、この確認を完全に回避できます。そのため、dmarc@yourdomain.comのような単純な転送が、いちばん壊れにくい構成です。

ステップ6：宛先のメールボックスを確認する#

レコードが有効で、承認も済んでいるなら、レポートは届いていても紛れてしまっている可能性があります。

• 添付ファイルのフィルタリング。 レポートは.gzまたは.zipの添付ファイルとして届き、XMLのみのこともあります。圧縮された添付ファイルを除去するメールフィルターは、何も言わずに破棄します。迷惑メール、隔離、アーカイブを削除するルールを確認してください。
• メールボックスの容量超過。 送信量の多いドメインでは、1日に数十通のレポートが届くことがあります。小さな共有メールボックスはすぐにいっぱいになり、受信を拒否し始めます。
• 書き換えるエイリアスや転送。 外部の送信者をブロックするグループエイリアスは、プロバイダーからのレポートを拒否します。

件名に「Report Domain」とドメイン名を含むメールを検索してください。フィルタリングを確認しても1通も見つからないなら、問題はもっと手前にあります。

専用のメールボックス、またはレポートを代わりに受け取ってくれるサービスを使えば、こうした問題の大半は避けられます。個人の受信トレイに生のXMLが届くと、重要な情報が埋もれてしまう点も、DMARCレポートの読み方で説明しています。

Qualisendのレポート用アドレスを使っている場合#

rua=がDMARCレポートの<key>@dmarc.qualisend.comアドレスを指している場合、宛先に関する確認はQualisend側で処理されます。Qualisendはワイルドカードの承認レコードを公開しているため、プロバイダーはどのドメインについてもそのアドレスに送信でき、ステップ5の承認レコードを追加する必要はありません。それでもデータが届かない原因として、次のものがあります。

• ドメインが対象になっていない。 レポートが保存されるのは、ワークスペースでカバレッジをオンにしたドメイン、またはそのサブドメインのみです。対象外のドメインのレポートは受け付けられても保存されないため、ダッシュボードは空のままになります。
• サブスクリプションが有効でない。 有効なDMARCサブスクリプションのないワークスペースのアドレスに送られたレポートは、拒否されます。
• アドレスをローテーションした。 ローテーションすると、古いアドレスはすぐにメールの受信を停止するため、それを記載しているrua=はすべて、DNSを更新するまでレポートを失います。
• レコードにアドレスが記載されていない。 すでにDMARCレコードがある場合は、そのrua=リストに,mailto:<address>を追加し、ポリシーと他のアドレスはそのまま残してください。

QualisendがDNSを編集することはありません。レコードの変更は、お使いのDNSホストでご自身で行っていただきます。最初のレポートは通常24〜48時間以内に届くと画面に表示されますが、これはプロバイダーの実際の動作と一致しています。

サブドメインと優先されるレコード#

届かないレポートがサブドメインのものなら、そこに実際に何が公開されているかを確認してください。独自のDMARCレコードを持つサブドメインはそのレコードを使い、そのレコードにrua=がなければ、親ドメインのアドレスには何も送られません。レコードを持たないサブドメインは、親ドメインのレコードとそのsp=ポリシーにフォールバックします。レポートにはポリシーに記載されたドメイン名が使われるため、メインのドメインではなく、その名前で探してください。

DNSを変更した後は、ドメイン全体をドメイン診断にかけるのがおすすめです。DMARCレコードの欠落、ポリシータグのないレコード、p=noneのポリシーを検出し、公開されているレコードも表示するので、rua=の値をご自身で確認できます。有料のドメイン診断の監視では、有効なポリシーにrua=がまったくない場合にも警告します。DNSの編集後にこの問題が繰り返し起こる場合は、ドメイン診断の監視ガイドで、レポートが止まる前に気づく方法を説明しています。

最終チェックリスト#

• レコードの公開後、48時間待つ。
• dig TXT _dmarc.yourdomain.comを実行して、結果を読む。
• レコードが1つだけで、v=DMARC1で始まり、p=が明示されていることを確認する。
• rua=mailto:で、アドレスの間がカンマで区切られていることを確認する。
• アドレスが別ドメインにある場合は、_report._dmarcの承認レコードを確認する。
• 宛先メールボックスの迷惑メール、隔離、サイズ制限、フィルターを確認する。
• レポートを送るプロバイダーに、そのドメインから実際にメールを送っているか確認する。

レポートが届き始めたら、次の仕事はその内容を理解することです。DMARCモニタリングとお使いのドメインで誰が送信しているかで説明しています。

DMARCレポートが届くようになれば、誰がお使いのドメインで送信しているかは分かりますが、リストが健全かどうかは分かりません。次にリストを確認したい場合は、無料プランの料金ページにある100クレジットでフル検証を実行でき、無料メールチェッカーは1件ずつのアドレスに対応します。認証が機能していても、受信トレイに届くには健全なリストが必要です。