メール転送とは？その仕組みとベストプラクティス

メールの転送は、配信失敗の最も一般的な原因の一つですが、多くのドメイン管理者は、何か問題が発生しているという明確な兆候を捉えられていません。転送処理によってメッセージデータが変更され、最新の認証プロトコルが機能しなくなることがありますが、この事実はしばしば見過ごされてしまいます。データが一致しなくなるため、受信サーバーは転送されたメールを不審なものとして扱い、スパムフォルダに振り分けたり、あるいは完全にブロックしたりすることがよくあります。

メール転送とは何ですか？

メール転送とは、あるアドレス宛てに届いたメールを別のアドレスに転送するサーバー側の処理です。この処理はメールサーバー上で行われるため、送信者には一切気づかれることなく、受信者側でも手動での操作は一切必要ありません。 

しかし、その前に、手動によるメール転送と自動メール転送の違いについて確認しておきましょう。 混乱を避けるために、 どこで と いつ 転送が行われるかを確認すると、混乱を解消するのに役立ちます：

• 手動でのメール転送： これは メールが メールが受信トレイに届いた後に発生します。メールを開き、「転送」をクリックし、新しい受信者のアドレスを入力して送信します。メール1通ごとに手動での操作が必要です。
• メールの自動転送： これは 一度設定すれば後は放っておける ルールです。一度設定すれば（メールの設定画面かサーバー上で）、受信したメッセージはあなたが目にする前に、システムが即座に別のアドレスへ転送します。

組織では、以下のような一般的なケースでメールの自動転送を利用しています： 

• ドメインエイリアス: 一般的なビジネス用メールアドレスから、従業員の個人用受信箱へ直接転送する機能。
• 自動転送ルール: メールを別のアカウントに転送するための、ユーザーレベルまたはシステムレベルのフィルタを作成します。 
• メーリングリスト: 受信した1通のメッセージを、多数の購読者に対して一度に配信すること。 
• サードパーティ経由のルーティング: トランザクションログやサポートチケットを外部システムに送信し、処理を行うこと。 

メールの転送とリダイレクト

一般にこの2つの用語は同じ意味で使われることが多いですが、メールサーバーにとっては異なる意味を持ちます。 

メールが転送されると、メールサーバーは実質的にそのメッセージを複製し、新たなトランザクションを開始します。サーバーはメールに独自のバックグラウンドルーティング情報を付加しますが、受信トレイに表示される「差出人」欄には元の差出人の名前がそのまま表示されます。この違いこそが、受信サーバーに不審感を抱かせる原因となっています。 

真のリダイレクトは、より受動的な処理です。メッセージを再構築するのではなく、サーバーはバックグラウンドのエンベロープや送信プロパティを変更することなく、元のメールを新しい宛先にそのまま転送します。受信サーバーから見れば、リダイレクトされたメールは、元の送信者の受信トレイから直接自分の受信トレイに届いたかのように見えます。仲介者は存在せず、データも変更されておらず、認証も破られていません。 

一目でわかる：転送とリダイレクトの違い

メールの転送はどのように機能するのでしょうか？

メッセージがインターネット上をどのように伝送されるかについて、順を追って説明します： 

• ステップ1：元の送信者が、受信者の初期メールサーバーにメールを送信します。 
• ステップ2：元のサーバーは受信メッセージを受け取り、一連の転送ルールに基づいてそのメッセージを確認します。 
• ステップ3：転送仲介サーバーは、メッセージを最終的な宛先サーバーに送信するために新しい接続を開始し、トラフィックを自身のシステムとIPアドレスを経由してルーティングします。 
• ステップ4：宛先サーバーは、予期しない中間IPアドレスからメッセージを受信する。 

対立 

この過程において、3つの大きな変化が起こります： 

1. 接続元の送信元IPアドレスは、転送サーバーのIPアドレスに変更され、 
2. 「From」ヘッダーは元の送信者のドメインと同じままとなり、 
3. メッセージ本文やヘッダーは、メーリングリストのフッターや中継ヘッダーを追加するなどして変更される場合があります。 

こうした構造的な変更により、メールの認証が機能しなくなります。 

メールの転送が認証に与える影響

