レポートは、まず観測結果を伝えるもの
件名に「Report domain」とあるメールは、必ずしも障害通知ではありません。受信側のメール事業者が、一定期間に観測した、あなたの送信者ドメインを使用するメールを集計しています。すべてが正常な場合もあります。アカウント侵害の確認通知でも、特定のメールが届かなかったことを示すバウンスメールでもありません。
集計レポートは、DMARCレコードのruaで指定した宛先に送るよう要求されます。実データはXMLの添付ファイルに入り、多くの場合は圧縮されています。本文が空でも、レポートが使えないわけではありません。一方、見慣れた差出人名だけで本物とも判断できません。管理された手順でファイルを処理します。 [1] [3]
件数を数える前に、期間を確認する
最初にreport_metadataを見ます。報告元は誰か、report_idは何か、date_rangeが示すUTCの期間はいつかを確認し、次にpolicy_publishedのドメインを調べます。受信日時は集計対象期間とは別です。countは、該当する認証結果の組み合わせで集計されたメール数であり、顧客数、人数、セキュリティ事故数ではありません。
複数のファイルを集める場合は、再現できる集計ルールが必要です。報告元、ドメイン、レポートID、期間、内容を照合し、同一レポートの再送で件数を増やさないようにします。期間が部分的に重なる場合、重複分を正確に差し引けるとは限りません。その制約を明記し、見かけだけ精密な合計値を示さないことが大切です。 [1]
SPFの成功とDMARCの成功は同じではない
auth_resultsはSPFとDKIMそれぞれの認証結果です。policy_evaluatedは、それらをDMARCとして評価した結果で、ドメインのアライメントも含みます。表示上の差出人ドメインを示すheader_fromと比較してください。配信事業者のドメインで認証に成功しても、表示上の送信者ドメインとの必要な関係がなければ十分ではありません。
SPFかDKIMの少なくとも一方が認証に成功し、表示上のFromドメインと整合していればDMARCは成功します。そのため、SPFが失敗しても、有効で整合したDKIM署名によってDMARCが成功する場合があります。一通に複数のDKIM署名があり、結果が異なることもあります。一つの「fail」だけで全体を判断せず、成功して整合した識別子を確認します。 [1] [2]
対象を確定する
報告元、ドメイン、期間、レポートIDを確認し、重複したコピーを除外する。
送信経路を特定する
送信元、SPF/DKIMの結果、アライメントを、承認済みの送信サービス一覧と照合する。
差異を調べる
正規の送信エラーを修正するか、不明な送信元を調査するか、確認結果を記録する。
証拠を伴う判断を残す
担当者、確認した送信経路、次回の確認日を記録します。実際の配信は別途確認します。
実際のメールや顧客データを含まない確認手順の模式図です。DMARCの結果と配信の証拠は別々に扱います。
よくある結果の組み合わせを読む
次の表はpolicy_evaluated内のSPFとDKIMを対象とし、auth_resultsの生の結果を対象にしていません。結果を読み解くための表であり、特定サービスの送信許可やメール本文の信頼性を証明するものではありません。 [1] [2]
表は左右にスクロールできます。
| 報告された結果 | 読み取り方 | 次の確認 |
|---|---|---|
| SPF pass、DKIM pass | 両方の経路がDMARC評価に成功。 | 送信元を承認済みの送信サービスに対応付ける。 |
| SPF fail、DKIM pass | DKIMによってDMARCに成功。 | SPFの差異や転送の影響を別途調べる。 |
| SPF pass、DKIM fail | SPFによってDMARCに成功。 | DKIMを調べる。SPFだけでは転送の影響を受けやすい。 |
| SPF fail、DKIM fail | 成功して整合した認証経路がない。 | 正規サービスの設定不備、転送、不正使用を区別する。 |
| 結果が欠落・読み取り不能 | そのレコードでは確実に判断できない。 | 形式と処理を確認する。失敗ゼロとは数えない。 |
未知のIPアドレスは、まず送信元を確かめる
事業者名やデータセンターの所在地だけでは、誰が送信を開始したかは分かりません。共用のメール基盤は、多くの顧客のメールを送信する場合があります。実際に承認しているサービスと照合してください。通常のメールボックス、Webフォーム、請求書システム、サポートシステム、メールマガジンは、それぞれ別に一覧化します。
ドメイン、DKIMセレクター、送信ログ、管理された条件で受信したメールが、経路を特定する手掛かりになります。警告を消すために未知のIPアドレスをSPFへ追加しないでください。先に送信許可を確認します。正規サービスの不具合なら、修正担当者と再確認に必要な証拠を決めます。Webメールの送信テスト成功だけでは、Webフォームの設定も正しいとは言えません。 [2] [4]
「none」は受信トレイへの到着を意味しない
dispositionはDMARC評価において報告された扱いを示します。noneは配信証明ではなく、quarantineも個別のメールが最終的にどのフォルダーに入ったかを確実には示しません。受信側は他のルールも適用できます。DMARCが成功しても、受信トレイへの到着や内容の信頼性は保証されません。特定の未着メールは、送信ログ、バウンス通知、可能なら受信した原本で調べます。
さらに、レポートが示すのは、報告を行ったシステムから見えた指定期間の情報だけです。レポートの欠落やデータの空白は、送信ゼロや不正使用ゼロを意味しません。欠落を記録してください。傾向を比較する際は、同じ報告元と同じ長さの期間を使い、対象範囲が変わっていないか確認します。 [1] [4]
結果を担当者のいる対応項目にする
承認済みで業務上重要な送信経路がDMARCに失敗する場合や、結果が予期せず変わる場合は対応が必要です。繰り返し現れる未知の送信元も特定します。対応は証拠に基づいて選び、DNSポリシーを自動的に強めたり弱めたりするものではありません。変更前に正規の送信経路を把握して検証し、既知の認証不備を修正します。 [2]
- 報告元、ドメイン、UTC期間、重複レポートを確認する。
- SPF/DKIMの生の結果とDMARCアライメントを区別する。
- 想定外の送信元をサービスと担当者に対応付ける。
- 許可したテストメール、関連ヘッダー、送信ログを確認する。
- 修正内容、変更時間帯、切り戻し手順を決める。
- 変更後は認証と実際の配信をそれぞれ確認する。