SPF・DKIM・DMARC を外部から確認する方法 — dig と API で設定漏れを検出する

SPF・DKIM・DMARC はメール認証の 3 要素ですが、手元の dig コマンドだけでは設定漏れに気づけないケースがあります。この記事では、dig による確認手順とその限界を整理し、外部 API を使って 3 要素をまとめて検証する方法を解説します。

メール認証はなぜ「外から」確認する必要があるのか

SPF（RFC 7208）・DKIM（RFC 6376）・DMARC（RFC 7489）は、送信元ドメインの正当性を受信サーバーが検証するための仕組みです。設定はすべて DNS の TXT レコードとして公開されますが、手元の dig コマンドで確認した結果が、Gmail や Microsoft 365 のサーバーから見た結果と一致するとは限りません。

ローカルのリゾルバーにはキャッシュがあり、TTL が切れるまで古い値を返し続けます。レコードを変更した直後に dig で確認しても、変更前の値が返ってくることがあります。

SPF だけ設定して DKIM や DMARC が未設定のケースでは、dig の結果だけを見ると「設定済み」と判断してしまいがちです。受信サーバーは 3 つすべてを評価するため、一部の欠落がメール到達率に直接影響します。

dig で確認する手順と限界

手元で各レコードを確認するには、以下のコマンドを使います。example.com を自分のドメインに置き換えて実行してみてください。

SPF レコード

dig TXT example.com +short

"v=spf1 include:_spf.google.com ~all"

ドメイン直下の TXT レコードから v=spf1 で始まるものが SPF レコードです。

DKIM レコード

dig TXT default._domainkey.example.com +short

DKIM は {セレクター}._domainkey.{ドメイン} の形式で問い合わせます。何も返らない場合は、セレクター名が間違っているか、DKIM が未設定です。セレクター名はメールサービスによって異なり、Google Workspace は google、Microsoft 365 は selector1 / selector2 を使います。正しいセレクター名を知らないと確認自体ができません。

DMARC レコード

dig TXT _dmarc.example.com +short

"v=DMARC1; p=none; rua=mailto:dmarc@example.com"

_dmarc.{ドメイン} の TXT レコードが DMARC ポリシーです。

dig の限界

この方法には 3 つの問題があります。

• ローカルキャッシュの影響を受けるため、DNS を変更した直後の確認には向かない
• SPF・DKIM・DMARC を個別にコマンドを打って確認する必要がある
• DKIM のセレクター名を事前に知っていないと確認できない

dig は「レコードが存在するか」を確認する手段であり、「外部の受信サーバーからどう見えるか」を確認する手段ではありません。

外部 API を使ってまとめて確認する

Labee Dev Toolbox のメール認証 API は、外部のパブリックリゾルバーを使ってレコードを取得します。ローカルのキャッシュや社内 DNS を経由しません。example.com を自分のドメインに置き換えて実行してみてください。

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@example.com",
      "exists": true
    },
    "bimi": {
      "record": null,
      "exists": false
    }
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

1 回のリクエストで SPF・DKIM・DMARC・BIMI の 4 項目が返ります。"exists": false の項目があれば、その設定が外部から確認できない状態です。

DKIM の自動セレクター検索

DKIM はセレクターを省略すると mode: "auto" で動作します。API は google、selector1、selector2、s1、s2、k1 など 12 種類 のセレクター候補を自動的に検索し、一致したものを matches 配列に返します。selector フィールドには最初に見つかったセレクター名が入ります。

"exhaustive": false が示すとおり、すべてのセレクターを網羅しているわけではありません。独自のセレクター名を使っている場合は selector パラメーターで明示的に指定します。

curl "https://labee.dev/api/mail-auth?domain=example.com&selector=mykey"

