DMARCレコードのタグ完全リファレンス

この記事でわかること

• DMARCレコードに書く全11タグ（v / p / sp / rua / ruf / pct / adkim / aspf / fo / rf / ri）の役割とデフォルト値
• 実運用で「最低限書くべきタグ」と「省略してよいタグ」の見分け方
• 運用フェーズ別の記述例と、よくある書き間違い

DMARCレコードは「タグの組み合わせ」でできている

DMARC（ディーマーク）はDNSの_dmarc.<ドメイン>にTXTレコードとして1行で書きます。たとえば次のようなレコードです。

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; adkim=r; aspf=r

セミコロン区切りの「タグ=値」が連なる構造で、それぞれのタグに役割があります。仕様はRFC 7489で定義されており、必須・オプション・デフォルト値も明確に決まっています。

ただし、Web上の解説記事には「rufは必ず書いたほうがいい」「pctで段階的に上げる」など、一見もっともらしいけれど現状の運用に合わない情報が混ざっています。本記事では実務で「どのタグをどう書けばいいか」を、誤解なく一覧できる形で整理します。

DMARCそのものの概念や初期設定の3ステップは、先にDMARC とは？仕組みと中小企業が今すぐやるべき対応を 5 分でわかる入門とDMARC設定方法を徹底解説をご確認ください。

RFC 7489（2015年公開、現行の正式仕様）で定義されているタグは次の11個です。必須はvとpの2つだけで、残りはすべてオプションです。

タグ	必須/任意	デフォルト	役割
v	必須	なし（DMARC1固定）	バージョン識別子
p	必須	なし	自ドメインのポリシー（none / quarantine / reject）
sp	任意	pの値	サブドメインのポリシー
rua	任意	なし	集計レポートの送信先（mailto:）
ruf	任意	なし	失敗レポートの送信先（mailto:）
pct	任意	100	ポリシー適用割合（0〜100）
adkim	任意	r（relaxed）	DKIMアライメントモード
aspf	任意	r（relaxed）	SPFアライメントモード
fo	任意	0	失敗レポートの生成条件
rf	任意	afrf	失敗レポートのフォーマット
ri	任意	86400（24時間）	集計レポートの希望間隔（秒）

ここから個別タグの詳細を、必須・主要・補助の順で説明していきます。

必須・主要タグの書き方（v / p / rua / sp / pct / adkim / aspf）

実運用で実際に書き分けが必要になるのは、必須2タグと主要5タグの計7つです。

v=DMARC1（必須）

レコード冒頭に必ず書きます。値はDMARC1の固定で、それ以外を書くとレコード自体が無効と判定されます。先頭以外の位置に書いた場合も無効です。

p=｜自ドメインのポリシー（必須）

DMARCの中核となるタグで、3つの値から1つを選びます。

• p=none: 監視モード。認証に失敗してもブロックしない。レポートだけ受け取る初期段階の値
• p=quarantine: 認証に失敗したメールを迷惑メールフォルダへ振り分けるよう受信側に依頼
• p=reject: 認証に失敗したメールを受信拒否するよう受信側に依頼

段階強化の鉄則として、いきなりp=rejectを設定するとSaaS経由の正規メールまで一斉に拒否される事故が起こります。p=noneで2〜4週間レポートを観察し、正規送信元のSPF/DKIMが揃ってからp=quarantine、さらに観察を経てp=rejectに進める手順を、DMARCのp=quarantine強化｜段階的移行の手順に整理しています。

rua=mailto:...｜集計レポートの送信先

DMARCを設定する最大の目的の1つは、毎日XML形式で届く集計レポート（aggregate report）を読んで、自社ドメインから送信されているメールの実態を把握することです。ruaはその送信先を指定します。

rua=mailto:[email protected]

複数アドレス指定もできますが、運用シンプル化のため最初は1つで十分です。

rua=mailto:[email protected],mailto:[email protected]

ruaを別ドメインに送りたい場合の注意: たとえばDMARCレポート可視化サービスの自社専用アドレスに転送する場合など、rua=mailto:[email protected]のように自社ドメイン外を指定するときは、受信側ドメインに<送信元ドメイン>._report._dmarc.<受信側ドメイン>の許可TXTレコードを設定する必要があります（RFC 7489 Section 7.1、External Destination Verification）。設定漏れがあるとレポートが届かないため、ベンダ提供の手順書を必ず参照してください。

レポートの読み方はDMARCレポート見方ガイド｜XML集計の読み方で解説しています。

sp=｜サブドメインのポリシー

