Labee Dev Toolbox
技術ノートガイド用語解説
無料で試す
  1. ホーム
  2. / ガイド
  3. / メールが届かない時の確認チェックリスト — 原因の切り分けと対処法
チェックリスト 初級

メールが届かない時の確認チェックリスト — 原因の切り分けと対処法

2026年4月24日 更新 所要時間: 10分

送信したメールが届かない、迷惑メールフォルダーに入ってしまう。メール配送トラブルは SPF → DKIM → DMARC → MX → PTR → DNSBL → レピュテーション → TLS の順に確認することで、大半の原因を特定できます。原因は DNS レコードの設定不備、IP アドレスの信頼性、メールサーバーの暗号化設定など幅広い範囲にまたがりますが、このチェックリストに沿って順番に切り分ければ、どこに問題があるかを効率的に突き止められます。

このチェックリストでは、メール配送トラブルの原因を 8 つのステップで順番に切り分けます。SPF・DKIM・DMARC の認証設定から、MX レコード、逆引き DNS（PTR）、ブロックリスト（DNSBL）、送信者レピュテーション、メールサーバーの TLS 設定まで、確認すべき項目を網羅しています。

example.com の部分は実際のドメイン名に置き換えてください。

flowchart TD
    Start["メールが届かない"] --> SPF{"SPF レコードが\n存在する?"}
    SPF -- No --> FixSPF["SPF を設定する\n→ Step 1"]
    SPF -- Yes --> DKIM{"DKIM レコードが\n存在する?"}
    DKIM -- No --> FixDKIM["DKIM を設定する\n→ Step 2"]
    DKIM -- Yes --> DMARC{"DMARC レコードが\n存在する?"}
    DMARC -- No --> FixDMARC["DMARC を設定する\n→ Step 3"]
    DMARC -- Yes --> MX{"MX レコードが\n正しい?"}
    MX -- No --> FixMX["MX を修正する\n→ Step 4"]
    MX -- Yes --> PTR{"PTR / FCrDNS が\n正しい?"}
    PTR -- No --> FixPTR["PTR を設定する\n→ Step 5"]
    PTR -- Yes --> DNSBL{"DNSBL に\n登録されていない?"}
    DNSBL -- "登録あり" --> FixDNSBL["解除申請する\n→ Step 6"]
    DNSBL -- "登録なし" --> Rep["送信者レピュテーション\nと TLS を確認\n→ Step 7・8"]

チェックリスト一括コピー用

以下をコピーして手元のメモやIssueに貼り付ければ、そのまま確認リストとして使えます。

## メール配送トラブルシューティング チェックリスト

### Step 1 SPF
- [ ] TXT レコードに `v=spf1` が存在する
  - `dig TXT example.com +short`
- [ ] `include:` に利用中の送信サービスが含まれている
- [ ] 末尾が `~all` または `-all` で終わっている
- [ ] SPF レコードが 1件だけ存在する
- [ ] DNS ルックアップ回数が 10回以内に収まっている

### Step 2 DKIM
- [ ] `{selector}._domainkey.example.com` に TXT レコードが存在する
  - `dig TXT google._domainkey.example.com +short`
- [ ] レコードが `v=DKIM1` で始まっている
- [ ] `p=` に Base64 の公開鍵が含まれている
- [ ] セレクター名がメール送信サービスの設定と一致している

### Step 3 DMARC
- [ ] `_dmarc.example.com` に TXT レコードが存在する
  - `dig TXT _dmarc.example.com +short`
- [ ] レコードが `v=DMARC1` で始まっている
- [ ] `p=` に none・quarantine・reject のいずれかが設定されている
- [ ] `rua=` でレポート受信先が指定されている

### Step 4 MX レコード
- [ ] MX レコードが存在する
  - `dig MX example.com +short`
- [ ] 宛先ホスト名が正しいメールサーバーを指している
- [ ] 優先度（priority）が意図どおりに設定されている

### Step 5 逆引き DNS（PTR）と FCrDNS
- [ ] 送信 IP に PTR レコードが設定されている
  - `dig -x 203.0.113.1 +short`
