2026年6月1日

SPF・DMARC・DKIM・MXを常時監視する方法｜メール認証の設定崩れを早期に検知する

メール認証 SPF DMARC DKIM 死活監視

メール認証レコードは「気づかないうちに」壊れる

ドメイン管理画面でSPFやDMARCを正しく設定したのに、ある日突然「メールが届かない」と言われた経験はありませんか。SSL証明書のように残り日数が見える仕組みが無いため、メール認証のトラブルはほぼ常に事後発覚します。

代表的な「壊れ方」は以下のとおりです。

SPFレコードを編集したつもりが v=spf1 のバージョン文字を消してしまった — そもそも認識されない
新しいメール送信SaaSを追加して include: を増やしたら lookup 10 回上限を超えた — RFC 7208 で永続的失敗扱い
DMARCの p=quarantine を試そうとして p= を書き忘れた — タグが必須なので無効レコードに
DKIMセレクタを切り替えたあと、旧セレクタのレコードを残したまま新レコードを公開し忘れた — 署名検証が全失敗
MXレコードが「テスト中」のサブドメインを指したまま戻し忘れていた — 配信SLAが壊れている

特に制作会社が複数のクライアントドメインを管理している場合、各社のドメイン管理画面に常駐するわけにもいきません。「設定した時点で正しい」ではなく「今この瞬間も正しい」を機械的に確認し続ける仕組みが必要です。

監視対象の4タイプを整理する

Miterl の 2026-06-01 リリースで、メール認証 4 タイプの監視を追加しました。

タイプ	何を確認するか	失敗時の典型シナリオ
MX	MXレコードが存在し、ホストを返すか	DNSゾーン編集ミス・移行中の暫定MXのまま戻し忘れ
SPF	`v=spf1 ... all` を満たす単一レコードか / lookup ≤10	include 追加で 10 回上限超過・誤って2レコード公開
DMARC	`_dmarc.<domain>` に有効な `p=` 付きレコードか	`p=` 抜け・`pct` が範囲外・`rua=` の URI 形式破損
DKIM	指定セレクタの `{selector}._domainkey.<domain>` に有効公開鍵	セレクタ切替時の置き換え漏れ・空 `p=`（revoked）

ポイントは、Miterlは構文ルールまで含めて検証することです。レコードは引けても文法が壊れていれば Down 扱いになります。DMARC の pct=120 のように一見気づきにくい誤りも、内部で RFC 7489 のレンジ検証をかけているため見逃しません。

APIで監視を作成する

メール認証監視は HTTP 監視や SSL 監視と同じ Monitor リソースの一種です。type に mx / spf / dmarc / dkim を指定して作成します。

MX監視

# MX監視（type: mx）— example.com の MX レコードを 5 分おきにチェック
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "example.com MX",
    "type": "mx",
    "url": "example.com",
    "interval_seconds": 300
  }'

url はスキームを付けず apex ドメインだけを指定します（WHOIS監視と同じ流儀）。MX が存在しない・引けない場合に Down となります。

SPF監視

# SPF監視 — v=spf1 / all / lookup 10 回上限まで自動検証
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
  }'

複数 SPF レコードが返ったり、v=spf1 プレフィックスが無い場合、all ターミナルが無い場合、include + a + mx の合計 DNS lookup が 11 回以上になる場合などはいずれも構文違反として Down になります。

DMARC監視

# DMARC監視 — _dmarc.<domain> の p= / pct / rua URI を自動検証
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "example.com DMARC",
    "type": "dmarc",
    "url": "example.com",
    "interval_seconds": 300
  }'

p= 必須・pct は 0〜100・adkim / aspf は r か s・rua= / ruf= は mailto: または https: URI、といった RFC 7489 のルールを満たさないと Down になります。

DKIM監視（セレクタ複数対応）

# DKIM監視 — 複数セレクタを 1 モニターでまとめて検証（最大 5 つ）
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "example.com DKIM",
    "type": "dkim",
    "url": "example.com",
    "interval_seconds": 300,
    "dkim_selectors": ["selector1", "selector2", "google"]
  }'

dkim_selectors は配列で最大 5 件まで設定できます。{selector}._domainkey.{url} の TXT レコードを 1 件ずつ引き、v=DKIM1 / p=<公開鍵> のうち 1 件でも空鍵（revoked）または base64 として無効ならその時点で Down 扱いです。Google Workspace（google）・SendGrid（s1, s2）・Mailgun（mailo._domainkey 等）のような複数 ESP を併用している場合、まとめて 1 つの監視で見られます。

ダッシュボードから設定する

API を使わずに作成する場合、ダッシュボードの監視追加画面で「監視タイプ」プルダウンから MX / SPF / DMARC / DKIM を選択します。DKIM のときだけ「DKIMセレクタ」入力欄（タグ入力）が表示されるので、ESPごとのセレクタを Enter で追加してください。

制作会社向けの運用フロー例

