SPF・DMARC・DKIMの設定確認手順｜メール認証を正しく構成するガイド

「設定したはずなのにメールが届かない」を防ぐ

SPFやDMARCは「一度設定すれば終わり」と思いがちですが、DNS編集のたびに壊れるリスクがあります。特に制作会社が複数クライアントのドメインを管理している場合、新しいメール送信サービスの追加やDNSゾーン移行の際に認証レコードが崩れていても、気づくのはクライアントから「メールが届かない」と言われてからがほとんどです。

本記事では、SPF・DMARC・DKIM・MXの正しい設定内容と確認手順を解説します。既存設定が正しいかチェックするコマンドも掲載しているので、初期設定時・引き継ぎ時・定期点検時にそのまま使えます。

メール認証の4タイプを理解する

4タイプはそれぞれ独立しており、SPFが通っていてもDMARCポリシーが壊れていればメールが迷惑メール扱いになるケースがあります。

SPFの正しい設定

基本構文

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

• v=spf1 — バージョン宣言。必ず先頭に置く
• include: — 外部の送信サーバーを信頼する
• ~all — リストにないサーバーからの送信は「ソフト失敗」扱い（推奨）
• -all — リストにないサーバーからの送信は「ハード失敗」（厳格にしたい場合）

よくある設定ミス

SPF の確認コマンド

# TXT レコードのうち v=spf1 で始まるものを抽出
dig +short TXT example.com | grep 'v=spf1'

# 返ってくるレコードが 1 件のみであることを確認
# 2 件以上ある場合は即座に是正が必要

DMARCの正しい設定

基本構文

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

• v=DMARC1 — バージョン宣言
• p= — ポリシー。none（監視のみ）→ quarantine（迷惑メールフォルダ）→ reject（拒否）の順に厳格化
• rua= — 集計レポートの送信先（mailto: URI）
• pct= — ポリシーを適用するメールの割合（0〜100）

よくある設定ミス

DMARCの確認コマンド

# DMARC レコードを確認
dig +short TXT _dmarc.example.com

# p= タグが含まれているか確認
dig +short TXT _dmarc.example.com | grep 'p='

p=none の場合はポリシーが「監視のみ」です。メール認証が安定したら p=quarantine → p=reject に段階的に強化しましょう。

DKIMの正しい設定

基本構文（公開鍵レコード）

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

• v=DKIM1 — バージョン宣言
• k=rsa — 鍵アルゴリズム（通常は省略可）
• p= — Base64 エンコードされた公開鍵（空の場合は「鍵失効」扱い）

セレクタの確認方法

DKIMのセレクタ名はメール送信サービスごとに異なります。代表的なサービスのセレクタ名は以下のとおりです。

# セレクタが "google" の場合の DKIM 公開鍵確認
dig +short TXT google._domainkey.example.com

# 返ってきたレコードに v=DKIM1 と p=<公開鍵文字列> が含まれていれば有効

よくある設定ミス

MXの確認

# MX レコードと優先度を確認
dig +short MX example.com

# 例: 10 aspmx.l.google.com.
#     20 alt1.aspmx.l.google.com.

MXレコードが返ってこない、または一時的なサブドメインを指したままの場合はメール受信ができません。ドメイン移行やテスト後に元の MX に戻し忘れていないか確認してください。

4タイプをまとめてチェックするスクリプト

新規クライアントの受け入れ時や定期点検時に使えるシェルスクリプトです。

#!/bin/bash
# 引数: ドメイン名（例: ./check-mail-auth.sh example.com）
DOMAIN="${1:?ドメイン名を指定してください}"
SELECTOR="${2:-google}"

echo "=== MX ==="
dig +short MX "$DOMAIN"

echo "=== SPF ==="
dig +short TXT "$DOMAIN" | grep 'v=spf1'

echo "=== DMARC ==="
dig +short TXT "_dmarc.$DOMAIN"

echo "=== DKIM (セレクタ: $SELECTOR) ==="
dig +short TXT "${SELECTOR}._domainkey.$DOMAIN"

このスクリプトで出力を目視確認したあと、各タイプを Miterl に登録すれば以降は変更を自動検知できます。

設定後は継続監視に切り替える

初回設定が正しくても、以下のタイミングで再び壊れるリスクがあります。

• 新しいメール送信 SaaS を追加して include: を増やしたとき（SPF lookup 超過）
• DNS ゾーン移行後に認証レコードが引き継がれなかったとき
• メール送信ツールのセレクタが自動ローテーションされたとき

このような「気づかない壊れ方」を検知するために、Miterl の監視を活用してください。HTTP 監視や SSL 監視と同じ API で MX / SPF / DMARC / DKIM を登録できます。

# SPF 監視を登録する例（構文ルールまで自動検証）
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "example.com SPF",
    "type": "spf",
    "url": "example.com",
    "interval_seconds": 300
  }'

RFC 7208 の lookup 上限超過や複数 SPF レコードの検出など、人手では気づきにくい構文エラーも自動で Down 扱いになります。詳しい設定方法は「SPF・DMARC・DKIM・MXを常時監視する方法」をご覧ください。

制作会社の保守メニューにメール認証監視を組み込む際の運用フローは「SPF・DMARC・DKIM・MXを常時監視する方法」の「制作会社向けの運用フロー例」セクションが参考になります。

まとめ

• SPF: v=spf1 で始まる TXT レコードを apex ドメインに 1 件だけ設定し、lookup 上限（10 回）を超えないようにする
• DMARC: _dmarc.<ドメイン> に p= タグ必須。まず p=none で様子を見て段階的に強化
• DKIM: セレクタ切替時は旧・新両方の公開鍵が DNS に存在することを確認してから切り替える
• MX: 移行後に一時的な MX に戻し忘れていないかを定期確認

設定が正しくできたら、Miterl で常時監視に切り替えることで「気づかない壊れ方」を防げます。ドメイン関連のチェックをまとめて確認したい場合は「Webサイト公開前の監視設定チェックリスト」も活用してください。SSL証明書監視と組み合わせる場合は「SSL証明書の期限切れ事故を防ぐ！自動監視で安全なサイト運用を」もあわせてご覧ください。監視の基本タイプ（HTTP・DNS・SSL）との関係は「非エンジニアでもわかるサーバー監視入門」で整理しています。機能の詳細はドキュメントに、よくある疑問はFAQに、まずは試したい方は無料登録からどうぞ。