- [ ] PTR で返るホスト名の A レコードが元の IP に一致する（FCrDNS）

### Step 6 DNSBL（ブロックリスト）
- [ ] 送信サーバーの IP アドレスが主要な DNSBL（Spamhaus ZEN、Barracuda、SpamCop など）に登録されていない
  - `dig 1.113.0.203.{your-key}.zen.dq.spamhaus.net +short`（DQS 利用時。従来の zen.spamhaus.org は公開リゾルバーでは正確な結果を返さない場合あり）

### Step 7 送信者レピュテーション
- [ ] Google Postmaster Tools でドメインレピュテーションが Low / Bad になっていない
- [ ] ハードバウンス率が 2% 未満に収まっている
- [ ] 迷惑メール報告率が 0.10% 未満を維持している（推奨 0.10% 未満、上限 0.30%）

### Step 8 メールサーバーの TLS
- [ ] STARTTLS に対応している
  - `openssl s_client -starttls smtp -connect mail.example.com:25`
- [ ] 証明書の有効期限が切れていない
  - `openssl s_client -starttls smtp -connect mail.example.com:25 2>/dev/null | openssl x509 -noout -dates`

### 一括確認（API）
- `curl "https://labee.dev/api/mail-auth?domain=example.com"`
- `curl "https://labee.dev/api/dns?domain=example.com&type=MX"`
- `curl "https://labee.dev/api/ip?ip=203.0.113.1"`

Step 1 SPF レコードを確認する

SPF（Sender Policy Framework、RFC 7208）は、ドメインからメールを送信できるサーバーの IP アドレスを DNS の TXT レコードに列挙する仕組みです。受信サーバーはメールの送信元 IP を SPF レコードと照合し、許可されていない IP からのメールを拒否またはスパム判定します。SPF が未設定のドメインから送ったメールは、Gmail や Outlook で迷惑メールに振り分けられます。

Google Workspace や Microsoft 365 などのメールプラットフォーム、SendGrid、Amazon SES、Postmark などのメール送信サービスを利用している場合は、各サービスのセットアップガイドに従って include: を追加する形で SPF を設定します。

チェック項目

  • example.com の TXT レコードに v=spf1 で始まるレコードが存在する
  • include: に利用中のメール送信サービス（Google Workspace なら _spf.google.com、SendGrid なら sendgrid.net など）が含まれている
  • レコードの末尾が ~all（ソフトフェイル）または -all（ハードフェイル）で終わっている
  • SPF レコードが 1件だけ存在する（同一ドメインに複数あると RFC 7208 違反で認証失敗になる）
  • include: のネストを含む DNS ルックアップ回数が 10回以内に収まっている

確認コマンド

dig TXT example.com +short
"v=spf1 include:_spf.google.com ~all"

v=spf1 で始まる行がなければ SPF は未設定です。複数行に v=spf1 が現れる場合は、1つのレコードに統合する必要があります。

labee.dev の API でも確認できます。

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": null,
      "exists": false,
      "selector": "",
      "matches": [],
      "checkedSelectors": ["google", "selector1", "selector2", "s1", "s2", "k1", "k2", "k3", "default", "dkim", "mail", "smtp", "mte1", "mte2", "pdk1", "pdk2", "mesmtp", "zoho"],
      "exhaustive": false
    },
    "dmarc": { "record": null, "exists": false, "source": null, "domain": "example.com" },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 142 }
}

data.spf.exists が true であることを確認してください。false の場合、SPF レコードが存在しないか、DNS に反映されていません。

Step 2 DKIM レコードとセレクターを確認する

DKIM（DomainKeys Identified Mail、RFC 6376）は、送信サーバーがメールのヘッダーと本文に電子署名を付与し、受信サーバーが DNS 上の公開鍵で署名を検証する仕組みです。セレクターという識別子を使って複数の鍵を共存させられます。

