DMARC RUA: 報告先と XML の読み方

DMARC RUA は DMARC レコードに記載する集計レポートの送信先で、参加する受信側がそこへ報告できます。設定しなければ認証や不明な送信元を調べる重要な情報が減りますが、レポートがあっても全体を網羅するわけではありません。基本は小規模企業のビジネスメールをご覧ください。

CRM の設定不足、忘れられた WordPress プラグイン、転送後の SPF 失敗などが原因調査を難しくします。RUA は一部のトラフィックを見える形にし、推測ではなくデータで確認するのに役立ちます。

ここでは RUA タグ、DNS への公開、XML の読み方、問題を直す確認順序を説明します。

DMARC RUA とは

RUA は集計認証レポートの宛先を指定します。SPF、DKIM、アライメント、送信 IP、DMARC 処理を期間ごとにまとめ、多くは日次で届きます。ただし報告する受信側が観測したメールに限られます。

DMARC レコードの rua=mailto:... は集計レポートをここへ要求する指定です。RFC 7489 は rua で報告先を指定する仕組みを説明しています。レポートには認証結果、アライメント、ドメイン、件数、適用された処理などが含まれます。

制限の適用には根拠が必要です。p=none、p=quarantine、p=reject はレポートと送信元台帳、実際のテストを基に選びます。RUA だけで完全に準備できたとは判断できません。

RUA レポートが示す内容

集計情報であり、個別メールのコピーではありません。観測された送信元、元の SPF と DKIM 結果、DMARC に必要なドメインのアライメントを確認できます。auth_results は元の認証、policy_evaluated はアライメントを含む DMARC 評価です。

定期的な運用確認に使えます。本文は含みませんが、サービスの設定不足、なりすましの疑い、アライメント問題の手掛かりが得られます。

タグ	役割	内容	用途
`rua`	集計レポートを要求	送信元 IP と認証結果別の XML 要約	定期監視とポリシー導入
`ruf`	失敗レポートを要求	対応する受信側から個別の失敗情報	特定の問題の追加調査

通常は RUA から始め、ruf は具体的な必要がある場合に使います。対応は限られ、詳細情報にはプライバシーへの配慮が必要です。

例: ドメインが Google Workspace、請求アプリ、ヘルプデスクで送信しています。参加する受信側が観測すれば、レポートに送信元が現れる可能性があります。ヘルプデスクのアライメント失敗は確認対象ですが、不明な送信元や別の国の所在地だけでは偽装の証拠になりません。

RUA アドレスを公開する

_dmarc.yourdomain.com に TXT を作り、有効な rua=mailto: アドレスを含めます。未確認の送信元があるなら、直ちに制限せず監視から始めます。

次は任意の厳格アライメントを使う例で、すべてのドメインに適した既定設定ではありません。

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

厳格設定を使わない簡単な代替例です。両方を同時に公開しないでください。

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

専用メールボックスか分析サービスを使い、圧縮 XML が通常のサポート作業に混ざらないようにします。

TrekMail の必要な DNS レコードは設定を説明しています。SPF、DKIM、DMARC の組み込み確認は DNS のミスを検出する場合がありますが、全送信元の実際のメール検証を代替しません。

RUA レコードの確認方法

DNS を直接照会し、レポートが届くか確認します。レコードの誤りで宛先を使えない場合がありますが、レポート不足は受信側の不参加や許可の不足でも起こります。

dig または nslookup を使います。

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

公開した DMARC TXT が応答に含まれることを確認します。RFC 7489 には次のような有効な形式があります。

"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"

多くは日次ですが、送信時期や参加状況は異なります。届かない時間があっても、DNS が正しい、あるいはトラフィックがないとは判断できません。

RUA レポートを順序立てて読む

XML で送信元を特定し、SPF と DKIM、その後にアライメントと処理を確認します。DMARC 成功には少なくとも一つの方式で認証成功とアライメントがそろう必要があります。

次の順で調べます。

送信元 IP と逆引き DNS を自分のシステムと比較します。PTR 名だけで身元を確認できるわけではありません。
件数を比べます。2 件と 20,000 件は規模が違いますが、少数でも業務上重要な送信元の場合があります。
SPF、DKIM、アライメントを確認します。アライメントのない成功だけでは不十分ですが、ほかに成功したアライメント付き経路があれば DMARC は成功します。
処理を読みます。none は特定の配信や監視だけを証明せず、quarantine は決まったフォルダーを保証せず、reject は例外のない遮断を保証しません。
正規、設定不足、疑わしい、未確認の送信元に分類します。