複数クライアントを束ねている運用では、メール認証も SSL と同じく保守メニューに含めるのがおすすめです。

新規クライアント受け入れ時に MX/SPF/DMARC をまず登録 — 既存設定が正しいかその場で確認できる
DKIM は ESP 切替のタイミングで追加 — セレクタを把握できているうちに登録
アラート連絡先は Slack または Chatwork に集約 — 設定方法はSlack・Chatworkへのアラート通知設定を参照
月次レポートで「メール認証ステータス」を含める — クライアントへの保守価値の可視化に直結

「メールが届かない」というクレームは到達確認まで含めると一次切り分けに半日かかることもありますが、認証レコードが Up になっていれば少なくともDNS層は健全であることを即答できます。これだけで初動の精度が大きく上がります。

既存ドメインの設定を一覧で確認するコマンド

新規受け入れの初動チェックや、保守継続中ドメインの定期点検に使えるコマンドを置いておきます。

# MX
dig +short MX example.com

# SPF（TXTのうち v=spf1 で始まるものを抽出）
dig +short TXT example.com | grep -E '"v=spf1'

# DMARC
dig +short TXT _dmarc.example.com

# DKIM（セレクタを知っている前提）
dig +short TXT selector1._domainkey.example.com

これらをスポット確認したあとで Miterl に登録すれば、以降は変更が起きた瞬間に通知が届く運用に切り替えられます。

全認証監視モニターの状態を一括取得する

複数ドメインを管理している場合、API で全モニターの状態をまとめて引くと「いま壊れている認証はどれか」が即わかります。

# メール認証タイプだけ抜き出して一覧表示
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq -r '.data[]
      | select(.type == "spf" or .type == "dmarc" or .type == "dkim" or .type == "mx")
      | "\(.type)\t\(.name)\t\(.status)"'

Status が down のものは認証構文か DNS 配信のどちらかが壊れています。down_at の時刻と直近の変更履歴を突き合わせれば、原因の DNS 編集を特定するのが容易になります。

既存の死活監視との関係

メール認証監視は HTTP / SSL / WHOIS / DNS と独立した監視タイプです。詳しくは「サイト監視の基本タイプ｜HTTP・Ping・DNS・SSLの違い」で扱った早見表に加えて、以下の組み合わせ目安を参考にしてください。

対象	必須監視	強く推奨
コーポレートサイト（メール送信あり）	HTTP・SSL	SPF・DMARC・WHOIS
EC・予約系（自社配信メール）	HTTP・SSL・SPF	DMARC・DKIM・MX
トランザクションメール特化サービス	SPF・DMARC・DKIM	MX・HTTP

SPF と DMARC は「とりあえず入れておく」コストが低く、構文崩壊だけでもメール到達率に直接効くため、まずはこの 2 タイプから始めるのがおすすめです。

よくある質問（FAQ）

SPF のレコードが 2 つに分かれてしまっている場合、どう検知されますか？

RFC 7208 上、SPF は同一ドメインに 1 レコードのみ許容されています。Miterl では複数の v=spf1 レコードを検出するとそれだけで Down 扱いになり、エラーメッセージに「multiple v=spf1 records」と入ります。受信側 MTA によっては 1 つ目だけ評価される実装もあるため、見かけの送信は通っていても運用としては早めに是正すべき状態です。

DKIM の公開鍵がローテーションされる場合、監視はどう設定すべきですか？

旧セレクタと新セレクタの両方を dkim_selectors に入れておき、ローテーション完了後に旧セレクタを外す運用が安全です。ローテーション中はどちらかが署名検証に使われるため、両方が有効である状態を Miterl 側でも担保できます。

メンテナンスでドメイン移管中の誤アラートはどう防ぎますか？

メンテナンスウィンドウ機能で計画停止と同じく時間帯を区切ってアラートを抑制できます。監視チェック自体は継続するため、移管予定時刻を過ぎても直らない場合はすぐに気づけます。

まとめ

メール認証は「設定して終わり」にできない領域です。DNS 編集や ESP 切替の度に静かに壊れるリスクがあり、気づくのは決まってクライアントからの「メールが届かない」連絡です。

MX/SPF/DMARC/DKIM の 構文ルールまで含めて自動検証することで、レコード崩壊を即時検知できる
DKIM は複数セレクタを 1 モニターで束ねられるため、ESP 併用時も管理コストが増えない
保守メニューに認証監視を含めると、「メール届かない」の初動切り分けが早くなる
月次レポートでステータスを可視化すると保守の価値が伝わりやすい

Webサイトを本番公開する前のドメイン関連チェックは「Webサイト公開前の監視設定チェックリスト」にもまとめています。SSL証明書と並んで監視必須の領域なので、合わせて「SSL証明書の期限切れ事故を防ぐ！自動監視で安全なサイト運用を」も参考にしてください。設定方法の詳細はドキュメントに、料金はFAQに、まずは試してみたい方は無料登録からどうぞ。最新のリリース履歴はChangelogでも確認できます。