RFC 9989は2026年5月に公開されたDMARCの新しい標準で、RFC 7489に取って代わるものです。これは標準の更新であり、利用者が設定済みのエイリアスや転送先を一律に変更する指示ではありません。メールが届いたか、認証結果がどこで変わったか、受信側がどう分類したかを確認してから対応を決めてください。
この記事は、エイリアスや転送先で購読メール・サイト通知を受け取る個人利用者向けです。
顧客や案件ごとにメールを振り分けるフリーランスの方は、発信元と転送経路のどちらを調べるべきか判断できます。
独自ドメインや転送経路を管理する担当者は、認証結果に基づいて確認先を切り分けられます。
最終更新日：2026年11月2日。RFCの現行情報はRFC EditorのRFC 9989およびRFC 7960、転送に関する受信サービスの案内はGoogleのメール転送に関する公式ガイダンスを基に確認しています。
まず「届かない」と「迷惑メールに入った」を分けます
対象のメールが迷惑メールフォルダーにあるなら、少なくとも受信側には到達しており、主な問題は分類です。一方、見つからない場合は、受信箱だけでなく迷惑メール、隔離領域、すべてのメールの検索結果を調べ、転送前の宛先にも届いているか確認します。
確認対象は一通に絞ると、後の比較が容易です。送信者、受信日時、エイリアスの宛先を記録し、同じ送信者の別メールや別経路のメールと取り違えないようにします。顧客からの連絡なら、送信者に再送を依頼する前に、対象の一通が隔離されていないかも確認してください。
認証結果はヘッダー単位で読みます
メールの原文表示を開き、Authentication-Resultsを探します。このフィールドの形式や意味はRFC 8601で定められています。そこに記載されたSPF、DKIM、DMARCの結果を、それぞれ別に記録してください。
SPFは受信サーバーから見た送信元の経路を評価するため、転送で経路が変わると、転送後に失敗する場合があります。転送されたメールのSPF失敗だけでは、元の送信者が不正だとは判断できません。DMARCはSPFまたはDKIMの結果だけでなく、認証されたドメインとFromのドメインとの整合性も含めて判定されます。DKIMが成功していてもドメインが整合しない場合は、DMARCが失敗することがあります。
Googleの認証結果を確認する公式手順を参考に、各結果とドメインを一緒に確認します。ヘッダーに複数の認証結果があるときは、付与した受信サーバーも見比べ、転送前の評価と転送後の評価を混同しないことが重要です。
署名が転送中に変わった可能性を調べます
DKIMはメールの内容や署名対象のヘッダーを検証します。転送処理が件名や本文、署名対象のヘッダーを書き換えると、転送後のDKIM検証に影響する可能性があります。間接メール経路の相互運用上の問題はRFC 7960が扱っていますが、特定の転送方式なら必ず失敗するという意味ではありません。
同じメールについて、転送前の受信先で確認できる認証結果と、転送後のメールヘッダーを分けて比べます。転送前はDKIMが成功し、転送後だけ失敗している場合は、転送時の変更や経路を管理する側への確認が候補になります。転送前の情報を取得できない場合は、受信側の一通だけから原因を断定せず、転送担当者や送信者にヘッダー情報を共有して確認します。
Googleも転送がメール認証に影響し得ることを案内し、転送処理でDKIMを損なわないための注意点を示しています。ただし、その案内は特定の受信環境における管理上の助言です。すべての転送サービスやメールが同じ結果になるとは限らないため、個別のヘッダー結果を優先してください。
よくある疑問
新しいDMARC標準に合わせて、既存の転送設定も変更すべきですか？
標準の公開だけを根拠に、エイリアス、転送先、独自ドメインのポリシーをまとめて変更する必要はありません。RFC 9989はDMARCの標準を更新したものですが、特定の利用者に個別の転送設定変更を求めるものではありません。問題が見つかったメールの認証結果を確認し、実際の故障箇所が分かるまで設定変更を保留してください。
SPFが失敗してDKIMが成功したら、送信者へ連絡すべきですか？
まずDKIMの署名ドメインがFromのドメインと整合しているかを確認します。整合していてDMARCも成功しているなら、SPFの失敗だけを理由に送信者へ設定変更を求める必要はありません。DMARCも失敗している場合は、転送前後の結果を照合し、元メールの認証問題なのか、転送後の変更なのかを確認してから担当先を決めます。
問題の場所に応じて問い合わせ先を変えます
ヘッダーの確認後は、結果に合わせて担当先を選びます。独自ドメインを使っている場合、DNSレコードや送信構成を変更する前に、ドメイン管理者が現在の送信経路と設定を確認してください。一般的な記録値をそのままコピーして追加すると、既存の送信構成に影響するおそれがあります。
- 対象メールを検索し、迷惑メールや隔離領域も調べます。
- 送信者、受信日時、エイリアス宛先を記録します。
- 原文表示で
Authentication-Resultsを探し、SPF、DKIM、DMARCと各ドメインを控えます。 - 可能であれば転送前のメールと転送後のメールを照合し、どの結果が変化したかを確認します。
- 原メールの認証が転送前から異常なら、記録したヘッダーを添えて送信者に確認します。
- 転送後だけ結果が変化した、または内容が書き換わった可能性があれば、転送ルールやドメインを管理する担当者に確認します。
- 認証結果に明確な問題がないのに迷惑メールへ分類される場合は、受信サービスの申告手順や許可リストの仕組みを使います。
| 観察された状態 | 可能性のある問題箇所 | 次に確認する相手・項目 |
|---|---|---|
| 転送前からSPF・DKIM・DMARCに問題がある | 送信側の認証設定や送信経路 | 送信者にヘッダーを共有して確認 |
| 転送後にSPFだけ失敗し、DKIMは成功 | 転送で送信経路が変化した可能性 | DKIMのドメイン整合性とDMARC結果を確認 |
| 転送前は成功し、転送後にDKIMが失敗 | 転送中の内容・ヘッダー変更の可能性 | 転送ルールの管理者に処理内容を確認 |
| 認証結果に問題が見当たらず迷惑メールに分類 | 受信側の分類や送信者評価 | 受信サービスの申告・許可設定を確認 |
継続受信と一時利用を分けて管理します
顧客対応や重要なアカウント通知など、後から返信や長期保管が必要なメールは、転送の有無だけでなく、実際に管理できる受信先を選ぶ必要があります。エイリアスと一時メールの使い分けを検討する場合は、メールエイリアスと一時メールの違いも確認してください。
問題が転送経路にあると分かった場合は、受信先だけを変える前に、どの地点で認証結果が変化したかを担当者と共有します。新規登録の通知など、長期の返信・保管を必要としない用途では、主アドレスを登録フォームに渡さずに済む受信先を分ける方法もあります。登録時にメールアドレスを保護する方法を確認し、用途に合う場合はOrbForwardの一時メールも選択肢に加えると、主アドレスへの不要な通知を抑えやすくなります。銀行、決済、行政手続きなど、本人確認や長期のアカウント回復に使うアドレスは、一時利用と分けて管理してください。
よくある質問
DMARCの新標準が公開されたら、設定済みの転送先も変更が必要ですか？
標準の公開だけを理由に、転送先やドメインのDMARCポリシーを変更する必要はありません。まず対象メールの認証結果と受信場所を確認し、原メール、転送処理、受信側の分類のどこに問題があるかを切り分けてください。
エイリアス経由のメールが迷惑メールに入ったとき、最初に何を確認しますか？
迷惑メールフォルダーだけでなく、隔離領域や受信箱内の検索結果も確認し、メール自体が届いているかを調べます。対象を特定できるよう、送信者、受信日時、宛先を記録してから、そのメールのヘッダーを確認します。
転送後にSPFが失敗し、DKIMが成功している場合はどう判断しますか？
SPFの失敗だけで、送信元の偽装やDMARCの失敗が確定するわけではありません。DKIMの成功に加えて、署名ドメインとFromのドメインが整合しているかを確認します。整合性が確認できても迷惑メールに入る場合は、受信側の分類や送信者の評価も調べます。
メールヘッダーでDMARC、SPF、DKIMの結果を見るにはどうしますか？
対象メールの原文表示からAuthentication-Resultsを探し、同じヘッダー内のSPF、DKIM、DMARCの結果と、それぞれのドメイン情報を記録します。複数の認証結果がある場合は、どの受信サーバーが付けたものかも確認し、転送前後の結果を混同しないようにします。
この登録に合ったアドレスを選ぶ
一度きりの認証コードには一時メール、長く使うアカウントには匿名転送エイリアスを使い、実際のメールアドレスを公開しないようにしましょう。