ドメインヘルスチェック:無料の完全監査(DNS+SSL+メール+アップタイム)

なぜドメインヘルスが重要なのか

ほとんどのチームが「ドメインは健全」と言うとき、通常それが意味するのは「最後に誰かがチェックしたとき、ウェブサイトは200を返した」ということです。それは少なくとも5つのうちの1つのシグナルにすぎません——そして他の4つは、誰もが見ているその1つよりも、より多くの障害、より多くの収益損失、より多くの顧客信頼へのダメージを引き起こします。

ドメインが健全であるとは、到達可能で、安全で、認証され、評判が良く、観測可能であることです。SEOはこれに依存します(Googleは混在コンテンツ、期限切れ証明書、遅いTTFBにペナルティを与えます)。配信性はこれに依存します(GmailとYahooは現在、大量送信者向けに整合していないドメインからのメールを拒否しています)。セキュリティはこれに依存します(ぶら下がりCNAMEはサブドメイン乗っ取りを待っているようなものです)。そして顧客信頼はこれに依存します(クレジットカード入力時のブラウザ警告は、コンバージョンが消え、返金がトリガーされることを意味します)。

このガイドは5分間の監査です。終わりまでに、5つの柱のどれが今あなたのドメインで静かに失敗しているか、確認するためにどのコマンドを実行するか、修正するためにNova Uptimeのどの無料ツールを使うかが正確に分かります。空文句なし、マーケティング文句なし——シニアSREがあなたからドメインを渡されて「これいい状態?」と聞かれたときに通り抜ける監査だけです。

ドメインヘルスの5つの柱#

柱を1つずつ見る前に、メンタルモデルを示します。すべての健全なドメインは5つすべてのチェックをパスします。ほとんどの本番ドメインは少なくとも1つで失敗します——そしてチームは、その失敗が顧客のチケットになるまで気づきません。

• 柱1:DNS設定 — A、AAAA、MX、CNAME、TXT、DNSSEC。すべてのレコードが存在し、正しく、然るべき場所を指していますか?
• 柱2:SSL/TLS証明書 — 有効期間ウィンドウ、チェーン整合性、SANカバレッジ、暗号強度、HSTS。今日と60日後にすべてのブラウザが証明書を信頼しますか?
• 柱3:メール認証 — SPF、DKIM、DMARC、アライメント。攻撃者はあなたのドメインをなりすませますか?正規のメールは受信箱に届いていますか、それとも迷惑メールフォルダですか?
• 柱4:レピュテーション — Spamhaus、Barracuda、SORBS、SpamCopでのDNSBL登録。送信IPまたはドメインが、配信性を静かに焼き払うブラックリストに登録されていますか?
• 柱5:アップタイムとパフォーマンス — HTTPステータス、レスポンスタイムのパーセンタイル、マルチリージョン到達性、ドメイン期限、登録経過年数。サイトは実際に稼働していて、速くて、来週の火曜日に期限切れになろうとしていませんか?

各柱には、ターミナルから実行できる30秒のチェック、無料のNova Uptimeツールで実行できるより深い検査、次の障害の前にアラートされるよう設定できる継続的モニタがあります。

柱1:DNS設定#

DNSは基盤です。DNSが間違っていれば、他の4つの柱は問題になりません——リクエストはサーバーに届きません。

重要なレコード

• Aレコードは、ホスト名をIPv4アドレスにマッピングします。すべてのドメインには、エイペックスとwwwそれぞれに少なくとも1つ必要です。
• AAAAレコードは、ホスト名をIPv6アドレスにマッピングします。ほとんどのチームはこれをスキップします。スキップすべきではありません。IPv6トラフィックは、主要市場のモバイルトラフィックの30〜40%を日常的に占めるようになっており、AAAAレコードがないとIPv4へのフォールバックが強制され——遅延が増え、設定が貧弱なキャリアネットワークでは時折障害が発生します。
• MXレコードは、メールルーティングを定義します。複数のMXレコードは優先度値を使います(低い = 優先)。私たちが見る最も一般的なMXバグは、SMTPリスナーがないエイペックスドメインに対して優先度0のMXレコードを向けるものです——メールはサイレントにバウンスします。
• CNAMEレコードはエイリアスです。危険はぶら下がりCNAMEです:もう使っていないサービス(廃止されたS3バケット、古いHerokuアプリ、サンセットされたZendeskインスタンス)を指すCNAME。上流プロバイダーでそのリソースを取得した攻撃者があなたのサブドメインを乗っ取ります。
• TXTレコードは、検証、SPF、DMARC、ドメイン所有権トークンを運びます。定期的に監査すべきです——使用を停止したサービスからの古い検証はゾーンを散らかし、SPFルックアップ数を増やします。
• DNSSECは、DNS応答に暗号的な信頼チェーンを追加します。キャッシュポイズニングとDNSハイジャックを防ぎます。厳密には必須ではありませんが、お金、認証情報、ヘルスケアデータを扱うドメインには推奨されます。

