メールドメイン診断の監視：何を、いつチェックするか

メールドメインの実体は、ほんの数本のDNSレコードです。公開した日には正しかったそれらも、その後にホスティングを変えたり、送信ツールを追加したり、鍵をローテーションしたり、「使っていない」TXTレコードを整理したりするうちに、状況が変わっていきます。壊れても、誰も知らせてくれません。しばらくはメールが流れ続け、やがてバウンスや迷惑メール振り分けがじわじわ増えますが、いつから始まったのか誰にもわかりません。このガイドでは、メールドメインの健全性とは何か、どのレコードが対象なのか、音もなく壊れるのは何か、そして単発のチェックと毎日実行する監視がどう違うのかを説明します。

結論#

メールドメインの健全性とは、「受信側がこのドメイン宛てにメールを配信し、このドメインからのメールを信頼するために必要なDNSレコードが、存在し、有効で、変更されていないか」という問いのことです。具体的には次の6つを指します。MX（誰かがあなた宛てに配信できるか）、SPF（どのサーバーがあなたの名義で送信してよいか）、DKIM（署名用の鍵が公開されているか）、DMARC（認証に失敗したとき受信側にどう処理してほしいか）、そして任意の追加項目であるMTA-STSとBIMIです。単発のチェックでわかるのは、いまこの時点の状態です。これに対して監視はチェックを定期的に繰り返し、何かが変わったときに知らせてくれます。失敗のほとんどは、最初の設定ミスではなく後からの退行（リグレッション）だからです。まず無料のドメイン診断で現状の基準値を取り、そのうえで、頼りにしているドメインに毎日の監視が見合うかどうかを判断してください。

ドメイン診断でチェックする内容#

表のレコードはそれぞれ別の問いに答えるもので、どれも単独で壊れることがあります。

メールが届き、信頼されるかどうかを左右するのは、最初の4つです。書き方は、DMARCの設定手順と、SPF、DKIM、DMARCをまとめて解説した概要で説明しています。MTA-STSとTLS-RPTやBIMIは任意の強化策なので、未設定であることは緊急事態ではなく、参考情報にとどまります。

いまでは、メールボックスプロバイダー側もこれを求めている点にご注意ください。GoogleとYahooの送信者要件では、一括送信者に対して、SPF、DKIM、DMARCレコードを用意し、FromドメインをSPFまたはDKIMとアライメントさせることが求められています。Microsoftも、Outlook.comのアドレス宛てに大量送信する送信者に同様のルールを適用しています。レコードが知らないうちに消えると、一夜にして要件を満たす状態から満たさない状態に変わってしまうことがあります。

誰にも気づかれずに壊れるもの#

認証の失敗は、失敗らしい見た目をしていないことがほとんどです。メールは受け付けられ、一部は迷惑メールフォルダーに入り、原因は数か月間誰も見ていないレコードにあります。次のようなケースが繰り返し起きています。

• DNS移行でTXTレコードが抜け落ちる。 DNSホストを移すとき、インポートツールはAレコードとCNAMEレコードをコピーしますが、SPF、DKIM、DMARCのTXTエントリは欠落したり、壊れたりします。詳しくは、SPF、DKIM、DMARCが機能しなくなったときをご覧ください。
• SPFレコードが2つになる。 マーケティングツールの案内に従って誰かが「このTXTレコードを追加」し、ドメインにSPFレコードが2つできてしまいます。受信側はこれを恒久的なエラーとして扱うため、すべてのメールでSPFが失敗します。
• SPFが10回を超えるDNSルックアップになる。 ツールを追加するたびにinclude:が増え、ある日、レコードが上限を超えます。数え方と対処法は、SPFのDNSルックアップが多すぎる場合で説明しています。
• DKIMキーがローテーションまたは削除される。 プロバイダーが新しいセレクターに切り替えたり、メールがまだ署名されているのに誰かが古い鍵を削除したりします。送信者が実際にどの鍵を使っているかを調べる方法は、DKIMセレクターの見つけ方で説明しています。
• DMARCが削除される、またはレポートが届かない。 レコード自体がなくなっているか、rua=の送り先が役に立たない場所を指しているため、誰があなたの名義で送信しているのかが見えません。
• 短いDKIMキーが残り続ける。 1024ビットの鍵でも動作するため、何年もそのまま残ってしまいます。標準では、署名側は2048ビット以上を使うべきとされています。

どれも、攻撃者を必要としません。ごく普通の保守作業で起きることなので、人が定期的に目視でレビューしても見落とされます。数字が動くまでは、壊れているようには見えないからです。

単発のチェックか、毎日の監視か#

単発のチェックが適しているのは、次の3つの場面です。レコードを公開または変更した後、特定の問い合わせの原因を調べているとき、そして自分で設定していないドメインを引き継いだときです。無料で、数秒で終わり、スナップショットが得られます。全体像を見るにはドメイン診断を、認証レコードだけを確認したい場合はSPF、DKIM、DMARCチェッカーを使ってください。

監視が答えるのは別の問いです。つまり、昨日から何が変わったのか、そして誰に知らせるべきなのか、ということです。上で挙げた失敗はどれも、チェックとチェックの間に起こります。重要なのは、「レコードが壊れた」から「誰かが気づく」までの時間です。手作業の運用では、バウンス率が上がって調査が始まるまでの時間がそのまま空白期間になります。毎日チェックすれば、それが最大でも1日に収まります。