セレクター名はメール送信サービスの管理画面で確認できます。Google Workspace は google、Microsoft 365 は selector1・selector2、SendGrid は s1・s2 が一般的です。多くのサービスでは、管理画面のセットアップウィザードに従って DNS に CNAME レコードを追加するだけで DKIM の設定が完了します。

チェック項目

  • {selector}._domainkey.example.com に TXT レコードが存在する
  • レコードの値が v=DKIM1 で始まっている
  • p= フィールドに Base64 エンコードされた公開鍵が含まれている（p= が空だと鍵が取り消された状態を意味する）
  • メール送信サービスの管理画面に表示されているセレクター名と、DNS に設定したセレクター名が一致している

確認コマンド

google セレクターの場合の例です。

dig TXT google._domainkey.example.com +short
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

レコードが返らない場合は、セレクター名が間違っているか、DNS への反映が完了していません。

labee.dev の API では selector パラメーターで特定のセレクターを指定できます。

curl "https://labee.dev/api/mail-auth?domain=example.com&selector=google"
{
  "success": true,
  "data": {
    "spf": {
      "record": "v=spf1 include:_spf.google.com ~all",
      "exists": true
    },
    "dkim": {
      "mode": "explicit",
      "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...",
      "exists": true,
      "selector": "google"
    },
    "dmarc": { "record": null, "exists": false, "source": null, "domain": "example.com" },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 98 }
}

data.dkim.exists が true で、data.dkim.selector が指定したセレクターと一致していることを確認してください。selector パラメーターを省略した場合、API は 18 種の一般的なセレクター候補を自動検出します。

Step 3 DMARC ポリシーを確認する

DMARC（Domain-based Message Authentication, Reporting and Conformance、RFC 7489）は、SPF と DKIM の検証結果に基づいて、認証失敗メールの処理方法を受信サーバーに指示するポリシーです。2024年2月以降、Gmail は1日 5,000通以上 送信するドメインに DMARC 設定を必須としています。

チェック項目

  • _dmarc.example.com に TXT レコードが存在する
  • レコードの値が v=DMARC1 で始まっている
  • p= に none・quarantine・reject のいずれかが設定されている
  • rua= でレポート受信先メールアドレスが指定されている（例: rua=mailto:dmarc-reports@example.com）

確認コマンド

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

レコードが存在しない場合、DMARC が未設定です。p=none でも Gmail の送信者要件は満たしますが、なりすまし防止の観点では p=quarantine または p=reject への移行が推奨されています。

labee.dev の API でも確認できます。

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": null,
      "exists": false,
      "selector": "",
      "matches": [],
      "checkedSelectors": ["google", "selector1", "selector2", "s1", "s2", "k1", "k2", "k3", "default", "dkim", "mail", "smtp", "mte1", "mte2", "pdk1", "pdk2", "mesmtp", "zoho"],
      "exhaustive": false
    },
    "dmarc": {
      "record": "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com",
      "exists": true,
      "source": "exact",
      "domain": "example.com"
    },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 115 }
}

data.dmarc.exists が true であることを確認してください。data.dmarc.source が organizational の場合、サブドメイン自体にはレコードがなく親ドメインのポリシーを継承しています。サブドメイン固有のポリシーが必要な場合は _dmarc.sub.example.com に個別のレコードを設定してください。

Step 4 MX レコードを確認する

MX（Mail Exchanger）レコードは、そのドメイン宛のメールをどのサーバーが受け取るかを指定します。MX レコードが存在しない、または間違ったホスト名を指していると、送信側のメールサーバーが配送先を見つけられずメールが返送されます。

チェック項目

  • MX レコードが存在する
  • 宛先ホスト名が正しいメールサーバーを指している（Google Workspace なら aspmx.l.google.com など）
  • 優先度（priority）が意図どおりに設定されている（数値が小さいほど優先度が高い）

確認コマンド

dig MX example.com +short
10 aspmx.l.google.com.
20 alt1.aspmx.l.google.com.

MX レコードが返らない場合、ドメイン宛のメールは配送できません。ホスト名の末尾にドット（.）が付くのは DNS の正規表記です。