クイックチェック

dig +short A yourdomain.com
dig +short AAAA yourdomain.com
dig +short MX yourdomain.com
dig +short TXT yourdomain.com
dig DNSKEY yourdomain.com +short

MX固有の検証には、Nova Uptimeのメールヘルスチェッカーを実行してください——MXレコード、優先度を確認し、各MXホスト名をIPに解決します。

柱2:SSL/TLS証明書#

動作する証明書だけでは不十分です。SSL証明書には間違っている可能性のある独立した6つの事項があり、ほとんどの監視ツールはそのうちのちょうど1つ——有効期限——をチェックします。

何を検証するか

• **notBeforeとnotAfter**は、有効期間ウィンドウを定義します。Let's Encryptの90日サイクルと、2028年までに47日証明書への業界推進により、期限切れは速くサイレントに発生します。30日先を知る必要があります。
• 発行者チェーン整合性。サーバーが提示する証明書には、信頼されたルートにリンクする中間証明書が含まれている必要があります。証明書はChrome(中間をキャッシュする)では問題なく検証されますが、古いSafari、iOS、または欠落している中間を取得しないヘッドレスツールでは壊れます。これは「私のブラウザでは動くのに」SSLバグの中で最も一般的なものです。
• SAN(Subject Alternative Name)カバレッジ。証明書には、提供するすべてのホスト名がリストされている必要があります:エイペックス、www、同じ証明書を使うサブドメイン。www.yourdomain.comに有効だがベアエイペックスには無効な証明書は、よくある設定ミスです。
• 暗号スイートとプロトコルバージョン。TLS 1.0と1.1は非推奨です。TLS 1.2が下限、TLS 1.3が目標です。弱い暗号(RC4、3DES、古い設定でのCBCモードを含むもの)は無効化すべきです。
• HSTSヘッダー。Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadは、ブラウザに永遠にHTTPを拒否するよう伝えます。HSTSがなければ、中間者攻撃者が初回接触時に接続をダウングレードできます。
• OCSPステープリング。サーバーは、TLSハンドシェイクに証明書有効性の署名済み証明を添付し、CAのOCSPレスポンダへのラウンドトリップを排除します。より速く、よりプライベートです。ほとんどのモダンウェブサーバーがサポートしていますが、有効化しているものは少ないです。

クイックチェック

echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null \
  | openssl x509 -noout -dates -issuer -subject

30日期限アラートとチェーン検証を伴う継続的監視には、Nova UptimeのSSL期限チェッカーを使用してください。

柱3:メール認証#

これは2026年にルールが変わった柱です。GmailとYahooの大量送信者施行は、欠落した、または整合していないDMARCレコードがレピュテーションだけでなく受信箱配置のコストになることを意味します。

SPF — あなたのドメインのために誰が送信できるか#

SPFは、あなたとしてメールを送信することを認可されたIPとドメインをリストするDNS TXTレコードです。2つの罠:

• 10回のDNSルックアップ制限。 SPFレコードの各include:がカウントされます。SendGrid単独で3ルックアップ、Google Workspace(3)、Mailchimp(1)、トランザクションプロバイダー(3)を加えると、制限を超えます。受信サーバーはpermerrorを返し、メールは失敗します。
• +all(または修飾子なし)。 末尾の修飾子(-all、~all、?all、+all)は、リストにないソースからのメールをどう扱うかを受信側に伝えます。+allは「誰でも私としてメール送信できる」——絶対に使わないでください。

Nova UptimeのSPFチェッカーで検証してください。

DKIM — 暗号署名#

DKIMは、各送信メッセージに秘密鍵で署名します。受信者はselector._domainkey.yourdomain.comから公開鍵を取得し、署名を検証します。2つの罠:

• セレクタの混乱。 DKIMにワイルドカードはありません。送信サービスが使うセレクタ(s1、google、mandrill、selector1など)を知る必要があります。鍵は{selector}._domainkey.yourdomain.comにあります。
• 鍵ローテーション。 DKIM鍵は年に1回ローテーションすべきです。ほとんどのチームは一度設定して5年間忘れます。