メールの自動転送が行われると、メール認証プロトコルによるメッセージの検証方法に影響を与える変更が生じます。 

SPF (Sender Policy Framework) 

SPFは、エンベロープ送信者のReturn-Pathに記載されているドメインのDNSレコードに、接続元のサーバーのIPアドレスが記載されているかどうかを確認することで、受信メールを検証します。 

• 問題点は何か？メールが転送されると、転送を行う中継サーバーはメッセージを送信するために新たな接続を確立し、そのトラフィックを自身のインフラストラクチャとIPアドレスを経由してルーティングする。 
• その結果はどうなるか？転送サーバーのIPアドレスが元の送信者のSPFレコードに記載されていないため、最終的な宛先でエンベロープ送信者の検証に失敗します。したがって、転送時にはほぼ必ずSPF検証に失敗することになります。 

DKIM (DomainKeys Identified Mail) 

DKIMは、ドメインに関連付けられた暗号署名を使用して、メッセージの内容が送信中に改ざんされていないことを確認します。 

• 問題点は何か？通常、中間サーバーがメッセージを受動的に転送するだけの場合、この暗号署名は基本的な転送を経ても変更されることなく維持されます。しかし、転送サーバーがメッセージ本文を変更したり、トラッキングピクセルやヘッダーを追加したりすると、元のデータが変更されてしまいます。 
• その結果は？コンテンツが変更されると、DKIM署名が一致しなくなり、認証が完全に無効になります。 

DMARC 

DMARCは、電子メールが認証を通過するためにSPFアラインメントまたはDKIMアラインメントのいずれかを満たすことを求めるポリシー層として機能します。 

• 問題点は何か？転送行為そのものがSPFを無効にしてしまうため、メールがDMARCを通過するにはDKIMに依存することになります。もし転送の中継サーバーがメッセージ本文やヘッダーも変更してしまうと、SPFだけでなくDKIMも失敗してしまいます。 
• その結果はどうなるか？両方のプロトコルが失敗すると、必然的にDMARCの検証も失敗します。元の送信者のドメインに厳格なDMARCポリシー（p=reject）が設定されている場合、正当な転送メールは受信サーバーによってブロックされてしまいます。

転送技術の進化：ARCからDKIM2へ

従来の電子メール認証において、転送によって生じる根本的な欠陥を解決するため、インターネットコミュニティは当初、 ARC（Authenticated Received Chain） を考案し、中継者がメッセージを暗号的に保証できるようにしました。

ARCとは？

簡単に言えば、ARCは一連の公証人の印鑑のような役割を果たす電子メールプロトコルです。電子メールが転送の中継サーバー（メーリングリストや自動転送設定された受信箱など）を経由する際、各サーバーがメッセージに暗号署名を行い、その元の認証結果を保証します。これにより、最終的に受信するサーバーは、検証済みのチェーンを遡って確認することで、その電子メールが転送される前に正当なものであったことを確認することができます。

DKIM2への移行

しかし、電子メールのセキュリティ環境は変化しつつある。 2026年5月17日付のIETFドラフト（draft-ietf-dkim-dkim2-spec-02）によると、業界は現在、 DKIM2への移行を積極的に進めている。

ARCの運用上の教訓がこの、より洗練されたネイティブなソリューションに組み込まれているため、2026年4月に別途提出されたIETFドラフトでは、ARCを 歴史的標準として正式に再分類することが提案されている。

DKIM2が転送問題をネイティブに解決する方法

ARCは実験的な回避策として機能していましたが、DKIM2はプロトコルのコア部分で、転送時の不具合を直接修正します。メーリングリストや転送サーバーがメールの内容を変更した場合、DKIM2は順序付けられた 管理の連鎖 を構築することで処理します。

各中継システムは、そのシステム固有の変更内容を記録し、独自の署名を付加します。これにより、受信サーバーは認証の連鎖を途切れさせることなく、メールを元の送信者までシームレスに追跡することができます。

2026年5月のアップデートにおける主な改良点：

