DMARC とは — SPF・DKIM の結果でなりすましメールを止める

DMARC とは何ですか？

DMARC は、SPF と DKIM の認証結果を使って、なりすましと疑われるメールを受信側にどう扱わせるかを、送信ドメインの所有者が DNS で宣言する仕組みです。_dmarc で始まるサブドメインの TXT レコードに、認証失敗時の処遇（監視・隔離・拒否）とレポートの送付先を書きます。SPF や DKIM を実際の防御に変える最後の一枚です。

DMARC は Domain-based Message Authentication, Reporting & Conformance の略です。 名前のとおり 2 つの役割があります。1 つは、SPF や DKIM で認証に失敗したメールをどう扱うかを送信ドメイン側から受信側へ指示すること。 もう 1 つは、自分のドメインを名乗るメールが世界中でどう認証されているかをレポートで受け取ることです。

設定する場所は決まっていて、_dmarc.example.com という名前の DNS TXT レコードに書きます。SPF が example.com 直下、 DMARC が _dmarc のサブドメイン、と場所が固定である点は、セレクタ名が送信側任せで外部から発見できない DKIM と対照的です。

; DMARC は _dmarc サブドメインの TXT レコード 1 本に書く
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:reports@example.com"

;   v=DMARC1  必須。DMARC レコードである宣言（先頭に固定）
;   p=none    ポリシー。none / quarantine / reject のいずれか
;   rua=...   集計レポートの送付先。実質必須（無いと現状を把握できない）

ここで大切なのは、DMARC 単体では何も認証しないということです。実際にメールを検査するのは SPF と DKIM で、 DMARC はその結果の使い方を決める上位の仕組みです。だから DMARC の話は、必ず SPF・DKIM との関係から始まります。

SPF・DKIM とはどういう関係ですか？（アライメント）

DMARC の核心はアライメント（整合性）で、画面に表示される From ヘッダーのドメインと、SPF や DKIM が認証したドメインが一致するかを見ます。SPF アライメントか DKIM アライメントの、どちらか一方でも合格すれば DMARC は pass です。片方が壊れても、もう片方が生きていれば通るため、転送にも強くなります。

SPF や DKIM は、それぞれ「あるドメインの認証」には成功します。しかし攻撃者は、 自分が正当に管理する別ドメインで SPF・DKIM を通過させたうえで、画面に表示される From: だけをあなたのドメインに偽装できます。認証したドメインと、表示上の差出人が食い違っていても、SPF・DKIM 単体はそれを問題にしません。

この食い違いを検査するのがアライメントです。DMARC は次の 2 系統を確認し、どちらか一方でも合格すれば pass とします。

「どちらか一方でよい」設計が、DMARC を転送に強くしています。メーリングリストや .forward による転送では、 接続元 IP が変わって SPF が壊れがちですが、DKIM 署名は本文が改変されなければ転送先でも生き残ります。 逆に、件名を書き換える種類の転送では DKIM が壊れても SPF アライメントが残る、というように二重の保険になります。 だから SPF と DKIM は両方入れる価値があります。

アライメントの厳格度は adkim（DKIM 用）と aspf（SPF 用）で調整できます。既定は r（relaxed・緩い）で、 組織ドメインが一致すればサブドメインの違いを許します。s（strict・厳格）にすると完全一致を要求します。最初は緩いままで構いません。 詳しい攻撃の手口は SPF・DMARC でなりすましメールを防ぐ で順を追って説明しています。

書式とポリシー（none / quarantine / reject）はどう指定しますか？

ポリシーは p タグで指定し、none（監視のみで何もしない）、quarantine（迷惑メール扱い）、reject（受信拒否）の 3 段階から選びます。書式は v=DMARC1 で始め、p と、レポート送付先の rua を続けるのが基本形です。実際に配送を止めるのは quarantine と reject で、none は防御ではなく観測のための設定です。

ポリシーは p= タグで指定します。この 1 語が「認証に失敗したメールをどうするか」を決める本体です。

主要なタグは次のとおりです。必須は v と p だけですが、実務では rua も欠かせません。

レポート（rua / ruf）では何が分かりますか？

rua は集計レポート（Aggregate）の送付先で、どのドメインや IP から自分を名乗るメールが送られ、認証に通ったかを日次の XML で受け取れます。ruf は個別の失敗レポート（Forensic）ですが、対応する受信側は限られます。実務では rua を必ず設定し、正規の送信元をすべて洗い出してからポリシーを厳しくします。

レポートは、段階導入を安全に進めるための唯一の目です。rua を設定しておくと、受信側の各メールプロバイダから、あなたのドメインを名乗って送られたメールの認証結果が集計されて届きます。ここで初めて、 自分でも把握していなかった正規の送信元が見えてきます。

• 会計ソフト・請求書発行サービスからの自動送信
• 採用管理システムや問い合わせフォームの自動返信
• 営業部門が個別契約した MA ツールやメール配信サービス
• 古いサーバーに残った cron のアラートメール

これらを p=none の期間にすべて洗い出し、SPF か DKIM で正しく認証できる状態に直してから、初めてポリシーを厳しくします。rua を設定していないと、この洗い出しが原理的にできません。