判断の目安は次のとおりです。

1. ドメインが1つで、変更が少なく、送信ツールも1つ。 変更のたびに単発のチェックを行えば、おそらく十分です。
2. ドメインや送信元が複数ある、またはDNSを触れる人が2人以上いる。 誰かが連絡なしにレコードを編集した最初の1回で、毎日の監視は元が取れます。
3. 送信に使っていない、パーク中または補助のドメイン。 ときどきチェックしてください。そうしたドメインでDMARCレコードがない、または緩いままだと、なりすましを招く隙になります。

アラートの対象にするもの#

アラートが役に立つのは、めったに鳴らず、内容が具体的な場合だけです。夜中に人を起こしてでも知らせる価値があるのは、変更によってメールがいままさに失敗しているレコードです。目安として、次のように分けるのがよいでしょう。

その日のうちに対応する：

• MXがない、またはMXホストが名前解決できない。
• SPFがない、SPFが2つ公開されている、構文エラー、またはルックアップが10回を超えている。
• DMARCがない、または無効（DMARCレコードが2つある場合を含む）。
• 頼りにしているDKIMセレクターで鍵が返ってこなくなった（この製品が報告できるのは、あなたが登録したセレクターについてのみです）。

今週中に見直す：

• SPFのルックアップが9回または10回で、1つ追加するだけで失敗する状態。
• DMARCがまだp=noneのまま、またはレポートを受け取るrua=アドレスがない。
• 1024ビットのDKIMキー、またはテスト中を示すフラグ（t=y）が付いたままの鍵。
• SPFの?all修飾子や、推奨されていないptrメカニズム。

参考情報：

• MTA-STSやBIMIのレコードが現れた、または消えた。

Qualisendのドメイン診断の監視では、これらを2段階の重大度に対応させています。MX、SPF、DKIM、DMARCにわたる20種類の問題コードに、それぞれ「bad」または「warn」を付け、ドメインの評価は、存在する中で最も重い重大度とします。最初のリストはすべて「bad」、2番目のリストはすべて「warn」です。問題が発生したときと解消したときに、メールでお知らせします。タイムアウトなどのDNSエラーは「チェックできませんでした」として扱われ、アラートは送りません。リゾルバーの不調が誤報にならないようにするためです。問題は2回連続で正常になった時点で解消と判定されるため、手動で再チェックしない限り、解消の通知は最大2日遅れることがあります。

基準値とルーティン#

大半の効果は、専用のプラットフォームがなくても得られます。ドメインごとに、次のことを1回やってください。

1. 送信元を書き出す。 そのドメインの名義で送信するすべてのシステム（メールボックスプロバイダー、マーケティングプラットフォーム、トランザクションメール用サービス、CRM、ヘルプデスク、請求ツール）を一覧にします。それぞれがSPFに反映され、DKIMで署名されている必要があります。
2. 基準となるチェックを実行して、結果を保存する。 SPFのルックアップ数、存在するDKIMセレクター、DMARCポリシーを控えておきます。
3. 各送信元が使うDKIMセレクターを記録する。 セレクター名は忘れやすく、後から推測するのは困難です。どこで確認できるかは、DKIMセレクターの見つけ方で説明しています。
4. DMARCにレポート用アドレスを公開する。 失敗の痕跡が残るようになります。レポートの扱いは、レポートの読み方とDMARCモニタリングで説明しています。
5. DNSを変更するたびに、また送信ツールを追加または削除するたびに再チェックし、それとは別に月に1回もチェックする。

ドメインが売上に直結しているなら、最後の手順が、人がやめてしまいがちな作業です。監視が代わりに担うのは、まさにここです。

監視では見えないもの#

見当違いの部分で監視を頼りにしないよう、限界をはっきりさせておきます。

• 読み取るのは公開DNSです。テストメールの送信、実際の送信メールの観察、受信箱への到達率の測定は行いません。SPFレコードが完全に有効でも、追加し忘れた送信元があれば漏れは起こります。実際のメールがどう認証され、受信サーバーに何が見えるかを確認するには、メール到達性テストを使ってください。こちらも受信箱への到達率は測定しません。
• DMARCは解析しますが、MTA-STSとBIMIは存在するかだけを確認します。MTA-STSのポリシーファイルを取得したり、BIMIのロゴや証明書を検証したりはしません。
• 監視するのはドメインであり、送信IPではありません。また、DNSを変更することはありません。問題の修正は、お使いのDNSホストで行います。
• 「毎日」は文字どおり毎日です。変更はリアルタイムではなく、24時間以内に検出されます。
• あなたのドメインを名乗って誰が送信しているかはわかりません。それを調べるのがDMARC集計レポートであり、DMARCレポートは、それを中心に作られた別製品です。

料金は、標準レートでティアごとの定額です。1ドメインは月額$8.99、最大10ドメインは$89、最大60ドメインは$499で、クレジットは不要、ほかの製品を買う必要もありません。

もう1点、標準は変わっていくことを心に留めておいてください。DMARCはRFC 7489で定義されましたが、2026年5月にRFC 9989に置き換えられました。細かな動作に依存する場合は、最新の文書を確認してください。

DNSが健全であれば、あなたのメールは信頼されますが、その背後にあるリストまできれいにしてくれるわけではありません。無料プランの料金ページには、リストに対してフル検証を実行できる100クレジットが含まれています。しっかり監視されたドメインでも、受信箱にたどり着くには健全なリストが必要です。