• 除外されたヘッダー: Authentication-Results ヘッダーは、メールが境界を越える際に不必要な検証エラーが発生するのを防ぐため、署名対象から除外されるようになりました。
• より厳格な制御フラグ： 送信者は強化された donotmodify および donotexplode フラグを使用して、メッセージの不正な改変や分割ルーティングを防ぐことができます。
• 簡潔なコード： 仕様書から不要な z bodyレシピ を削除し、互換性のある実装の構築方法を簡素化します。

重要なお知らせ： DKIM2は現在もIETFのドラフト段階にあり、まだ正式に公開されていません。この仕様は、最終的なインターネット標準として正式に公開される前に、さらなる技術的な変更や改良が行われる見込みです。 

メール転送のベストプラクティス

ドメイン管理者が遵守すべき、メール転送に関するベストプラクティスは以下の通りです：

• DKIMの整合性を優先する： DKIMを主な整合性確認方法として使用してください。SPFは転送時に失敗する可能性が高いことから、有効で改変されていないDKIM署名は、DMARC検証を通過するための最善の防御策となることがよくあります。 
• 緩和された正規化の設定: メールサーバーのDKIM正規化を「c=relaxed/relaxed」に設定してください。これにより、転送中に空白やヘッダーの大文字小文字にわずかな変更が生じても、暗号署名が破損することはありません。  
• 既存のARCを維持する（ただしDKIM2への移行を検討する）： 社内のメールインフラですでに ARCプロトコル署名を利用している場合は、レガシーゲートウェイへの対応のため、これを有効に維持してください。ただし、新しいARCのエンジニアリングに多額の投資を行うべきではありません。最新の2026年版IETFドラフトによると、ARCの運用上の知見がDKIM2に組み込まれているため、ARCは将来的に「歴史的標準」として再分類される可能性があります。
• 信頼できる 信頼済みARCシーラー（現時点では）：Microsoft 365環境では、引き続き、既知の信頼できる転送仲介者を手動で 「信頼できる ARC シーラー」 リストに手動で追加し続けてください。これにより、業界がDKIM2へ移行する間も、正当な転送メールが破棄されるのを防ぐことができます。
• DMARC集計レポートの確認： 集計XMLデータを確認し、SPFのみの整合性問題として転送失敗が発生している箇所を特定してください。これらのレポートを使用して、転送が配信率に与える正確な影響を特定し、測定します。 DMARCポリシーのオーバーライド を確認することで、受信ネットワークがこれらの通信フローをどのように扱っているかを把握するのに役立ちます。
• 共有メールボックスへの移行： 内部ルーティングについては、受信トレイの自動転送ルールではなく、共有メールボックスの使用を検討してください。共有メールボックスを使用すると、複数のユーザーが同じメールストリームに直接アクセスできるため、サーバー間転送によって生じる認証の問題を回避できます。  
• ポリシーを段階的に適用する： アクティブな転送パスがある場合は、p=none から開始してください。モニタリングレポートを通じて転送されたトラフィックを確認した後、ポリシーをより厳格なレベル（p=quarantine または p=reject）に変更してください。 

当社の包括的な メール転送ガイド をご覧いただくか、 Google ARC送信者ガイドライン をご確認いただき、設定が現在の業界標準に準拠しているかご確認ください。

メール転送の種類

転送のさまざまな処理レベルを理解することで、認証の問題がどこで発生しているのかを特定しやすくなります。 

サーバーレベルでの転送

このタイプは、メール転送エージェント（MTA）または企業のメールサーバーレベルで設定され、特定のドメイン条件を満たすすべての受信メッセージに対してグローバルなルーティングルールを適用します。これは受信と同時に即座に実行され、企業のエイリアスに対して非常に効率的です。 

クライアントレベル転送

これは、GmailやOutlookなどのメールクライアント内で、各ユーザーが設定する機能です。ユーザーが定義した受信トレイのルールやフィルターを利用して、受信したメッセージを外部アカウント、個人用アカウント、またはサブアカウントに転送します。 

ドメインエイリアス

ドメイン全体または特定のアドレスから送信されるすべての受信トラフィックを、別の宛先受信箱に自動的に転送する仕組みです。これは、企業環境において、対外的なイメージをクリーンに保つために一般的に利用されています。 

メーリング・リスト

単一の中央アドレスに送信されたメールが、自動的に多数の個々の購読者に転送される配信システム。メーリングリストは、DKIM認証に失敗するリスクが最も高い。 

