DMARCレコードを公開しても、メール運用の状態が自動的に分かるわけではありません。DMARCは、受信側が送信メッセージのFromドメインとSPFまたはDKIMで認証された識別子の整合を評価し、結果をドメイン所有者へ報告する仕組みです。レポートを読むと、正規の請求書サービス、マーケティングツール、採用システム、問い合わせフォーム、転送経路が同じドメインから送信していることを発見できます。反対に、見覚えのない送信元があっても、それだけで攻撃と断定はできません。観測、照合、修正、再観測の順番を決めることが、配信事故を避けながらポリシーを強める近道です。
2026年の仕様を前提に用語をそろえる
2026年5月にIETFのRFC 9989が公開され、従来のRFC 7489を置き換えるDMARCの仕様として整理されました。集計レポートはRFC 9990、失敗レポートはRFC 9991で扱われます。実務では受信側やメールサービスが異なる仕様世代をまたいで動作するため、レポートに含まれるフィールドを固定的に決めつけず、現行仕様とサービスの説明を照合してください。DMARCのpassはメッセージの内容が安全だという意味ではなく、Fromドメインの利用と認証識別子の整合に関する結果です。送信者の身元、マルウェアの有無、利用者の意図まで証明するものではありません。
レポートを受け取る前にDNSを確認する
最初に、対象ドメインの_dmarcレコードを確認します。v=DMARC1があり、pの値がnone、quarantine、rejectのどれか、ruaが意図した集計レポート先を示しているかを確認してください。ruaの宛先が別ドメインの場合は、受信側が外部レポートを送ってよいことを示す承認レコードが必要になることがあります。DNSの検索結果が空、古い、複数のTXTに分かれているといった状態を記録し、文字列を手作業で継ぎ足して解釈しないことが重要です。レポートが届かない原因は、ポリシーの構文、宛先の承認、受信側の対応、メールボックスの容量など複数あり得ます。
_dmarc.example.jp. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"集計レポートで最初に見る列
XMLの集計レポートを開いたら、まずレポート期間、提出者、対象ドメイン、ポリシー、source_ip、件数を確認します。次に、そのIPや送信元を自社のメールサービス、SaaS、外部委託先、社内アプリの台帳と照合します。policy_evaluatedのdisposition、dkim、spfは、それぞれ受信側がどのポリシーを適用したか、DKIMとSPFがDMARCの整合を満たしたかを考える手掛かりです。認証そのものがpassでも、Fromドメインと認証ドメインが整合しなければDMARCのpassにならない場合があります。合計件数だけでなく、送信元ごとの比率と時間変化を残してください。
- レポート期間、提出者、対象ドメイン
- 送信元IPとメッセージ件数
- FromドメインとSPFの認証ドメイン
- DKIMのd値とセレクター、署名結果
- SPFとDKIMの整合モードおよびDMARC結果
- 適用されたポリシーと確認時刻
未知の送信元を安全に分類する
未知のsource_ipを見つけたときは、直ちにブロック対象の一覧へ入れません。まず逆引きや登録情報だけで組織を断定せず、送信サービスの契約台帳、メールヘッダー、アプリケーションの設定、委託先の説明と照合します。転送サービスやメーリングリストは、正規メールでも元のSPF整合を壊すことがあります。DKIMのd値が自社ドメインで署名され、Fromとの整合も取れているなら、SPFだけの失敗とは意味が異なります。正規と確認できない送信元は、正規化、修正依頼、監視継続、未確認のままという状態を明示し、悪意というラベルを証拠なしで付けないでください。
SPF失敗とDKIM失敗を切り分ける
SPFの失敗は、送信元IPが公開SPFにない、転送で送信元が変わった、SPFの参照上限や構文に問題がある、といった原因で起きます。DKIMの失敗は、署名がない、署名後に本文やヘッダーが変更された、公開鍵が見つからない、セレクターを間違えた、といった原因を分けて調べます。両方が失敗したからといって、すぐに正規サービスを停止するのではなく、実際のメールを一通取り出してAuthentication-Results、From、Return-Path、DKIM署名を確認します。メール本文に含まれる個人情報や機密情報をレポートへ広げないよう、共有時は最小限の項目に絞ります。
p=noneから強制適用へ進む条件
p=noneは保護がないというより、受信側の扱いを変更せず観測を続ける段階です。強制適用へ進む前に、正規の送信元が台帳に登録され、主要な受信者からレポートが届き、SPFまたはDKIMのどちらかがFromドメインと整合していることを確認します。新しい送信サービス、キャンペーン、請求システムの開始が近いなら、先にテスト送信を行います。quarantineやrejectへ変更する場合も、全体を一度に切り替えるか、対象の範囲を限定するか、誤配信時に戻す担当者と手順を決めます。数値目標を一律に置くより、失敗する正規メールの種類と事業影響を説明できることが大切です。
集計レポートのカバー率にも限界があります。すべての受信者が報告するとは限らず、同じ送信元が複数の提出者に分かれて見えることもあります。レポートが少ないことを、失敗がない証拠とは扱いません。観測期間、対象となるメール量、未報告の可能性を判断記録に残し、ポリシー変更後も失敗件数と正規メールの苦情やバウンスを別の指標で追います。
複数ドメインとサブドメインを管理する
企業では、ブランドのルートドメイン、送信用サブドメイン、採用サイト、請求書専用ドメイン、買収した会社の旧ドメインが並行します。組織ドメインのポリシーがサブドメインへどう影響するかを確認し、例外がある場合は所有者と期限を台帳に書きます。ドメインごとにruaの宛先、送信元、担当者、現在のp、最終確認日時をそろえると、設定漏れを発見しやすくなります。DNS検索とメールセキュリティチェックで公開状態を確認し、SPFやDKIMのセレクター変更も同じ案件に記録してください。
{
"domain": "example.jp",
"source": "198.51.100.20",
"count": 1250,
"spf": "fail",
"dkim": "pass",
"alignment": "pass",
"classification": "authorized_service",
"next_action": "confirm_sender_owner"
}ドメイン数や送信元が増えると、メールボックスに届くXMLを人が毎日読む運用は続きません。レポートを取り込む場合は、送信元の正規化、重複排除、期間集計、未知、認証失敗、変更、確認済みという状態を保持します。自動処理はp=rejectへの変更を勝手に実行するのではなく、担当者が確認すべき差分を通知する役割に限定します。DomScanのDMARCビルダー、メールセキュリティチェック、SPFビルダー、DKIMディスカバリーを組み合わせて公開設定を確認し、DNS検索の結果とレポートの観測を同じドメインに結び付けると、設定と実際の送信の差を追いやすくなります。
DMARC分析の成果は、pass率を高く見せることではありません。どの正規サービスがどの認証を使い、どの送信元が未確認で、どの修正が終わり、どの不確実性が残っているかを説明できることです。レポートの形式や受信者の対応は変わるため、仕様書と実際のデータを定期的に見直してください。メール移行、DNS変更、委託先追加のたびに短い再確認を行えば、強制適用後の配信事故を小さくできます。