注意点として、rua レポートは圧縮された XMLで届き、そのまま人が読むのはかなり厳しいものです。 量が多いなら無料のレポート解析サービスを使い、少なければ手元で展開して構いません。ruf（詳細な失敗レポート）は個々のメールに近い情報を含むため有用ですが、プライバシー上の理由で送信しない受信側が多く、 届かないことを前提にしておくのが現実的です。まずは rua を確実に受け取れる状態にしてください。

段階的な進め方（none → quarantine → reject）を教えてください

まず p=none と rua だけを設定してレポートを集め、正規のメールがすべて SPF か DKIM で認証できていることを確認します。次に p=quarantine で隔離を試し、問題がなければ p=reject へ進みます。順番を飛ばして最初から reject にすると、認証設定を忘れていた正規のメールが静かに届かなくなります。

; ── 段階導入（順番を飛ばさない）──

; 【第 1 段階】監視のみ。まず 2〜4 週間。この時点では何もブロックされない
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

; 【第 2 段階】隔離。pct で一部から適用し、問題なければ割合を上げる
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"

; 【第 3 段階】拒否。サブドメインにも同じ扱いを適用する（sp）
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"

なぜ順番を飛ばしてはいけないか

いきなり p=reject を入れると、「自分たちが送っていることを忘れていた正規のメール」が消えます。 しかもこれは静かに起きます。エラー画面が出るわけではなく、相手の受信箱に届かないだけなので、 気づいたときには請求書や問い合わせ通知が数週間ぶん失われている、ということが起こります。

pct タグを使うと、quarantine や reject を一部の割合だけに適用できます。 まず pct=25 あたりから始め、レポートに問題が出なければ 50 → 100 と上げていくと、影響を小さく抑えながら移行できます。 ただし pct の扱いは受信側によって差があるため、最終的には pct を外して p=reject を全面適用するのがゴールです。

2024 年の送信者要件で何が変わりましたか？

2024 年 2 月以降、Google と Yahoo は一定量以上を送る大量送信者に対し、SPF・DKIM に加えて DMARC の設定を必須化しました。設定がないと、なりすまし以前にメールが Gmail などに届かなくなります。DMARC は「あったほうがよい」対策から、メールを届けるための前提条件へと位置づけが変わりました。

これまで DMARC は「セキュリティ意識の高いドメインが入れるもの」でしたが、位置づけが明確に変わりました。

ここで求められるのは、単に DMARC レコードが存在することです（最低ラインは p=none でも受理されます）。 とはいえ、せっかく設定するなら防御として機能する quarantine 以上を目指すのが筋です。到達性の確保と、なりすましの防止は、同じ設定で同時に前進します。

メールを送らないドメインはどう設定すべきですか？

メールを一切送らないドメインは、最初から p=reject を設定するのが正解です。正規の送信が存在しない以上、厳格化しても誤って止めてしまうメールが原理的にないからです。むしろ何も宣言していないドメインは第三者に名乗られ放題なので、リダイレクト用や旧ブランドのドメインこそ、今すぐ reject を入れてください。

実務で最も多い誤解が「うちはこのドメインでメールを送っていないから DMARC は関係ない」というものです。逆です。狙われるのは、まさにそういうドメインです。何も宣言していないドメインは、受信側にとって偽物と判定する根拠が一切ないため、invoice@あなたの会社.co.jp を名乗る請求書偽装メールが、そのまま取引先の受信箱に届きます。

そして、メールを送らないドメインには大きな利点があります。正規の送信が 1 通も存在しないため、誤って止めてしまうメールが原理的にありません。段階導入すら不要で、初日から p=reject を入れられます。

; ── メールを一切送らないドメインの設定 ──
; 正規の送信が無いので、初日から最も厳しくしてよい（誤爆しようがない）

; 認証に失敗したもの＝すべて拒否
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

; SPF 側でも「どこからも送らない」を宣言しておく
example.com.        IN TXT "v=spf1 -all"

リダイレクト用に取っただけの旧ドメイン、キャンペーン用ドメイン、旧ブランドのドメイン——こうした「使っていないドメイン」こそ、今すぐ p=reject を入れてください。所要時間は数分、正規の送信がない以上リスクはゼロです。

設定できているか確認するには？

_dmarc サブドメインの TXT レコードを dig などで直接引くのが最も確実です。管理画面では正しく見えても、実際には反映されていないことがあります。本ツールの診断でも DMARC の実レコードを取得し、p=none のように設定はあるが防御として効いていない状態も個別に指摘します。反映には TTL のぶんの時間がかかる点に注意してください。

# DMARC レコードを直接引く（_dmarc サブドメインの TXT）
dig +short TXT _dmarc.example.com

# 返る値の例:
#   "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
# p=none のままなら「設定はあるが防御は効いていない」状態

DNS の変更は即座には広まりません。TTL のぶんだけ古い値がキャッシュされ続けるので、変更直後に確認して「反映されていない」と慌てないでください。作業前に TTL を短くしておくと、切り替えが楽になります。

本ツールの診断では、DMARC の実レコードを取得したうえで、p=none のような「設定はあるが効いていない」状態も個別に警告します。 あわせて SPF・DKIM・MX や、DNSSEC・CAA といったドメイン周りの設定も確認できます。関連する話題は SPF・DMARC でなりすましメールを防ぐ にまとめています。 仕様の一次情報は RFC 7489（DMARC） と dmarc.org の概要 を参照してください。