ドメインを取得したら最初にやる DNS チェック — NS から SSL 到達確認まで一通り解説
ドメインを取得した直後に DNS レコードの設定を一通り確認しておくと、メールが届かない・サイトが表示されないといったトラブルを未然に防げます。この記事では、NS レコードから SSL の到達確認まで、dig コマンドと外部 API の両面から確認する手順を順番に整理します。各コマンドの example.com は自分のドメインに置き換えて実行してください。
NS レコードでネームサーバーを確認する
最初に確認するのは NS レコードです。ドメインの DNS がどのネームサーバーで管理されているかを示すレコードで、ここが間違っていると以降のすべてのレコード設定が反映されません。レジストラでドメインを購入した直後はレジストラ既定の NS が割り当てられているため、外部の DNS サービスを使う場合はまず NS の切り替えが必要です。
dig で NS レコードを確認します。
dig NS example.com +short
ns1.example-dns.com.
ns2.example-dns.com.
レジストラの管理画面で設定したネームサーバーと一致しているかを確認します。末尾のドット(.)は DNS の正規表記なので無視して構いません。
Labee Dev Toolbox の DNS API でも外部視点から同じ情報を取得できます。コマンド操作に慣れていない場合は、ブラウザーから Labee Dev Toolbox の DNS チェック画面にアクセスすれば、ドメイン名を入力するだけで同じ結果を確認できます。
curl "https://labee.dev/api/dns?domain=example.com&type=NS"
{
"success": true,
"data": {
"domain": "example.com",
"records": {
"NS": ["ns1.example-dns.com", "ns2.example-dns.com"]
}
},
"error": null,
"meta": { "responseTime": 40 }
}
records.NS はネームサーバーのホスト名が文字列の配列で返ります。dig の結果と一致していれば、外部からも正しいネームサーバーが参照されています。NS が意図しないサーバーを指していると、A レコードや MX レコードをいくら変更しても設定が一切反映されないため、最初に必ず確認してください。
A レコードでサーバーの IP を確認する
ドメインが正しいサーバーの IP アドレスに向いているかを確認します。
dig A example.com +short
203.0.113.1
自分のサーバーの IP アドレスが返れば正常です。何も返らない場合は A レコードが未設定です。CDN やロードバランサーを経由する構成では、直接の IP ではなく CNAME で CDN のホスト名を指すケースもあるため、構成に応じて確認対象を使い分けてください。
外部からの見え方を確認する場合は DNS API を使います。
curl "https://labee.dev/api/dns?domain=example.com&type=A"
{
"success": true,
"data": {
"domain": "example.com",
"records": {
"A": [
{ "address": "203.0.113.1", "ttl": 3600 }
]
}
},
"error": null,
"meta": { "responseTime": 45 }
}
records.A は address(IP アドレス)と ttl(キャッシュ秒数)を含むオブジェクトの配列です。null の場合は A レコードが存在しません。TTL が短い(300 秒など)状態であれば、移行時にレコードを変更してもキャッシュが早く切れるため伝播が速くなります。
MX レコードでメール受信先を確認する
独自ドメインのメールアドレスを使う場合、MX レコードが受信サーバーを指定します。MX が未設定だとメールを一切受信できません。
dig MX example.com +short
10 mail.example.com.
左の数字が優先度(小さいほど優先)、右がメールサーバーのホスト名です。メールサービスの設定ガイドに記載されたホスト名と一致しているかを確認します。Google Workspace なら ASPMX.L.GOOGLE.COM など複数の MX が必要で、Microsoft 365 なら *.mail.protection.outlook.com を指定するのが一般的です。
DNS API でも確認できます。
curl "https://labee.dev/api/dns?domain=example.com&type=MX"
{
"success": true,
"data": {
"domain": "example.com",
"records": {
"MX": [
{ "priority": 10, "exchange": "mail.example.com" }
]
}
},
"error": null,
"meta": { "responseTime": 35 }
}
priority が優先度、exchange がメールサーバーのホスト名です。複数の MX レコードがある場合は配列に複数のオブジェクトが含まれます。
SPF・DKIM・DMARC を初期設定する
SPF・DKIM・DMARC はメールを送信するドメインに必要な設定です。Web サイトの公開だけが目的でメール送信を行わないドメインであれば、このセクションはスキップして構いません。
メール認証の 3 要素は、ドメイン取得直後に設定しておくと後からの対応が楽です。未設定のまま放置すると、そのドメインを送信元に偽装したなりすましメールを防げません。Gmail は個人用 Gmail アカウントへ 1 日あたり 5,000 件を超えるメールを送信するドメインに対して 3 要素すべてを要求しています。
SPF
SPF は「このドメインからメールを送信してよいサーバー」を宣言する TXT レコードです。
dig TXT example.com +short
"v=spf1 include:_spf.google.com ~all"
v=spf1 で始まるレコードが SPF です。include: でメールサービスの送信サーバーを許可し、末尾の ~all(ソフトフェイル)または -all(ハードフェイル)で許可リスト外からの送信をどう扱うかを指定します。SPF では DNS ルックアップが最大 10 回までという制約があるため、include を追加しすぎるとエラーになります。
DKIM
DKIM はメールに電子署名を付与し、改ざんを検知する仕組みです。公開鍵を {セレクター}._domainkey.example.com の TXT レコードとして公開します。セレクター名はメールサービスによって異なり、Google Workspace なら google、Microsoft 365 なら selector1 / selector2 が一般的です。
dig TXT google._domainkey.example.com +short
"v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
何も返らない場合は、セレクター名が間違っているか DKIM が未設定です。メールサービスの管理画面で公開鍵レコードの値を確認し、DNS に登録してください。
DMARC
DMARC は SPF と DKIM の検証結果に基づいて、認証に失敗したメールをどう処理するかを受信サーバーに指示するポリシーです。_dmarc.example.com の TXT レコードとして設定します。
dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:dmarc-report@example.com"
初期設定では p=none(監視のみ)から始めます。rua=mailto: で指定したアドレスに集計レポートが届くので、レポートの内容を確認しながら p=quarantine(迷惑メールに分類)、p=reject(拒否)へ段階的に移行します。いきなり p=reject にすると、正規の送信経路が SPF/DKIM を通過できていない場合にメールが届かなくなるため、まずはレポートで実態を把握してください。
SPF・DKIM・DMARC の設定を外部視点からまとめて検証する方法はこちらで詳しく解説しています。
技術ノートSPF・DKIM・DMARC を外部から確認する方法 — dig と API で設定漏れを検出するdig コマンドと外部 API を使って、SPF・DKIM・DMARC の設定状況を外部視点から確認する手順を解説します。DKIM セレクターの自動検索、Gmail のバルクセンダー要件との照合、よくある設定漏れパターンの特定方法も紹介します。設定項目を一つずつ確認したい場合はこちらも活用してください。
ガイドメール認証 完全チェックリストSPF・DKIM・DMARC の設定状況を一つずつ確認できるチェックリストです。Gmail / Outlook の送信者認証に対応するための最低限の項目をまとめています。メール認証 API で 3 要素をまとめて確認する
dig では SPF・DKIM・DMARC をそれぞれ個別に確認する必要がありますが、Labee Dev Toolbox のメール認証 API を使えば 1 回のリクエストで 3 要素すべてを外部視点から確認できます。
curl "https://labee.dev/api/mail-auth?domain=example.com"
{
"success": true,
"data": {
"spf": {
"record": "v=spf1 include:_spf.google.com ~all",
"exists": true
},
"dkim": {
"mode": "auto",
"record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...",
"exists": true,
"selector": "google",
"matches": [
{ "selector": "google", "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...", "exists": true }
],
"checkedSelectors": ["google", "selector1", "selector2", "s1", "s2", "k1", "k2", "k3", "default", "dkim", "mail", "smtp"],
"exhaustive": false
},
"dmarc": {
"record": "v=DMARC1; p=none; rua=mailto:dmarc-report@example.com",
"exists": true
},
"bimi": {
"record": null,
"exists": false
}
},
"error": null,
"meta": { "responseTime": 120 }
}
exists が false の項目は外部から確認できない状態です。DKIM はセレクターを省略すると auto モードで google・selector1・default など 12 種類の一般的なセレクターを自動検索します。独自のセレクター名を使っている場合は ?selector=mykey のように明示してください。exhaustive が false なので、自動検索ですべてのセレクターを網羅しているわけではありません。
SSL の到達確認
A レコードを設定してサーバーを公開したら、外部から HTTPS でアクセスできるかを確認します。
openssl で手元から確認する場合は次のコマンドを使います。
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates
notBefore=Apr 1 00:00:00 2026 GMT
notAfter=Jul 1 00:00:00 2026 GMT
証明書の有効期間が表示されれば、ポート 443 で SSL 接続が成立しています。Let’s Encrypt を利用する場合、有効期間は 90 日なので自動更新の設定が入っているかもあわせて確認してください。接続自体が失敗する場合は、証明書の未発行、ファイアウォールのポートブロック、A レコードの誤設定のいずれかを疑ってください。
自動更新が失敗する代表的なパターンとその対策はこちらにまとめています。
技術ノートSSL 証明書の期限切れを防ぐために知っておくべきこと — 自動更新の落とし穴と対策SSL 証明書の期限切れはサイトを即座にダウンさせます。2029 年には最大有効期間が 47 日に短縮されます。openssl での有効期限確認、外部からの到達確認、Certbot の自動更新が失敗するパターンと対策を解説します。Labee Dev Toolbox の SSL API を使えば、外部視点での到達確認ができます。
curl "https://labee.dev/api/ssl-cert?hostname=example.com"
{
"success": true,
"data": {
"hostname": "example.com",
"port": 443,
"reachable": true,
"status": 200
},
"error": null,
"meta": { "responseTime": 150 }
}
reachable が true であれば、外部から HTTPS で到達できています。false の場合はレスポンスの error フィールドに原因が記載されるので、ファイアウォール・証明書・ポート開放のいずれに問題があるかの手がかりになります。
一括取得で設定漏れを洗い出す
ここまで NS・A・MX・TXT・SSL を個別に確認してきましたが、最後にまとめてチェックすることで設定漏れを防げます。dig でレコードタイプごとに順に確認します。
dig A example.com +short
dig AAAA example.com +short
dig MX example.com +short
dig TXT example.com +short
dig NS example.com +short
dig SOA example.com +short
dig CAA example.com +short
それぞれの出力を見て、A レコードに正しい IP が入っているか、AAAA(IPv6)が必要なのに未設定でないか、MX がメールサービスのホスト名を指しているか、TXT に SPF レコードが含まれているか、NS が意図したネームサーバーかを順に確認します。CAA は証明書の発行元を制限するレコードで、Let’s Encrypt のみに限定する場合は 0 issue "letsencrypt.org" が返ります。何も返らなければ発行制限がかかっていない状態です。
Labee Dev Toolbox の DNS API を使えば、これらを一括で取得できます。type パラメーターを省略すると A, AAAA, MX, TXT, NS, CNAME, SOA, CAA の 8 種類をまとめて返します。
curl "https://labee.dev/api/dns?domain=example.com"
{
"success": true,
"data": {
"domain": "example.com",
"records": {
"A": [{ "address": "203.0.113.1", "ttl": 3600 }],
"AAAA": null,
"MX": [{ "priority": 10, "exchange": "mail.example.com" }],
"TXT": [["v=spf1 include:_spf.google.com ~all"]],
"NS": ["ns1.example-dns.com", "ns2.example-dns.com"],
"CNAME": null,
"SOA": [{ "mname": "ns1.example-dns.com", "rname": "admin.example-dns.com", "serial": 2026041201, "refresh": 7200, "retry": 3600, "expire": 1209600, "minimum": 86400 }],
"CAA": null
}
},
"error": null,
"meta": { "responseTime": 120 }
}
レコードが存在しない種類は null で返ります。たとえば AAAA が null なら IPv6 の A レコードが未設定、CAA が null なら証明書の発行制限がかかっていない状態です。dig で個別に確認した結果と照合すれば、外部からの見え方も含めて設定漏れを洗い出せます。NS・A・MX・SPF/DKIM/DMARC・SSL の 5 項目を順番に確認して、ドメインの初期設定を完了させてください。ブラウザーから確認する場合は Labee Dev Toolbox の DNS チェック画面やメール認証チェック画面、SSL 到達確認画面も活用できます。