Nova UptimeのDKIMチェッカー経由でチェックしてください——50の一般的なセレクタを自動スキャンします。

DMARC — ポリシー層#

DMARCは、SPFとDKIMが失敗したときに何をすべきかを受信サーバーに伝えます。3つのポリシー:

• p=none — 監視のみ、何のアクションも取りません。最初の2〜4週間レポートを収集している間に使ってください。
• p=quarantine — 失敗メールを迷惑メールに送ります。
• p=reject — 失敗メールを完全に拒否します。これが目標です。

ほとんどのドメインがp=noneに永遠に止まっているのは、誰も集計(rua)レポートを読まないからです。ほとんどのドメインにならないでください。私たちのDMARCポリシー設定ガイドを通り抜け、Nova UptimeのDMARCチェッカーで検証してください。

アライメント — 誰もが見逃す部分

DMARCは、SPFまたはDKIMドメインがFromヘッダードメインと整合することを要求します。メッセージはSPF(mailgun.orgに対して)をパスし、DKIM(mandrillapp.comによって署名)をパスできますが、Fromヘッダーがyou@yourdomain.comと言う場合、何も整合しないためDMARCは失敗します。すべての送信サービスにカスタムリターンパスドメインとDKIM署名ドメインを設定して修正してください。

4つすべてを一度にチェックするには、Nova Uptimeのメールヘルスチェッカーを使ってください——SPF、DKIM、DMARC、アライメントを一緒にスコアリングします。

柱4:レピュテーション(ブラックリスト)#

完璧な認証があっても、貧弱なレピュテーションは迷惑メールに送られます。DNSBL(DNSベースのブロックリスト)は公開スコアボードです。

DNSBLが追跡するもの#

一部のブロックリストはIP(送信メールサーバーのアドレス)を追跡します。他はドメイン(メッセージ本文のURI)を追跡します。各ブロックリストには独自の登録基準がありますが、一般的なトリガーは:スパムトラップへの送信、高い苦情率、突然のボリュームスパイク、既知のスパマーと同じIPブロック上にあること、です。

重要なリスト

• Spamhaus SBL/XBL/PBL/DBL — ゴールドスタンダード。主要なメールボックスプロバイダーはSpamhausを直接参照しています。
• Barracuda Reputation Block List — エンタープライズフィルタで広く使われています。
• SORBS — 複数のフィードを集約します;攻撃的になることがあります。
• SpamCop — ユーザー苦情によって駆動されます;比較的短い登録期間ですが高ボリュームです。

あなたが登録された理由

最も一般的な4つの理由:(1)プラットフォーム上の侵害されたアカウントがスパムを送信した、(2)共有IP設定の顧客が送信した、(3)古い未検証リストにキャンペーンを送信した、(4)フォームが認証されていないサインアップを許可し、ボットがプラットフォームを使って送信している。

チェック方法

Nova Uptimeのブラックリストチェッカーを使ってください——60以上のDNSBLに並列で問い合わせ、IPとドメインがフラグ付けされたリストを正確に表示し、それぞれの登録解除リンクを示します。

登録された場合、最初に基底の問題を修正し(侵害されたアカウントを閉じる、リストをクリーンにする、フォームを修正する)、その後登録解除リクエストを提出します。1週間後に同じ根本原因で再登録されると、より長い禁止になります。

柱5:アップタイムとパフォーマンス#

これは誰もが見ている柱です——そしてここでさえも、ほとんどのチームが見ているのは1つのメトリックだけです。

何を測定するか

• HTTPステータスコード。200は健全。4xxはあなたの問題。5xxはサーバーの問題。3xxリダイレクトは3ホップ以内に200に解決すべきです。
• レスポンスタイムのパーセンタイル。中央値(p50)はストーリーラインで、p95とp99が真実です。p50 200msでp99 9,000msのサイトは、100リクエストに1つに影響する深刻な問題があります——通常は遅いデータベースクエリかコールドキャッシュです。
• マルチリージョン到達性。シングルリージョン監視は、あなたの障害をキャッチします。顧客の障害——アジアでのBGPルートフラップ、地域的なCloudflareインシデント、ユーザーの10%に影響するISPピアリング紛争——を見逃します。
• 障害スクリーンショット。サイトがダウンしたときに、ユーザーが見ている画面をキャプチャします。「サイト到達不能」は、問題が500、Cloudflareチャレンジページ、決済プロバイダーのiframeの失敗のいずれであっても、モニタからは同じに見えます。
• ドメイン期限。ドメインは期限切れになります。自動更新は失敗します(クレジットカード期限切れ、レジストラアカウント停止、請求メールが元従業員のメールボックスに行く)。レジストラの期限日と——SEOの権威を示す登録経過年数を追跡します。

