DMARCメール認証学習Web 担当者

DMARC ruf と fo タグの実用ガイド

ドメイン番人5 分で読めます
目次

この記事でわかること

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

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

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

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

DMARCタグ全体の整理はDMARCレコードのタグ完全リファレンスに譲り、本記事ではrufと、その挙動を制御するfoタグに絞って解説します。

v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

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

rua と ruf の機能対比

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=dfo=sは調査用途で、特定のプロトコルの不具合を切り分けたいときに使います。複数指定したい場合はfo=d:sのようにコロンで区切ります。

fo タグの判定フロー

国内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レポートが届かない原因で別途整理しています。

受け取れた場合のレポート形式(AFRF)

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

Feedback-Type: auth-failure
User-Agent: Lua/1.0
Version: 1
Original-Mail-From: [email protected]
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ポリシー強化の進め方に整理

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

v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; pct=100

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

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

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

次の一歩は無料診断から。