labee.dev の DNS API で MX レコードを取得できます。

curl "https://labee.dev/api/dns?domain=example.com&type=MX"
{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "MX": [
        { "priority": 10, "exchange": "aspmx.l.google.com" },
        { "priority": 20, "exchange": "alt1.aspmx.l.google.com" }
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 85 }
}

data.records.MX 配列に正しいメールサーバーのホスト名が含まれていることを確認してください。

Step 5 逆引き DNS（PTR）と FCrDNS を確認する

逆引き DNS（PTR レコード）は、IP アドレスからホスト名を引く仕組みです。受信サーバーは送信元 IP の PTR レコードを確認し、PTR が未設定の IP からのメールをスパムとして扱います。Gmail は送信者ガイドラインで PTR レコードの設定を求めており、未設定の IP からのメールは配送を制限します。

Google Workspace、Microsoft 365、SendGrid、Amazon SES などのマネージドサービスを利用している場合は、PTR レコードはサービス側で管理されています。このステップの確認が必要なのは、自前のサーバーからメールを送信している場合です。

FCrDNS（Forward-Confirmed reverse DNS）は、PTR で得られたホスト名を正引き（A レコード）して元の IP に一致するかを検証する仕組みです。PTR が設定されていても、正引きで IP が一致しなければ FCrDNS は失敗します。

チェック項目

  • 送信サーバーの IP アドレスに PTR レコードが設定されている
  • PTR レコードで返るホスト名の A レコードが元の IP アドレスに一致する（FCrDNS が成立する）

確認コマンド

送信 IP が 203.0.113.1 の場合の例です。

dig -x 203.0.113.1 +short
mail.example.com.

PTR レコードが返ったら、そのホスト名を正引きして IP が一致するかを確認します。

dig A mail.example.com +short
203.0.113.1

PTR の結果と A レコードの結果が一致すれば、FCrDNS は成立しています。

labee.dev の IP API で PTR レコードを確認できます。

curl "https://labee.dev/api/ip?ip=203.0.113.1"
{
  "success": true,
  "data": {
    "ip": "203.0.113.1",
    "type": "IPv4",
    "isPrivate": false,
    "ptr": "mail.example.com"
  },
  "error": null,
  "meta": { "responseTime": 65 }
}

data.ptr にホスト名が返っていれば PTR レコードは設定されています。null の場合は PTR が未設定です。FCrDNS の正引き検証は、追加で DNS API を使って確認できます。