Google は個人用 Gmail への通常の直接送信者に SPF または DKIM を要求します。一括送信者は両方と DMARC が必要で、少なくとも一つの成功経路を From: ドメインへアライメントさせます。RUA は実際の問題を見つける手掛かりですが、受信トレイへの配信は保証しません。

RUA で調べる三つの問題

正規の送信元の認証不足、転送による SPF 失敗、なりすましの疑いを分けます。対応する前に追加情報で確認してください。

1. 正規の送信元の設定不足

既知のサービスでも、必要な SPF やアライメント付き DKIM がない場合があります。DMARC は成功したアライメント付き SPF または DKIM で十分ですが、DKIM 不足は転送で問題になる場合があります。まず送信元を直します。

持ち込み送信サービスでは実際の経路に合わせて DNS を設定します。持ち込み SMTPをご覧ください。対象の有料プランの管理型 TrekMail SMTPは送信と署名の設定を説明しています。

2. 転送で SPF が失敗する

新しい送信 IP で SPF が失敗しても、メールが偽装とは限りません。署名対象データが正規化ルール上維持されれば DKIM は成功できます。アライメントも満たせば DMARC は成功しますが、SPF 失敗を一律に無視せず、実際の経路をテストします。

メール転送の設定とドメインのメールを Gmail に転送するが参考になります。SPF 失敗と DMARC 失敗は異なる結果です。

3. 不明な送信元となりすましの疑い

不明な IP は未登録サービス、共有リレー、転送、悪用のいずれかかもしれません。確認せず SPF や許可リストに追加しないでください。正規の送信元の設定を確認してから制限を検討します。

RUA を外部サービスへ向けるべきか

外部サービスで XML を読みやすくできますが、DNS の要件とデータの扱いを確認します。外部宛先には許可が必要で、一部の受信側は報告前に確認します。

RFC 7489 は組織ドメイン外の rua 宛先について、宛先ドメインの DNS に次のような確認レコードを置く方式を説明しています。

example.com._report._dmarc.thirdparty.example.net. IN TXT "v=DMARC1"

確認がなければ、レポート作成側が外部宛先を無視する場合があります。分析サービスの正確な手順を使い、宛先側の許可を調べてください。

p=none から Quarantine や Reject に進む時期

レポート、送信元台帳、テストを使ってからポリシーを変えます。未解明の失敗は偽装とは限りません。正規の処理を十分に確認してから、厳しい扱いを要求します。

手順の例です。

p=none を使って RUA を公開する。
例えば 1 週間から 2 週間観察し、まれな送信周期を別に確認する。
正規の各送信元で、成功したアライメント付き SPF または DKIM を確保する。
検証後に p=quarantine を検討する。
重要なメールと残る失敗を確認した後に p=reject を検討する。

観察とテストを省くと、見落とした設定を顧客が先に見つける場合があります。確認と正規メールの失敗への対応を計画します。

共通の手順で RUA を運用する

XML は手動で分析するか、解析サービスに委ねます。標準化した DNS と共通画面はドメイン、メールボックス、移行、送信を管理しやすくできますが、自動のレポート解釈とは別です。

分散した運用	TrekMail での共通運用
ドメインごとに SPF、DKIM、DMARC の方法が違う	ドメイン DNS とメールボックスを共通画面で追跡
アライメントを壊した送信元が不明	DNS 設定フローと調査用の文書
転送問題を SPF だけのせいにする	DMARC、DKIM、実際の転送経路を合わせて確認
ユーザー単位の価格で複数ドメインの予算が難しい	月額 $3.50 からの価格目安で、共有ストレージの定額プランを提供

TrekMail は DMARC 分析ツールではありません。プランに応じて独自ドメイン、IMAP メールボックス、キャッチオール、転送、IMAP 移行、持ち込みか管理型 SMTP を提供します。管理を簡単にできる場合はありますが、レポート分析は別に必要です。

有料プランの価格目安は月額 $3.50 からです。Nano は無料でカード不要の選択肢として提供されています。有料プランは 14 日間の試用を提供する場合があり、クレジットカードが必要です。最新の価格、機能、条件を確認してください。