## この記事でわかること

- 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:dmarc@example.co.jp; pct=100; adkim=r; aspf=r
```

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

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

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

![DMARCレコードの構造](/blog/dmarc-record-tags-reference/record-structure.svg)

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強化｜段階的移行の手順](/blog/dmarc-policy-tightening)に整理しています。

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

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

```
rua=mailto:dmarc@example.co.jp
```

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

```
rua=mailto:dmarc@example.co.jp,mailto:reports@example.co.jp
```

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

レポートの読み方は[DMARCレポート見方ガイド｜XML集計の読み方](/blog/dmarc-report-reading)で解説しています。

### `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`を明示しておく**のが安全です。

![p と sp の適用範囲](/blog/dmarc-record-tags-reference/p-vs-sp.svg)

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

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

```
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.co.jp
```

上記の場合、認証に失敗したメールのうち**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の違い](/blog/dmarc-alignment-explained)に整理しています。

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

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

![補助タグの優先度](/blog/dmarc-record-tags-reference/optional-tag-priority.svg)

### `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:dmarc@example.co.jp; sp=none
```

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

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

```
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.co.jp; sp=none; adkim=r; aspf=r
```

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

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

```
v=DMARC1; p=reject; rua=mailto:dmarc@example.co.jp; sp=reject; adkim=r; aspf=r
```

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

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

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

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

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

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

```
NG: rua=dmarc@example.co.jp
OK: rua=mailto:dmarc@example.co.jp
```

`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`が届く設定になっているか。これらは見た目では判別しづらいポイントです。

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