pが組織ドメイン本体（example.co.jp）のポリシーを決めるのに対し、spは配下のサブドメイン（mail.example.co.jp、shop.example.co.jpなど）に適用するポリシーを指定します。

• 省略時のデフォルトは「pと同じ値」
• 値はpと同じくnone / quarantine / rejectの3つ

よくある運用パターン:

状況	推奨設定
組織ドメインから直接メールを送り、サブドメインは未使用	p=reject; sp=reject（攻撃者がサブドメインを偽装してくる経路を塞ぐ）
サブドメインから配信SaaS経由でメールを送る	p=reject; sp=noneから始め、SaaS側のSPF/DKIM整備後にspも強化
組織ドメイン本体はp=quarantine、サブドメインは未確認	p=quarantine; sp=quarantineまたはsp=noneで観察

spを明示的に書かないと、pを強化したタイミングでサブドメイン側も同時に強化されてしまい、把握していない送信経路で配送事故が起きるリスクがあります。サブドメインからの送信を1つでも持つ組織は、spを明示しておくのが安全です。

pct=｜ポリシーの適用割合

p=quarantineやp=rejectを一気に100%適用するのが不安なときに、適用割合を絞り込むタグです。値は0〜100の整数で、デフォルトは100。

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]

上記の場合、認証に失敗したメールのうち10%だけquarantine扱いになり、残り90%はポリシーが1段階下（この場合はp=none相当）として処理されます。p=rejectにpct=10を組み合わせると、認証失敗メールの10%が拒否され90%がquarantine相当扱いになります。

「10% → 25% → 50% → 100%」と段階的に上げて配送影響を観察するのが定石ですが、pctは受信側の実装ばらつきが大きく、特に0と100以外の値で誤差が出やすい点が知られています。次世代仕様のDMARCbisドラフトではpctタグは廃止予定で、t=y（テストモード、pct=0相当）に置き換えられる見込みです。実運用では、長期間中途半端なpct値で止めず、レポート観察期間を延ばす形でリスクを管理するのが堅実です。

adkim= / aspf=｜アライメントモード

DMARCは「SPFかDKIMがHeader Fromドメインと整合（アラインメント）した状態でpassすること」を要求します。adkimとaspfは、その整合性判定の厳しさを決めるタグです。

• r（relaxed、デフォルト）: 組織ドメインレベルで一致すればOK。mail.example.co.jpの署名でもexample.co.jpの差出人を通せる
• s（strict）: 完全一致が必要。サブドメイン経由の署名は通らない

adkim=r; aspf=r

運用ではrelaxed（デフォルト）で十分です。strictが必要になるのは、サブドメイン経由の正規送信を持たず、なりすまし耐性を最大化したい大企業や金融機関などに限られます。アライメントの判定例と関連する典型的な失敗パターンは、DMARCアライメントとは｜relaxed/strictの違いに整理しています。

補助タグの判断（ruf / fo / rf / ri）

ここから先は、設定するメリットが現状の国内運用では限定的なタグです。基本的には省略してよいものですが、Web上の古い記事では「必ず書きましょう」と紹介されていることもあるため、判断材料として整理します。

ruf=mailto:...｜失敗レポートの送信先

認証に失敗した個別メールのサンプル（件名や本文の一部を含む）を、ほぼリアルタイムで送ってもらう失敗レポート（failure report、forensic report）の送信先です。

ただしGmail、Microsoft、Yahooなど主要受信プロバイダの多くは、プライバシー上の理由からrufを送信していません。設定しても届かないことが多く、届いても件名・本文断片を含むため取り扱いに注意が必要です。中小企業の通常運用では設定不要で、特殊な調査が必要なときに限り検討します。

fo=｜失敗レポートの生成条件

rufを設定したときに、どんな状況でレポートを生成するかを指定します。値は4種類で、コロン区切りで複数指定可能です。

値	意味
0（デフォルト）	SPFとDKIMの両方がアラインメントを含めて失敗したときにレポート生成
1	SPFかDKIMのいずれか1つでもアラインメント込みで失敗したらレポート生成（最も詳細）
d	DKIM署名の検証自体が失敗したらレポート生成（アラインメントは問わず）
s	SPF検証自体が失敗したらレポート生成（アラインメントは問わず）

複数指定の例: fo=1:d:sは3種類すべてのレポートを希望する設定。ただしfoはあくまでrufが設定されているときのみ意味を持ち、上述の通りrufを実際に送信してくれるプロバイダが少ない現状では効果は限定的です。

rf=｜失敗レポートのフォーマット