59秒間隔、マルチリージョンチェック、スクリーンショット、WhatsApp/メール/Webhookアラートを伴う継続的監視には、Nova Uptime料金ページでサインアップしてください。登録経過年数と期限の1回限りのチェックには、ドメイン期限チェッカーとドメイン年齢チェッカーを使ってください。

5分間ヘルスチェックチェックリスト#

これらを順番に実行してください。各ステップには明確なpass/failがあります。

1. DNS — dig +short A yourdomain.com && dig +short AAAA yourdomain.com && dig +short MX yourdomain.com。3つすべてが値を返すべきです。MXが空ならメールは壊れています。
2. SSL — echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates。notAfterは30日以上先のはずです。
3. SPF — /tools/spf-checkerを訪れ、ドメインを入力。スコアは90以上のはずです。
4. DKIM — /tools/dkim-checkerを訪れ、ドメインを入力。ステータスは「Configured」のはずです。
5. DMARC — /tools/dmarc-checkerを訪れる。ポリシーはquarantineまたはrejectであるべきで、noneではないはずです。
6. メールヘルス(統合) — /tools/email-healthが、上記すべてにわたるA〜Fグレードを提供します。
7. ブラックリスト — /tools/blacklist-checker。登録ゼロが目標です。
8. SSL深掘りチェック — /tools/ssl-expiryでチェーン検証と30日アラート。
9. ドメイン期限 — /tools/domain-expiry。60日以上先であるべきです;SEO権威にはより長いほうが良いです。
10. アップタイム — curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://yourdomain.com。ステータス200、時間1.5秒未満。

これらのいずれかが失敗したら、トッププライオリティを特定したことになります。

実世界のストーリー

過去6か月のドメイン監査支援からのいくつかの例:

6か月隠れていた整合していないDKIM。 あるB2B SaaS企業は、カスタムサブドメイン(mail.theirsite.com)経由でトランザクションメールを送信していましたが、DKIMのd=タグはプロバイダーのドメインで、自分のものではありませんでした。Gmailの猶予期間により、メールは低ボリュームでは依然として受信箱に届いていました。最初の大規模キャンペーン——5万通——を実行したとき、開封率は4%でした。バウンスレポートは、Gmailが何か月もメッセージを静かにダウングレードしていたことを示していました。修正は10分のDNS変更でした。教訓は、「配信性は問題ないように見える」は測定ではないということです。

Safariだけが気づいた中間証明書。 あるeコマースサイトは、ホスティングプロバイダー経由でSSL証明書を自動更新しました。新しい証明書は正しくデプロイされましたが、中間証明書がバンドルから欠落していました。ChromeとFirefoxは前回の訪問から中間をキャッシュし、検証を続けました。Safari(中間を積極的にキャッシュしない)は、フルページのセキュリティ警告を表示しました。チェックアウトトラフィックの約18%がiOS Safariでした。彼らは、カスタマーサポートチケットが点と点をつなぐまで2日間の収益を失いました。

乗っ取りになったぶら下がりCNAME。 promo.theirdomain.comにあった古いマーケティングランディングページは、3年前に削除されたHerokuアプリへのCNAMEでした。攻撃者が同じHerokuアプリ名を登録し、12時間そのサブドメインは任意のHTMLを提供——会社のログインページを模倣したフィッシングフォームを含めて。修正は30秒のDNSクリーンアップでした。発見はゼロでした——チームは顧客がフィッシング試行を報告したときに初めて知りました。月次のサブドメイン監査がそれをキャッチしたでしょう。

まとめ

ドメインヘルスは1つではなく5つの柱です。上記の5分チェックリストを実行してください。失敗を修正してください。その後、時間とともにドリフトするものに継続的モニタを置きます——証明書は期限切れになり、ブラックリストは変わり、登録は失効し、SPFレコードはルックアップ制限を破るまで成長します。5つの柱すべて、無料で、1つのダッシュボードに、Nova Uptimeで。

関連記事

• DMARCポリシー設定ガイド:noneからrejectへ
• DKIM設定ステップバイステップガイド
• 無料メールヘルスチェッカー
• 無料SPFチェッカー
• 無料DKIMチェッカー
• 無料DMARCチェッカー
• 無料ブラックリストチェッカー
• 無料SSL期限チェッカー
• ドメイン期限チェッカー
• ドメイン年齢チェッカー