{
  "success": true,
  "data": {
    "spf": {
      "record": "v=spf1 include:_spf.google.com ~all",
      "exists": true
    },
    "dkim": {
      "mode": "explicit",
      "record": null,
      "exists": false,
      "selector": "mykey"
    },
    "dmarc": {
      "record": "v=DMARC1; p=none; rua=mailto:dmarc@example.com",
      "exists": true
    },
    "bimi": {
      "record": null,
      "exists": false
    }
  },
  "error": null,
  "meta": { "responseTime": 85 }
}

mode: "explicit" の場合、指定したセレクターのみを検索します。matches や checkedSelectors は返りません。

Gmail のバルクセンダー要件と照合する

Google のメール送信者のガイドラインでは、2024 年 2 月 1 日以降、個人用 Gmail アカウントへ 1 日あたり 5,000 件を超えるメールを送信するドメインに対して、SPF・DKIM・DMARC の 3 つすべての設定を要求しています。同一プライマリドメインから送信されたメールが合算でカウントされるため、サブドメインからの送信も含まれます。

要件をまとめると次のとおりです。

• SPF と DKIM の両方を設定する（どちらか一方だけでは不可）
• DMARC を設定する（ポリシーは p=none でも可）
• DMARC のアライメントは SPF または DKIM のいずれかが合致していれば通過する
• 送信ドメインまたは IP に正引き・逆引きの DNS レコード（PTR）が存在する
• Postmaster Tools で報告されるスパム率を 0.3% 未満に維持する

3 つのうち 1 つでも欠けていると、メールが迷惑メールに分類されるか拒否されます。

よくある設定漏れ

dig の結果と照合して、以下のパターンに該当していないか確認します。

• dig TXT example.com +short で v=spf1 が返るが、dig TXT google._domainkey.example.com +short が空。セレクター名の不一致か DKIM 未設定の可能性があります
• dig TXT _dmarc.example.com +short が空。DMARC の TXT レコードが登録されていません
• DMARC レコードに p=none が含まれている。バルクセンダー要件は p=none で通過しますが、なりすまし防止の効果はありません。運用が安定したら p=quarantine か p=reject への移行が有効です
• SPF レコードの include が多すぎる。RFC 7208 では DNS ルックアップの上限が 10 回 と定められており、include のネストが深いと超過します。dig TXT で SPF レコードを取得して include の数を確認してください

API のレスポンスでも同じ内容を確認できます。exists が false の項目は dig で空だった項目に対応します。

確認を CI に組み込む（開発者向け）

開発チームでドメインを管理している場合は、手動確認に頼らず CI で定期的にチェックすると安全です。

result=$(curl -fsS "https://labee.dev/api/mail-auth?domain=example.com")
spf=$(echo "$result" | jq -r '.data.spf.exists')
dkim=$(echo "$result" | jq -r '.data.dkim.exists')
dmarc=$(echo "$result" | jq -r '.data.dmarc.exists')

if [ "$spf" != "true" ] || [ "$dkim" != "true" ] || [ "$dmarc" != "true" ]; then
  echo "Mail auth check failed: SPF=$spf DKIM=$dkim DMARC=$dmarc"
  exit 1
fi

API キーは不要なので、Secrets の設定なしで動きます。GitHub Actions の cron: '0 9 * * 1' で週次実行しておけば、設定の欠落や意図しない変更を早期に検出できます。

送信元 IP の逆引き（PTR レコード）もメール到達率に影響します。PTR と FCrDNS の確認方法は次の記事を参照してください。

技術ノートIP アドレスから何がわかるか — dig と curl で種別・逆引き・プライベート判定を読み解くIP アドレスを調べると、IPv4/IPv6 の種別、PTR レコードによる逆引きホスト名（FCrDNS）、グローバル IP かプライベート IP かがわかります。dig -x と Labee IP API を使った確認手順を解説します。

SPF・DKIM・DMARC を一つずつ確認する手順はこちらにまとめています。

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

ブラウザーから確認する場合は Labee Dev Toolbox のメール認証チェック画面にドメインを入力すると、SPF・DKIM・DMARC・BIMI の状態を GUI で確認できます。