GmailとOutlookでのメール転送

GmailとMicrosoft 365は、それぞれ異なるクラウド基盤を用いてメール転送機能を実現しています。

Gmailでのメールの自動転送

Gmailでメールを転送する方法は以下の通りです：

手順 1：設定を開く

[ギア]アイコンをクリックしてください Gmailの右上にある をクリックし、 「すべての設定を表示」をクリックし、 「転送とPOP/IMAP」 」タブに移動します。

ステップ2：新しい住所を登録する

1. クリック 「転送先アドレスを追加」をクリックし をクリックし、転送先のメールアドレスを入力してください。
2. その受信トレイに移動し、Googleからの確認メールを開いて、確認リンクをクリックしてください。

ステップ3：転送方法を選択する

• すべてを転送するには： チェック 「受信メールのコピーを…に転送する」を選択し、元の受信トレイにコピーを残すか削除するかを決めて、 下部の をクリックします。
• 特定のメールを転送するには： [ここ]をクリック 「フィルターを作成」をクリック をクリックし（または検索バーのドロップダウンを使用）、条件（特定の送信者など）を設定し、 「転送先」」にチェックを入れ、 「フィルターを作成」をクリックします。

舞台裏では何が起きているのか？

Googleがメッセージを転送する場合、自社のサーバーを経由して送信します。これが最終的な受信先のメールセキュリティにどのような影響を与えるか、以下に説明します：

• SPFの検証は失敗する可能性が高いです： メールが本来の送信者ではなくGoogleのサーバーから送信されているため、通常のSPFチェックは通常失敗します。
• 通常、DKIMは通過します： Gmailはメール本文を一切変更しないため、元の送信者のDKIM署名はそのまま維持されます。
• Gmailは（現時点では）転送メールに自動的にARCヘッダーを追加します。これにより、SPF検証に失敗した場合でも、受信サーバーがそのメールが正当なものであることを確認できるようになります。

ワークスペース管理者のためのちょっとしたヒント： 以下の項目を常に確認してください DMARC集計レポート を常に確認し、転送によって引き起こされるSPFの問題を追跡・管理してください。

Outlook / Microsoft 365 でのメール転送

Microsoft 365 (M365) では、幅広いメールルーティングオプションが提供されていますが、メールセキュリティフィルターとの連携を適切に設定するには、入念な設定作業が必要です。

1. M365のメール転送の種類

管理者とユーザーは、以下の3つの異なる方法で転送を設定できます：

• 受信トレイのルール： Outlook内で作成される、ユーザーごとのルール。
• 転送ルール： Exchange Online で設定された、詳細な管理者レベルのルール。
• SMTPメールボックスの転送： 特定のメールボックスに適用される、シンプルメール転送プロトコル（SMTP）による転送設定。

2. 認証の問題：SPFおよびARCの失敗

転送はメールの経路を変更するため、その性質上、標準的なメール認証プロトコルと矛盾します：

• SPFの失敗： 転送中に、接続元のIPアドレスがMicrosoftのネットワークに変更されます。その結果、最終的な宛先では、元の送信者のSender Policy Framework（SPF）チェックに失敗します。
• ARCヘッダーのデフォルト設定： デフォルトでは、M365の転送ルールは、メッセージの履歴を検証するために、転送される送信メールにAuthenticated Received Chain (ARC) ヘッダーを追加します。
• 結果： ARCヘッダーがあるにもかかわらず、IPアドレスの変更により、しばしば 受信側のMicrosoftテナントにおいて というステータスのエラーが発生することがあります。

3. 行政上の解決策と政策

メールの配信成功率を確保し、セキュリティによるブロックを防ぐため、企業向けM365の管理者は以下の2つの重要な設定を管理する必要があります：

• 信頼できるARCシーラーの定義： 管理者は、配信率を向上させるために、Microsoft Defender ポータルで信頼できる外部仲介業者を「信頼できる ARC シーラー」として明示的に登録する必要があります。
• 外部転送を許可する: Microsoft では、新しいテナントにおいて、デフォルトで外部への自動転送をブロックするグローバルなセキュリティポリシーが適用されています。このセキュリティ対策のため、管理者が外部への転送を明示的に許可するまで、ユーザーが作成した転送ルールはエラー表示なしに失敗します。