curl "https://labee.dev/api/dns?domain=mail.example.com&type=A"
{
  "success": true,
  "data": {
    "domain": "mail.example.com",
    "records": {
      "A": [
        { "address": "203.0.113.1", "ttl": 300 }
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 42 }
}

data.records.A[0].address が元の送信 IP と一致していれば FCrDNS は成立しています。

Step 6 DNSBL（ブロックリスト）を確認する

DNSBL（DNS-based Blocklist）は、スパム送信に使われた IP アドレスをリスト化したデータベースです。受信サーバーは送信元 IP を DNSBL に照会し、リストに登録されていればメールを拒否または迷惑メールに分類します。自分のサーバーの IP が意図せず登録されていると、設定が正しくてもメールが届かなくなります。

コマンド操作に慣れていない場合は、Spamhaus のウェブサイト（https://www.spamhaus.org/lookup/）で送信 IP を直接検索する方法もあります。

チェック項目

  • 送信サーバーの IP アドレスが主要な DNSBL（Spamhaus ZEN、Barracuda、SpamCop など）に登録されていない

確認コマンド

DNSBL の照会は、IP アドレスのオクテットを逆順にして DNSBL のドメインに付加した名前を引きます。送信 IP が 203.0.113.1 で Spamhaus ZEN を確認する場合の例です。

Spamhaus は公開 DNS リゾルバー（Google Public DNS 等の公開リゾルバー）経由のクエリーを段階的に廃止しており、2025年以降は Data Query Service（DQS）への移行が必要です。無料の DQS アカウントを登録すると、専用のクエリードメイン（{key}.zen.dq.spamhaus.net）が発行されます。従来の zen.spamhaus.org を使ったクエリーは、公開リゾルバー経由ではエラーコード 127.255.255.254 を返すようになっています。

# DQS を利用する場合（推奨）
dig 1.113.0.203.{your-key}.zen.dq.spamhaus.net +short

# 従来形式（公開リゾルバー経由では正確な結果を返さない場合あり）
dig 1.113.0.203.zen.spamhaus.org +short

応答がなければ（空行が返れば）リストに登録されていません。127.0.0.x 形式の応答が返った場合は登録されています。返された IP の末尾のオクテットによってリストの種類がわかります（Spamhaus の場合、127.0.0.2 は SBL、127.0.0.4 は CBL など）。127.255.255.254 が返った場合は、クエリーが制限されていることを意味します。DQS への移行を検討してください。

登録されていた場合は、各 DNSBL の解除申請ページから削除リクエストを送信してください。Spamhaus は https://www.spamhaus.org/lookup/ から確認と解除申請ができます。

用語解説DNSBL（DNS Blocklist）スパム送信元の IP アドレスを DNS で公開し、受信サーバーがリアルタイムで参照するブロックリスト。Spamhaus が代表的なプロバイダー。labee.dev

Step 7 送信者レピュテーションを確認する

送信者レピュテーションは、IP アドレスやドメインに対する受信サーバー側の信頼度スコアです。迷惑メール報告の割合、バウンス率、送信量の急激な変化などが評価に影響します。レピュテーションが低下すると、SPF・DKIM・DMARC がすべて正しく設定されていてもメールが迷惑メールフォルダーに振り分けられます。

チェック項目

  • Google Postmaster Tools でドメインレピュテーションが Low / Bad になっていない
  • ハードバウンス率が 2% 未満に収まっている
  • 迷惑メール報告率が 0.10% 未満を維持している（Gmail の送信者ガイドラインでは推奨 0.10% 未満、上限 0.30%）

確認方法

Google Postmaster Tools（https://postmaster.google.com/）にドメインを登録すると、Gmail が受信したメールの認証結果、レピュテーション、暗号化率などを確認できます。登録にはドメインの DNS に TXT レコードを追加して所有権を証明する必要があります。

レピュテーションが低下している場合は、以下を確認してください。

  • 無効なアドレスへの送信を止める（バウンスしたアドレスをリストから削除する）
  • 配信停止リンクが正しく機能しているか確認する
  • 送信量を急激に増やしていないか確認する（新しい IP やドメインから大量送信すると、IP ウォームアップが不足してスパム判定されやすくなる）
用語解説送信者レピュテーション（Sender Reputation）メール送信元の IP アドレスやドメインに対する信頼度スコア。スコアが低いと Gmail 等で迷惑メールに分類される。labee.dev 用語解説ハードバウンス（Hard Bounce）宛先不明やドメイン不存在など永続的な原因でメールが配信できない状態。放置すると送信者レピュテーションが低下する。labee.dev 用語解説ソフトバウンス（Soft Bounce）メールボックス容量超過やサーバー一時障害など、一時的な原因で配信が失敗する現象。繰り返し発生するとハードバウンスに昇格する。labee.dev

Step 8 メールサーバーの TLS を確認する

STARTTLS は、メールサーバー間の SMTP 通信を途中から TLS 暗号化に切り替える仕組みです（RFC 3207）。Gmail は STARTTLS に対応していないサーバーからのメールに対して、受信者の画面に「暗号化されていません」という警告アイコンを表示します。証明書の有効期限が切れている場合、TLS ネゴシエーションが失敗して平文通信にフォールバックします。

Google Workspace、Microsoft 365 などのマネージドメールサービスでは STARTTLS は標準で有効になっています。このステップの確認が必要なのは、自前のメールサーバーを運用している場合です。

チェック項目

  • メールサーバーが STARTTLS に対応している
  • TLS 証明書の有効期限が切れていない

確認コマンド

openssl s_client -starttls smtp -connect mail.example.com:25 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3

接続が確立されれば STARTTLS は有効です。CONNECTION ESTABLISHED が表示されない場合、STARTTLS に対応していないか、ポート 25 へのアウトバウンド通信がブロックされています。

証明書の有効期限は以下のコマンドで確認できます。

openssl s_client -starttls smtp -connect mail.example.com:25 2>/dev/null | openssl x509 -noout -dates
notBefore=Jan  1 00:00:00 2025 GMT
notAfter=Apr  1 00:00:00 2026 GMT

notAfter の日付が現在より過去であれば証明書は期限切れです。

用語解説STARTTLS既存の平文プロトコルを TLS 暗号化にアップグレードする SMTP 拡張コマンド。メール配送経路の暗号化に広く使われる。labee.dev

よくある設定ミス

SPF レコードが複数存在する

同一ドメインに v=spf1 で始まる TXT レコードが 2件以上あると、RFC 7208 の規定により受信サーバーはチェック結果を permerror として扱います。複数のメール送信サービスを利用している場合は、include: を 1つのレコード内に並べてください。

v=spf1 include:_spf.google.com include:sendgrid.net ~all

DKIM セレクターが DNS に登録されていない

メール送信サービスの管理画面で DKIM を有効化しても、DNS に TXT レコードを追加しなければ受信サーバーは公開鍵を取得できません。サービス側で生成されたセレクター名と、DNS に登録した {selector}._domainkey.example.com のセレクター部分が一致しているかも確認してください。

PTR レコードが未設定のまま送信している

VPS やクラウドサーバーを自前で運用してメールを送信している場合、PTR レコードの設定はホスティング事業者の管理画面から行います。初期状態では PTR が設定されていないことが多く、そのままメールを送信すると Gmail などで拒否されます。Google Workspace、Microsoft 365、SendGrid、Amazon SES などのマネージドメール送信サービスを利用している場合は、サービス側の IP に PTR が設定されているため、この問題は発生しません。

DMARC の rua を設定していない

rua= がないと集計レポートが届かないため、自ドメインを騙ったなりすましメールの検知ができません。p=none で運用を開始する段階でも rua= は設定してください。レポートは XML 形式で届くため、dmarcian、Postmark DMARC、EasyDMARC などの解析サービスを使うと内容を確認しやすくなります。

バウンスしたアドレスに送り続けている

存在しないアドレスへの送信（ハードバウンス）を繰り返すと、送信者レピュテーションが低下します。メール配信サービスのバウンスログを定期的に確認し、ハードバウンスが発生したアドレスはリストから削除してください。

実際のドメインで確認してみる

登録不要、無料です。

無料で試す

Pro プラン（準備中）

DNS 変更の自動検知・SSL 期限アラート・複数ドメイン管理など、継続して確認し続けるための機能を準備中です。

関連ガイド

チェックリスト 初級

メール認証 完全チェックリスト

SPF・DKIM・DMARC の設定状況を一つずつ確認できるチェックリストです。Gmail / Outlook の送信者認証に対応するための最低限の項目をまとめています。

初級 ・ 10分
チェックリスト 初級

複数ドメイン管理の運用チェックリスト — 見落としゼロを目指す定期確認フロー

5〜20 個のドメインを管理する組織向けに、DNS・SSL・メール認証の定期確認フローをまとめたチェックリストです。curl と jq を使ったバッチ確認スクリプト例も紹介します。

初級 ・ 10分
ガイド 中級

DMARC ポリシー段階的移行ガイド — p=none から p=reject へ安全に移行する手順

DMARC ポリシーを p=none から p=quarantine、p=reject へ段階的に移行する手順を解説します。pct タグを使った段階適用、集計レポートの読み方、移行判断の基準をステップごとにまとめています。

中級 ・ 15分
コンテンツ 技術ノート ガイド 用語解説
ツール ツール一覧 API Reference
Labee 日本語トップ Labee LLC
© 2026 Labee LLC . All rights reserved.
ホーム ブログ ガイド 用語集