失敗レポートの形式を指定します。デフォルトはafrf（Authentication Failure Reporting Format、RFC 6591）で、現状この値以外は事実上使われていません。省略でOKです。

ri=｜集計レポートの希望間隔

集計レポート（rua）の生成間隔を秒単位で指定します。デフォルトは86400秒（24時間）。

ri=3600   # 1時間ごとを希望

ただしRFC 7489の規定上、これはあくまで「希望値」で、受信側は必ずしもこの間隔に従う必要がありません。実際にGmailなど多くのプロバイダは1日1回の固定送信を変更しません。省略でOKです。

DMARCbisドラフトではrfとriもタグ自体が削除予定となっており、補助タグの整理がさらに進む見通しです。

運用フェーズ別の記述例とよくある書き間違い

実際にDMARC設定を進めるうえで、フェーズごとに何をどう書けばよいかを示します。サブドメインを使う配信SaaSがある前提のサンプルです。

フェーズ1: 監視開始（運用1〜2か月目）

v=DMARC1; p=none; rua=mailto:[email protected]; sp=none

ポリシーはnoneで、まずはレポートを集めて自社の送信経路を全て把握します。sp=noneを明示し、サブドメインからの正規送信が把握できていない時点で配送停止が起きないようにします。

フェーズ2: 段階強化（運用3〜4か月目）

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; sp=none; adkim=r; aspf=r

正規送信のSPF/DKIMが揃ったらp=quarantineへ。pct=25で影響範囲を絞りながらレポートを観察します。サブドメイン側がまだ未対応ならsp=noneを維持。

フェーズ3: 本格運用（運用6か月目以降）

v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; adkim=r; aspf=r

p=rejectで本格運用に入り、サブドメインもsp=rejectで揃えます。pctは明示せずデフォルト100で運用するのが推奨です。

各フェーズの判断基準と、強化前に必ず確認すべき3点は、DMARCのp=quarantine強化｜段階的移行の手順に整理しています。

実際の問い合わせで頻出する誤りも、よくある書き間違いとしてまとめます。レコードを書いたあと、必ず無料診断ツールで構文チェックを受けてください。

書き間違い1: v=DMARC1を書き忘れる/位置が違う

vタグはレコード先頭に必須です。先頭以外に書いたり、v=dmarc1（小文字）と書いたりしたケースで「DMARCが認識されない」と相談を受けることがあります。

書き間違い2: ruaの値にmailto:を付け忘れる

NG: [email protected]
OK: rua=mailto:[email protected]

mailto:は仕様上必須のスキーム指定です。

書き間違い3: _dmarcサブドメインに置き忘れる

DMARCレコードはホスト名_dmarc.<ドメイン>に置きます。組織ドメイン直下のTXT（example.co.jp）に書いてしまうと、SPFと混在してDMARCとして読まれません。

書き間違い4: p=の値を大文字にする

NG: p=Reject
OK: p=reject

タグ値は小文字が前提です。受信側の実装によっては大文字小文字を許容するものもありますが、相互運用性のため小文字で書きます。

書き間違い5: 1ドメインに複数のDMARCレコード

DMARC仕様上、1ドメインに複数のDMARCレコード（複数のTXT）を置くとレコード自体が無効と判定されます。古いレコードを残したまま新規追加していないか、必ずdig TXT _dmarc.<ドメイン>で確認してください。

まとめ

要点をおさらいします。

• DMARCレコードのタグはRFC 7489で11個定義されており、必須はvとpの2つだけ
• 実運用で書くべきはv / p / rua / sp の4タグが中心。pct / adkim / aspf も状況に応じて
• ruf / fo / rf / riは主要プロバイダの実装状況上、省略してよい補助タグ
• DMARCbisドラフトではpct / rf / riが廃止予定、np（非存在サブドメインのポリシー）とt（テストモード）が追加予定で、補助タグはさらに整理される見通し

タグの意味を押さえれば、自社のフェーズに合わせた最小限のレコードで運用できます。書いたDMARCレコードが正しく機能しているか、pとspの整合性は取れているか、ruaが届く設定になっているか。これらは見た目では判別しづらいポイントです。

ドメイン番人の無料診断では、ドメインを入力するだけでDMARCレコードの構文チェックと、SPF/DKIMとの整合状態をその場で確認できます。各タグの値を日本語で逐語解説してほしい場合は無料の SPF / DKIM / DMARC 設定確認ツール、rua= で届くようになったレポートの可視化には DMARC レポート解析ツール おすすめ 7 選 を参考にしてください。専門家がわかりやすくサポートいたします。