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

- DMARCの`ruf`タグ（Forensic Report）が果たす役割と`rua`との明確な違い
- `fo`タグの4つの値（`0` / `1` / `d` / `s`）が意味する判定条件
- 日本国内のISPが`ruf`をほぼ送信しない実情と、その理由
- フォレンジックレポートに依存しない現実的なDMARC運用方針

## ruf タグは「個別メールのフォレンジックレポート」用

DMARC（ディーマーク）レコードに書ける宛先タグは2つあります。`rua`と`ruf`です。それぞれ届くレポートの性質はまったく違います。

- **`rua=mailto:...`**: 集計レポート（Aggregate Report）。1日1回、XML形式で「どのIPからどれだけ送信され、SPF/DKIMの結果がどうだったか」が統計的にまとまる
- **`ruf=mailto:...`**: 失敗レポート（Forensic Report、Failure Report）。SPFまたはDKIMで認証に失敗した個別メールについて、ヘッダや本文の一部をリアルタイムで送ってくる

DMARCタグ全体の整理は[DMARCレコードのタグ完全リファレンス](/blog/dmarc-record-tags-reference)に譲り、本記事では`ruf`と、その挙動を制御する`fo`タグに絞って解説します。

```
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.co.jp; ruf=mailto:forensic@example.co.jp; fo=1
```

`ruf`を書いておけば、なりすましメールが検知された瞬間にフォレンジックレポートが届く設計でしたが、現実はそう単純ではありません。

![rua と ruf の機能対比](/blog/dmarc-ruf-forensic-report/rua-vs-ruf.svg)

## fo タグの4つの値

`fo`タグは「どんな条件で失敗レポートを生成するか」を制御するタグで、`ruf`とセットで使います。値は4種類で、デフォルトは`0`です。

| 値 | 意味 | レポートが送られる条件 |
|---|---|---|
| `0` | デフォルト | SPFとDKIMの **両方** がfailし、DMARCが失敗したとき |
| `1` | 推奨 | SPFまたはDKIMの **いずれか** がfailしたとき |
| `d` | DKIMのみ | DKIMがfailしたとき（SPFは問わない） |
| `s` | SPFのみ | SPFがfailしたとき（DKIMは問わない） |

`fo=0`は条件が厳しく、レポートがほぼ生成されません。失敗の兆候を早く拾いたい場合は`fo=1`が実用的です。`fo=d`や`fo=s`は調査用途で、特定のプロトコルの不具合を切り分けたいときに使います。複数指定したい場合は`fo=d:s`のようにコロンで区切ります。

![fo タグの判定フロー](/blog/dmarc-ruf-forensic-report/fo-flow.svg)

## 国内ISPは ruf をほぼ送ってこない

`ruf`を設定しても日本の中小企業ではレポートがほとんど届きません。これは設定ミスではなく、受信側のプライバシー方針による現状です。

フォレンジックレポートには、認証に失敗したメールのヘッダ全体や本文の一部が含まれます。送信者・受信者のメールアドレス、件名、Message-IDなど、個人情報に該当しうる情報が外部ドメインに転送されることになります。GDPRや日本の個人情報保護法を踏まえ、主要な受信プロバイダはこの送信を取りやめています。

具体的には、次のプロバイダは現在`ruf`をほぼ送信していません。

- Gmail（Google Workspace 含む）
- Yahoo!メール（日本・米国）
- Microsoft 365（Exchange Online、Outlook.com）
- docomo / au / SoftBank などの国内キャリアメール

逆に、まだ`ruf`を送ってくれる例外もあります。一部の海外受信側（Comcast、AOL系の名残、特定のセキュリティゲートウェイ製品など）からは届くケースがあります。ただし日本企業の宛先構成では、ほぼ素通りと考えてよい状態です。

「設定したのに何も来ない」と感じる相談は多いですが、原因の多くは設定不備ではなく、そもそもレポートが生成されていないだけです。`rua`が届かないケースとは原因が異なるので、切り分けの順番を間違えないようにしてください。`rua`が届かない場合は[DMARCレポートが届かない原因](/blog/dmarc-rua-not-receiving)で別途整理しています。

### 受け取れた場合のレポート形式（AFRF）

例外的に`ruf`レポートが届いた場合、フォーマットは **AFRF（Abuse Reporting Format、RFC 5965）** に従います。中身は`message/rfc822`形式の添付に元メールのヘッダと本文の一部、加えて認証結果が記載されたフィードバックレポートが付いてきます。

```
Feedback-Type: auth-failure
User-Agent: Lua/1.0
Version: 1
Original-Mail-From: phishing@suspicious.example
Arrival-Date: Mon, 06 May 2026 09:12:33 +0900
Source-IP: 198.51.100.45
Auth-Failure: dmarc
Reported-Domain: example.co.jp
DKIM-Domain: example.co.jp
```

このレポートからわかるのは、なりすましの送信元IP・元の差出人・着信時刻・どの認証で落ちたか、です。攻撃の生データに近い情報なので、調査用途では価値があります。ただし送信元プロバイダ次第で内容が削られることもあり、解析は数件程度では傾向がつかめません。

## ruf に依存しないDMARC運用が現実的

国内中小企業の運用では、`ruf`にコストをかけるよりも次の優先順位が現実的です。

1. **`rua`の集計レポートを毎日読む**: 認証失敗の傾向はここで7〜8割わかる
2. **送信元IPを棚卸しする**: レポートに出てくるIPがすべて自社管理かを確認
3. **ポリシーを段階的に強化**: `p=none → quarantine → reject`の進め方は[DMARCポリシー強化の進め方](/blog/dmarc-policy-tightening)に整理

`ruf`は「設定しておいてもよいが、届かない前提で運用する」が妥当な姿勢です。`fo=1`で書いておけば、稀に届いたレポートが調査の手がかりになる程度の効果は期待できます。フォレンジック解析の専用ツールに数千円〜数万円の月額をかける前に、まず`rua`の集計を継続的に読み解ける体制を作るほうが効果的です。

```
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.co.jp; ruf=mailto:forensic@example.co.jp; fo=1; pct=100
```

上記のように`rua`と`ruf`を併記し、`fo=1`を加えるのが現状でできる最大限の設定です。届かないレポートを待つよりも、毎日届く`rua`を継続的に確認することに労力を割くのが、中小企業の現実的なDMARC運用と言えます。

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。