まとめ

インターネットの基本的なセキュリティツールは、サーバー間を転送されるメッセージを想定して設計されたものではありません。あるサーバーが別のサーバーにメールを転送すると、送信元のIPアドレスが変更され、SPFによる保護が無効になります。

しかし、セキュリティを強化するためにメールのルーティング機能を犠牲にする必要はありません。堅牢なDKIM設定とARCプロトコルを活用すれば、転送されたメールが確実に宛先の受信箱に届くようにすることができます。 

PowerDMARC を使えば、メール転送の設定全体を一目で確認できます。当社のプラットフォームでは、DMARCの集計データの追跡、複雑なメールエイリアスの問題の管理、そしてネットワーク全体での完璧な送信側ARC署名の実装が可能です。 

メールが届いているかどうか、もう推測する必要はありません。 今すぐ 今すぐPowerDMARCの無料トライアルに登録して、メールの送受信を最初から最後まで確実に保護しましょう。

よくあるご質問 

メールの転送はSPFを無効にしますか？ 

はい。SPFは、送信サーバーのIPアドレスが、送信者のDNSレコードに登録されている許可されたIPアドレスと一致するかどうかを確認します。転送ではメッセージが中継サーバーを経由して送信されるため、接続情報は元の送信者のSPFレコードと一致しません。したがって、チェックは失敗します！ 

メールの転送はDKIMを無効にしますか？ 

従来のDKIMでは、メーリングリストや中継サーバーがメール本文を変更したり、フッターを追加したり、ヘッダーを修正したりすると、転送が機能しなくなります。暗号ハッシュが変更されるため、元の署名が無効になり、DMARCの検証に失敗する原因となります。2026年5月17日付のIETFドラフトによると、今後導入されるDKIM2では、組み込みの「チェーン・オブ・カスターディ（Chain of Custody）」を確立することで、転送に対応する予定です。

認証を破るのではなく、メールを扱う各システムは、その変更内容を記録し、独自の署名を付加します。これにより、受信サーバーはメッセージを元の送信者までシームレスに追跡することができます。

転送したメールがなぜスパムフォルダに入ってしまうのですか？ 

転送されたメールは、送信元IPアドレスの変更によりSPF検証に失敗するため、スパムフォルダに振り分けられることがよくあります。この失敗が原因で下流のDMARC認証が失敗すると、受信メールシステムは受信メッセージを「認証されていない」または「なりすまし」としてマークします。 

メールの転送とメールのリダイレクトの違いは何ですか？ 

メールの転送では、新しいIPアドレスを持つ中継サーバーを経由させることでメールの送信経路を変更しますが、ヘッダーに表示される送信者情報は元のまま維持されます。一方、メールのリダイレクトでは、エンベロープの送信者プロパティを変更したり、認証の整合性を損なったりすることなく、元のメッセージを直接別のアドレスに送信するようシステムに指示します。 

メールの転送は安全ですか？ 

標準的なメール転送では、元のメッセージのルーティングヘッダーがサードパーティのシステムに公開されてしまうため、追跡が困難になり、SPFやDMARCなどの認証プロトコルが機能しなくなります。そのため、ARCのような保護策が適切に設定されていない場合、悪意のある攻撃者が整合性のないデータストリームを悪用しやすくなります。

• について
• 最新記事

Ahona Rudra

ドメインとメールセキュリティのエキスパートPowerDMARC

AhonaはPowerDMARCのマーケティングマネージャーで、サイバーセキュリティのトピックについて5年以上の執筆経験があり、ドメインと電子メールのセキュリティを専門としている。ジャーナリズムとコミュニケーションの卒業後学位を取得し、2019年からセキュリティ分野でキャリアを固めている。

最新記事 by Ahona Rudra(全て見る)

• 人事部門のメールおよび給与計算のセキュリティ：グローバルチームのためのベストプラクティス - 2026年6月22日
• Microsoft Entra でリスクの高い AI エージェントをブロックする方法 - 2026年6月15日
• Office 365 フィッシング対策ポリシー：設定方法 - 2026年6月3日