みなさん、こんにちは。
2025年10月に、GmailのPOPフェッチ廃止に伴う対策について記事を書きました。
その際、POPフェッチ廃止対策として最も現実的な代替策は「自動転送」であること、そしてその運用では迷惑メールと判定されたメールが「ロスト（消失）」するリスクを考慮しなければならないことを説明しました。
もしロストが許容できないのであれば、自動転送時にコピーをサーバーに残し、定期的に外部メーラーからPOP受信して取りこぼしをチェックする「保険」を併用する方法も提案しました。
その後、本家Googleをはじめ多くのテック系記事でも「自動転送」を推奨する内容が増えています。メールロストへの言及が少ないのは少し気になりますが、現実的な選択肢として自動転送が主流になるのは間違いないでしょう。
しかし、単純な転送設定だけでは、銀行などの重要メールが届かないリスクがあることも指摘されています。
参考：Gmail転送の落とし穴：2026年のPOP廃止で何が起きるか(管理者へDMARCでp=reject は 指定してはいけない! gmailに転送できなくなる。)
この問題の核心は「SPF認証」と「DMARCポリシー」です。ここが正しく機能していないと、転送メールはGmailに拒否される可能性が非常に高まります。
前回の記事ではSPF、DKIM、DMARCの設定の重要性に触れましたが、実はそれだけでは不十分なケースがあります。そこで必要になるのが「SRS（Sender Rewriting Scheme）」と「ARC（Authenticated Received Chain）」という技術です。
実は、個人で利用するレンタルサーバーやISP（プロバイダ）では、これら２つの技術のサポート状況がまちまちであり、なおかつ、SPF、DKIM、DMARCと違い、独自に設定できる項目ではないため、個人がサーバーを意図して選ぶ必要があります。
かなり技術寄りの記事になってしまいわかりづらいかもしれませんが、今回は転送を確実に成功させるため、この2つの技術について解説します。
なぜ「ただの転送」ではメールが届かないのか？
メールを転送すると、受信側のGmailから見て「本来の送信元ではないサーバーから送られてきた」状態（SPF失敗）になります。
特に、みずほ銀行、三井住友銀行、ゆうちょ銀行などのドメインは、DMARCポリシーを「p=reject（認証失敗時は拒否）」に設定しているようです。こうした設定があるドメインからのメールは、後述のしくみがないとGmail側で「門前払い」されてしまいます。
救世主その① – 認証の鎖をつなぐ「ARC」
現在、多くの転送トラブルを救っているのが ARC（Authenticated Received Chain） という仕組みです。
ARCの役割とメリット
ARCは、メールが転送経路をたどる際の「認証結果」をヘッダーに保存し、信頼のバトンを繋ぐ仕組みです。
- 転送成功率の向上
転送中にDKIM署名が壊れたり、SPFが失敗したりしても、Gmailは「最初の時点では正当なメールだった」という履歴を確認し、受信を許可してくれます。 - 不達通知が返る
後述するSRSを使わない場合、Return-Path（メールの配送ラベル上の送信元）は書き換わらないため、万が一Gmailが受信を拒否した場合でも、エラー通知は元の送信元へ正しく返ります。
【注目】さくらインターネットなら正式対応！
国内最大手のさくらインターネット（レンタルサーバ）は、このARCに正式対応しています。さくらを利用している方は、転送メールの信頼性が高いと考えて間違いないでしょう。
救世主その② – SPFを強制突破する「SRS」
もう一つの重要な技術が SRS（Sender Rewriting Scheme） です。
SRSの仕組み
SRSは、転送時にメールの「エンベロープFrom（配送ラベル上の送信元アドレス）」を、転送サーバー自身のドメインに書き換えます。
- 効果
Gmail側のSPFチェックを、転送サーバーのドメインで強制的にパス（pass）させることができます。ただし、これを機能させるには前回記事にした通り、自分のドメインのSPF、DKIM、DMARCが適切に設定されている必要があります。 - 対応サーバー
私が普段使用している XREA や hi-ho がSRSに対応していることは確認できました。その他のレンタルサーバーやISPについては各社の仕様を確認するしかありませんが、明記されていないことも多いため、不明な場合はサポートに問い合わせてみるのが確実です。
「SRS」と「ARC」どちらが重要？
結論から言えば、ARCだけでも転送失敗のリスクは大幅に減らせます。
ARCが効いていれば、従来の「転送したら届かない」という問題の多くが解消され、かつ不達通知の経路も維持されるからです。
しかし、理想的なのは、「SRS対応サーバーを使い、かつARCで認証結果を確定させる」組み合わせです。
- SRSでSPFを確実にパスさせる。
- ARCで「もし途中で何かが起きても、このメールは信頼できる」という証拠（封印）を残す。
この二重の守りがあれば、DMARC p=reject の厳しいドメインからのメールも安心して受信できるようになります。
自分の転送状況をヘッダーで確認する
今の設定で正しく「信頼のバトン」が渡されているかは、Gmailの「メッセージの原文を表示」から Authentication-Results で確認できます。
arc=passとなっていれば、Googleがそのメールの転送経路を信頼した証拠です。spf=passのドメインが、自分自身の転送サーバーのものになっていれば、SRSが機能しています。
2026年のメール安定運用のために
メール転送はリレー競技のようなものです。
- SRSは、転送者がルール違反（SPF失敗）にならないよう、自分のドメインのゼッケンに付け替えて走る行為。
- ARCは、転送者が「ここまでの走者は全員正しく走っていた」と記録帳にサイン（封印）する行為。
さくらインターネットのようなARC対応サーバーや、XREAのようなSRS対応サーバーを活用することで、2026年以降も自動転送による安定したメール環境を維持できます。
もし設定に自信がない場合は、転送設定を行った後も、定期的にメールクライアント（ThunderbirdやOutlookなど）によるPOP受信で取りこぼしがないかチェックする「保険」をかけておくことをお勧めします。
まずは確認！
お使いのサーバーからGmailへテストメールを送り、「メッセージのソースを表示」で Authentication-Results を確認してみましょう。これだけで、メール転送の「健康診断」ができるのでぜひ試してみてください。
本日も最後までお読みいただきありがとうございました。
それでは、よいGmailライフを！
