Labee Dev Toolbox
技術ノートガイド用語解説
無料で試す
  1. ホーム
  2. / ガイド
  3. / メール認証 完全チェックリスト
チェックリスト 初級

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

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

2024年2月以降、Gmail は1日5,000通以上を送信するドメインに対して SPF・DKIM・DMARC のすべてを必須としています。Outlook（Microsoft 365）も同様に未認証メールの拒否を強化しています。このチェックリストは、自分のドメインがこれらの要件を満たしているかを順番に確認するためのものです。

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

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

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

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

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

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

### DMARC
- [ ] `_dmarc.example.com` に TXT レコードが存在する
  - `dig TXT _dmarc.example.com +short`
- [ ] レコードが `v=DMARC1` で始まっている
- [ ] `p=` に none・quarantine・reject のいずれかが設定されている
- [ ] `rua=` でレポート受信先が指定されている
- [ ] SPF または DKIM の少なくとも一方がアライメントを通過している

### BIMI（任意）
- [ ] `default._bimi.example.com` に TXT レコードが存在する
  - `dig TXT default._bimi.example.com +short`
- [ ] レコードが `v=BIMI1` で始まっている
- [ ] `l=` に SVG ロゴの URL が設定されている
- [ ] VMC または CMC を取得済みで、PEM ファイルを HTTPS サーバーに配置している
- [ ] `a=` に PEM ファイルの URL が設定されている
- [ ] DMARC ポリシーが `p=quarantine` または `p=reject` になっている

### 一括確認（API）
- `curl "https://labee.dev/api/mail-auth?domain=example.com"`
- `curl "https://labee.dev/api/mail-auth?domain=example.com&selector=google"`

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

SPF（Sender Policy Framework）は、そのドメインからメールを送信できるサーバーを DNS に列挙する仕組みです。受信サーバーはメールの送信元 IP を SPF レコードと照合し、許可されていない IP からのメールを弾きます。

チェック項目

  • example.com の TXT レコードに v=spf1 で始まるレコードが存在する
  • include: に利用中のメール送信サービス（Google Workspace なら _spf.google.com、SendGrid なら sendgrid.net など）が含まれている
  • レコードの末尾が ~all（ソフトフェイル）または -all（ハードフェイル）で終わっている
  • SPF レコードが 1件だけ 存在する（同一ドメインに複数の SPF レコードがあると 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 で、data.spf.record の内容が dig の結果と一致していることを確認してください。

Step 2 DKIM レコードを確認する

DKIM（DomainKeys Identified Mail）は、送信サーバーがメールのヘッダーと本文に電子署名を付与し、受信サーバーが DNS に公開された公開鍵で検証する仕組みです。セレクターと呼ばれる識別子を使って複数の公開鍵を共存させられるため、Google Workspace、SendGrid、Amazon SES など複数サービスを併用する場合も、それぞれ別のセレクターで設定します。

セレクター名はメール送信サービスの管理画面で確認できます。Google Workspace では google、Microsoft 365 は selector1・selector2、SendGrid は s1・s2、Mailchimp は mte1・mte2、Mailgun は pdk1・pdk2 が一般的です。

チェック項目

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

確認コマンド

google セレクターの場合を例として示します。

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

レコードが返らない場合は、セレクター名が間違っているか、DNS への反映が完了していません。TTL が短い場合でも伝播には最大 48時間 かかることがあります。

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 は一般的なセレクター候補（google, selector1, s1, mte1, pdk1 など 18 種）を自動検出します。特定のセレクターを確認したい場合は明示的に指定してください。

Step 3 DMARC レコードを確認する

DMARC（Domain-based Message Authentication, Reporting and Conformance）は、SPF と DKIM の検証結果を基に、認証失敗メールをどう処理するかを受信サーバーに指示するポリシーです。レポート機能（rua、ruf）により、自ドメインを使った不正送信の検知にも使えます。

ポリシーは3段階あります。p=none は何もせず監視のみ、p=quarantine は迷惑メールフォルダーに振り分け、p=reject は完全に拒否します。Gmail の送信者要件では p=none でも要件を満たしますが、最終的には p=quarantine または p=reject への移行を推奨しています。

チェック項目

  • _dmarc.example.com に TXT レコードが存在する
  • レコードの値が v=DMARC1 で始まっている
  • p= に none・quarantine・reject のいずれかが設定されている
  • rua= でレポート受信先メールアドレスが指定されている（例: rua=mailto:dmarc-reports@example.com）
  • SPF または DKIM の少なくとも一方が当該ドメインでアライメントを通過している（DMARC はどちらかひとつのアライメント一致で通過する）

確認コマンド

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

labee.dev の API では、DMARC も同じエンドポイントで取得できます。

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.record の p= 値が意図したポリシーと一致していることを確認してください。data.dmarc.source はレコードの取得元を示します。exact は入力ドメインに直接設定されたレコード、organizational はサブドメインにレコードがなく親ドメイン（組織ドメイン）から継承されたことを意味します。

Step 4 BIMI レコードを確認する（任意）

BIMI（Brand Indicators for Message Identification）は、DMARC でメールが認証された場合に受信クライアントのブランドロゴを表示する拡張仕様です。Gmail や Apple Mail、Yahoo Mail が対応しています。BIMI を有効にするには DMARC ポリシーが p=quarantine または p=reject である必要があります。p=none では動作しません。

Gmail でロゴを表示するには VMC（Verified Mark Certificate） または CMC（Common Mark Certificate） のどちらかが必要です。VMC は商標登録済みのロゴに対して発行され、Gmail では青いチェックマーク（認証バッジ）も表示されます。CMC は商標登録がなくても取得でき（ロゴの使用実績が12ヶ月以上必要）、Gmail でのロゴ表示は可能ですがチェックマークは付きません。Yahoo Mail は例外として証明書なしでもロゴが表示されますが、Gmail や Apple Mail では証明書がなければ BIMI レコードを設定してもロゴは表示されません。

VMC・CMC は DigiCert や Entrust などの認証局から取得できます。費用は CMC が年額 $650 前後、VMC が年額 $1,200〜$1,500 程度です。取得後、PEM 形式の証明書ファイルを HTTPS サーバーに配置し、BIMI レコードの a= タグにその URL を設定します。

チェック項目

  • default._bimi.example.com に TXT レコードが存在する
  • レコードの値が v=BIMI1 で始まっている
  • l= に SVG フォーマットのロゴ URL が設定されている
  • VMC または CMC を取得済みで、PEM ファイルを HTTPS サーバーに配置している
  • a= タグに PEM ファイルの URL が設定されている
  • DMARC ポリシーが p=quarantine または p=reject になっている

確認コマンド

dig TXT default._bimi.example.com +short
"v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/cert.pem"

labee.dev の API では BIMI も同時に確認できます。

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=MIIBIjAN...",
      "exists": true,
      "selector": "google",
      "matches": [
        { "selector": "google", "record": "v=DKIM1; k=rsa; p=MIIBIjAN...", "exists": true }
      ],
      "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=reject; rua=mailto:dmarc-reports@example.com", "exists": true, "source": "exact", "domain": "example.com" },
    "bimi": {
      "record": "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/cert.pem",
      "exists": true
    }
  },
  "error": null,
  "meta": { "responseTime": 132 }
}

data.bimi.exists が true で、data.bimi.record の l= に正しい SVG URL が設定されていることを確認してください。

よくある設定ミス

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

同一ドメインに v=spf1 で始まる TXT レコードが2件以上あると、RFC 7208 の規定により受信サーバーはチェックを失敗（permerror）として扱います。複数のサービスを追加したい場合は include: を1つのレコード内に並べます。

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

DKIM セレクターが DNS に存在しない

メール送信サービスの管理画面でセレクターを生成しても、DNS に TXT レコードを登録しないと有効になりません。セレクターの登録先は {selector}._domainkey.example.com です。dig で確認してレコードが返らない場合は、DNS プロバイダーの管理画面で TXT レコードを追加してください。

DMARC の rua= を設定していない

rua= がないと、受信サーバーからの集計レポートが届かないため、なりすましメールの検知ができません。ポリシーを p=none で運用開始する段階でも rua= は必ず設定してください。レポートは XML 形式で送られるため、専用の解析サービス（dmarcian、Postmark など）を使うと読みやすくなります。

DNS の変更がまだ伝播していない

TTL を短く設定していても、DNS の変更は世界中のリゾルバーに伝播するまで最大 48時間 かかります。変更直後に dig や API で確認しても古い値が返る場合があります。TTL の値を確認し、その時間が経過した後に再度チェックしてください。

発展的なトピック

SPF・DKIM・DMARC・BIMI を設定したら、次は送信経路の暗号化やポリシーの段階的な適用も視野に入ってきます。以下のトピックはこのチェックリストでは扱っていませんが、メール配送のセキュリティをさらに強化する際に役立ちます。

MTA-STS（RFC 8461）

メール送信サーバーに TLS 暗号化と証明書検証を強制し、SMTP のダウングレード攻撃を防ぐ仕組みです。STARTTLS は暗号化をネゴシエーションできなければ平文にフォールバックしますが、MTA-STS を設定すると受信サーバーが TLS を必須として宣言できます。

用語解説MTA-STS（Mail Transfer Agent Strict Transport Security）メール送信サーバーに TLS 暗号化の強制と証明書検証を要求し、SMTP のダウングレード攻撃を防ぐ仕組み。RFC 8461 で標準化。labee.dev

TLS-RPT（RFC 8460）

メール送信サーバーが受信ドメインとの TLS 接続で発生したエラーを JSON レポートとして報告する仕組みです。MTA-STS と併用することで、証明書の問題や設定ミスによる配送失敗を早期に発見できます。DMARC の rua= と同様に、DNS の TXT レコードでレポート送信先を指定します。

用語解説TLS-RPT（SMTP TLS Reporting）メール配送時の TLS 接続エラーを送信サーバーが受信ドメインに報告する仕組み。MTA-STS と併用して暗号化の監視に使う。labee.dev

DMARC の pct パラメーター（RFC 7489）

DMARC レコードの pct= タグは、認証に失敗したメールのうち何パーセントにポリシーを適用するかを制御します。p=none から p=reject へ一気に切り替えると正規メールが拒否されるリスクがあるため、pct=10 → pct=50 → pct=100 のように段階的にポリシーを強化する運用で使います。

用語解説pct タグ（Percentage）DMARC レコードの pct タグで、ポリシー適用割合をパーセンテージで指定する設定。段階的なポリシー強化に使う。labee.dev

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

登録不要、無料です。

無料で試す

Pro プラン（準備中）

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

関連ガイド

チェックリスト 初級

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

メールが届かない・迷惑メールに振り分けられる時に、どこから確認すればいいかをステップごとにまとめたチェックリストです。SPF・DKIM・DMARC の確認から、逆引き DNS、ブロックリスト、送信者レピュテーションまで順番に切り分けられます。

初級 ・ 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.
ホーム ブログ ガイド 用語集